From qluo at real.com Tue Nov 2 10:22:15 2010
From: qluo at real.com (Qiang Luo)
Date: Tue Nov 2 16:33:25 2010
Subject: [Common-dev] Re: [Android-port-dev] CR: Determine flash file format
using the file content instead of file extension
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC4450817EBAE30@SEAMBX.corp.real.com>
References: <766B5A29D28DA442AB229AAEE2AFC4450817EBAE30@SEAMBX.corp.real.com>
Message-ID: <4CD056D7.80005@real.com>
Looks good.
Qiang
On 11/2/2010 10:58 AM, Renjie Huang wrote:
> Date: 2010-11-02
> Project: RealPlayer for Android Smartphones
>
> Synopsis: Determine flash file format using the file content instead of file extension
>
> Overview: It is not uncommon that flash files are mis-labeled with wrong file extension (.flv file labeled with .f4v, or .f4v files labeled with .flv), so force to ignore it and use file recognizer to determine the file format based on content for tolerance.
>
> Changed files: common/system/recognizer.cpp
>
> Platforms and Profiles Affected:
> Platform: 310, 361, 362
>
> Distribution Libraries Affected:
> NA
>
> Distribution library impact and planned action:
> NA
>
> Platforms and Profiles Build Verified:
> Platform: hxclient_3_1_0_atlas, hxclient_3_6_1_atlas
> Profile: helix-client-all-defines, helix-client-android-full
>
> Copyright assignment: I am a RealNetworks employee or contractor
>
>
>
> Renjie
From ext-g.manikanda at nokia.com Thu Nov 4 01:13:43 2010
From: ext-g.manikanda at nokia.com (ext-g.manikanda@nokia.com)
Date: Thu Nov 4 07:25:16 2010
Subject: [Common-dev] COMMIT: RESEND: CR: ou1cimx1#621073 - Thumbnail not
generated for mp4 video (tn engine error -17)
In-Reply-To: <07B338923962604386C3428AF0A470860C3AF9FFBA@NOK-EUMSG-02.mgdnok.nokia.com>
References:
<07B338923962604386C3428AF0A470860C3AF9FFBA@NOK-EUMSG-02.mgdnok.nokia.com>
Message-ID: <20D73E2631F7914F868646E119DEC1CE2A4E74B324@NOK-EUMSG-02.mgdnok.nokia.com>
Thank you Ashish . Checked into Cays 210,Brizo 420 and Head.
Regards,
Manikandan.G
_____________________________________________
From: Gupta Ashish.As (Nokia-MS/Dallas)
Sent: Friday, October 29, 2010 7:11 PM
To: Merapala Shashi (EXT-Sasken/Bangalore); I_EXT_HELIX_ALL_GMS DG
Subject: RE: RESEND: CR: ou1cimx1#621073 - Thumbnail not generated for mp4 video (tn engine error -17)
Looks fine.
Thanks
Ashish
_____________________________________________
From: Merapala Shashi (EXT-Sasken/Bangalore)
Sent: Friday, October 29, 2010 2:26 AM
To: I_EXT_HELIX_ALL_GMS DG
Subject: RESEND: CR: ou1cimx1#621073 - Thumbnail not generated for mp4 video (tn engine error -17)
Any feedback on this change ?
(This atom type 'ftypFACE' appears to be associated with video clips hosted in facebook.)
Thanks & Warm Regards,
Shashi Kiran Merapala
_____________________________________________
From: Merapala Shashi (EXT-Sasken/Bangalore)
Sent: Wednesday, October 27, 2010 8:53 PM
To: I_EXT_HELIX_ALL_GMS DG
Subject: CR: ou1cimx1#621073 - Thumbnail not generated for mp4 video (tn engine error -17)
"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: ext-shashi.merapala@nokia.com
Reviewed by:
Date: 10/27/2010
Project: SymbianMmf_wm
Error Id: ou1cimx1#621073
Synopsis: Thumbnail not generated for mp4 video (tn engine error -17)
Overview: The error reported mp4 video clip in question has atom type 'ftypFACE' which the symbian recognizer doesn't recognize and hence returns the mime type as NULL as it is unable to map a mime type for this particular atom type.
Solution: Added this atom type to the symbian recognizer to return a mime type.
Diff below.
Files added: None
Files modified: /cvsroot/common/system/platform/symbian/symbianrecognizer.cpp
Image size and heap use impact: Negligible
Module release testing (STIF): Done. Passed.
Test case(s) added: No
Memory leak check performed: NA
Platforms and profiles build verified: helix-client-s60-52-mmf-mdf-dsp
Platforms and profiles functionality verified: armv5
Branch: 210CayS, HEAD, 420Brizo
Index: symbianrecognizer.cpp
===================================================================
RCS file: /cvsroot/common/system/platform/symbian/symbianrecognizer.cpp,v
retrieving revision 1.2.156.10
diff -u -w -r1.2.156.10 symbianrecognizer.cpp
--- symbianrecognizer.cpp 25 May 2010 07:07:56 -0000 1.2.156.10
+++ symbianrecognizer.cpp 27 Oct 2010 14:59:04 -0000
@@ -50,6 +50,7 @@
_LIT8(KMSNVType ,"ftypMSNV" ); // mp4 MSNV format
_LIT8(KAvc1Type ,"ftypavc1" ); // avc1 format
_LIT8(KDby1Type ,"ftypdby1" ); // dby1 format
+ _LIT8(KFACEType ,"ftypFACE" ); // FACE
// mime types can be returned
_LIT8(K3GPPVideo , "video/3gpp" );
@@ -85,7 +86,8 @@
|| buffer.FindF(KIsomType) != KErrNotFound || buffer.FindF(KMp42Type) != KErrNotFound || buffer.FindF(KM4VType) != KErrNotFound
|| buffer.FindF(KMSNVType) != KErrNotFound
|| buffer.FindF(KAvc1Type) != KErrNotFound
- || buffer.FindF(KDby1Type) != KErrNotFound)
+ || buffer.FindF(KDby1Type) != KErrNotFound
+ || buffer.FindF(KFACEType) != KErrNotFound)
{
type = TDataType(KMP4Video);
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/common-dev/attachments/20101104/80d57035/attachment.html
From lqing at real.com Fri Nov 5 03:23:44 2010
From: lqing at real.com (Li Qing)
Date: Fri Nov 5 09:33:59 2010
Subject: [Common-dev] CR: Change the default HXPthreadMutex to recursive
mutex
Message-ID: <4A242CD46F4C34418D17941FF9746F977411DBE983@SEAMBX.corp.real.com>
Modified by: lqing@real.com
Date: 11/05/2010
Project: RealPlayer for Android Smartphones
Synopsis: Change the default HXPthreadMutex to recursive mutex
Overview: For some unknown reason, some mutex objects will be recursively locked in some abnormal situation. In this case, the state of the threads which are synced by those mutexes may become unpredictable. I modified the _Lock and _Unlock function to determine if the mutex is recursively locked, and dump some traceback info when some exceptions occur (the traceback info may be useful for debugging).
Files Added: None
Files Modified:
common/system/platform/unix/pthreadthreads.cpp
Image Size and Heap Use impact (Client -Only): None
Platforms and Profiles Affected:
Platform: android-donut3230-arm-qsd_8x50, android-2.2-arm-qsd_8250, android-2.2-arm-qsd_8650a
Profile: helix-client-android-full
Distribution Libraries Affected:None
Distribution library impact and planned action:None
Platforms and Profiles Build Verified:
Platform: android-2.2-arm-qsd_8250
Profile: helix-client-android-full
Platforms and Profiles Functionality verified:
Platform: android-2.2-arm-qsd_8250
Profile: helix-client-android-full
Branch: HEAD, 310atlas, 361atlas, 362atlas
Copyright assignment: I am a RealNetworks employee or contractor
Best Regards!
Li Qing
--
RealNetworks China, Beijing Office
Tel: 008601059542848
Fax: 008601085656477
Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang District,Beijing, China
Post Code: 100027
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pthreadthreads.cpp.diff
Type: text/x-patch
Size: 2822 bytes
Desc: pthreadthreads.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/common-dev/attachments/20101105/37dca3a5/pthreadthreads.cpp-0001.bin
From qluo at real.com Tue Nov 9 07:16:12 2010
From: qluo at real.com (Qiang Luo)
Date: Tue Nov 9 13:25:07 2010
Subject: [Common-dev] CR: Change the default HXPthreadMutex to recursive
mutex
In-Reply-To: <4A242CD46F4C34418D17941FF9746F977411DBE983@SEAMBX.corp.real.com>
References: <4A242CD46F4C34418D17941FF9746F977411DBE983@SEAMBX.corp.real.com>
Message-ID: <4CD965BC.5030107@real.com>
Hi Li Qing,
Could you be more specific about what bug/issue this change actually
fix? On your platform, what mutex type bellow are you using?
PTHREAD_MUTEX_NORMAL
PTHREAD_MUTEX_ERRORCHECK
PTHREAD_MUTEX_RECURSIVE
PTHREAD_MUTEX_DEFAULT
Besides the stack trace for debugging, what is the difference between
the original code and your change if the mutex type is
PTHREAD_MUTEX_RECURSIVE? Could you just check the return code of
pthread_mutex_lock() / pthread_mutex_unlock() if error checking needs to
be strengthened?
Thanks,
Qiang
On 11/5/2010 4:23 AM, Li Qing wrote:
> Modified by: lqing@real.com
> Date: 11/05/2010
> Project: RealPlayer for Android Smartphones
>
> Synopsis: Change the default HXPthreadMutex to recursive mutex
>
> Overview: For some unknown reason, some mutex objects will be recursively locked in some abnormal situation. In this case, the state of the threads which are synced by those mutexes may become unpredictable. I modified the _Lock and _Unlock function to determine if the mutex is recursively locked, and dump some traceback info when some exceptions occur (the traceback info may be useful for debugging).
>
> Files Added: None
>
> Files Modified:
> common/system/platform/unix/pthreadthreads.cpp
>
> Image Size and Heap Use impact (Client -Only): None
>
> Platforms and Profiles Affected:
> Platform: android-donut3230-arm-qsd_8x50, android-2.2-arm-qsd_8250, android-2.2-arm-qsd_8650a
> Profile: helix-client-android-full
>
> Distribution Libraries Affected:None
>
> Distribution library impact and planned action:None
>
> Platforms and Profiles Build Verified:
> Platform: android-2.2-arm-qsd_8250
> Profile: helix-client-android-full
>
> Platforms and Profiles Functionality verified:
> Platform: android-2.2-arm-qsd_8250
> Profile: helix-client-android-full
>
> Branch: HEAD, 310atlas, 361atlas, 362atlas
>
> Copyright assignment: I am a RealNetworks employee or contractor
>
>
> Best Regards!
> Li Qing
> --
> RealNetworks China, Beijing Office
> Tel: 008601059542848
> Fax: 008601085656477
> Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang District,Beijing, China
> Post Code: 100027
From lqing at real.com Sat Nov 13 20:33:58 2010
From: lqing at real.com (Li Qing)
Date: Sun Nov 14 02:41:59 2010
Subject: [Common-dev] CR: Change the default HXPthreadMutex to recursive
mutex
In-Reply-To: <4CD965BC.5030107@real.com>
References: <4A242CD46F4C34418D17941FF9746F977411DBE983@SEAMBX.corp.real.com>,
<4CD965BC.5030107@real.com>
Message-ID: <4A242CD46F4C34418D17941FF9746F977411DBE987@SEAMBX.corp.real.com>
Thanks, Qiang.
I misread the compilation condition for recursive mutex, I take back this CR.
Best Regards!
Li Qing
--
RealNetworks China, Beijing Office
Tel: 008601059542848
Fax: 008601085656477
Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang District,Beijing, China
Post Code: 100027
________________________________________
From: Qiang Luo
Sent: Tuesday, November 09, 2010 11:16 PM
To: Li Qing
Cc: common-dev@helixcommunity.org
Subject: Re: [Common-dev] CR: Change the default HXPthreadMutex to recursive mutex
Hi Li Qing,
Could you be more specific about what bug/issue this change actually
fix? On your platform, what mutex type bellow are you using?
PTHREAD_MUTEX_NORMAL
PTHREAD_MUTEX_ERRORCHECK
PTHREAD_MUTEX_RECURSIVE
PTHREAD_MUTEX_DEFAULT
Besides the stack trace for debugging, what is the difference between
the original code and your change if the mutex type is
PTHREAD_MUTEX_RECURSIVE? Could you just check the return code of
pthread_mutex_lock() / pthread_mutex_unlock() if error checking needs to
be strengthened?
Thanks,
Qiang
On 11/5/2010 4:23 AM, Li Qing wrote:
> Modified by: lqing@real.com
> Date: 11/05/2010
> Project: RealPlayer for Android Smartphones
>
> Synopsis: Change the default HXPthreadMutex to recursive mutex
>
> Overview: For some unknown reason, some mutex objects will be recursively locked in some abnormal situation. In this case, the state of the threads which are synced by those mutexes may become unpredictable. I modified the _Lock and _Unlock function to determine if the mutex is recursively locked, and dump some traceback info when some exceptions occur (the traceback info may be useful for debugging).
>
> Files Added: None
>
> Files Modified:
> common/system/platform/unix/pthreadthreads.cpp
>
> Image Size and Heap Use impact (Client -Only): None
>
> Platforms and Profiles Affected:
> Platform: android-donut3230-arm-qsd_8x50, android-2.2-arm-qsd_8250, android-2.2-arm-qsd_8650a
> Profile: helix-client-android-full
>
> Distribution Libraries Affected:None
>
> Distribution library impact and planned action:None
>
> Platforms and Profiles Build Verified:
> Platform: android-2.2-arm-qsd_8250
> Profile: helix-client-android-full
>
> Platforms and Profiles Functionality verified:
> Platform: android-2.2-arm-qsd_8250
> Profile: helix-client-android-full
>
> Branch: HEAD, 310atlas, 361atlas, 362atlas
>
> Copyright assignment: I am a RealNetworks employee or contractor
>
>
> Best Regards!
> Li Qing
> --
> RealNetworks China, Beijing Office
> Tel: 008601059542848
> Fax: 008601085656477
> Address: 18th Floor,Tower B,Pacific Century Place,2A GongTiBeiLu,Chaoyang District,Beijing, China
> Post Code: 100027
From qluo at real.com Sun Nov 14 15:16:21 2010
From: qluo at real.com (Qiang Luo)
Date: Sun Nov 14 21:23:51 2010
Subject: [Common-dev] CR: add HX_ASM_DISCONTINUITY to the ASM flags
definitions
Message-ID: <4CE06DC5.5050602@real.com>
Overview:
This CR adds HX_ASM_DISCONTINUITY to ASM flags definitions.
HX_ASM_DISCONTINUITY signals the change of the codec parameter(s) in the
audio/video streams start at the flagged packet. Let me know if you
have better name for it.
Thanks,
Qiang
branches:
head, hxclient_3_1_0_atlas
file modified:
common/include/ihxpckts.h
diff:
Index: ihxpckts.h
===================================================================
RCS file: /cvsroot/common/include/ihxpckts.h,v
retrieving revision 1.16
diff -u -r1.16 ihxpckts.h
--- ihxpckts.h 6 Jul 2007 20:43:42 -0000 1.16
+++ ihxpckts.h 14 Nov 2010 22:47:52 -0000
@@ -59,6 +59,7 @@
#define HX_ASM_SWITCH_ON 0x01
#define HX_ASM_SWITCH_OFF 0x02
#define HX_ASM_DROPPED_PKT 0x04
+#define HX_ASM_DISCONTINUITY 0x08
From jgordon at real.com Sun Nov 14 16:45:31 2010
From: jgordon at real.com (Jamie Gordon)
Date: Sun Nov 14 22:53:20 2010
Subject: [Common-dev] CR: add HX_ASM_DISCONTINUITY to the ASM
flags definitions
In-Reply-To: <4CE06DC5.5050602@real.com>
References: <4CE06DC5.5050602@real.com>
Message-ID: <4CE082AB.1000003@real.com>
It will need to be 0x10 rather than 0x08, as 0x08 is already in use
(I guess not on atlas, but on newer branches) for HX_ASM_SIDE_EFFECT.
Otherwise looks good!
-Jamie
On 11/14/2010 3:16 PM, Qiang Luo wrote:
> Overview:
> This CR adds HX_ASM_DISCONTINUITY to ASM flags definitions.
> HX_ASM_DISCONTINUITY signals the change of the codec parameter(s) in the
> audio/video streams start at the flagged packet. Let me know if you
> have better name for it.
>
> Thanks,
> Qiang
>
> branches:
> head, hxclient_3_1_0_atlas
>
> file modified:
> common/include/ihxpckts.h
>
> diff:
> Index: ihxpckts.h
> ===================================================================
> RCS file: /cvsroot/common/include/ihxpckts.h,v
> retrieving revision 1.16
> diff -u -r1.16 ihxpckts.h
> --- ihxpckts.h 6 Jul 2007 20:43:42 -0000 1.16
> +++ ihxpckts.h 14 Nov 2010 22:47:52 -0000
> @@ -59,6 +59,7 @@
> #define HX_ASM_SWITCH_ON 0x01
> #define HX_ASM_SWITCH_OFF 0x02
> #define HX_ASM_DROPPED_PKT 0x04
> +#define HX_ASM_DISCONTINUITY 0x08
>
> _______________________________________________
> Common-dev mailing list
> Common-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/common-dev
From sfu at real.com Sun Nov 14 19:33:19 2010
From: sfu at real.com (Sheldon Fu)
Date: Mon Nov 15 01:41:01 2010
Subject: [Common-dev] CR: add HX_ASM_DISCONTINUITY to the ASM
flags definitions
In-Reply-To: <4CE06DC5.5050602@real.com>
References: <4CE06DC5.5050602@real.com>
Message-ID: <4CE0A9FF.7070806@real.com>
Not all codecs are like h.264 that can carry the codec setup data in the
bitstream (actually most of them don't), so as a generic mechanism this
new flag should mean that the packet with the flag set is a new codec
setup data blob (aka OpaqueData in the stream header) and contains no
actual frame data.
fxd
Qiang Luo wrote:
> Overview:
> This CR adds HX_ASM_DISCONTINUITY to ASM flags definitions.
> HX_ASM_DISCONTINUITY signals the change of the codec parameter(s) in the
> audio/video streams start at the flagged packet. Let me know if you
> have better name for it.
>
> Thanks,
> Qiang
>
> branches:
> head, hxclient_3_1_0_atlas
>
> file modified:
> common/include/ihxpckts.h
>
> diff:
> Index: ihxpckts.h
> ===================================================================
> RCS file: /cvsroot/common/include/ihxpckts.h,v
> retrieving revision 1.16
> diff -u -r1.16 ihxpckts.h
> --- ihxpckts.h 6 Jul 2007 20:43:42 -0000 1.16
> +++ ihxpckts.h 14 Nov 2010 22:47:52 -0000
> @@ -59,6 +59,7 @@
> #define HX_ASM_SWITCH_ON 0x01
> #define HX_ASM_SWITCH_OFF 0x02
> #define HX_ASM_DROPPED_PKT 0x04
> +#define HX_ASM_DISCONTINUITY 0x08
>
> _______________________________________________
> Common-dev mailing list
> Common-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/common-dev
>
>
From qluo at real.com Mon Nov 15 07:22:15 2010
From: qluo at real.com (Qiang Luo)
Date: Mon Nov 15 13:29:33 2010
Subject: [Common-dev] CR: add HX_ASM_DISCONTINUITY to the ASM
flags definitions
In-Reply-To: <4CE0A9FF.7070806@real.com>
References: <4CE06DC5.5050602@real.com> <4CE0A9FF.7070806@real.com>
Message-ID: <4CE15027.6070806@real.com>
Thanks Jamie and Sheldon.
I have merged HX_ASM_SIDE_EFFECT from head and added comment for
HX_ASM_DISCONTINUITY. Chacked in to head and 310.
Qiang
new diff:
Index: ihxpckts.h
===================================================================
RCS file: /cvsroot/common/include/ihxpckts.h,v
retrieving revision 1.16
diff -u -r1.16 ihxpckts.h
--- ihxpckts.h 6 Jul 2007 20:43:42 -0000 1.16
+++ ihxpckts.h 15 Nov 2010 15:07:53 -0000
@@ -59,6 +59,17 @@
#define HX_ASM_SWITCH_ON 0x01
#define HX_ASM_SWITCH_OFF 0x02
#define HX_ASM_DROPPED_PKT 0x04
+/*
+ * HX_ASM_SIDE_EFFECT is used with HX_ASM_SWITCH_ON to
+ * indicate that that HX_ASM_SWITCH_ON is not the cause of the sync.
+ * mainly used in mp4 fileformat to indicate the end of the keyframe.
+ */
+#define HX_ASM_SIDE_EFFECT 0x08
+/*
+ * HX_ASM_DISCONTINUITY is used to indicate the change in codec parameters.
+ * The flagged packet shall carry codec setup data.
+ */
+#define HX_ASM_DISCONTINUITY 0x10
On 11/14/2010 7:33 PM, Sheldon Fu wrote:
> Not all codecs are like h.264 that can carry the codec setup data in the
> bitstream (actually most of them don't), so as a generic mechanism this
> new flag should mean that the packet with the flag set is a new codec
> setup data blob (aka OpaqueData in the stream header) and contains no
> actual frame data.
>
> fxd
>
> Qiang Luo wrote:
>> Overview:
>> This CR adds HX_ASM_DISCONTINUITY to ASM flags definitions.
>> HX_ASM_DISCONTINUITY signals the change of the codec parameter(s) in the
>> audio/video streams start at the flagged packet. Let me know if you
>> have better name for it.
>>
>> Thanks,
>> Qiang
>>
>> branches:
>> head, hxclient_3_1_0_atlas
>>
>> file modified:
>> common/include/ihxpckts.h
>>
>> diff:
>> Index: ihxpckts.h
>> ===================================================================
>> RCS file: /cvsroot/common/include/ihxpckts.h,v
>> retrieving revision 1.16
>> diff -u -r1.16 ihxpckts.h
>> --- ihxpckts.h 6 Jul 2007 20:43:42 -0000 1.16
>> +++ ihxpckts.h 14 Nov 2010 22:47:52 -0000
>> @@ -59,6 +59,7 @@
>> #define HX_ASM_SWITCH_ON 0x01
>> #define HX_ASM_SWITCH_OFF 0x02
>> #define HX_ASM_DROPPED_PKT 0x04
>> +#define HX_ASM_DISCONTINUITY 0x08
>>
>> _______________________________________________
>> Common-dev mailing list
>> Common-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/common-dev
>>
>>
> .
>
From qluo at real.com Wed Nov 24 23:41:59 2010
From: qluo at real.com (Qiang Luo)
Date: Thu Nov 25 05:47:06 2010
Subject: [Common-dev] Re: [Android-port-dev] CR: Changes to fix a bug in
time converter logic
In-Reply-To:
References: <766B5A29D28DA442AB229AAEE2AFC4450804432585@SEAMBX.corp.real.com>
Message-ID: <4CEE1347.6070403@real.com>
Looks good to me.
Qiang
On 11/23/2010 6:08 AM, Caijun Song wrote:
> Synopsis: Changes to fix a bug in time converter logic
>
> Overview: In timeconvert of fixed point time converter, it's possible that
> ulT1 is larger than 0x7fffffff, and T1.ulRef is very small, for example 0,
> this will lead to problem in following logic, this fix change this part
> logic from 32bits to 64bits to avoid such problem.
>
>
>
> Files Added:
> None
>
> Files Modified:
> Common/util/tconverter/fxpoint/tconverter_fxp.cpp
>
> Platforms and Profiles Functionality verified:
> System: android-2.2-arm-qsd_8650a
> Profile: helix-client-android-full
> Target: android_omx
> Branch: hxclient_3_6_2_atlas
>
> Branch Affected:
> hxclient_3_1_0_atlas hxclient_3_6_1_atlas hxclient_3_6_2_atlas
>
> Copyright assignment: I am a RealNetworks employee
>
>
> Regards.
> Caijun
From qluo at real.com Tue Nov 30 16:32:30 2010
From: qluo at real.com (Qiang Luo)
Date: Tue Nov 30 22:36:19 2010
Subject: [Common-dev] Re: [Android-port-dev] RE: CR:errors when do url
escape for special character %, #
In-Reply-To: <7ECCEA249B7CDC49A079EC0075E999AA07F7E6E32F@SEAMBX.corp.real.com>
References: <7ECCEA249B7CDC49A079EC0075E999AA07F7E6E32F@SEAMBX.corp.real.com>
Message-ID: <4CF5979E.9000503@real.com>
Henry,
If you rename a track to %12345.mp3 and feed the helix simple player
%2512345, helix client can play it. Then what issue are you exactly
fixing? Is the string in OpenURL() call %2512345 on android? If we can
play on desktop client, why not on android?
My concern is that this logic has been there for long time and seems
correct. There will be some risk to change it if we are not 100% sure.
Qiang
On 11/26/2010 2:04 AM, Henry Xing wrote:
>
> ------------------------------------------------------------------------
>
> *From:*hxing [mailto:hxing@real.com]
> *Sent:* Friday, November 26, 2010 6:02 PM
> *To:* 'android-port-dev@helixcommunity.org'; common-dev@helixcommunity.org
> *Cc:* Frank Lan; Helen Hua
> *Subject:* CR:errors when do url escape for special character %, #
>
> Modified by: hxing@real.com
> Date: 11/26/2010
>
> Project: RealPlayer for Android Smartphones
>
> Bug Number: 12046
> Synopsis: the video which name include '%' or '#' can't play
>
>
> Overview: if the file name include string like this %12345, these are
> problem when helix do escape this file url. The media player do the
> special char escape(conversion) before send file url to helix engine,
> the convert result is %2512345. firstly helix do unescape to this file
> url, the result is right %12345, after some logic handle, then it do
> escape again for the coming action, but the error happen in this time,
> our logic judge it have been escaped, do not do escape again. My
> update remove the logic condition of whether is escape or not. Do
> escape if it is the special character.
>
>
> Files Modified:
> common/util/hxescapeutil.cpp
>
>
> Image Size and Heap Use impact (Client -Only):
> None
>
> Platforms and Profiles Affected:
> Platform: android-donut3230-arm-qsd_8x50
>
> Profile: helix-client-android-full
>
>
> Distribution Libraries Affected:
> None
>
> Distribution library impact and planned action:
> None
>
> Platforms and Profiles Build Verified:
> Platform: android-donut3230-arm-qsd_8x50
>
> Profile: helix-client-android-full
>
>
> Platforms and Profiles Functionality verified:
> Platform: android-donut3230-arm-qsd_8x50
>
> Profile: helix-client-android-full
>
>
> Branch: 361atlas362atlas 363atlas
>
>
> Copyright assignment: I am a RealNetworks employee or contractor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/common-dev/attachments/20101130/06773bf3/attachment-0001.html
Copyright © 1995-2007 RealNetworks, Inc. All rights reserved.
RealNetworks and Helix are trademarks of RealNetworks.
All other trademarks or registered trademarks are the property of their respective holders.