[prev in list] [next in list] [prev in thread] [next in thread]
List: helix-video-dev
Subject: CN: [Video-dev] Porting Head for SymbianMMF target.
From: <rajesh.rathinasamy () nokia ! com>
Date: 2007-12-13 19:01:55
Message-ID: 78988A0C817D8B4F9734DE8EFCEA6F67DC73D8 () daebe104 ! NOE ! Nokia ! com
[Download RAW message or body]
All changes have been checked into head.
Only following changes are checked into 310Atlas
client/common/container/hxplugin.cpp
client/common/util/hxmedpltfmloader.cpp
client/core/hxcleng.cpp
client/core/hxntsrc.cpp
client/core/rtspprotocol.cpp
client/medpltfm/chxmedpltfm.cpp
client/medpltfm/dlliids.cpp
client/medpltfm/pub/chxmedpltfm.h
common/include/hxengin.h
common/include/hxiids.h
common/include/ihxtlogsystem.h
common/util/chxminiccf.cpp
datatype/null/renderer/nullrend.cpp
Thanks,
Rajesh.
>-----Original Message-----
>From: ext gwright@real.com [mailto:gwright@real.com]
>Sent: Wednesday, December 12, 2007 4:10 PM
>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas)
>Cc: gwright@real.com; client-dev@helixcommunity.org;
>porting-symbian@helixcommunity.org;
>common-dev@helixcommunity.org; video-dev@helixcommunity.org;
>clientapps-dev@helixcommunity.org
>Subject: RE: [Video-dev] CR: Porting Head for SymbianMMF target.
>
>
>>>Next, I think some of these changes would be good for
>310Atlas branch.
>>>I am not sure what branch you intend to release off of, but
>if you can
>>>move to the stable dev Atlas branch, 310Atlas, then you can take
>>>advantage of fixes we do as well as the community taking
>advantage of
>>>what you do. You can, of course, branch your own branch off of
>>>310Atlas so you are isolated.
>>
>> <<Rajesh>> Please let me know what changes you need for
>310Atlas and I
>> can checkin to that branch too (Will that be all changes except
>> SymbianMMF and Symbian MDF)
>>
>> I'm not sure of moving to branch 310Atlas, as all our fixes go to
>> 210CayS and Head alone and not 310Atlas.
>
>Yes, all fixes look good for 310Atlas except the symbian ones.
>
>If you are never going to move off of 210Cays, then I guess it
>doesn't make sense to merge the symbian changes to 310Atlas.
>But, it will mean you really have to watch the CRs coming in
>and ask for them to be merged to your branch as well. And, if
>your branch (210Cays) is not up to date with 310Atlas then the
>merges may become hard over time. That is why I suggested
>Nokia thinks about the branch strategy. Nothing has to be done
>today however.
>
>The rest of the changes look good.
>
>--greg.
>
>>
>>>
>>>
>>>Index: client/medpltfm/chxmedpltfm.cpp
>>>===================================================================
>>>RCS file: /cvsroot/client/medpltfm/chxmedpltfm.cpp,v
>>>retrieving revision 1.53
>>>diff -w -u -b -r1.53 chxmedpltfm.cpp
>>>--- client/medpltfm/chxmedpltfm.cpp 5 Oct 2007 20:15:51
>>>-0000 1.53
>>>+++ client/medpltfm/chxmedpltfm.cpp 7 Dec 2007 20:56:54 -0000
>>>@@ -87,10 +87,11 @@
>>> #include "recognizer.h"
>>> #include "hxxml.h"
>>> #include "hxxmlprs.h"
>>>+#ifdef HELIX_FEATURE_HTTP_SERVICE
>>> #include "chxhttp.h"
>>> #include "hxhttp.h"
>>>+#endif
>>> #include "hxinfcod.h"
>>>-#include "ihxautoupgrademgr.h"
>>> #include "hxver.h"
>>> #include "hxstrutl.h"
>>> #include "dbcs.h"
>>>
>>>You sure you want to remove ihxautoupgrademgr.h? Is it not needed?
>>>Perhaps you can wrap it in #if defined(HELIX_FEATURE_AUTOUPGRADE).
>>
>> <<Rajesh>> The header ihxautoupgrademgr.h is already included in
>> chxmedpltfm.h.
>>
>>>
>>>In your CR you say, "* hxengin.h & hxiids.h - IID clash for
>>>IHXThreadSafeScheduler > and IHXScheduler3 for platforms using non
>>>full guid. Created a new > guid for IHXScheduler3. "
>>>
>>>But:
>>>
>>>-DEFINE_GUID(IID_IHXScheduler2, 0x00000101, 0x901, 0x11d1,
>0x8b, 0x6,
>>>0x0,
>>>- 0xa0, 0x24, 0x40, 0x6d, 0x5a);
>>>+DEFINE_GUID(IID_IHXScheduler2, 0x9a26d8bf, 0xeb28, 0x4989,
>>>0xb2, 0xbd, 0x47,
>>>+ 0x2a, 0xbb, 0xd7, 0x6a, 0x16);
>>>
>>>You are changing IID_IHXScheduler2, typo right? Can you explain
>>>exactly what the clash is? If it is possible to get clashes
>with UUIDs
>>>then we need to make sure we document how so that it does not happen
>>>again. Changing UUIDs once they are published is a big no-no
>since 3rd
>>>party developers applications would break (they will no
>longer be able
>>>to QI for something they use to) without rebuilding their apps. It
>>>does appear the IHXScheduler2 is the newest, so it is probably the
>>>safest to change.
>>
>> <<Rajesh>> Yes, it is a typo error. I'm changing IHXScheduler2. In
>> case of platforms not using FULL GUID, we use the macro
>DEFINE_GUID_ENUM.
>>
>> #define DEFINE_GUID_ENUM(name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7,
>> b8) \
>> name = l + w1 * 3 + w2 * 5 + b1 * 7 + b2 * 11 + b3 * 13
>+ b4 * 17
>> + \
>> b5 * 19 + b6 * 23 + b7 * 29 + b8 * 31
>>
>> This calculation resulted in same value for
>IHXThreadSafeScheduler and
>> IHXScheduler2. I'm not sure how all iids are generated, it
>looks like
>> one was generated and others are just some increments. I noticed that
>> IHXScheduler2 was the latest, hence changed that one instead of
>> threadsafescheduler.
>>
>> DEFINE_GUID_ENUM(IID_IHXCallback, 0x00000100, 0x901,
>> 0x11d1, 0x8b, 0x6, 0x0, 0xa0, 0x24, 0x40, 0x6d, 0x59)
>> DEFINE_GUID_ENUM(IID_IHXScheduler, 0x00000101, 0x901,
>> 0x11d1, 0x8b, 0x6, 0x0, 0xa0, 0x24, 0x40, 0x6d, 0x59)
>> DEFINE_GUID_ENUM(IID_IHXScheduler2, 0x00000101, 0x901,
>> 0x11d1, 0x8b, 0x6, 0x0, 0xa0, 0x24, 0x40, 0x6d, 0x5a) <---
>> DEFINE_GUID_ENUM(IID_IHXThreadSafeScheduler, 0x00000120, 0x901,
>> 0x11d1, 0x8b, 0x6, 0x0, 0xa0, 0x24, 0x40, 0x6d, 0x59) <---
>>
>>
>>>
>>>rest looks good.
>>>--greg.
>>>
>>>
>>>rajesh.rathinasamy@nokia.com wrote:
>>>>
>>>>> "Nokia submits this code under the terms of a commercial
>>>contribution
>>>>> agreement with RealNetworks, and I am authorized to
>contribute this
>>>>> code under said agreement."
>>>>>
>>>>> Modified by: rajesh.rathinasamy@nokia.com
>>>>>
>>>>> Reviewed by:
>>>>>
>>>>> Date: 09-Nov-2007
>>>>>
>>>>> Project: SymbianMmf_rel
>>>>>
>>>>> ErrorId: NA
>>>>>
>>>>> Synopsis: CR: Porting Head for SymbianMMF target.
>>>>>
>>>>> MMF Controller changes:
>>>>> ===================
>>>>> * Base controller loads the media platform during construction
>>>>> phase. Media playback engine will be created only when it
>>>is required.
>>>>> * Changed MMF context to have provision to enable and
>>>disable QI for
>>>>> CCF. This case is used for creation of log modules. Log
>>>modules need
>>>>> a
>>>>> context which can support QI for Pref & CCF & Log system.
>>>>> Mediaplatform does not need a CCF as per our implementation.
>>>>> * Since log system and MediaPlatform are inter dependent, the
>>>>> shutdown order has to make sure that first the log modules are
>>>>> closed, followed by Media Platform
>>>>> and later unload the log dlls.
>>>>> * Initialization of Media platform is delayed so that
>>>we don't have
>>>>> a scheduler or other service running.
>>>>> * Added new plugin dlls to installation scripts. (media
>>>platform,
>>>>> playback eng, network service & rtsp )
>>>>>
>>>>> Build Changes:
>>>>> ===========
>>>>> * Defined a config flag to disable console printing
>>>>> (HELIX_CONFIG_DISABLE_CONSOLE_PRINT)
>>>>> * Updated Helix bif to include client media platform as
>>>a part of
>>>>> build
>>>>>
>>>>> MDF Video changes:
>>>>> ===============
>>>>> * VideoPacemaker and Allocators need context during its
>>>creation.
>>>>> Modified those code to provide the context.
>>>>>
>>>>> Other changes:
>>>>> ===========
>>>>> * hxplugin.cpp - Initialization of plugin has been
>>>done only for
>>>>> Component plugin and not for other cases. Otherwise it results in
>>>>> InitPlugin being called more than once on renderers
>>>>> causing memory leaks.
>>>>> * chxsymbianliteprefs.cpp - Change to provide context
>>>>> * hxmedpltfmloader.cpp - Provided the support for
>>>NO_STATIC build.
>>>>> Removed the writable static data for symbian builds with
>>>the help of
>>>>> global manager
>>>>> * hxcleng.cpp - Interface typecast results in wrong
>>>function being
>>>>> called.
>>>>> * hxntsrc.cpp - Fixed the default transport to be UDP
>>>unless it is
>>>>> forced to TCP with a feature flag.
>>>>> * rtspprotocol.cpp - Varibale initialization was
>>>skipped for a goto
>>>>> case. ARMV5 compiler reports error. So minimizes the scope of the
>>>>> error.
>>>>>
>>>>> * MediaPlatform changes - Feature flags missing for some header
>>>>> inclusion and variables.
>>>>> * hxengin.h & hxiids.h - IID clash for
>>>IHXThreadSafeScheduler and
>>>>> IHXScheduler3 for platforms using non full guid. Created
>a new guid
>>>>> for IHXScheduler3.
>>>>> This was
>>>resulting in
>>>>> wrong function(StopScheduler) being called during streaming and
>>>>> client was stuck at relaoding.
>>>>> * ihxtlogsystem.h - Added missing log area
>>>>> * hxtsymlogobserver.h & .cpp - Disabled the
>>>PLUGIN_LOAD_AT_STARTUP
>>>>> flag for symbian.
>>>>> * Miniccf - Added mutex support
>>>>> * encstr.h & .cpp - Removed the console printing utilities for
>>>>> symbian.
>>>>>
>>>>> Pending Changes:
>>>>> ==============
>>>>> * Symbian Metadataengine porting.
>>>>> * Need to investigate on why netwksvc is being loaded for local
>>>>> playback. ClientEngine loads during override service.
>>>>>
>>>>> Root Cause of the problem: NA
>>>>>
>>>>> Files Modified:
>>>>> ===========
>>>>> build/umakecf/symbian-91.cf
>>>>> build/bif-cvs/helix/common/build/BIF/helix.bif
>>>>>
>>>>> client/common/container/hxplugin.cpp
>>>>> client/common/container/platform/symbian/chxsymbianliteprefs.cpp
>>>>> client/common/util/hxmedpltfmloader.cpp
>>>>> client/core/hxcleng.cpp
>>>>> client/core/hxntsrc.cpp
>>>>> client/core/rtspprotocol.cpp
>>>>> client/medpltfm/chxmedpltfm.cpp
>>>>> client/medpltfm/dlliids.cpp
>>>>> client/medpltfm/pub/chxmedpltfm.h
>>>>>
>>>>> common/include/hxengin.h
>>>>> common/include/hxiids.h
>>>>> common/include/ihxtlogsystem.h
>>>>>
>>>>> common/log/logobserverfile/platform/symbian/hxtsymlogobserver.cpp
>>>>> common/log/logobserverfile/platform/symbian/hxtsymlogobserver.h
>>>>> common/util/chxminiccf.cpp
>>>>> common/util/encstr.cpp
>>>>> common/util/pub/encstr.h
>>>>>
>>>>> clientapps/symbianMmf/MmfCtrlLib
>>>>> clientapps/symbianMmf/hxmmfcontext.cpp
>>>>> clientapps/symbianMmf/hxmmfcontext.h
>>>>> clientapps/symbianMmf/hxmmfplayctrl.cpp
>>>>> clientapps/symbianMmf/hxmmfplayctrl.h
>>>>> clientapps/symbianMmf/hxmmfstatectrl.cpp
>>>>> clientapps/symbianMmf/hxmmfstatectrl.h
>>>>> clientapps/symbianMmf/hxmmfstateimpl.cpp
>>>>> clientapps/symbianMmf/audiocontroller/hxmmfaudioctrl.cpp
>>>>> clientapps/symbianMmf/audiocontroller/installMMF.pcf
>>>>> clientapps/symbianMmf/common/Umakefil
>>>>> clientapps/symbianMmf/common/hxmmfbasectrl.cpp
>>>>> clientapps/symbianMmf/common/hxmmfbasectrl.h
>>>>> clientapps/symbianMmf/videocontroller/hxmmfctrlimpl.cpp
>>>>> clientapps/symbianMmf/videocontroller/hxmmfdefines.h
>>>>> clientapps/symbianMmf/videocontroller/installMMF.pcf
>>>>>
>>>>> datatype/mdf/video/format/h264/mdfh264payloadformat.cpp
>>>>> datatype/mdf/video/format/h264/pub/mdfh264payloadformat.h
>>>>> datatype/mdf/video/format/mp4/Umakefil
>>>>> datatype/mdf/video/format/mp4/mdfmp4payloadformat.cpp
>>>>> datatype/mdf/video/format/mp4/pub/mdfmp4payloadformat.h
>>>>> datatype/mdf/video/format/rm/Umakefil
>>>>> datatype/mdf/video/format/rm/mdfrvxpayloadformat.cpp
>>>>> datatype/mdf/video/format/rm/pub/mdfrvxpayloadformat.h
>>>>> datatype/mdf/video/renderer/mdfvideoadapter.cpp
>>>>> datatype/null/renderer/nullrend.cpp
>>>>>
>>>>>
>>>>>
>>>datatype/tools/metadataeng/engine/platform/symbian/symbian_metadataen
>>>>> g
>>>>> .cpp
>>>>>
>>>>> Image Size and Heap Use impact: TBD
>>>>>
>>>>> Module Release testing (STIF) : Passed.
>>>>>
>>>>> Test case(s) Added : No.
>>>>>
>>>>> Memory leak check performed : Yes. No new leaks introduced.
>>>>>
>>>>> Platforms and Profiles Build Verified:
>>>>> helix-client-s60-32-mmf-mdf-arm
>>>>>
>>>>> Platforms and Profiles Functionality verified: armv5,winscw
>>>>>
>>>>> Branch: Head
>>>>> <<cvs_diff.txt>>
>>>>>
>>>>>
>>>---------------------------------------------------------------------
>>>>> ---
>>>>>
>>>>> This body part will be downloaded on demand.
>>>
>>>
>>
>
>
_______________________________________________
Video-dev mailing list
Video-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/video-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic