From qluo at real.com Mon Oct 3 22:20:51 2011
From: qluo at real.com (Qiang Luo)
Date: Mon Oct 3 22:22:10 2011
Subject: [datatype-dev] CR: mp4 video render frame drop fix
Message-ID: <4E8A3543.608@real.com>
Overview:
We have seen excessive video frame drops for HLS/ts playback making the
video not smooth, like hiccups. Considerable amount of the frame drops
are not related to the video being decoded too late. The drops are in
fact caused by the output frame queue is full. In render, we should
never try to decode and move the frame to the output queue if there is
no room to hold it. In this CR, I added one fix in
CMP4VideoFormat::CreateDecodedPacket() and one check in
CMP4VideoFormat::DecodeFrame() to prevent "output-buffer-full frame
drop" from happening.
Branches:
310, 380 (I will also check the head and 361 branches to see if we need
this fix)
File modified:
/cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
Please review attached diff.
Thanks,
Qiang
-------------- next part --------------
Index: mp4vdfmt.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp,v
retrieving revision 1.18.8.35
diff -u -w -r1.18.8.35 mp4vdfmt.cpp
--- mp4vdfmt.cpp 4 Aug 2011 01:55:43 -0000 1.18.8.35
+++ mp4vdfmt.cpp 3 Oct 2011 21:53:27 -0000
@@ -1073,18 +1073,6 @@
m_pMP4VideoRenderer->BltIfNeeded();
- // If frame is decoded, return it to be queued
- if (pDecodedFrame)
- {
- if (!ReturnDecodedPacket(pDecodedFrame))
- {
- // Unable to return decoded frame - throw it away
- m_pFramePool->Put(pDecodedFrame);
- m_pMP4VideoRenderer->ReportDroppedFrame();
- }
- pDecodedFrame = NULL;
- }
-
// If decoded packet isn't available, create one by decoding the
// frame to decode
if (!pDecodedPacket && pFrameToDecode)
@@ -1267,6 +1255,18 @@
m_pMP4VideoRenderer->ReportDroppedFrame();
}
+ // If frame is decoded, return it to be queued
+ if (pDecodedFrame)
+ {
+ if (!ReturnDecodedPacket(pDecodedFrame))
+ {
+ // Unable to return decoded frame - throw it away
+ m_pFramePool->Put(pDecodedFrame);
+ m_pMP4VideoRenderer->ReportDroppedFrame();
+ }
+ pDecodedFrame = NULL;
+ }
+
// See if more decoded frames are avaialable
if (CanReturnDecodedPacket())
{
@@ -1656,6 +1656,9 @@
UINT32 bNPump=FALSE;
m_pDecoder->ProcessOutputFrames(&bNPump);
}
+
+ if (CanReturnDecodedPacket())
+ {
CMediaPacket* pPacket = CreateDecodedPacket(NULL);
if(pPacket)
{
@@ -1670,6 +1673,8 @@
{
bRet = FALSE;
}
+ }
+
m_pDecoderMutex->Unlock();
}
return bRet;
From jgordon at real.com Tue Oct 4 00:37:40 2011
From: jgordon at real.com (Jamie Gordon)
Date: Tue Oct 4 00:38:21 2011
Subject: [datatype-dev] CR: mp4 video render frame drop fix
In-Reply-To: <4E8A3543.608@real.com>
References: <4E8A3543.608@real.com>
Message-ID: <4E8A5554.7070504@real.com>
looks good!
On 10/3/2011 3:20 PM, Qiang Luo wrote:
> Overview:
> We have seen excessive video frame drops for HLS/ts playback making the
> video not smooth, like hiccups. Considerable amount of the frame drops
> are not related to the video being decoded too late. The drops are in
> fact caused by the output frame queue is full. In render, we should
> never try to decode and move the frame to the output queue if there is
> no room to hold it. In this CR, I added one fix in
> CMP4VideoFormat::CreateDecodedPacket() and one check in
> CMP4VideoFormat::DecodeFrame() to prevent "output-buffer-full frame
> drop" from happening.
>
> Branches:
> 310, 380 (I will also check the head and 361 branches to see if we need
> this fix)
>
> File modified:
> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>
> Please review attached diff.
>
> Thanks,
> Qiang
From qluo at real.com Tue Oct 4 02:00:39 2011
From: qluo at real.com (Qiang Luo)
Date: Tue Oct 4 02:02:00 2011
Subject: [datatype-dev] CR: mp4 video render frame drop fix
In-Reply-To: <4E8A5554.7070504@real.com>
References: <4E8A3543.608@real.com> <4E8A5554.7070504@real.com>
Message-ID: <4E8A68C7.2020201@real.com>
Thanks for the review Jamie. I have checked in the fix to head, 310,
380 branches. The 361 atlas and hxclient_3_6_1_tiger also need this
fix. However, I will let the android projects team evaluate and do the
actual merge.
Qiang
On 10/3/2011 5:37 PM, Jamie Gordon wrote:
> looks good!
>
> On 10/3/2011 3:20 PM, Qiang Luo wrote:
>> Overview:
>> We have seen excessive video frame drops for HLS/ts playback making the
>> video not smooth, like hiccups. Considerable amount of the frame drops
>> are not related to the video being decoded too late. The drops are in
>> fact caused by the output frame queue is full. In render, we should
>> never try to decode and move the frame to the output queue if there is
>> no room to hold it. In this CR, I added one fix in
>> CMP4VideoFormat::CreateDecodedPacket() and one check in
>> CMP4VideoFormat::DecodeFrame() to prevent "output-buffer-full frame
>> drop" from happening.
>>
>> Branches:
>> 310, 380 (I will also check the head and 361 branches to see if we need
>> this fix)
>>
>> File modified:
>> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>
>> Please review attached diff.
>>
>> Thanks,
>> Qiang
> .
>
From sfu at real.com Tue Oct 4 03:29:43 2011
From: sfu at real.com (Sheldon Fu)
Date: Tue Oct 4 03:31:03 2011
Subject: [datatype-dev] CR: mp4 video render frame drop fix
In-Reply-To: <4E8A5554.7070504@real.com>
References: <4E8A3543.608@real.com> <4E8A5554.7070504@real.com>
Message-ID: <4E8A7DA7.2010207@real.com>
We may not want to move the ReturnDecodedPacket() block to the end of
the loop. If you do that, the return from CreateDecodedPacket will
*always* be NULL, making the method prototype quite meaningless and
changes the return code of DecodeFrame() too (it will in turn returns
always false while in old code it will be mostly true).
I think the function was designed to return the single decoded frame
(w/o calling ReturnDecodedPacket) when decoder has an one-in-one-out
behavior and when there could be one-in-multiple-out (or async output),
return all frames *but* the last one with ReturnDecodedPacket -- the
last one should always be returned by the method.
Although the safeguard change looks like a good idea but I am not sure
why we are seeing 'excessive video frame drops' in practice. All the
decoders we have has that one-in-one-out behavior so it should never
overflow the output buffer -- the base format class DecodeFrame only
calls CreateDecodedPacket when the output buffer is not full.
Hardware decoder on Android is async but we set the output queue size to
be the decoder output queue size so it will have no chance to overflow.
Only case I can think of that there is a problem is with the newly
modified Aricent decoder wrapper to support B frame re-ordering -- it
can return multiple frames with a single PNStream_Input call because of
internal buffering for re-ordering. In that case, indeed a fix is
needed, but still we probably want to keep the semantic meaning of
CreateDecodedPacket.
fxd
On 10/03/2011 08:37 PM, Jamie Gordon wrote:
> looks good!
>
> On 10/3/2011 3:20 PM, Qiang Luo wrote:
>> Overview:
>> We have seen excessive video frame drops for HLS/ts playback making the
>> video not smooth, like hiccups. Considerable amount of the frame drops
>> are not related to the video being decoded too late. The drops are in
>> fact caused by the output frame queue is full. In render, we should
>> never try to decode and move the frame to the output queue if there is
>> no room to hold it. In this CR, I added one fix in
>> CMP4VideoFormat::CreateDecodedPacket() and one check in
>> CMP4VideoFormat::DecodeFrame() to prevent "output-buffer-full frame
>> drop" from happening.
>>
>> Branches:
>> 310, 380 (I will also check the head and 361 branches to see if we need
>> this fix)
>>
>> File modified:
>> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>
>> Please review attached diff.
>>
>> Thanks,
>> Qiang
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
From qluo at real.com Tue Oct 4 04:15:18 2011
From: qluo at real.com (Qiang Luo)
Date: Tue Oct 4 04:16:32 2011
Subject: [datatype-dev] CR: mp4 video render frame drop fix
In-Reply-To: <4E8A7DA7.2010207@real.com>
References: <4E8A3543.608@real.com> <4E8A5554.7070504@real.com>
<4E8A7DA7.2010207@real.com>
Message-ID: <4E8A8856.4090508@real.com>
Thanks for the feedback Sheldon.
I thought about let CreateDecodedPacket() return the last decoded
frame. That requires a little bit more complicated check of the output
queue count to break the loop before it is full. Otherwise the framed
will be dropped in the base render. Since the returned last frame is
going to be put into the same output queue in the base render anyway, I
see no difference where to insert the frame.
We do have excessive video frame drops for some repro streams. For
/drop/13909/13909_3m.ts on the pss.real.com ftp share, Adam and I
observed 840 frame got dropped playing this 3-minute content, about 4.7
frames per second. With my fix, no video frame gets dropped.
Qiang
On 10/3/2011 8:29 PM, Sheldon Fu wrote:
> We may not want to move the ReturnDecodedPacket() block to the end of
> the loop. If you do that, the return from CreateDecodedPacket will
> *always* be NULL, making the method prototype quite meaningless and
> changes the return code of DecodeFrame() too (it will in turn returns
> always false while in old code it will be mostly true).
>
> I think the function was designed to return the single decoded frame
> (w/o calling ReturnDecodedPacket) when decoder has an one-in-one-out
> behavior and when there could be one-in-multiple-out (or async output),
> return all frames *but* the last one with ReturnDecodedPacket -- the
> last one should always be returned by the method.
>
> Although the safeguard change looks like a good idea but I am not sure
> why we are seeing 'excessive video frame drops' in practice. All the
> decoders we have has that one-in-one-out behavior so it should never
> overflow the output buffer -- the base format class DecodeFrame only
> calls CreateDecodedPacket when the output buffer is not full.
>
> Hardware decoder on Android is async but we set the output queue size to
> be the decoder output queue size so it will have no chance to overflow.
>
> Only case I can think of that there is a problem is with the newly
> modified Aricent decoder wrapper to support B frame re-ordering -- it
> can return multiple frames with a single PNStream_Input call because of
> internal buffering for re-ordering. In that case, indeed a fix is
> needed, but still we probably want to keep the semantic meaning of
> CreateDecodedPacket.
>
> fxd
>
> On 10/03/2011 08:37 PM, Jamie Gordon wrote:
>> looks good!
>>
>> On 10/3/2011 3:20 PM, Qiang Luo wrote:
>>> Overview:
>>> We have seen excessive video frame drops for HLS/ts playback making the
>>> video not smooth, like hiccups. Considerable amount of the frame drops
>>> are not related to the video being decoded too late. The drops are in
>>> fact caused by the output frame queue is full. In render, we should
>>> never try to decode and move the frame to the output queue if there is
>>> no room to hold it. In this CR, I added one fix in
>>> CMP4VideoFormat::CreateDecodedPacket() and one check in
>>> CMP4VideoFormat::DecodeFrame() to prevent "output-buffer-full frame
>>> drop" from happening.
>>>
>>> Branches:
>>> 310, 380 (I will also check the head and 361 branches to see if we need
>>> this fix)
>>>
>>> File modified:
>>> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>>
>>> Please review attached diff.
>>>
>>> Thanks,
>>> Qiang
>> _______________________________________________
>> Datatype-dev mailing list
>> Datatype-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>
> .
>
From sfu at real.com Tue Oct 4 04:23:29 2011
From: sfu at real.com (Sheldon Fu)
Date: Tue Oct 4 04:24:47 2011
Subject: [datatype-dev] CR: mp4 video render frame drop fix
In-Reply-To: <4E8A8856.4090508@real.com>
References: <4E8A3543.608@real.com> <4E8A5554.7070504@real.com>
<4E8A7DA7.2010207@real.com>,<4E8A8856.4090508@real.com>
Message-ID:
It does affect the return value of DecodeFrame itself and I think higher level logic too. You may want to double check. It may work may have some effect on how the decoder thread is running.
If you insist on your change then you need to cleanup the code after the loop. 'return pDecodedFrame' doesn't make sense anymore and only serve to confuse 3rd party reader.
The frame dropping is with the regular Aricent decoder? Did you find out why it can overflow the output queue? if the decoder can only return at most one frame per PNStream_Input call, this shouldn't happen at all.
fxd
________________________________________
From: Qiang Luo
Sent: Tuesday, October 04, 2011 12:15 AM
To: Sheldon Fu
Cc: Jamie Gordon; datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CR: mp4 video render frame drop fix
Thanks for the feedback Sheldon.
I thought about let CreateDecodedPacket() return the last decoded
frame. That requires a little bit more complicated check of the output
queue count to break the loop before it is full. Otherwise the framed
will be dropped in the base render. Since the returned last frame is
going to be put into the same output queue in the base render anyway, I
see no difference where to insert the frame.
We do have excessive video frame drops for some repro streams. For
/drop/13909/13909_3m.ts on the pss.real.com ftp share, Adam and I
observed 840 frame got dropped playing this 3-minute content, about 4.7
frames per second. With my fix, no video frame gets dropped.
Qiang
On 10/3/2011 8:29 PM, Sheldon Fu wrote:
> We may not want to move the ReturnDecodedPacket() block to the end of
> the loop. If you do that, the return from CreateDecodedPacket will
> *always* be NULL, making the method prototype quite meaningless and
> changes the return code of DecodeFrame() too (it will in turn returns
> always false while in old code it will be mostly true).
>
> I think the function was designed to return the single decoded frame
> (w/o calling ReturnDecodedPacket) when decoder has an one-in-one-out
> behavior and when there could be one-in-multiple-out (or async output),
> return all frames *but* the last one with ReturnDecodedPacket -- the
> last one should always be returned by the method.
>
> Although the safeguard change looks like a good idea but I am not sure
> why we are seeing 'excessive video frame drops' in practice. All the
> decoders we have has that one-in-one-out behavior so it should never
> overflow the output buffer -- the base format class DecodeFrame only
> calls CreateDecodedPacket when the output buffer is not full.
>
> Hardware decoder on Android is async but we set the output queue size to
> be the decoder output queue size so it will have no chance to overflow.
>
> Only case I can think of that there is a problem is with the newly
> modified Aricent decoder wrapper to support B frame re-ordering -- it
> can return multiple frames with a single PNStream_Input call because of
> internal buffering for re-ordering. In that case, indeed a fix is
> needed, but still we probably want to keep the semantic meaning of
> CreateDecodedPacket.
>
> fxd
>
> On 10/03/2011 08:37 PM, Jamie Gordon wrote:
>> looks good!
>>
>> On 10/3/2011 3:20 PM, Qiang Luo wrote:
>>> Overview:
>>> We have seen excessive video frame drops for HLS/ts playback making the
>>> video not smooth, like hiccups. Considerable amount of the frame drops
>>> are not related to the video being decoded too late. The drops are in
>>> fact caused by the output frame queue is full. In render, we should
>>> never try to decode and move the frame to the output queue if there is
>>> no room to hold it. In this CR, I added one fix in
>>> CMP4VideoFormat::CreateDecodedPacket() and one check in
>>> CMP4VideoFormat::DecodeFrame() to prevent "output-buffer-full frame
>>> drop" from happening.
>>>
>>> Branches:
>>> 310, 380 (I will also check the head and 361 branches to see if we need
>>> this fix)
>>>
>>> File modified:
>>> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>>
>>> Please review attached diff.
>>>
>>> Thanks,
>>> Qiang
>> _______________________________________________
>> Datatype-dev mailing list
>> Datatype-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>
> .
>
From qluo at real.com Tue Oct 4 05:16:06 2011
From: qluo at real.com (Qiang Luo)
Date: Tue Oct 4 05:17:24 2011
Subject: [datatype-dev] CR: mp4 video render frame drop fix
In-Reply-To:
References: <4E8A3543.608@real.com> <4E8A5554.7070504@real.com>
<4E8A7DA7.2010207@real.com>, <4E8A8856.4090508@real.com>
Message-ID: <4E8A9696.90602@real.com>
Sheldon,
Attached is the updated change. Does it address your concern?
Qiang
On 10/3/2011 9:23 PM, Sheldon Fu wrote:
> It does affect the return value of DecodeFrame itself and I think higher level logic too. You may want to double check. It may work may have some effect on how the decoder thread is running.
>
> If you insist on your change then you need to cleanup the code after the loop. 'return pDecodedFrame' doesn't make sense anymore and only serve to confuse 3rd party reader.
>
> The frame dropping is with the regular Aricent decoder? Did you find out why it can overflow the output queue? if the decoder can only return at most one frame per PNStream_Input call, this shouldn't happen at all.
>
> fxd
> ________________________________________
> From: Qiang Luo
> Sent: Tuesday, October 04, 2011 12:15 AM
> To: Sheldon Fu
> Cc: Jamie Gordon; datatype-dev@helixcommunity.org
> Subject: Re: [datatype-dev] CR: mp4 video render frame drop fix
>
> Thanks for the feedback Sheldon.
>
> I thought about let CreateDecodedPacket() return the last decoded
> frame. That requires a little bit more complicated check of the output
> queue count to break the loop before it is full. Otherwise the framed
> will be dropped in the base render. Since the returned last frame is
> going to be put into the same output queue in the base render anyway, I
> see no difference where to insert the frame.
>
> We do have excessive video frame drops for some repro streams. For
> /drop/13909/13909_3m.ts on the pss.real.com ftp share, Adam and I
> observed 840 frame got dropped playing this 3-minute content, about 4.7
> frames per second. With my fix, no video frame gets dropped.
>
> Qiang
>
> On 10/3/2011 8:29 PM, Sheldon Fu wrote:
>> We may not want to move the ReturnDecodedPacket() block to the end of
>> the loop. If you do that, the return from CreateDecodedPacket will
>> *always* be NULL, making the method prototype quite meaningless and
>> changes the return code of DecodeFrame() too (it will in turn returns
>> always false while in old code it will be mostly true).
>>
>> I think the function was designed to return the single decoded frame
>> (w/o calling ReturnDecodedPacket) when decoder has an one-in-one-out
>> behavior and when there could be one-in-multiple-out (or async output),
>> return all frames *but* the last one with ReturnDecodedPacket -- the
>> last one should always be returned by the method.
>>
>> Although the safeguard change looks like a good idea but I am not sure
>> why we are seeing 'excessive video frame drops' in practice. All the
>> decoders we have has that one-in-one-out behavior so it should never
>> overflow the output buffer -- the base format class DecodeFrame only
>> calls CreateDecodedPacket when the output buffer is not full.
>>
>> Hardware decoder on Android is async but we set the output queue size to
>> be the decoder output queue size so it will have no chance to overflow.
>>
>> Only case I can think of that there is a problem is with the newly
>> modified Aricent decoder wrapper to support B frame re-ordering -- it
>> can return multiple frames with a single PNStream_Input call because of
>> internal buffering for re-ordering. In that case, indeed a fix is
>> needed, but still we probably want to keep the semantic meaning of
>> CreateDecodedPacket.
>>
>> fxd
>>
>> On 10/03/2011 08:37 PM, Jamie Gordon wrote:
>>> looks good!
>>>
>>> On 10/3/2011 3:20 PM, Qiang Luo wrote:
>>>> Overview:
>>>> We have seen excessive video frame drops for HLS/ts playback making the
>>>> video not smooth, like hiccups. Considerable amount of the frame drops
>>>> are not related to the video being decoded too late. The drops are in
>>>> fact caused by the output frame queue is full. In render, we should
>>>> never try to decode and move the frame to the output queue if there is
>>>> no room to hold it. In this CR, I added one fix in
>>>> CMP4VideoFormat::CreateDecodedPacket() and one check in
>>>> CMP4VideoFormat::DecodeFrame() to prevent "output-buffer-full frame
>>>> drop" from happening.
>>>>
>>>> Branches:
>>>> 310, 380 (I will also check the head and 361 branches to see if we need
>>>> this fix)
>>>>
>>>> File modified:
>>>> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>>>
>>>> Please review attached diff.
>>>>
>>>> Thanks,
>>>> Qiang
>>> _______________________________________________
>>> Datatype-dev mailing list
>>> Datatype-dev@helixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>>
>> .
>>
> .
>
-------------- next part --------------
Index: mp4vdfmt.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp,v
retrieving revision 1.18.8.35
diff -u -w -r1.18.8.35 mp4vdfmt.cpp
--- mp4vdfmt.cpp 4 Aug 2011 01:55:43 -0000 1.18.8.35
+++ mp4vdfmt.cpp 4 Oct 2011 05:10:49 -0000
@@ -1268,7 +1268,9 @@
}
// See if more decoded frames are avaialable
- if (CanReturnDecodedPacket())
+ UINT32 ulOutFrameQueueFreeCount = GetDecodedFrameQueueFreeCount();
+ if ( ulOutFrameQueueFreeCount > 1 ||
+ (ulOutFrameQueueFreeCount > 0 && !pDecodedFrame))
{
pDecodedPacket = (HXCODEC_DATA*) m_pDecodedRngBuf->Get();
}
@@ -1656,6 +1658,9 @@
UINT32 bNPump=FALSE;
m_pDecoder->ProcessOutputFrames(&bNPump);
}
+
+ if (CanReturnDecodedPacket())
+ {
CMediaPacket* pPacket = CreateDecodedPacket(NULL);
if(pPacket)
{
@@ -1670,6 +1675,8 @@
{
bRet = FALSE;
}
+ }
+
m_pDecoderMutex->Unlock();
}
return bRet;
Index: pub/vidrendf.h
===================================================================
RCS file: /cvsroot/datatype/common/vidrend/pub/vidrendf.h,v
retrieving revision 1.21.2.8
diff -u -r1.21.2.8 vidrendf.h
--- pub/vidrendf.h 12 Dec 2010 21:55:48 -0000 1.21.2.8
+++ pub/vidrendf.h 4 Oct 2011 05:13:53 -0000
@@ -115,6 +115,11 @@
return !m_pOutputQueue->IsFull(TRUE);
}
+ UINT32 GetDecodedFrameQueueFreeCount() const
+ {
+ return (m_pOutputQueue->Size() - m_pOutputQueue->Count());
+ }
+
void OnRawPacketsEnded(void);
HXBOOL GetNextFrameTime(UINT32 &ulTime)
From sfu at real.com Tue Oct 4 12:31:40 2011
From: sfu at real.com (Sheldon Fu)
Date: Tue Oct 4 12:32:58 2011
Subject: [datatype-dev] CR: mp4 video render frame drop fix
In-Reply-To: <4E8A9696.90602@real.com>
References: <4E8A3543.608@real.com> <4E8A5554.7070504@real.com>
<4E8A7DA7.2010207@real.com>, <4E8A8856.4090508@real.com>
<4E8A9696.90602@real.com>
Message-ID: <4E8AFCAC.7080302@real.com>
This looks to be a safer change. It's only cosmetic but instead of
having both CanReturnDecodedPacket and GetDecodedFrameQueueFreeCount(),
it may look cleaner to redefine CanReturnDecodedPacket() to take a
parameter as intended number of the frames to return, with a default
value of 1.
I am still curious how frame dropping happens. Which decoder is this
with really?
fxd
On 10/04/2011 01:16 AM, Qiang Luo wrote:
> Sheldon,
>
> Attached is the updated change. Does it address your concern?
>
> Qiang
>
> On 10/3/2011 9:23 PM, Sheldon Fu wrote:
>> It does affect the return value of DecodeFrame itself and I think higher level logic too. You may want to double check. It may work may have some effect on how the decoder thread is running.
>>
>> If you insist on your change then you need to cleanup the code after the loop. 'return pDecodedFrame' doesn't make sense anymore and only serve to confuse 3rd party reader.
>>
>> The frame dropping is with the regular Aricent decoder? Did you find out why it can overflow the output queue? if the decoder can only return at most one frame per PNStream_Input call, this shouldn't happen at all.
>>
>> fxd
>> ________________________________________
>> From: Qiang Luo
>> Sent: Tuesday, October 04, 2011 12:15 AM
>> To: Sheldon Fu
>> Cc: Jamie Gordon; datatype-dev@helixcommunity.org
>> Subject: Re: [datatype-dev] CR: mp4 video render frame drop fix
>>
>> Thanks for the feedback Sheldon.
>>
>> I thought about let CreateDecodedPacket() return the last decoded
>> frame. That requires a little bit more complicated check of the output
>> queue count to break the loop before it is full. Otherwise the framed
>> will be dropped in the base render. Since the returned last frame is
>> going to be put into the same output queue in the base render anyway, I
>> see no difference where to insert the frame.
>>
>> We do have excessive video frame drops for some repro streams. For
>> /drop/13909/13909_3m.ts on the pss.real.com ftp share, Adam and I
>> observed 840 frame got dropped playing this 3-minute content, about 4.7
>> frames per second. With my fix, no video frame gets dropped.
>>
>> Qiang
>>
>> On 10/3/2011 8:29 PM, Sheldon Fu wrote:
>>> We may not want to move the ReturnDecodedPacket() block to the end of
>>> the loop. If you do that, the return from CreateDecodedPacket will
>>> *always* be NULL, making the method prototype quite meaningless and
>>> changes the return code of DecodeFrame() too (it will in turn returns
>>> always false while in old code it will be mostly true).
>>>
>>> I think the function was designed to return the single decoded frame
>>> (w/o calling ReturnDecodedPacket) when decoder has an one-in-one-out
>>> behavior and when there could be one-in-multiple-out (or async output),
>>> return all frames *but* the last one with ReturnDecodedPacket -- the
>>> last one should always be returned by the method.
>>>
>>> Although the safeguard change looks like a good idea but I am not sure
>>> why we are seeing 'excessive video frame drops' in practice. All the
>>> decoders we have has that one-in-one-out behavior so it should never
>>> overflow the output buffer -- the base format class DecodeFrame only
>>> calls CreateDecodedPacket when the output buffer is not full.
>>>
>>> Hardware decoder on Android is async but we set the output queue size to
>>> be the decoder output queue size so it will have no chance to overflow.
>>>
>>> Only case I can think of that there is a problem is with the newly
>>> modified Aricent decoder wrapper to support B frame re-ordering -- it
>>> can return multiple frames with a single PNStream_Input call because of
>>> internal buffering for re-ordering. In that case, indeed a fix is
>>> needed, but still we probably want to keep the semantic meaning of
>>> CreateDecodedPacket.
>>>
>>> fxd
>>>
>>> On 10/03/2011 08:37 PM, Jamie Gordon wrote:
>>>> looks good!
>>>>
>>>> On 10/3/2011 3:20 PM, Qiang Luo wrote:
>>>>> Overview:
>>>>> We have seen excessive video frame drops for HLS/ts playback making the
>>>>> video not smooth, like hiccups. Considerable amount of the frame drops
>>>>> are not related to the video being decoded too late. The drops are in
>>>>> fact caused by the output frame queue is full. In render, we should
>>>>> never try to decode and move the frame to the output queue if there is
>>>>> no room to hold it. In this CR, I added one fix in
>>>>> CMP4VideoFormat::CreateDecodedPacket() and one check in
>>>>> CMP4VideoFormat::DecodeFrame() to prevent "output-buffer-full frame
>>>>> drop" from happening.
>>>>>
>>>>> Branches:
>>>>> 310, 380 (I will also check the head and 361 branches to see if we need
>>>>> this fix)
>>>>>
>>>>> File modified:
>>>>> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>>>>
>>>>> Please review attached diff.
>>>>>
>>>>> Thanks,
>>>>> Qiang
>>>> _______________________________________________
>>>> Datatype-dev mailing list
>>>> Datatype-dev@helixcommunity.org
>>>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>>>
>>> .
>>>
>> .
>>
From qluo at real.com Tue Oct 4 13:04:40 2011
From: qluo at real.com (Qiang Luo)
Date: Tue Oct 4 13:05:57 2011
Subject: [datatype-dev] CR: mp4 video render frame drop fix
In-Reply-To: <4E8AFCAC.7080302@real.com>
References: <4E8A3543.608@real.com> <4E8A5554.7070504@real.com>
<4E8A7DA7.2010207@real.com>, <4E8A8856.4090508@real.com>
<4E8A9696.90602@real.com> <4E8AFCAC.7080302@real.com>
Message-ID: <4E8B0468.90905@real.com>
Thanks Sheldon. Attached is the new diff per your suggestion.
Branches:
head, 310, 380
Files modified:
/cvsroot/datatype/common/vidrend/pub/vidrendf.h
/cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
I'm seeing frame drops using software decoder on desktop and aricent
decoder on android. I think all repro contents have B-frames.
Qiang
On 10/4/2011 5:31 AM, Sheldon Fu wrote:
> This looks to be a safer change. It's only cosmetic but instead of
> having both CanReturnDecodedPacket and GetDecodedFrameQueueFreeCount(),
> it may look cleaner to redefine CanReturnDecodedPacket() to take a
> parameter as intended number of the frames to return, with a default
> value of 1.
>
> I am still curious how frame dropping happens. Which decoder is this
> with really?
>
> fxd
>
> On 10/04/2011 01:16 AM, Qiang Luo wrote:
>> Sheldon,
>>
>> Attached is the updated change. Does it address your concern?
>>
>> Qiang
>>
>> On 10/3/2011 9:23 PM, Sheldon Fu wrote:
>>> It does affect the return value of DecodeFrame itself and I think higher level logic too. You may want to double check. It may work may have some effect on how the decoder thread is running.
>>>
>>> If you insist on your change then you need to cleanup the code after the loop. 'return pDecodedFrame' doesn't make sense anymore and only serve to confuse 3rd party reader.
>>>
>>> The frame dropping is with the regular Aricent decoder? Did you find out why it can overflow the output queue? if the decoder can only return at most one frame per PNStream_Input call, this shouldn't happen at all.
>>>
>>> fxd
>>> ________________________________________
>>> From: Qiang Luo
>>> Sent: Tuesday, October 04, 2011 12:15 AM
>>> To: Sheldon Fu
>>> Cc: Jamie Gordon; datatype-dev@helixcommunity.org
>>> Subject: Re: [datatype-dev] CR: mp4 video render frame drop fix
>>>
>>> Thanks for the feedback Sheldon.
>>>
>>> I thought about let CreateDecodedPacket() return the last decoded
>>> frame. That requires a little bit more complicated check of the output
>>> queue count to break the loop before it is full. Otherwise the framed
>>> will be dropped in the base render. Since the returned last frame is
>>> going to be put into the same output queue in the base render anyway, I
>>> see no difference where to insert the frame.
>>>
>>> We do have excessive video frame drops for some repro streams. For
>>> /drop/13909/13909_3m.ts on the pss.real.com ftp share, Adam and I
>>> observed 840 frame got dropped playing this 3-minute content, about 4.7
>>> frames per second. With my fix, no video frame gets dropped.
>>>
>>> Qiang
>>>
>>> On 10/3/2011 8:29 PM, Sheldon Fu wrote:
>>>> We may not want to move the ReturnDecodedPacket() block to the end of
>>>> the loop. If you do that, the return from CreateDecodedPacket will
>>>> *always* be NULL, making the method prototype quite meaningless and
>>>> changes the return code of DecodeFrame() too (it will in turn returns
>>>> always false while in old code it will be mostly true).
>>>>
>>>> I think the function was designed to return the single decoded frame
>>>> (w/o calling ReturnDecodedPacket) when decoder has an one-in-one-out
>>>> behavior and when there could be one-in-multiple-out (or async output),
>>>> return all frames *but* the last one with ReturnDecodedPacket -- the
>>>> last one should always be returned by the method.
>>>>
>>>> Although the safeguard change looks like a good idea but I am not sure
>>>> why we are seeing 'excessive video frame drops' in practice. All the
>>>> decoders we have has that one-in-one-out behavior so it should never
>>>> overflow the output buffer -- the base format class DecodeFrame only
>>>> calls CreateDecodedPacket when the output buffer is not full.
>>>>
>>>> Hardware decoder on Android is async but we set the output queue size to
>>>> be the decoder output queue size so it will have no chance to overflow.
>>>>
>>>> Only case I can think of that there is a problem is with the newly
>>>> modified Aricent decoder wrapper to support B frame re-ordering -- it
>>>> can return multiple frames with a single PNStream_Input call because of
>>>> internal buffering for re-ordering. In that case, indeed a fix is
>>>> needed, but still we probably want to keep the semantic meaning of
>>>> CreateDecodedPacket.
>>>>
>>>> fxd
>>>>
>>>> On 10/03/2011 08:37 PM, Jamie Gordon wrote:
>>>>> looks good!
>>>>>
>>>>> On 10/3/2011 3:20 PM, Qiang Luo wrote:
>>>>>> Overview:
>>>>>> We have seen excessive video frame drops for HLS/ts playback making the
>>>>>> video not smooth, like hiccups. Considerable amount of the frame drops
>>>>>> are not related to the video being decoded too late. The drops are in
>>>>>> fact caused by the output frame queue is full. In render, we should
>>>>>> never try to decode and move the frame to the output queue if there is
>>>>>> no room to hold it. In this CR, I added one fix in
>>>>>> CMP4VideoFormat::CreateDecodedPacket() and one check in
>>>>>> CMP4VideoFormat::DecodeFrame() to prevent "output-buffer-full frame
>>>>>> drop" from happening.
>>>>>>
>>>>>> Branches:
>>>>>> 310, 380 (I will also check the head and 361 branches to see if we need
>>>>>> this fix)
>>>>>>
>>>>>> File modified:
>>>>>> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>>>>>
>>>>>> Please review attached diff.
>>>>>>
>>>>>> Thanks,
>>>>>> Qiang
>>>>> _______________________________________________
>>>>> Datatype-dev mailing list
>>>>> Datatype-dev@helixcommunity.org
>>>>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>>>>
>>>> .
>>>>
>>> .
>>>
> .
>
-------------- next part --------------
Index: pub/vidrendf.h
===================================================================
RCS file: /cvsroot/datatype/common/vidrend/pub/vidrendf.h,v
retrieving revision 1.21.2.8
diff -u -w -r1.21.2.8 vidrendf.h
--- pub/vidrendf.h 12 Dec 2010 21:55:48 -0000 1.21.2.8
+++ pub/vidrendf.h 4 Oct 2011 12:49:45 -0000
@@ -110,9 +110,10 @@
CMediaPacket* Dequeue(void);
virtual HXBOOL DecodeFrame(UINT32 ulMaxExtraFrames = MAX_VIDREND_DECODE_SPIN);
HXBOOL ReturnDecodedPacket(CMediaPacket* pDecodedPacket);
- HXBOOL CanReturnDecodedPacket(void)
+ HXBOOL CanReturnDecodedPacket(UINT32 ulRequestedCount = 1)
{
- return !m_pOutputQueue->IsFull(TRUE);
+ UINT32 ulFreeCount = m_pOutputQueue->Size() - m_pOutputQueue->Count();
+ return (ulFreeCount >= ulRequestedCount) ? TRUE : FALSE;
}
void OnRawPacketsEnded(void);
Index: mp4vdfmt.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp,v
retrieving revision 1.18.8.35
diff -u -w -r1.18.8.35 mp4vdfmt.cpp
--- mp4vdfmt.cpp 4 Aug 2011 01:55:43 -0000 1.18.8.35
+++ mp4vdfmt.cpp 4 Oct 2011 12:54:59 -0000
@@ -1268,7 +1268,8 @@
}
// See if more decoded frames are avaialable
- if (CanReturnDecodedPacket())
+ if ((CanReturnDecodedPacket(2) && pDecodedFrame) ||
+ (CanReturnDecodedPacket(1) && !pDecodedFrame))
{
pDecodedPacket = (HXCODEC_DATA*) m_pDecodedRngBuf->Get();
}
@@ -1656,6 +1657,9 @@
UINT32 bNPump=FALSE;
m_pDecoder->ProcessOutputFrames(&bNPump);
}
+
+ if (CanReturnDecodedPacket())
+ {
CMediaPacket* pPacket = CreateDecodedPacket(NULL);
if(pPacket)
{
@@ -1670,6 +1674,8 @@
{
bRet = FALSE;
}
+ }
+
m_pDecoderMutex->Unlock();
}
From sfu at real.com Tue Oct 4 14:02:58 2011
From: sfu at real.com (Sheldon Fu)
Date: Tue Oct 4 14:04:14 2011
Subject: [datatype-dev] CR: mp4 video render frame drop fix
In-Reply-To: <4E8B0468.90905@real.com>
References: <4E8A3543.608@real.com> <4E8A5554.7070504@real.com>
<4E8A7DA7.2010207@real.com>, <4E8A8856.4090508@real.com>
<4E8A9696.90602@real.com> <4E8AFCAC.7080302@real.com>
<4E8B0468.90905@real.com>
Message-ID: <4E8B1212.7020004@real.com>
It might be clearer to reformat the if condition, with some comment --
//we may need two spaces in the output queue for both pDecodedFrame and
the new packet
if (CanReturnDecodedPacket(pDecodedFrame ? 2 : 1))
The method CreateDecodedPacket is already hard to understand and with
some unnecessary logic I think (it's probably copied from the RV
renderer initially).
It makes sense that this is only a problem for content with B frames.
fxd
On 10/04/2011 09:04 AM, Qiang Luo wrote:
> Thanks Sheldon. Attached is the new diff per your suggestion.
>
> Branches:
> head, 310, 380
>
> Files modified:
> /cvsroot/datatype/common/vidrend/pub/vidrendf.h
> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>
> I'm seeing frame drops using software decoder on desktop and aricent
> decoder on android. I think all repro contents have B-frames.
>
> Qiang
>
> On 10/4/2011 5:31 AM, Sheldon Fu wrote:
>> This looks to be a safer change. It's only cosmetic but instead of
>> having both CanReturnDecodedPacket and GetDecodedFrameQueueFreeCount(),
>> it may look cleaner to redefine CanReturnDecodedPacket() to take a
>> parameter as intended number of the frames to return, with a default
>> value of 1.
>>
>> I am still curious how frame dropping happens. Which decoder is this
>> with really?
>>
>> fxd
>>
>> On 10/04/2011 01:16 AM, Qiang Luo wrote:
>>> Sheldon,
>>>
>>> Attached is the updated change. Does it address your concern?
>>>
>>> Qiang
>>>
>>> On 10/3/2011 9:23 PM, Sheldon Fu wrote:
>>>> It does affect the return value of DecodeFrame itself and I think higher level logic too. You may want to double check. It may work may have some effect on how the decoder thread is running.
>>>>
>>>> If you insist on your change then you need to cleanup the code after the loop. 'return pDecodedFrame' doesn't make sense anymore and only serve to confuse 3rd party reader.
>>>>
>>>> The frame dropping is with the regular Aricent decoder? Did you find out why it can overflow the output queue? if the decoder can only return at most one frame per PNStream_Input call, this shouldn't happen at all.
>>>>
>>>> fxd
>>>> ________________________________________
>>>> From: Qiang Luo
>>>> Sent: Tuesday, October 04, 2011 12:15 AM
>>>> To: Sheldon Fu
>>>> Cc: Jamie Gordon; datatype-dev@helixcommunity.org
>>>> Subject: Re: [datatype-dev] CR: mp4 video render frame drop fix
>>>>
>>>> Thanks for the feedback Sheldon.
>>>>
>>>> I thought about let CreateDecodedPacket() return the last decoded
>>>> frame. That requires a little bit more complicated check of the output
>>>> queue count to break the loop before it is full. Otherwise the framed
>>>> will be dropped in the base render. Since the returned last frame is
>>>> going to be put into the same output queue in the base render anyway, I
>>>> see no difference where to insert the frame.
>>>>
>>>> We do have excessive video frame drops for some repro streams. For
>>>> /drop/13909/13909_3m.ts on the pss.real.com ftp share, Adam and I
>>>> observed 840 frame got dropped playing this 3-minute content, about 4.7
>>>> frames per second. With my fix, no video frame gets dropped.
>>>>
>>>> Qiang
>>>>
>>>> On 10/3/2011 8:29 PM, Sheldon Fu wrote:
>>>>> We may not want to move the ReturnDecodedPacket() block to the end of
>>>>> the loop. If you do that, the return from CreateDecodedPacket will
>>>>> *always* be NULL, making the method prototype quite meaningless and
>>>>> changes the return code of DecodeFrame() too (it will in turn returns
>>>>> always false while in old code it will be mostly true).
>>>>>
>>>>> I think the function was designed to return the single decoded frame
>>>>> (w/o calling ReturnDecodedPacket) when decoder has an one-in-one-out
>>>>> behavior and when there could be one-in-multiple-out (or async output),
>>>>> return all frames *but* the last one with ReturnDecodedPacket -- the
>>>>> last one should always be returned by the method.
>>>>>
>>>>> Although the safeguard change looks like a good idea but I am not sure
>>>>> why we are seeing 'excessive video frame drops' in practice. All the
>>>>> decoders we have has that one-in-one-out behavior so it should never
>>>>> overflow the output buffer -- the base format class DecodeFrame only
>>>>> calls CreateDecodedPacket when the output buffer is not full.
>>>>>
>>>>> Hardware decoder on Android is async but we set the output queue size to
>>>>> be the decoder output queue size so it will have no chance to overflow.
>>>>>
>>>>> Only case I can think of that there is a problem is with the newly
>>>>> modified Aricent decoder wrapper to support B frame re-ordering -- it
>>>>> can return multiple frames with a single PNStream_Input call because of
>>>>> internal buffering for re-ordering. In that case, indeed a fix is
>>>>> needed, but still we probably want to keep the semantic meaning of
>>>>> CreateDecodedPacket.
>>>>>
>>>>> fxd
>>>>>
>>>>> On 10/03/2011 08:37 PM, Jamie Gordon wrote:
>>>>>> looks good!
>>>>>>
>>>>>> On 10/3/2011 3:20 PM, Qiang Luo wrote:
>>>>>>> Overview:
>>>>>>> We have seen excessive video frame drops for HLS/ts playback making the
>>>>>>> video not smooth, like hiccups. Considerable amount of the frame drops
>>>>>>> are not related to the video being decoded too late. The drops are in
>>>>>>> fact caused by the output frame queue is full. In render, we should
>>>>>>> never try to decode and move the frame to the output queue if there is
>>>>>>> no room to hold it. In this CR, I added one fix in
>>>>>>> CMP4VideoFormat::CreateDecodedPacket() and one check in
>>>>>>> CMP4VideoFormat::DecodeFrame() to prevent "output-buffer-full frame
>>>>>>> drop" from happening.
>>>>>>>
>>>>>>> Branches:
>>>>>>> 310, 380 (I will also check the head and 361 branches to see if we need
>>>>>>> this fix)
>>>>>>>
>>>>>>> File modified:
>>>>>>> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>>>>>>
>>>>>>> Please review attached diff.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Qiang
>>>>>> _______________________________________________
>>>>>> Datatype-dev mailing list
>>>>>> Datatype-dev@helixcommunity.org
>>>>>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>>>>>
>>>>> .
>>>>>
>>>> .
>>>>
>> .
>>
From qluo at real.com Tue Oct 4 17:13:03 2011
From: qluo at real.com (Qiang Luo)
Date: Tue Oct 4 17:14:26 2011
Subject: [datatype-dev] CR: mp4 video render frame drop fix
In-Reply-To: <4E8B1212.7020004@real.com>
References: <4E8A3543.608@real.com> <4E8A5554.7070504@real.com>
<4E8A7DA7.2010207@real.com>, <4E8A8856.4090508@real.com>
<4E8A9696.90602@real.com> <4E8AFCAC.7080302@real.com>
<4E8B0468.90905@real.com> <4E8B1212.7020004@real.com>
Message-ID: <4E8B3E9F.9040603@real.com>
Made recommended improvements and checked into head, 310, 380 branches.
Thanks,
Qiang
On 10/4/2011 7:02 AM, Sheldon Fu wrote:
> It might be clearer to reformat the if condition, with some comment --
>
> //we may need two spaces in the output queue for both pDecodedFrame and
> the new packet
> if (CanReturnDecodedPacket(pDecodedFrame ? 2 : 1))
>
> The method CreateDecodedPacket is already hard to understand and with
> some unnecessary logic I think (it's probably copied from the RV
> renderer initially).
>
> It makes sense that this is only a problem for content with B frames.
>
> fxd
>
> On 10/04/2011 09:04 AM, Qiang Luo wrote:
>> Thanks Sheldon. Attached is the new diff per your suggestion.
>>
>> Branches:
>> head, 310, 380
>>
>> Files modified:
>> /cvsroot/datatype/common/vidrend/pub/vidrendf.h
>> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>
>> I'm seeing frame drops using software decoder on desktop and aricent
>> decoder on android. I think all repro contents have B-frames.
>>
>> Qiang
>>
>> On 10/4/2011 5:31 AM, Sheldon Fu wrote:
>>> This looks to be a safer change. It's only cosmetic but instead of
>>> having both CanReturnDecodedPacket and GetDecodedFrameQueueFreeCount(),
>>> it may look cleaner to redefine CanReturnDecodedPacket() to take a
>>> parameter as intended number of the frames to return, with a default
>>> value of 1.
>>>
>>> I am still curious how frame dropping happens. Which decoder is this
>>> with really?
>>>
>>> fxd
>>>
>>> On 10/04/2011 01:16 AM, Qiang Luo wrote:
>>>> Sheldon,
>>>>
>>>> Attached is the updated change. Does it address your concern?
>>>>
>>>> Qiang
>>>>
>>>> On 10/3/2011 9:23 PM, Sheldon Fu wrote:
>>>>> It does affect the return value of DecodeFrame itself and I think higher level logic too. You may want to double check. It may work may have some effect on how the decoder thread is running.
>>>>>
>>>>> If you insist on your change then you need to cleanup the code after the loop. 'return pDecodedFrame' doesn't make sense anymore and only serve to confuse 3rd party reader.
>>>>>
>>>>> The frame dropping is with the regular Aricent decoder? Did you find out why it can overflow the output queue? if the decoder can only return at most one frame per PNStream_Input call, this shouldn't happen at all.
>>>>>
>>>>> fxd
>>>>> ________________________________________
>>>>> From: Qiang Luo
>>>>> Sent: Tuesday, October 04, 2011 12:15 AM
>>>>> To: Sheldon Fu
>>>>> Cc: Jamie Gordon; datatype-dev@helixcommunity.org
>>>>> Subject: Re: [datatype-dev] CR: mp4 video render frame drop fix
>>>>>
>>>>> Thanks for the feedback Sheldon.
>>>>>
>>>>> I thought about let CreateDecodedPacket() return the last decoded
>>>>> frame. That requires a little bit more complicated check of the output
>>>>> queue count to break the loop before it is full. Otherwise the framed
>>>>> will be dropped in the base render. Since the returned last frame is
>>>>> going to be put into the same output queue in the base render anyway, I
>>>>> see no difference where to insert the frame.
>>>>>
>>>>> We do have excessive video frame drops for some repro streams. For
>>>>> /drop/13909/13909_3m.ts on the pss.real.com ftp share, Adam and I
>>>>> observed 840 frame got dropped playing this 3-minute content, about 4.7
>>>>> frames per second. With my fix, no video frame gets dropped.
>>>>>
>>>>> Qiang
>>>>>
>>>>> On 10/3/2011 8:29 PM, Sheldon Fu wrote:
>>>>>> We may not want to move the ReturnDecodedPacket() block to the end of
>>>>>> the loop. If you do that, the return from CreateDecodedPacket will
>>>>>> *always* be NULL, making the method prototype quite meaningless and
>>>>>> changes the return code of DecodeFrame() too (it will in turn returns
>>>>>> always false while in old code it will be mostly true).
>>>>>>
>>>>>> I think the function was designed to return the single decoded frame
>>>>>> (w/o calling ReturnDecodedPacket) when decoder has an one-in-one-out
>>>>>> behavior and when there could be one-in-multiple-out (or async output),
>>>>>> return all frames *but* the last one with ReturnDecodedPacket -- the
>>>>>> last one should always be returned by the method.
>>>>>>
>>>>>> Although the safeguard change looks like a good idea but I am not sure
>>>>>> why we are seeing 'excessive video frame drops' in practice. All the
>>>>>> decoders we have has that one-in-one-out behavior so it should never
>>>>>> overflow the output buffer -- the base format class DecodeFrame only
>>>>>> calls CreateDecodedPacket when the output buffer is not full.
>>>>>>
>>>>>> Hardware decoder on Android is async but we set the output queue size to
>>>>>> be the decoder output queue size so it will have no chance to overflow.
>>>>>>
>>>>>> Only case I can think of that there is a problem is with the newly
>>>>>> modified Aricent decoder wrapper to support B frame re-ordering -- it
>>>>>> can return multiple frames with a single PNStream_Input call because of
>>>>>> internal buffering for re-ordering. In that case, indeed a fix is
>>>>>> needed, but still we probably want to keep the semantic meaning of
>>>>>> CreateDecodedPacket.
>>>>>>
>>>>>> fxd
>>>>>>
>>>>>> On 10/03/2011 08:37 PM, Jamie Gordon wrote:
>>>>>>> looks good!
>>>>>>>
>>>>>>> On 10/3/2011 3:20 PM, Qiang Luo wrote:
>>>>>>>> Overview:
>>>>>>>> We have seen excessive video frame drops for HLS/ts playback making the
>>>>>>>> video not smooth, like hiccups. Considerable amount of the frame drops
>>>>>>>> are not related to the video being decoded too late. The drops are in
>>>>>>>> fact caused by the output frame queue is full. In render, we should
>>>>>>>> never try to decode and move the frame to the output queue if there is
>>>>>>>> no room to hold it. In this CR, I added one fix in
>>>>>>>> CMP4VideoFormat::CreateDecodedPacket() and one check in
>>>>>>>> CMP4VideoFormat::DecodeFrame() to prevent "output-buffer-full frame
>>>>>>>> drop" from happening.
>>>>>>>>
>>>>>>>> Branches:
>>>>>>>> 310, 380 (I will also check the head and 361 branches to see if we need
>>>>>>>> this fix)
>>>>>>>>
>>>>>>>> File modified:
>>>>>>>> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>>>>>>>
>>>>>>>> Please review attached diff.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Qiang
>>>>>>> _______________________________________________
>>>>>>> Datatype-dev mailing list
>>>>>>> Datatype-dev@helixcommunity.org
>>>>>>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>>>>>>
>>>>>> .
>>>>>>
>>>>> .
>>>>>
>>> .
>>>
> .
>
From Joeli at real.com Sat Oct 8 02:36:36 2011
From: Joeli at real.com (Joe Li)
Date: Sat Oct 8 02:39:03 2011
Subject: [datatype-dev] CR: BUG 13948: there often pops up message "sorry,
this video cannot be played"
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: nullrend.cpp.diff
Type: application/octet-stream
Size: 692 bytes
Desc: nullrend.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111007/0c43fa5a/nullrend.cpp-0001.obj
From Joeli at real.com Sat Oct 8 02:57:08 2011
From: Joeli at real.com (Joe Li)
Date: Sat Oct 8 02:58:28 2011
Subject: [datatype-dev] CR: Bug 13974: some mpeg4 format .mkv files can't be
played
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkv_file_format.cpp.diff
Type: application/octet-stream
Size: 556 bytes
Desc: mkv_file_format.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111007/8c1b0d28/mkv_file_format.cpp.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nullrend.cpp.diff
Type: application/octet-stream
Size: 833 bytes
Desc: nullrend.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111007/8c1b0d28/nullrend.cpp.obj
From hxing at real.com Sat Oct 8 03:46:18 2011
From: hxing at real.com (Henry Xing)
Date: Sat Oct 8 03:47:42 2011
Subject: [datatype-dev] CR: mp4 video render frame drop fix
In-Reply-To: <4E8B1212.7020004@real.com>
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA094E65D40A@SEAMBX.corp.real.com>
Checked into 361_atlas branch.
henry
-----Original Message-----
From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Sheldon Fu
Sent: Tuesday, October 04, 2011 10:03 PM
To: Qiang Luo
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CR: mp4 video render frame drop fix
It might be clearer to reformat the if condition, with some comment --
//we may need two spaces in the output queue for both pDecodedFrame and
the new packet
if (CanReturnDecodedPacket(pDecodedFrame ? 2 : 1))
The method CreateDecodedPacket is already hard to understand and with
some unnecessary logic I think (it's probably copied from the RV
renderer initially).
It makes sense that this is only a problem for content with B frames.
fxd
On 10/04/2011 09:04 AM, Qiang Luo wrote:
> Thanks Sheldon. Attached is the new diff per your suggestion.
>
> Branches:
> head, 310, 380
>
> Files modified:
> /cvsroot/datatype/common/vidrend/pub/vidrendf.h
> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>
> I'm seeing frame drops using software decoder on desktop and aricent
> decoder on android. I think all repro contents have B-frames.
>
> Qiang
>
> On 10/4/2011 5:31 AM, Sheldon Fu wrote:
>> This looks to be a safer change. It's only cosmetic but instead of
>> having both CanReturnDecodedPacket and GetDecodedFrameQueueFreeCount(),
>> it may look cleaner to redefine CanReturnDecodedPacket() to take a
>> parameter as intended number of the frames to return, with a default
>> value of 1.
>>
>> I am still curious how frame dropping happens. Which decoder is this
>> with really?
>>
>> fxd
>>
>> On 10/04/2011 01:16 AM, Qiang Luo wrote:
>>> Sheldon,
>>>
>>> Attached is the updated change. Does it address your concern?
>>>
>>> Qiang
>>>
>>> On 10/3/2011 9:23 PM, Sheldon Fu wrote:
>>>> It does affect the return value of DecodeFrame itself and I think higher level logic too. You may want to double check. It may work may have some effect on how the decoder thread is running.
>>>>
>>>> If you insist on your change then you need to cleanup the code after the loop. 'return pDecodedFrame' doesn't make sense anymore and only serve to confuse 3rd party reader.
>>>>
>>>> The frame dropping is with the regular Aricent decoder? Did you find out why it can overflow the output queue? if the decoder can only return at most one frame per PNStream_Input call, this shouldn't happen at all.
>>>>
>>>> fxd
>>>> ________________________________________
>>>> From: Qiang Luo
>>>> Sent: Tuesday, October 04, 2011 12:15 AM
>>>> To: Sheldon Fu
>>>> Cc: Jamie Gordon; datatype-dev@helixcommunity.org
>>>> Subject: Re: [datatype-dev] CR: mp4 video render frame drop fix
>>>>
>>>> Thanks for the feedback Sheldon.
>>>>
>>>> I thought about let CreateDecodedPacket() return the last decoded
>>>> frame. That requires a little bit more complicated check of the output
>>>> queue count to break the loop before it is full. Otherwise the framed
>>>> will be dropped in the base render. Since the returned last frame is
>>>> going to be put into the same output queue in the base render anyway, I
>>>> see no difference where to insert the frame.
>>>>
>>>> We do have excessive video frame drops for some repro streams. For
>>>> /drop/13909/13909_3m.ts on the pss.real.com ftp share, Adam and I
>>>> observed 840 frame got dropped playing this 3-minute content, about 4.7
>>>> frames per second. With my fix, no video frame gets dropped.
>>>>
>>>> Qiang
>>>>
>>>> On 10/3/2011 8:29 PM, Sheldon Fu wrote:
>>>>> We may not want to move the ReturnDecodedPacket() block to the end of
>>>>> the loop. If you do that, the return from CreateDecodedPacket will
>>>>> *always* be NULL, making the method prototype quite meaningless and
>>>>> changes the return code of DecodeFrame() too (it will in turn returns
>>>>> always false while in old code it will be mostly true).
>>>>>
>>>>> I think the function was designed to return the single decoded frame
>>>>> (w/o calling ReturnDecodedPacket) when decoder has an one-in-one-out
>>>>> behavior and when there could be one-in-multiple-out (or async output),
>>>>> return all frames *but* the last one with ReturnDecodedPacket -- the
>>>>> last one should always be returned by the method.
>>>>>
>>>>> Although the safeguard change looks like a good idea but I am not sure
>>>>> why we are seeing 'excessive video frame drops' in practice. All the
>>>>> decoders we have has that one-in-one-out behavior so it should never
>>>>> overflow the output buffer -- the base format class DecodeFrame only
>>>>> calls CreateDecodedPacket when the output buffer is not full.
>>>>>
>>>>> Hardware decoder on Android is async but we set the output queue size to
>>>>> be the decoder output queue size so it will have no chance to overflow.
>>>>>
>>>>> Only case I can think of that there is a problem is with the newly
>>>>> modified Aricent decoder wrapper to support B frame re-ordering -- it
>>>>> can return multiple frames with a single PNStream_Input call because of
>>>>> internal buffering for re-ordering. In that case, indeed a fix is
>>>>> needed, but still we probably want to keep the semantic meaning of
>>>>> CreateDecodedPacket.
>>>>>
>>>>> fxd
>>>>>
>>>>> On 10/03/2011 08:37 PM, Jamie Gordon wrote:
>>>>>> looks good!
>>>>>>
>>>>>> On 10/3/2011 3:20 PM, Qiang Luo wrote:
>>>>>>> Overview:
>>>>>>> We have seen excessive video frame drops for HLS/ts playback making the
>>>>>>> video not smooth, like hiccups. Considerable amount of the frame drops
>>>>>>> are not related to the video being decoded too late. The drops are in
>>>>>>> fact caused by the output frame queue is full. In render, we should
>>>>>>> never try to decode and move the frame to the output queue if there is
>>>>>>> no room to hold it. In this CR, I added one fix in
>>>>>>> CMP4VideoFormat::CreateDecodedPacket() and one check in
>>>>>>> CMP4VideoFormat::DecodeFrame() to prevent "output-buffer-full frame
>>>>>>> drop" from happening.
>>>>>>>
>>>>>>> Branches:
>>>>>>> 310, 380 (I will also check the head and 361 branches to see if we need
>>>>>>> this fix)
>>>>>>>
>>>>>>> File modified:
>>>>>>> /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp
>>>>>>>
>>>>>>> Please review attached diff.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Qiang
>>>>>> _______________________________________________
>>>>>> Datatype-dev mailing list
>>>>>> Datatype-dev@helixcommunity.org
>>>>>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>>>>>>
>>>>> .
>>>>>
>>>> .
>>>>
>> .
>>
_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
From xzhao at real.com Sat Oct 8 13:54:34 2011
From: xzhao at real.com (Xiaolu Zhao)
Date: Sat Oct 8 13:57:19 2011
Subject: [datatype-dev] CR: [13972]Add support for ADTS AAC audio in mov file
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44508EE1B24C2@SEAMBX.corp.real.com>
Modified by: xzhao@real.com
Project: RealPlayer for Android Smartphones
Bug Number: 13972
Bug URL: https://bugs.helixcommunity.org/show_bug.cgi?id=13972
Synopsis: Add support for ADTS AAC audio in mov file
Overview: Currently ADTS AAC audio stream in mov is not supported. In order to support ADTS AAC audio stream, have to get the first audio frame as opaque data to init audio decoder. In this patch, when found it is ADTS AAC stream, clear inproper opaque data(which is some version int). While build stream header in CQTTrack and find out opaque data is null, then get a packet for that stream. While packet is ready, set opaque data in reserved stream header.
Currently I use MP4OBJ_AUDIO_ISO_IEC_14496_3_D and "mp4a" as the indicator for ADTS AAC audio stream. Not sure this criteria is correct all clips. ISO/IEC 14496 has multiple audio codec including AAC. Please correct me if I am wrong.
Files Modified:
qtatmmgs.cpp
qtffplin.cpp
qttrack.cpp
pub/iqttrack.h
pub/qttrack.h
Platforms and Profiles Affected:
Platform: hxclient_3_1_0_atlas hxclient_3_6_1_atlas
Profile: helix-client-android-full
Copyright assignment: I am a RealNetworks employee or contractor
Best Regards
Zhao Xiaolu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp4fileformat.diff
Type: text/x-diff
Size: 7308 bytes
Desc: mp4fileformat.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111008/91651a08/mp4fileformat-0001.bin
From hxing at real.com Sat Oct 8 13:57:30 2011
From: hxing at real.com (Henry Xing)
Date: Sat Oct 8 13:58:37 2011
Subject: [datatype-dev] CR: can not play video in the sina wibo application
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA094E65D413@SEAMBX.corp.real.com>
Skipped content of type multipart/alternative-------------- next part --------------
Index: atomizer.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/atomizer.cpp,v
retrieving revision 1.18.8.6.2.4
diff -u -w -r1.18.8.6.2.4 atomizer.cpp
--- atomizer.cpp 5 May 2011 02:08:09 -0000 1.18.8.6.2.4
+++ atomizer.cpp 8 Oct 2011 12:17:30 -0000
@@ -1010,6 +1010,7 @@
* this file is likely formatted for
* progressive download
*/
+ m_ulCurrentOffset = m_ulFinalOffset;
CompleteAtomization(HXR_OK);
}
else
From hxing at real.com Sat Oct 8 13:59:15 2011
From: hxing at real.com (Henry Xing)
Date: Sat Oct 8 14:00:35 2011
Subject: [datatype-dev] RE: CR: can not play video in the sina wibo
application
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA094E65D415@SEAMBX.corp.real.com>
Skipped content of type multipart/alternative-------------- next part --------------
Index: atomizer.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/fileformat/atomizer.cpp,v
retrieving revision 1.18.8.6.2.4
diff -u -w -r1.18.8.6.2.4 atomizer.cpp
--- atomizer.cpp 5 May 2011 02:08:09 -0000 1.18.8.6.2.4
+++ atomizer.cpp 8 Oct 2011 12:17:30 -0000
@@ -1010,6 +1010,7 @@
* this file is likely formatted for
* progressive download
*/
+ m_ulCurrentOffset = m_ulFinalOffset;
CompleteAtomization(HXR_OK);
}
else
From xzhao at real.com Sun Oct 9 06:21:29 2011
From: xzhao at real.com (Xiaolu Zhao)
Date: Sun Oct 9 06:27:16 2011
Subject: [datatype-dev] RE: [13972]Add support for ADTS AAC audio in mov file
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC44508EE1B24C2@SEAMBX.corp.real.com>
References: <766B5A29D28DA442AB229AAEE2AFC44508EE1B24C2@SEAMBX.corp.real.com>
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44508EE1B24C4@SEAMBX.corp.real.com>
Update the patch, which is to change the ADTS detect method. According to more streams test, I found MP4OBJ_AUDIO_ISO_IEC_14496_3_D and "mp4a" are not enough to detect ADTS AAC clip in mov, such as raw AAC has the same property. I also checked all the property in its header(file header, movie header and stream header), none of them indicate it is ADTS AAC. So I think the last way to detect is to read a packet at first and tell. All the clips in hand can play well with this patch.
Best Regards
Zhao Xiaolu
________________________________________
From: Xiaolu Zhao
Sent: Saturday, October 08, 2011 9:54 PM
To: android-port-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: CR: [13972]Add support for ADTS AAC audio in mov file
Modified by: xzhao@real.com
Project: RealPlayer for Android Smartphones
Bug Number: 13972
Bug URL: https://bugs.helixcommunity.org/show_bug.cgi?id=13972
Synopsis: Add support for ADTS AAC audio in mov file
Overview: Currently ADTS AAC audio stream in mov is not supported. In order to support ADTS AAC audio stream, have to get the first audio frame as opaque data to init audio decoder. In this patch, when found it is ADTS AAC stream, clear inproper opaque data(which is some version int). While build stream header in CQTTrack and find out opaque data is null, then get a packet for that stream. While packet is ready, set opaque data in reserved stream header.
Currently I use MP4OBJ_AUDIO_ISO_IEC_14496_3_D and "mp4a" as the indicator for ADTS AAC audio stream. Not sure this criteria is correct all clips. ISO/IEC 14496 has multiple audio codec including AAC. Please correct me if I am wrong.
Files Modified:
qtatmmgs.cpp
qtffplin.cpp
qttrack.cpp
pub/iqttrack.h
pub/qttrack.h
Platforms and Profiles Affected:
Platform: hxclient_3_1_0_atlas hxclient_3_6_1_atlas
Profile: helix-client-android-full
Copyright assignment: I am a RealNetworks employee or contractor
Best Regards
Zhao Xiaolu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp4fileformat1.diff
Type: text/x-diff
Size: 9064 bytes
Desc: mp4fileformat1.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111008/a837ed1b/mp4fileformat1-0001.bin
From qluo at real.com Sun Oct 9 06:40:19 2011
From: qluo at real.com (Qiang Luo)
Date: Sun Oct 9 06:41:43 2011
Subject: [datatype-dev] CR: can not play video in the sina wibo application
In-Reply-To: <7ECCEA249B7CDC49A079EC0075E999AA094E65D413@SEAMBX.corp.real.com>
References: <7ECCEA249B7CDC49A079EC0075E999AA094E65D413@SEAMBX.corp.real.com>
Message-ID: <4E9141D3.4070807@real.com>
Looks good.
Qiang
On 10/8/2011 6:57 AM, Henry Xing wrote:
>
> Modified by: hxing@real.com
>
> Synopsis: can not play video in the sina wibo application
>
> Overview:
>
> For progressive download file, skip mdat atom and just finish the
> atomization. But in this scenario the variable m_ulCurrentOffset is
> less than m_ulFinalOffset, so set the variable m_ulCurrentOffset with
> the value of m_ulFinalOffset, otherwise this file will be handled as a
> corrupt file in function CompleteAtomization();
>
> Files Modified:
>
> datatype/mp4/fileformat/atomizer.cpp
>
> Platforms and Profiles Affected:
>
> Platform: 361 310 and head
>
> Profile: helix-client-android-full
>
> Copyright assignment: I am a RealNetworks employee or contractor
>
> Best Regards
>
> Henry hhsing
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111008/113284a4/attachment.html
From qluo at real.com Sun Oct 9 06:43:12 2011
From: qluo at real.com (Qiang Luo)
Date: Sun Oct 9 06:59:52 2011
Subject: [datatype-dev] CR: Bug 13974: some mpeg4 format .mkv files can't
be played
In-Reply-To:
References:
Message-ID: <4E914280.10402@real.com>
Looks good.
Qiang
On 10/7/2011 7:57 PM, Joe Li wrote:
>
> Modified by: joeli@real.com
>
> Date: 10/08/2011
>
> Project: RealPlayer for Android Smartphones
>
> Synopsis: add nullrender for mkv audio stream and support MFP4 in mkv
>
> According to the customer?s request.
>
> We add nullrender for mkv audio stream, if the file?s audio not
> supported but video available, we should play this file.
>
> And enable MFP4 mpeg4 fileformat supported in mkv content.
>
> Files Added:
>
> N/A
>
> File Modified:
>
> datatype/mkv/fileformat/mkv_file_format.cpp
>
> datatype/null/renderer/nullrender.cpp
>
> Image Size and Heap Use impact (Client -Only):
>
> None
>
> Platforms and Profiles Affected:
>
> Platform: hxclient_3_6_1_atlas
>
> Profile: helix-client-android-full
>
> Distribution Libraries Affected:
>
> None
>
> Distribution library impact and planned action:
>
> None
>
> Thanks
>
> Joe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111008/b2a7c44c/attachment.html
From qluo at real.com Sun Oct 9 07:55:05 2011
From: qluo at real.com (Qiang Luo)
Date: Sun Oct 9 08:29:24 2011
Subject: [datatype-dev] CR: BUG 13948: there often pops up message "sorry,
this video cannot be played"
In-Reply-To:
References:
Message-ID: <4E915359.8080008@real.com>
Looks good.
Qiang
On 10/7/2011 7:36 PM, Joe Li wrote:
>
> Modified by: joeli@real.com
>
> Date: 10/08/2011
>
> Project: RealPlayer for Android Smartphones
>
> Synopsis: BUG 13948: there often pops up message ?sorry,this video
> cannot be played?
>
> When scanning some avi media files, due to the mimetype of video
> stream is not supported. It will use null renderer to match the video
> stream.
>
> While if it failed to LoadUntimedRendererForStreamHeader, it will new
> CStubVideoPlayer and CStubStream, and set the CStubStream
> GetStreamType to null;
>
> So it crashed at nullrend?s StartStream, we should handle this case in
> nullrend.cpp.
>
> Files Added:
>
> N/A
>
> File Modified:
>
> datatype/null/renderer/nullrender.cpp
>
> Image Size and Heap Use impact (Client -Only):
>
> None
>
> Platforms and Profiles Affected:
>
> Platform: hxclient_3_6_1_atlas
>
> Profile: helix-client-android-full
>
> Distribution Libraries Affected:
>
> None
>
> Distribution library impact and planned action:
>
> None
>
> Thanks
>
> Joe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111009/8c321319/attachment-0001.html
From hxing at real.com Sun Oct 9 09:20:39 2011
From: hxing at real.com (Henry Xing)
Date: Sun Oct 9 09:54:31 2011
Subject: [datatype-dev] CR: can not play video in the sina wibo application
In-Reply-To: <4E9141D3.4070807@real.com>
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA094E65D433@SEAMBX.corp.real.com>
Thanks! Checked into 310 and 361. The some logic already exist in head branch
henry
________________________________
From: Qiang Luo
Sent: Sunday, October 09, 2011 2:40 PM
To: Henry Xing
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CR: can not play video in the sina wibo application
Looks good.
Qiang
On 10/8/2011 6:57 AM, Henry Xing wrote:
Modified by: hxing@real.com
Synopsis: can not play video in the sina wibo application
Overview:
For progressive download file, skip mdat atom and just finish the atomization. But in this scenario the variable m_ulCurrentOffset is less than m_ulFinalOffset, so set the variable m_ulCurrentOffset with the value of m_ulFinalOffset, otherwise this file will be handled as a corrupt file in function CompleteAtomization();
Files Modified:
datatype/mp4/fileformat/atomizer.cpp
Platforms and Profiles Affected:
Platform: 361 310 and head
Profile: helix-client-android-full
Copyright assignment: I am a RealNetworks employee or contractor
Best Regards
Henry hhsing
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111009/233c1934/attachment.html
From Joeli at real.com Sun Oct 9 11:59:33 2011
From: Joeli at real.com (Joe Li)
Date: Sun Oct 9 12:01:08 2011
Subject: [datatype-dev] CR; enable divx in mp4 container and mp2 in mkv
container
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkv_file_format.cpp.diff
Type: application/octet-stream
Size: 561 bytes
Desc: mkv_file_format.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111009/2c291be3/mkv_file_format.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp4ff.diff
Type: application/octet-stream
Size: 1911 bytes
Desc: mp4ff.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111009/2c291be3/mp4ff-0001.obj
From Joeli at real.com Sun Oct 9 07:42:21 2011
From: Joeli at real.com (Joe Li)
Date: Sun Oct 9 12:59:45 2011
Subject: [datatype-dev] CR: Bug 13974: some mpeg4 format .mkv files
can't be played
In-Reply-To: <4E914280.10402@real.com>
Message-ID:
Thanks Qiang
Checked in 361atlas
Joe
________________________________
From: Qiang Luo
Sent: Sunday, October 09, 2011 2:43 PM
To: Joe Li
Cc: datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CR: Bug 13974: some mpeg4 format .mkv files can't be played
Looks good.
Qiang
On 10/7/2011 7:57 PM, Joe Li wrote:
Modified by: joeli@real.com
Date: 10/08/2011
Project: RealPlayer for Android Smartphones
Synopsis: add nullrender for mkv audio stream and support MFP4 in mkv
According to the customer's request.
We add nullrender for mkv audio stream, if the file's audio not supported but video available, we should play this file.
And enable MFP4 mpeg4 fileformat supported in mkv content.
Files Added:
N/A
File Modified:
datatype/mkv/fileformat/mkv_file_format.cpp
datatype/null/renderer/nullrender.cpp
Image Size and Heap Use impact (Client -Only):
None
Platforms and Profiles Affected:
Platform: hxclient_3_6_1_atlas
Profile: helix-client-android-full
Distribution Libraries Affected:
None
Distribution library impact and planned action:
None
Thanks
Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111009/d6da06a4/attachment.html
From Joeli at real.com Mon Oct 10 02:25:34 2011
From: Joeli at real.com (Joe Li)
Date: Mon Oct 10 02:26:59 2011
Subject: [datatype-dev] RE: [Android-port-dev] RE: [13972]Add support for
ADTS AAC audio in mov file
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC44508EE1B24C4@SEAMBX.corp.real.com>
Message-ID:
I think we should detect AAC as the follow configuration types: eAACConfigADIF,eAACConfigADTS,eAACConfigAudioSpecificCfg.
No just for ADTS config type;
Meanwhile as for some wrong generic mimetype to be checked in the first audio packet:
+ // If it contain the most basic mimetype, need to get a packet to detect its mux type
+ if (SUCCEEDED(retVal) && strstr(m_TrackInfo.GetMimeType(), "X-RN-QT-RAWAU"))
+ {
Maybe we can set the correct mimetype before its done.
Thanks
Joe
-----Original Message-----
From: android-port-dev-bounces@lists.helixcommunity.org [mailto:android-port-dev-bounces@lists.helixcommunity.org] On Behalf Of Xiaolu Zhao
Sent: Sunday, October 09, 2011 2:21 PM
To: Xiaolu Zhao; android-port-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: [Android-port-dev] RE: [13972]Add support for ADTS AAC audio in mov file
Update the patch, which is to change the ADTS detect method. According to more streams test, I found MP4OBJ_AUDIO_ISO_IEC_14496_3_D and "mp4a" are not enough to detect ADTS AAC clip in mov, such as raw AAC has the same property. I also checked all the property in its header(file header, movie header and stream header), none of them indicate it is ADTS AAC. So I think the last way to detect is to read a packet at first and tell. All the clips in hand can play well with this patch.
Best Regards
Zhao Xiaolu
________________________________________
From: Xiaolu Zhao
Sent: Saturday, October 08, 2011 9:54 PM
To: android-port-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: CR: [13972]Add support for ADTS AAC audio in mov file
Modified by: xzhao@real.com
Project: RealPlayer for Android Smartphones
Bug Number: 13972
Bug URL: https://bugs.helixcommunity.org/show_bug.cgi?id=13972
Synopsis: Add support for ADTS AAC audio in mov file
Overview: Currently ADTS AAC audio stream in mov is not supported. In order to support ADTS AAC audio stream, have to get the first audio frame as opaque data to init audio decoder. In this patch, when found it is ADTS AAC stream, clear inproper opaque data(which is some version int). While build stream header in CQTTrack and find out opaque data is null, then get a packet for that stream. While packet is ready, set opaque data in reserved stream header.
Currently I use MP4OBJ_AUDIO_ISO_IEC_14496_3_D and "mp4a" as the indicator for ADTS AAC audio stream. Not sure this criteria is correct all clips. ISO/IEC 14496 has multiple audio codec including AAC. Please correct me if I am wrong.
Files Modified:
qtatmmgs.cpp
qtffplin.cpp
qttrack.cpp
pub/iqttrack.h
pub/qttrack.h
Platforms and Profiles Affected:
Platform: hxclient_3_1_0_atlas hxclient_3_6_1_atlas
Profile: helix-client-android-full
Copyright assignment: I am a RealNetworks employee or contractor
Best Regards
Zhao Xiaolu
From Joeli at real.com Mon Oct 10 06:41:29 2011
From: Joeli at real.com (Joe Li)
Date: Mon Oct 10 06:43:05 2011
Subject: [datatype-dev] RE: [Android-port-dev] RE: [13972]Add support for
ADTS AAC audio in mov file
In-Reply-To:
Message-ID:
As for ADTS AAC.
It looks good to me.
Thanks
Joe
-----Original Message-----
From: android-port-dev-bounces@lists.helixcommunity.org [mailto:android-port-dev-bounces@lists.helixcommunity.org] On Behalf Of Joe Li
Sent: Monday, October 10, 2011 10:26 AM
To: Xiaolu Zhao; android-port-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: RE: [Android-port-dev] RE: [13972]Add support for ADTS AAC audio in mov file
I think we should detect AAC as the follow configuration types: eAACConfigADIF,eAACConfigADTS,eAACConfigAudioSpecificCfg.
No just for ADTS config type;
Meanwhile as for some wrong generic mimetype to be checked in the first audio packet:
+ // If it contain the most basic mimetype, need to get a packet to detect its mux type
+ if (SUCCEEDED(retVal) && strstr(m_TrackInfo.GetMimeType(), "X-RN-QT-RAWAU"))
+ {
Maybe we can set the correct mimetype before its done.
Thanks
Joe
-----Original Message-----
From: android-port-dev-bounces@lists.helixcommunity.org [mailto:android-port-dev-bounces@lists.helixcommunity.org] On Behalf Of Xiaolu Zhao
Sent: Sunday, October 09, 2011 2:21 PM
To: Xiaolu Zhao; android-port-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: [Android-port-dev] RE: [13972]Add support for ADTS AAC audio in mov file
Update the patch, which is to change the ADTS detect method. According to more streams test, I found MP4OBJ_AUDIO_ISO_IEC_14496_3_D and "mp4a" are not enough to detect ADTS AAC clip in mov, such as raw AAC has the same property. I also checked all the property in its header(file header, movie header and stream header), none of them indicate it is ADTS AAC. So I think the last way to detect is to read a packet at first and tell. All the clips in hand can play well with this patch.
Best Regards
Zhao Xiaolu
________________________________________
From: Xiaolu Zhao
Sent: Saturday, October 08, 2011 9:54 PM
To: android-port-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: CR: [13972]Add support for ADTS AAC audio in mov file
Modified by: xzhao@real.com
Project: RealPlayer for Android Smartphones
Bug Number: 13972
Bug URL: https://bugs.helixcommunity.org/show_bug.cgi?id=13972
Synopsis: Add support for ADTS AAC audio in mov file
Overview: Currently ADTS AAC audio stream in mov is not supported. In order to support ADTS AAC audio stream, have to get the first audio frame as opaque data to init audio decoder. In this patch, when found it is ADTS AAC stream, clear inproper opaque data(which is some version int). While build stream header in CQTTrack and find out opaque data is null, then get a packet for that stream. While packet is ready, set opaque data in reserved stream header.
Currently I use MP4OBJ_AUDIO_ISO_IEC_14496_3_D and "mp4a" as the indicator for ADTS AAC audio stream. Not sure this criteria is correct all clips. ISO/IEC 14496 has multiple audio codec including AAC. Please correct me if I am wrong.
Files Modified:
qtatmmgs.cpp
qtffplin.cpp
qttrack.cpp
pub/iqttrack.h
pub/qttrack.h
Platforms and Profiles Affected:
Platform: hxclient_3_1_0_atlas hxclient_3_6_1_atlas
Profile: helix-client-android-full
Copyright assignment: I am a RealNetworks employee or contractor
Best Regards
Zhao Xiaolu
_______________________________________________
Android-port-dev mailing list
Android-port-dev@lists.helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/android-port-dev
From Joeli at real.com Mon Oct 10 07:34:00 2011
From: Joeli at real.com (Joe Li)
Date: Mon Oct 10 07:35:22 2011
Subject: [datatype-dev] CR:Bug 13687: h.264/mpeg1 format .MOV file can't
play as normal in android
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: qtatmmgs.cpp.diff
Type: application/octet-stream
Size: 1153 bytes
Desc: qtatmmgs.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111010/9633f1cd/qtatmmgs.cpp-0001.obj
From xzhao at real.com Mon Oct 10 07:35:14 2011
From: xzhao at real.com (Xiaolu Zhao)
Date: Mon Oct 10 07:37:17 2011
Subject: [datatype-dev] RE: [Android-port-dev] RE: [13972]Add support for
ADTS AAC audio in mov file
In-Reply-To:
References: ,
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44508EE1B24D0@SEAMBX.corp.real.com>
Thank you Joe. Update the patch a little bit. Updated patch as attached. Checked into 361Atlas.
Best Regards
Zhao Xiaolu
________________________________________
From: Joe Li
Sent: Monday, October 10, 2011 2:41 PM
To: Joe Li; Xiaolu Zhao; android-port-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: RE: [Android-port-dev] RE: [13972]Add support for ADTS AAC audio in mov file
As for ADTS AAC.
It looks good to me.
Thanks
Joe
-----Original Message-----
From: android-port-dev-bounces@lists.helixcommunity.org [mailto:android-port-dev-bounces@lists.helixcommunity.org] On Behalf Of Joe Li
Sent: Monday, October 10, 2011 10:26 AM
To: Xiaolu Zhao; android-port-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: RE: [Android-port-dev] RE: [13972]Add support for ADTS AAC audio in mov file
I think we should detect AAC as the follow configuration types: eAACConfigADIF,eAACConfigADTS,eAACConfigAudioSpecificCfg.
No just for ADTS config type;
Meanwhile as for some wrong generic mimetype to be checked in the first audio packet:
+ // If it contain the most basic mimetype, need to get a packet to detect its mux type
+ if (SUCCEEDED(retVal) && strstr(m_TrackInfo.GetMimeType(), "X-RN-QT-RAWAU"))
+ {
Maybe we can set the correct mimetype before its done.
Thanks
Joe
-----Original Message-----
From: android-port-dev-bounces@lists.helixcommunity.org [mailto:android-port-dev-bounces@lists.helixcommunity.org] On Behalf Of Xiaolu Zhao
Sent: Sunday, October 09, 2011 2:21 PM
To: Xiaolu Zhao; android-port-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: [Android-port-dev] RE: [13972]Add support for ADTS AAC audio in mov file
Update the patch, which is to change the ADTS detect method. According to more streams test, I found MP4OBJ_AUDIO_ISO_IEC_14496_3_D and "mp4a" are not enough to detect ADTS AAC clip in mov, such as raw AAC has the same property. I also checked all the property in its header(file header, movie header and stream header), none of them indicate it is ADTS AAC. So I think the last way to detect is to read a packet at first and tell. All the clips in hand can play well with this patch.
Best Regards
Zhao Xiaolu
________________________________________
From: Xiaolu Zhao
Sent: Saturday, October 08, 2011 9:54 PM
To: android-port-dev@helixcommunity.org; datatype-dev@helixcommunity.org
Subject: CR: [13972]Add support for ADTS AAC audio in mov file
Modified by: xzhao@real.com
Project: RealPlayer for Android Smartphones
Bug Number: 13972
Bug URL: https://bugs.helixcommunity.org/show_bug.cgi?id=13972
Synopsis: Add support for ADTS AAC audio in mov file
Overview: Currently ADTS AAC audio stream in mov is not supported. In order to support ADTS AAC audio stream, have to get the first audio frame as opaque data to init audio decoder. In this patch, when found it is ADTS AAC stream, clear inproper opaque data(which is some version int). While build stream header in CQTTrack and find out opaque data is null, then get a packet for that stream. While packet is ready, set opaque data in reserved stream header.
Currently I use MP4OBJ_AUDIO_ISO_IEC_14496_3_D and "mp4a" as the indicator for ADTS AAC audio stream. Not sure this criteria is correct all clips. ISO/IEC 14496 has multiple audio codec including AAC. Please correct me if I am wrong.
Files Modified:
qtatmmgs.cpp
qtffplin.cpp
qttrack.cpp
pub/iqttrack.h
pub/qttrack.h
Platforms and Profiles Affected:
Platform: hxclient_3_1_0_atlas hxclient_3_6_1_atlas
Profile: helix-client-android-full
Copyright assignment: I am a RealNetworks employee or contractor
Best Regards
Zhao Xiaolu
_______________________________________________
Android-port-dev mailing list
Android-port-dev@lists.helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/android-port-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp4fileformat.diff
Type: text/x-diff
Size: 6910 bytes
Desc: mp4fileformat.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111010/9379885c/mp4fileformat.bin
From ext-pritam.biswas at nokia.com Mon Oct 10 09:30:02 2011
From: ext-pritam.biswas at nokia.com (ext-pritam.biswas@nokia.com)
Date: Mon Oct 10 09:31:40 2011
Subject: [datatype-dev] CR: ou1cimx1#884650: Videos: System error occurs
when trying to drag playback progress bar beyond download
progress bar d
References: <000c01cc63d2$20cf72d0$626e5870$@dasari@nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D0D@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D19@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D23@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D29@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D2B@xesebe102.nee.nokia.com>,
<4AFF7497EFFE48469E4D2A776D6ED3EF592D2C@xesebe102.nee.nokia.com>
<170F1AEE-C790-47DD-98AB-45FBE1ABCCF1@mimectl>
Message-ID: <4AFF7497EFFE48469E4D2A776D6ED3EF592D2F@xesebe102.nee.nokia.com>
"Nokia submits this code under the terms of a commercial contribution agreement with Real Networks, and I am authorized to contribute this code under said agreement."
Modified by: EXT-Pritam.Biswas@nokia.com
Reviewed by: dongsung.kim@nokia.com
ext-nadeem.wahid@nokia.com
RC Id: ou1cimx1#884650
Date: 10/10/2011.
Project: symbian_client_apps.
Synopsis: System error occurs when trying to drag playback progress bar beyond download progress bar .
Overview: During Progressive download, if a Read() is requested with size more than downloaded size then a timer is set to RetryRead() after a particular time allowing the file to be downloaded.
In this use case several Seeks are done by user to go to unbuffered region of the progress bar initiating several Read() requests. At one of such request the timer was set when the requested size was more than the downloaded size. When the timer times out at RetryRead(), file object sends call back to Riff Reader which was not expected by Riff Reader and returns HXR_UNEXPECTED error.
Fix: When any read is pending new seek request shall not be processed by the Rmfileformat. Handling seek request in RmFileFormat at proper state, like mp4 file format, is the fix.
Currently changes are done for only interleaved streams, as reported link had interleaved RM Files for PDL.
File modified & changes:
cvsroot\datatype-restricted\rm\fileformat\intrstrm.h
cvsroot\datatype-restricted\rm\fileformat\intrstrm.cpp
Image Size and Heap Use impact: No impact
Module Release testing (STIF) : Done. "WMV play pause seek" failed but not related to fix.
Test case(s) Added : No
Memory leak check performed : No leaks introduced.
Platforms and Profiles Build Verified: helix-client-symbian-4.
Platforms and Profiles Functionality verified: armv5.
Branch: 420 Brizo
Diff:
Index: intrstrm.cpp
===================================================================
RCS file: /cvsroot/rarvcode-formprot/fileformat/intrstrm.cpp,v
retrieving revision 1.38
diff -u -w -r1.38 intrstrm.cpp
--- intrstrm.cpp 30 Mar 2009 23:25:23 -0000 1.38
+++ intrstrm.cpp 16 Sep 2011 11:10:35 -0000
@@ -191,7 +191,9 @@
m_bReverseLimitIsTime(FALSE),
m_ulReverseLimitOffset(0),
m_ulReverseLimitTime(0),
- m_bNeedBackwardSeek(FALSE)
+ m_bNeedBackwardSeek(FALSE),
+ m_bSeekPending(FALSE),
+ m_ulSeekOffset(0)
{
}
@@ -981,7 +983,12 @@
HX_RESULT status;
ULONG32 ulFoundTime = 0;
ULONG32 ulDataOffset = 0;
-
+ if ( m_state != Ready )
+ {
+ m_ulSeekOffset= ulOffset;
+ m_bSeekPending = TRUE;
+ return HXR_OK;
+ }
for(i = 0; i < m_usNumStreams; i++)
{
// Clear out buffers
@@ -1167,6 +1174,13 @@
HX_RESULT pnr = HXR_OK;
UINT32 len;
UINT8* buf;
+ if(m_bSeekPending)
+ {
+ m_state=Ready;
+ Seek(m_usRequestID,m_ulSeekOffset);
+ m_bSeekPending =FALSE;
+ return HXR_OK;
+ }
// do our state action
switch (m_state)
Index: intrstrm.h
===================================================================
RCS file: /cvsroot/rarvcode-formprot/fileformat/intrstrm.h,v
retrieving revision 1.19
diff -u -w -r1.19 intrstrm.h
--- intrstrm.h 18 Aug 2008 11:11:41 -0000 1.19
+++ intrstrm.h 16 Sep 2011 11:10:35 -0000
@@ -120,6 +120,8 @@
UINT32 m_ulReverseLimitOffset;
UINT32 m_ulReverseLimitTime;
HXBOOL m_bNeedBackwardSeek;
+ HXBOOL m_bSeekPending;
+ UINT32 m_ulSeekOffset;
class PacketList;
class PacketNode;
From sfu at real.com Mon Oct 10 20:07:15 2011
From: sfu at real.com (Sheldon Fu)
Date: Mon Oct 10 20:39:50 2011
Subject: [datatype-dev] CR/CN: HXC-45 fix of the simple typo
Message-ID: <4E935073.70206@real.com>
Overview:
The simple typo in copy-paste causes the wrong right side padding value
is used when video width is not multiple of 16 for H.264 content.
Checked in Head, Atlas310 and Atlas380.
fxd
Index: mp4vdfmt.cpp
===================================================================
RCS file: /cvsroot/datatype/mp4/video/renderer/mp4vdfmt.cpp,v
retrieving revision 1.18.8.35.4.2
diff -u -w -r1.18.8.35.4.2 mp4vdfmt.cpp
--- mp4vdfmt.cpp 4 Oct 2011 17:10:27 -0000 1.18.8.35.4.2
+++ mp4vdfmt.cpp 10 Oct 2011 20:03:59 -0000
@@ -428,7 +428,7 @@
{
HX_FORMAT_IMAGE2* pMofOutI2 = (HX_FORMAT_IMAGE2*)pMofOutI;
ulPadLeft = pMofOutI2->uiPadWidthLeft;
- ulPadRight = pMofOutI2->uiPadWidthLeft;
+ ulPadRight = pMofOutI2->uiPadWidthRight;
ulPadTop = pMofOutI2->uiPadHeightTop;
ulPadBottom = pMofOutI2->uiPadHeightBottom;
}
From zlin at real.com Tue Oct 11 01:46:22 2011
From: zlin at real.com (zlin)
Date: Tue Oct 11 01:49:08 2011
Subject: [datatype-dev] CR: Add DTS & AC3 for avi fileformat
Message-ID: <4E939FEE.6050602@real.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: avistrm.cpp.diff
Type: text/x-patch
Size: 3333 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111011/3f8cb100/avistrm.cpp-0001.bin
From yuanzhang at real.com Tue Oct 11 08:54:23 2011
From: yuanzhang at real.com (yuan)
Date: Tue Oct 11 08:56:18 2011
Subject: [datatype-dev] CR: fix 13859 excess data at the end of file
makes flv file format to return HXR_FAIL
In-Reply-To: <1317259933.4151.7.camel@yuan-laptop.corp.real.com>
References: <1317208445.2895.25.camel@yuan-laptop.corp.real.com>
<4E834178.3030404@real.com>
<1317259933.4151.7.camel@yuan-laptop.corp.real.com>
Message-ID: <1318323263.4178.31.camel@yuan-laptop.corp.real.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: fileformat.diff
Type: text/x-patch
Size: 17307 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111011/91f67801/fileformat-0001.bin
From qluo at real.com Tue Oct 11 11:46:29 2011
From: qluo at real.com (Qiang Luo)
Date: Tue Oct 11 11:48:25 2011
Subject: [datatype-dev] CR: fix 13859 excess data at the end of file makes
flv file format to return HXR_FAIL
In-Reply-To: <1318323263.4178.31.camel@yuan-laptop.corp.real.com>
References: <1317208445.2895.25.camel@yuan-laptop.corp.real.com>
<4E834178.3030404@real.com>
<1317259933.4151.7.camel@yuan-laptop.corp.real.com>
<1318323263.4178.31.camel@yuan-laptop.corp.real.com>
Message-ID: <4E942C95.2010301@real.com>
Looks good to me. Please merge to head and 310 branches.
Qiang
On 10/11/2011 1:54 AM, Yuan Zhang wrote:
> Modified by: yuanzhang@real.com
>
> Date: 09/28/2011
>
> Project: RealPlayer for Android Smartphones
>
> Bug Number: 13859
>
>
> Synopsis:cannot play some flv files
>
>
> Overview:
>
>
> There is data after the last video or audio packet , whose size is
> less than HX_FLV_TAG_HEADER_SIZE.
>
> It will make helix player to exit with error.
>
> if excess data is found,
>
> when the file is being parsed, it should be treated as a sign of
> finishing file parsing.
> when the file is being played, TerminateAllStreams() must be
> called after all packets in m_pMergeSorter is sent.
>
>
> In addtion, audio packet of this file contains AAC ADTS playload,
> Syncword must be stripped or there is no sound.
>
>
> To help debugging, a little refactoring is done
>
>
>
>
>
> Files Added:
>
> None
>
>
> Files Modified:
>
>
> /datatype/flash/flv/fileformat/flv_file_format.cpp
>
> /datatype/flash/flv/fileformat/flv_local_payload.cpp
>
> /datatype/flash/flv/fileformat/pub/flv_file_format.h
>
>
>
>
> Image Size and Heap Use impact (Client -Only): none
>
>
> Distribution Libraries Affected: none
>
>
> Platforms and Profiles Affected:
>
> Platform:android-2.3-arm-smdk_c210
> Profile: helix-client-android-LePhoneTD-C210
>
>
> Platforms and Profiles Build Verified:
>
> Platform:android-2.3-arm-smdk_c210
> Profile: helix-client-android-LePhoneTD-C210
>
>
>
> Platforms and Profiles Functionality verified:
>
> Platform:android-2.3-arm-smdk_c210
> Profile: helix-client-android-LePhoneTD-C210
>
>
>
> Branch: 361_atlas
>
>
>
> Copyright assignment: I am a RealNetworks employee
>
>
>
>
> Yuan
>
> -----Original Message-----
> *From*: Yuan Zhang >
> *To*: Qiang Luo >
> *Cc*: datatype-dev@helixcommunity.org >
> *Subject*: Re: [datatype-dev] CR: fix 13859 excess data at the end of
> file makes flv file format to return HXR_FAIL
> *Date*: Wed, 28 Sep 2011 18:32:13 -0700
>
> Thank you very much.
>
> I will update CR later.
>
> Yuan
>
>
> -----Original Message-----
> *From*: Qiang Luo >
> *To*: Yuan Zhang >
> *Cc*: datatype-dev@helixcommunity.org >
> *Subject*: Re: [datatype-dev] CR: fix 13859 excess data at the end of
> file makes flv file format to return HXR_FAIL
> *Date*: Wed, 28 Sep 2011 08:47:04 -0700
>
> Yuan,
>
> Instead of short-circuit the CHXFLVFileFormat::GFHTagHeaderReadDone()
> function with FileHeaderReady(), would it a better alternative of
> following the normal code flow by adding
> retVal = HXR_OK;
> m_ulState = kStateGFHFinalSeekDonePending;
> m_ulSeekOffsetRequested = m_cHeader.GetDataOffset();
> m_pFileObject->Seek(m_ulSeekOffsetRequested, FALSE);
>
> Qiang
>
> On 9/28/2011 4:14 AM, Yuan Zhang wrote:
>> Modified by: yuanzhang@real.com
>>
>> Date: 09/28/2011
>>
>> Project: RealPlayer for Android Smartphones
>>
>> Bug Number: 13859
>>
>>
>> Synopsis:cannot play some flv files
>>
>>
>> Overview:
>>
>>
>> There is data after the last video or audio packet , whose size is
>> less than HX_FLV_TAG_HEADER_SIZE.
>>
>> It will make flv file format to return HXR_FAIL
>>
>> When this situation is met, m_pFormatResponse->FileHeaderReady should
>> be called.
>>
>>
>>
>>
>>
>>
>> Files Added:
>>
>> None
>>
>>
>> Files Modified:
>>
>>
>> /datatype/flash/flv/fileformat/flv_file_format.cpp
>>
>>
>>
>> Image Size and Heap Use impact (Client -Only): none
>>
>>
>> Distribution Libraries Affected: none
>>
>>
>> Platforms and Profiles Affected:
>>
>> Platform:android-2.3-arm-smdk_c210
>> Profile: helix-client-android-LePhoneTD-C210
>>
>>
>> Platforms and Profiles Build Verified:
>>
>> Platform:android-2.3-arm-smdk_c210
>> Profile: helix-client-android-LePhoneTD-C210
>>
>>
>>
>> Platforms and Profiles Functionality verified:
>>
>> Platform:android-2.3-arm-smdk_c210
>> Profile: helix-client-android-LePhoneTD-C210
>>
>>
>>
>> Branch: 361_atlas
>>
>>
>>
>> Copyright assignment: I am a RealNetworks employee
>>
>>
>>
>> Thanks
>>
>> Yuan Zhang
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111011/a154360d/attachment.html
From ext-pritam.biswas at nokia.com Tue Oct 11 13:50:24 2011
From: ext-pritam.biswas at nokia.com (ext-pritam.biswas@nokia.com)
Date: Tue Oct 11 13:52:52 2011
Subject: [datatype-dev] RE: ou1cimx1#884650: Videos: System error occurs
when trying to drag playback progress bar beyond download
progress bar d
References: <000c01cc63d2$20cf72d0$626e5870$@dasari@nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D0D@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D19@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D23@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D29@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D2B@xesebe102.nee.nokia.com>,
<4AFF7497EFFE48469E4D2A776D6ED3EF592D2C@xesebe102.nee.nokia.com>
<170F1AEE-C790-47DD-98AB-45FBE1ABCCF1@mimectl>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D2F@xesebe102.nee.nokia.com>
Message-ID: <4AFF7497EFFE48469E4D2A776D6ED3EF592D33@xesebe102.nee.nokia.com>
Any comment on this fix?
Regards,
Pritam.
________________________________
From: Biswas Pritam (EXT-Sasken/India)
Sent: Mon 10/10/2011 3:00 PM
To: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: CR: ou1cimx1#884650: Videos: System error occurs when trying to drag playback progress bar beyond download progress bar d
"Nokia submits this code under the terms of a commercial contribution agreement with Real Networks, and I am authorized to contribute this code under said agreement."
Modified by: EXT-Pritam.Biswas@nokia.com
Reviewed by: dongsung.kim@nokia.com
ext-nadeem.wahid@nokia.com
RC Id: ou1cimx1#884650
Date: 10/10/2011.
Project: symbian_client_apps.
Synopsis: System error occurs when trying to drag playback progress bar beyond download progress bar .
Overview: During Progressive download, if a Read() is requested with size more than downloaded size then a timer is set to RetryRead() after a particular time allowing the file to be downloaded.
In this use case several Seeks are done by user to go to unbuffered region of the progress bar initiating several Read() requests. At one of such request the timer was set when the requested size was more than the downloaded size. When the timer times out at RetryRead(), file object sends call back to Riff Reader which was not expected by Riff Reader and returns HXR_UNEXPECTED error.
Fix: When any read is pending new seek request shall not be processed by the Rmfileformat. Handling seek request in RmFileFormat at proper state, like mp4 file format, is the fix.
Currently changes are done for only interleaved streams, as reported link had interleaved RM Files for PDL.
File modified & changes:
cvsroot\datatype-restricted\rm\fileformat\intrstrm.h
cvsroot\datatype-restricted\rm\fileformat\intrstrm.cpp
Image Size and Heap Use impact: No impact
Module Release testing (STIF) : Done. "WMV play pause seek" failed but not related to fix.
Test case(s) Added : No
Memory leak check performed : No leaks introduced.
Platforms and Profiles Build Verified: helix-client-symbian-4.
Platforms and Profiles Functionality verified: armv5.
Branch: 420 Brizo
Diff:
Index: intrstrm.cpp
===================================================================
RCS file: /cvsroot/rarvcode-formprot/fileformat/intrstrm.cpp,v
retrieving revision 1.38
diff -u -w -r1.38 intrstrm.cpp
--- intrstrm.cpp 30 Mar 2009 23:25:23 -0000 1.38
+++ intrstrm.cpp 16 Sep 2011 11:10:35 -0000
@@ -191,7 +191,9 @@
m_bReverseLimitIsTime(FALSE),
m_ulReverseLimitOffset(0),
m_ulReverseLimitTime(0),
- m_bNeedBackwardSeek(FALSE)
+ m_bNeedBackwardSeek(FALSE),
+ m_bSeekPending(FALSE),
+ m_ulSeekOffset(0)
{
}
@@ -981,7 +983,12 @@
HX_RESULT status;
ULONG32 ulFoundTime = 0;
ULONG32 ulDataOffset = 0;
-
+ if ( m_state != Ready )
+ {
+ m_ulSeekOffset= ulOffset;
+ m_bSeekPending = TRUE;
+ return HXR_OK;
+ }
for(i = 0; i < m_usNumStreams; i++)
{
// Clear out buffers
@@ -1167,6 +1174,13 @@
HX_RESULT pnr = HXR_OK;
UINT32 len;
UINT8* buf;
+ if(m_bSeekPending)
+ {
+ m_state=Ready;
+ Seek(m_usRequestID,m_ulSeekOffset);
+ m_bSeekPending =FALSE;
+ return HXR_OK;
+ }
// do our state action
switch (m_state)
Index: intrstrm.h
===================================================================
RCS file: /cvsroot/rarvcode-formprot/fileformat/intrstrm.h,v
retrieving revision 1.19
diff -u -w -r1.19 intrstrm.h
--- intrstrm.h 18 Aug 2008 11:11:41 -0000 1.19
+++ intrstrm.h 16 Sep 2011 11:10:35 -0000
@@ -120,6 +120,8 @@
UINT32 m_ulReverseLimitOffset;
UINT32 m_ulReverseLimitTime;
HXBOOL m_bNeedBackwardSeek;
+ HXBOOL m_bSeekPending;
+ UINT32 m_ulSeekOffset;
class PacketList;
class PacketNode;
From ehayashi at real.com Tue Oct 11 23:21:52 2011
From: ehayashi at real.com (Enryo Lam)
Date: Tue Oct 11 23:24:08 2011
Subject: [datatype-dev] CR: Enable audio renderer to report error message
and stop playback.
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44508EE35E224@SEAMBX.corp.real.com>
Project: RealPlayer 15
Bug Number: 402686 iDefense - iDefense VCP Submission V-8g5210zi36 - RealNetworks RealPlayer AAC Codec Memory Corruption Vulnerability
Synopsis: Enable audio renderer to report error message and stop playback.
Overview:
A fix is made to the aac decoder to return HXR_ABORT during decoding of a corrupted aac file.
This change handles HXR_ABORT and reports the error message as a callback.
Files Added:
None
File modified:
datatype/common/audrend/audrend.cpp
datatype/common/audrend/pub/audrend.h
datatype/rm/audio/renderer/rarender.cpp
datatype/rm/audio/renderer/rarender.h
Branches:
hxclient_3_1_0_atlas, HEAD
Platforms Tested: win32-i386-vc9
Builds Verified: win32-i386-vc9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype_rm.diff
Type: application/octet-stream
Size: 8245 bytes
Desc: datatype_rm.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111011/a54abd6c/datatype_rm-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype_comon.diff
Type: application/octet-stream
Size: 8467 bytes
Desc: datatype_comon.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111011/a54abd6c/datatype_comon-0001.obj
From yuanzhang at real.com Wed Oct 12 08:04:47 2011
From: yuanzhang at real.com (yuan)
Date: Wed Oct 12 08:06:46 2011
Subject: [datatype-dev] CR: fix 13859 excess data at the end of file
makes flv file format to return HXR_FAIL
In-Reply-To: <4E942C95.2010301@real.com>
References: <1317208445.2895.25.camel@yuan-laptop.corp.real.com>
<4E834178.3030404@real.com>
<1317259933.4151.7.camel@yuan-laptop.corp.real.com>
<1318323263.4178.31.camel@yuan-laptop.corp.real.com>
<4E942C95.2010301@real.com>
Message-ID: <1318406687.3467.1.camel@yuan-desktop>
Thanks Qiang.
committed into 361_atlas and 361_tiger
merged into 310_atlas and head.
On Tue, 2011-10-11 at 04:46 -0700, Qiang Luo wrote:
> Looks good to me. Please merge to head and 310 branches.
>
> Qiang
>
> On 10/11/2011 1:54 AM, Yuan Zhang wrote:
>
> > Modified by: yuanzhang@real.com
> >
> > Date: 09/28/2011
> >
> > Project: RealPlayer for Android Smartphones
> >
> > Bug Number: 13859
> >
> >
> > Synopsis: cannot play some flv files
> >
> >
> > Overview:
> >
> >
> > There is data after the last video or audio packet , whose size is
> > less than HX_FLV_TAG_HEADER_SIZE.
> >
> > It will make helix player to exit with error.
> >
> > if excess data is found,
> >
> > when the file is being parsed, it should be treated as a
> > sign of finishing file parsing.
> > when the file is being played, TerminateAllStreams() must be
> > called after all packets in m_pMergeSorter is sent.
> >
> >
> > In addtion, audio packet of this file contains AAC ADTS playload,
> > Syncword must be stripped or there is no sound.
> >
> >
> > To help debugging, a little refactoring is done
> >
> >
> >
> >
> >
> > Files Added:
> >
> > None
> >
> >
> > Files Modified:
> >
> >
> > /datatype/flash/flv/fileformat/flv_file_format.cpp
> >
> > /datatype/flash/flv/fileformat/flv_local_payload.cpp
> >
> > /datatype/flash/flv/fileformat/pub/flv_file_format.h
> >
> >
> >
> >
> > Image Size and Heap Use impact (Client -Only): none
> >
> >
> > Distribution Libraries Affected: none
> >
> >
> > Platforms and Profiles Affected:
> >
> > Platform: android-2.3-arm-smdk_c210
> > Profile: helix-client-android-LePhoneTD-C210
> >
> >
> > Platforms and Profiles Build Verified:
> >
> > Platform: android-2.3-arm-smdk_c210
> > Profile: helix-client-android-LePhoneTD-C210
> >
> >
> >
> > Platforms and Profiles Functionality verified:
> >
> > Platform: android-2.3-arm-smdk_c210
> > Profile: helix-client-android-LePhoneTD-C210
> >
> >
> >
> > Branch: 361_atlas
> >
> >
> >
> > Copyright assignment: I am a RealNetworks employee
> >
> >
> >
> >
> > Yuan
> >
> > -----Original Message-----
> > From: Yuan Zhang
> > To: Qiang Luo
> > Cc: datatype-dev@helixcommunity.org
> >
> > Subject: Re: [datatype-dev] CR: fix 13859 excess data at the end of
> > file makes flv file format to return HXR_FAIL
> > Date: Wed, 28 Sep 2011 18:32:13 -0700
> >
> > Thank you very much.
> >
> > I will update CR later.
> >
> > Yuan
> >
> >
> > -----Original Message-----
> > From: Qiang Luo
> > To: Yuan Zhang
> > Cc: datatype-dev@helixcommunity.org
> >
> > Subject: Re: [datatype-dev] CR: fix 13859 excess data at the end of
> > file makes flv file format to return HXR_FAIL
> > Date: Wed, 28 Sep 2011 08:47:04 -0700
> >
> > Yuan,
> >
> > Instead of short-circuit the
> > CHXFLVFileFormat::GFHTagHeaderReadDone() function with
> > FileHeaderReady(), would it a better alternative of following the
> > normal code flow by adding
> > retVal = HXR_OK;
> > m_ulState = kStateGFHFinalSeekDonePending;
> > m_ulSeekOffsetRequested = m_cHeader.GetDataOffset();
> > m_pFileObject->Seek(m_ulSeekOffsetRequested, FALSE);
> >
> > Qiang
> >
> > On 9/28/2011 4:14 AM, Yuan Zhang wrote:
> >
> > > Modified by: yuanzhang@real.com
> > >
> > > Date: 09/28/2011
> > >
> > > Project: RealPlayer for Android Smartphones
> > >
> > > Bug Number: 13859
> > >
> > >
> > > Synopsis: cannot play some flv files
> > >
> > >
> > > Overview:
> > >
> > >
> > > There is data after the last video or audio packet , whose size is
> > > less than HX_FLV_TAG_HEADER_SIZE.
> > >
> > > It will make flv file format to return HXR_FAIL
> > >
> > > When this situation is met, m_pFormatResponse->FileHeaderReady
> > > should be called.
> > >
> > >
> > >
> > >
> > >
> > >
> > > Files Added:
> > >
> > > None
> > >
> > >
> > > Files Modified:
> > >
> > >
> > > /datatype/flash/flv/fileformat/flv_file_format.cpp
> > >
> > >
> > >
> > > Image Size and Heap Use impact (Client -Only): none
> > >
> > >
> > > Distribution Libraries Affected: none
> > >
> > >
> > > Platforms and Profiles Affected:
> > >
> > > Platform: android-2.3-arm-smdk_c210
> > > Profile: helix-client-android-LePhoneTD-C210
> > >
> > >
> > > Platforms and Profiles Build Verified:
> > >
> > > Platform: android-2.3-arm-smdk_c210
> > > Profile: helix-client-android-LePhoneTD-C210
> > >
> > >
> > >
> > > Platforms and Profiles Functionality verified:
> > >
> > > Platform: android-2.3-arm-smdk_c210
> > > Profile: helix-client-android-LePhoneTD-C210
> > >
> > >
> > >
> > > Branch: 361_atlas
> > >
> > >
> > >
> > > Copyright assignment: I am a RealNetworks employee
> > >
> > >
> > >
> > > Thanks
> > >
> > > Yuan Zhang
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111012/aab2e058/attachment.html
From ehayashi at real.com Thu Oct 13 00:30:34 2011
From: ehayashi at real.com (Enryo Lam)
Date: Thu Oct 13 00:31:58 2011
Subject: [datatype-dev] RE: CR: Enable audio renderer to report error
message and stop playback.
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC44508EE35E224@SEAMBX.corp.real.com>
References: <766B5A29D28DA442AB229AAEE2AFC44508EE35E224@SEAMBX.corp.real.com>
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44508EE35E796@SEAMBX.corp.real.com>
I am trying another approach. Please disregard this CR.
-----Original Message-----
From: player-dev-bounces@mag-dev.prognet.com [mailto:player-dev-bounces@mag-dev.prognet.com] On Behalf Of Enryo Lam
Sent: Tuesday, October 11, 2011 4:22 PM
To: datatype-dev@helixcommunity.org; DL-realplayer-dev
Subject: [realplayer-dev] CR: Enable audio renderer to report error message and stop playback.
Project: RealPlayer 15
Bug Number: 402686 iDefense - iDefense VCP Submission V-8g5210zi36 - RealNetworks RealPlayer AAC Codec Memory Corruption Vulnerability
Synopsis: Enable audio renderer to report error message and stop playback.
Overview:
A fix is made to the aac decoder to return HXR_ABORT during decoding of a corrupted aac file.
This change handles HXR_ABORT and reports the error message as a callback.
Files Added:
None
File modified:
datatype/common/audrend/audrend.cpp
datatype/common/audrend/pub/audrend.h
datatype/rm/audio/renderer/rarender.cpp
datatype/rm/audio/renderer/rarender.h
Branches:
hxclient_3_1_0_atlas, HEAD
Platforms Tested: win32-i386-vc9
Builds Verified: win32-i386-vc9
From xzhao at real.com Thu Oct 13 08:31:54 2011
From: xzhao at real.com (Xiaolu Zhao)
Date: Thu Oct 13 08:33:26 2011
Subject: [datatype-dev] CR; enable divx in mp4 container and mp2 in mkv
container
In-Reply-To:
References:
Message-ID: <766B5A29D28DA442AB229AAEE2AFC44508EE1B24DE@SEAMBX.corp.real.com>
Looks good to me.
Best Regards
Zhao Xiaolu
________________________________________
From: datatype-dev-bounces@helixcommunity.org [datatype-dev-bounces@helixcommunity.org] On Behalf Of Joe Li
Sent: Sunday, October 09, 2011 7:59 PM
To: datatype-dev@helixcommunity.org
Subject: [datatype-dev] CR; enable divx in mp4 container and mp2 in mkv container
Modified by: joeli@real.com
Date: 10/09/2011
Project: RealPlayer for Android Smartphones
Synopsis: enable divx in mp4 container and mp2 in mkv container
There is 5 media files from the customer can?t be supported in helix.
So enable these fileformat to support it.
Files Added:
N/A
File Modified:
datatype/mkv/fileformat/mkv_file_format.cpp
datatype/mp4/fileformat/qtatmmgs.cpp
datatype/mp4/fileformat/pub/qtatoms.h
Image Size and Heap Use impact (Client -Only):
None
Platforms and Profiles Affected:
Platform: hxclient_3_6_1_atlas
Profile: helix-client-android-full
Distribution Libraries Affected:
None
Distribution library impact and planned action:
None
Thanks
Joe
From shuohuang at real.com Thu Oct 13 10:42:50 2011
From: shuohuang at real.com (Shuo Huang)
Date: Thu Oct 13 10:55:15 2011
Subject: [datatype-dev] CR: Porting Android error code to LeTV and LePAD
Message-ID: <55A2D694BAFF824EABCF05271B3084FC750E0FD3A3@SEAMBX.corp.real.com>
Hi
I am porting Xiaolu pervious error handling from U1 to 361 branch.
Attachment:
resolution.diff is modified diff codes.
Email is Xiaolu's previously CR for this work.
Files Modified:
player/kit/android/errorsink.cpp
common/include/hxresult.h
common/vidrend/vidrendf.cpp
common/vidrend/pub/vidrendf.h
rm/video/renderer/rvxvdfmt.cpp
h263/renderer/h263vidfmt.cpp
mp4/video/renderer/mp4vdfmt.cpp
mpg/renderer/mpgvidfmt.cpp
wm/video/renderer/wmvformat.cpp
player/kit/android/errorsink.cpp
player/kit/android/3.0/errorsink.cpp
Platform Affected:
hxclient_3_6_1_atlas
Copyright assignment: I am a RealNetworks employee or contractor
Shuo Huang
Call Me Skype
Mobile:+8615001349135
EXT: 2711
»Æ˶
-------------- next part --------------
An embedded message was scrubbed...
From: Xiaolu Zhao
Subject: RE: [Android-port-dev] CR: Add Android specific error type for
reporting to Android framework
Date: Thu, 30 Dec 2010 20:06:06 -0800
Size: 21502
Url: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111013/b2a0d4ed/attachment-0001.mht
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resolution.diff
Type: application/octet-stream
Size: 9582 bytes
Desc: resolution.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111013/b2a0d4ed/resolution-0001.obj
From qluo at real.com Thu Oct 13 15:01:05 2011
From: qluo at real.com (Qiang Luo)
Date: Thu Oct 13 15:02:36 2011
Subject: [datatype-dev] CR: Porting Android error code to LeTV and LePAD
In-Reply-To: <55A2D694BAFF824EABCF05271B3084FC750E0FD3A3@SEAMBX.corp.real.com>
References: <55A2D694BAFF824EABCF05271B3084FC750E0FD3A3@SEAMBX.corp.real.com>
Message-ID: <4E96FD31.6010006@real.com>
OK.
Qiang
On 10/13/2011 3:42 AM, Shuo Huang wrote:
> Hi
>
> I am porting Xiaolu pervious error handling from U1 to 361 branch.
>
> Attachment:
> resolution.diff is modified diff codes.
> Email is Xiaolu's previously CR for this work.
>
>
> Files Modified:
> player/kit/android/errorsink.cpp
> common/include/hxresult.h
> common/vidrend/vidrendf.cpp
> common/vidrend/pub/vidrendf.h
> rm/video/renderer/rvxvdfmt.cpp
> h263/renderer/h263vidfmt.cpp
> mp4/video/renderer/mp4vdfmt.cpp
> mpg/renderer/mpgvidfmt.cpp
> wm/video/renderer/wmvformat.cpp
> player/kit/android/errorsink.cpp
> player/kit/android/3.0/errorsink.cpp
>
> Platform Affected:
> hxclient_3_6_1_atlas
>
> Copyright assignment: I am a RealNetworks employee or contractor
>
> Shuo Huang
> Call Me Skype
> Mobile:+8615001349135
> EXT: 2711
> ??
>
From qluo at real.com Thu Oct 13 15:10:48 2011
From: qluo at real.com (Qiang Luo)
Date: Thu Oct 13 15:12:05 2011
Subject: [datatype-dev] CR; enable divx in mp4 container and mp2 in mkv
container
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC44508EE1B24DE@SEAMBX.corp.real.com>
References:
<766B5A29D28DA442AB229AAEE2AFC44508EE1B24DE@SEAMBX.corp.real.com>
Message-ID: <4E96FF78.6030805@real.com>
Please also merge the fix to head and 310 branches.
Thanks,
Qiang
On 10/13/2011 1:31 AM, Xiaolu Zhao wrote:
> Looks good to me.
>
> Best Regards
> Zhao Xiaolu
> ________________________________________
> From: datatype-dev-bounces@helixcommunity.org [datatype-dev-bounces@helixcommunity.org] On Behalf Of Joe Li
> Sent: Sunday, October 09, 2011 7:59 PM
> To: datatype-dev@helixcommunity.org
> Subject: [datatype-dev] CR; enable divx in mp4 container and mp2 in mkv container
>
> Modified by: joeli@real.com
> Date: 10/09/2011
> Project: RealPlayer for Android Smartphones
>
> Synopsis: enable divx in mp4 container and mp2 in mkv container
>
> There is 5 media files from the customer can?t be supported in helix.
> So enable these fileformat to support it.
>
>
> Files Added:
> N/A
>
> File Modified:
> datatype/mkv/fileformat/mkv_file_format.cpp
> datatype/mp4/fileformat/qtatmmgs.cpp
> datatype/mp4/fileformat/pub/qtatoms.h
>
> Image Size and Heap Use impact (Client -Only):
> None
>
> Platforms and Profiles Affected:
> Platform: hxclient_3_6_1_atlas
> Profile: helix-client-android-full
>
> Distribution Libraries Affected:
> None
>
> Distribution library impact and planned action:
> None
>
>
> Thanks
> Joe
>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
From Joeli at real.com Mon Oct 17 09:45:43 2011
From: Joeli at real.com (Joe Li)
Date: Mon Oct 17 09:47:05 2011
Subject: [datatype-dev] CR: Enhance the frame width and height of H264
decoder parameter
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp4.video.diff
Type: application/octet-stream
Size: 3001 bytes
Desc: mp4.video.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111017/2ef4adf3/mp4.video-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: COmxVideoDec.cpp.diff
Type: application/octet-stream
Size: 1020 bytes
Desc: COmxVideoDec.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111017/2ef4adf3/COmxVideoDec.cpp-0001.obj
From Joeli at real.com Mon Oct 17 10:22:39 2011
From: Joeli at real.com (Joe Li)
Date: Mon Oct 17 10:24:01 2011
Subject: [datatype-dev] CR; enable divx in mp4 container and mp2 in mkv
container
In-Reply-To: <4E96FF78.6030805@real.com>
Message-ID:
Thanks Qiang
Checked in 310 and head.
Thanks
Joe
-----Original Message-----
From: Qiang Luo
Sent: Thursday, October 13, 2011 11:11 PM
To: Xiaolu Zhao
Cc: Joe Li; datatype-dev@helixcommunity.org
Subject: Re: [datatype-dev] CR; enable divx in mp4 container and mp2 in mkv container
Please also merge the fix to head and 310 branches.
Thanks,
Qiang
On 10/13/2011 1:31 AM, Xiaolu Zhao wrote:
> Looks good to me.
>
> Best Regards
> Zhao Xiaolu
> ________________________________________
> From: datatype-dev-bounces@helixcommunity.org [datatype-dev-bounces@helixcommunity.org] On Behalf Of Joe Li
> Sent: Sunday, October 09, 2011 7:59 PM
> To: datatype-dev@helixcommunity.org
> Subject: [datatype-dev] CR; enable divx in mp4 container and mp2 in mkv container
>
> Modified by: joeli@real.com
> Date: 10/09/2011
> Project: RealPlayer for Android Smartphones
>
> Synopsis: enable divx in mp4 container and mp2 in mkv container
>
> There is 5 media files from the customer can't be supported in helix.
> So enable these fileformat to support it.
>
>
> Files Added:
> N/A
>
> File Modified:
> datatype/mkv/fileformat/mkv_file_format.cpp
> datatype/mp4/fileformat/qtatmmgs.cpp
> datatype/mp4/fileformat/pub/qtatoms.h
>
> Image Size and Heap Use impact (Client -Only):
> None
>
> Platforms and Profiles Affected:
> Platform: hxclient_3_6_1_atlas
> Profile: helix-client-android-full
>
> Distribution Libraries Affected:
> None
>
> Distribution library impact and planned action:
> None
>
>
> Thanks
> Joe
>
>
> _______________________________________________
> Datatype-dev mailing list
> Datatype-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
>
From jgordon at real.com Tue Oct 25 02:58:25 2011
From: jgordon at real.com (Jamie Gordon)
Date: Tue Oct 25 03:00:13 2011
Subject: [datatype-dev] Re: [Nokia-private-dev] RE: ou1cimx1#884650: Videos:
System error
occurs when trying to drag playback progress bar beyond download progress
bar d
In-Reply-To: <4AFF7497EFFE48469E4D2A776D6ED3EF592D33@xesebe102.nee.nokia.com>
References: <000c01cc63d2$20cf72d0$626e5870$@dasari@nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D0D@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D19@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D23@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D29@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D2B@xesebe102.nee.nokia.com>
, <4AFF7497EFFE48469E4D2A776D6ED3EF592D2C@xesebe102.nee.nokia.com>
<170F1AEE-C790-47DD-98AB-45FBE1ABCCF1@mimectl>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D2F@xesebe102.nee.nokia.com>
<4AFF7497EFFE48469E4D2A776D6ED3EF592D33@xesebe102.nee.nokia.com>
Message-ID: <1319511506.4681.372.camel@franny>
ok
On Tue, 2011-10-11 at 06:50 -0700, ext-pritam.biswas@nokia.com wrote:
> Any comment on this fix?
>
> Regards,
> Pritam.
>
> ________________________________
>
> From: Biswas Pritam (EXT-Sasken/India)
> Sent: Mon 10/10/2011 3:00 PM
> To: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
> Subject: CR: ou1cimx1#884650: Videos: System error occurs when trying to drag playback progress bar beyond download progress bar d
>
>
> "Nokia submits this code under the terms of a commercial contribution agreement with Real Networks, and I am authorized to contribute this code under said agreement."
>
>
>
> Modified by: EXT-Pritam.Biswas@nokia.com
>
>
>
> Reviewed by: dongsung.kim@nokia.com
>
> ext-nadeem.wahid@nokia.com
>
>
>
> RC Id: ou1cimx1#884650
>
>
>
> Date: 10/10/2011.
>
>
>
> Project: symbian_client_apps.
>
>
>
> Synopsis: System error occurs when trying to drag playback progress bar beyond download progress bar .
>
>
>
> Overview: During Progressive download, if a Read() is requested with size more than downloaded size then a timer is set to RetryRead() after a particular time allowing the file to be downloaded.
>
> In this use case several Seeks are done by user to go to unbuffered region of the progress bar initiating several Read() requests. At one of such request the timer was set when the requested size was more than the downloaded size. When the timer times out at RetryRead(), file object sends call back to Riff Reader which was not expected by Riff Reader and returns HXR_UNEXPECTED error.
>
>
> Fix: When any read is pending new seek request shall not be processed by the Rmfileformat. Handling seek request in RmFileFormat at proper state, like mp4 file format, is the fix.
>
> Currently changes are done for only interleaved streams, as reported link had interleaved RM Files for PDL.
>
>
>
> File modified & changes:
>
> cvsroot\datatype-restricted\rm\fileformat\intrstrm.h
>
> cvsroot\datatype-restricted\rm\fileformat\intrstrm.cpp
>
>
>
> Image Size and Heap Use impact: No impact
>
>
>
> Module Release testing (STIF) : Done. "WMV play pause seek" failed but not related to fix.
>
> Test case(s) Added : No
>
>
>
> Memory leak check performed : No leaks introduced.
>
>
>
> Platforms and Profiles Build Verified: helix-client-symbian-4.
>
>
>
> Platforms and Profiles Functionality verified: armv5.
>
>
>
> Branch: 420 Brizo
>
>
>
> Diff:
>
> Index: intrstrm.cpp
> ===================================================================
> RCS file: /cvsroot/rarvcode-formprot/fileformat/intrstrm.cpp,v
> retrieving revision 1.38
> diff -u -w -r1.38 intrstrm.cpp
> --- intrstrm.cpp 30 Mar 2009 23:25:23 -0000 1.38
> +++ intrstrm.cpp 16 Sep 2011 11:10:35 -0000
> @@ -191,7 +191,9 @@
> m_bReverseLimitIsTime(FALSE),
> m_ulReverseLimitOffset(0),
> m_ulReverseLimitTime(0),
> - m_bNeedBackwardSeek(FALSE)
> + m_bNeedBackwardSeek(FALSE),
> + m_bSeekPending(FALSE),
> + m_ulSeekOffset(0)
> {
> }
>
> @@ -981,7 +983,12 @@
> HX_RESULT status;
> ULONG32 ulFoundTime = 0;
> ULONG32 ulDataOffset = 0;
> -
> + if ( m_state != Ready )
> + {
> + m_ulSeekOffset= ulOffset;
> + m_bSeekPending = TRUE;
> + return HXR_OK;
> + }
> for(i = 0; i < m_usNumStreams; i++)
> {
> // Clear out buffers
> @@ -1167,6 +1174,13 @@
> HX_RESULT pnr = HXR_OK;
> UINT32 len;
> UINT8* buf;
> + if(m_bSeekPending)
> + {
> + m_state=Ready;
> + Seek(m_usRequestID,m_ulSeekOffset);
> + m_bSeekPending =FALSE;
> + return HXR_OK;
> + }
>
> // do our state action
> switch (m_state)
> Index: intrstrm.h
> ===================================================================
> RCS file: /cvsroot/rarvcode-formprot/fileformat/intrstrm.h,v
> retrieving revision 1.19
> diff -u -w -r1.19 intrstrm.h
> --- intrstrm.h 18 Aug 2008 11:11:41 -0000 1.19
> +++ intrstrm.h 16 Sep 2011 11:10:35 -0000
> @@ -120,6 +120,8 @@
> UINT32 m_ulReverseLimitOffset;
> UINT32 m_ulReverseLimitTime;
> HXBOOL m_bNeedBackwardSeek;
> + HXBOOL m_bSeekPending;
> + UINT32 m_ulSeekOffset;
>
> class PacketList;
> class PacketNode;
>
>
>
> _______________________________________________
> Nokia-private-dev mailing list
> Nokia-private-dev@helixcommunity.org
> http://lists.helixcommunity.org/mailman/listinfo/nokia-private-dev
From cchen at real.com Tue Oct 25 23:32:47 2011
From: cchen at real.com (Charles Chen)
Date: Tue Oct 25 23:34:14 2011
Subject: [datatype-dev] CR: Fix bug# 13998 HLS: Helix crashes after rate
switching on m920 phone
Message-ID: <766B5A29D28DA442AB229AAEE2AFC4450D9EDD3934@SEAMBX.corp.real.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: miniandroidsite.cpp.patch
Type: application/octet-stream
Size: 1027 bytes
Desc: miniandroidsite.cpp.patch
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111025/3686da52/miniandroidsite.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: miniandroidsurf.cpp.patch
Type: application/octet-stream
Size: 859 bytes
Desc: miniandroidsurf.cpp.patch
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111025/3686da52/miniandroidsurf.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: miniandroidsurf.h.patch
Type: application/octet-stream
Size: 782 bytes
Desc: miniandroidsurf.h.patch
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111025/3686da52/miniandroidsurf.h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp4vdfmt.cpp.patch
Type: application/octet-stream
Size: 1214 bytes
Desc: mp4vdfmt.cpp.patch
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111025/3686da52/mp4vdfmt.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h264espyld.cpp.patch
Type: application/octet-stream
Size: 2188 bytes
Desc: h264espyld.cpp.patch
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111025/3686da52/h264espyld.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h264espyld.h.patch
Type: application/octet-stream
Size: 718 bytes
Desc: h264espyld.h.patch
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111025/3686da52/h264espyld.h-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CH263OmxDec.cpp.patch
Type: application/octet-stream
Size: 723 bytes
Desc: CH263OmxDec.cpp.patch
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111025/3686da52/CH263OmxDec.cpp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: helix-client-android-msm7k.pf.patch
Type: application/octet-stream
Size: 707 bytes
Desc: helix-client-android-msm7k.pf.patch
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111025/3686da52/helix-client-android-msm7k.pf-0001.obj
From qluo at real.com Wed Oct 26 05:59:41 2011
From: qluo at real.com (Qiang Luo)
Date: Wed Oct 26 06:00:57 2011
Subject: [datatype-dev] Re: [Android-port-dev] CR: Fix bug# 13998 HLS: Helix
crashes after rate switching on m920 phone
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC4450D9EDD3934@SEAMBX.corp.real.com>
References: <766B5A29D28DA442AB229AAEE2AFC4450D9EDD3934@SEAMBX.corp.real.com>
Message-ID: <4EA7A1CD.3010800@real.com>
Looks good.
Qiang
On 10/25/2011 4:32 PM, Charles Chen wrote:
>
> Modified by: cchen@real.com
>
> Date: 10/25/2011
>
> Project: HLS-m920
>
> Bug# 13998
>
> Synopsis:
>
> 1.HLS playback on m920 phone (MSM7627t on Android 2.3.4) crashes after
> rate switch. The crash is due to incorrect releasing of destination
> buffer after rate switch.
>
> 2.Seek during HLS playback freezes QC H.264 DSP core until reboot
> phone. The issue is due to logic error in determining video size
> change which forces decoder reinitialization in h264 es payload class.
>
> 3.Incorrect build profile setting generated wrong Helix binary files
>
> Overview:
>
> 1.Added new ANDROID_MSM7627T_SURF definition for m920 build to invoke
> the releasing of destination buffer at the right time
>
> 2.Added last frame width and height member variables in
> H264ESPayloadFormat class for the
> H264ESPayloadFormat::SetAssemblerConfig() to correctly determine
> whether video size has changed or not
>
> 3.Modified helix-client-android-msm7k.pf to select the correct build
> settings, also fixed compilation errors exposed by the new profile
>
> File added: none
>
> Files modified (patch files attached):
>
> video/sitelib/platform/unix/miniandroidsite.cpp
>
> video/sitelib/platform/unix/miniandroidsurf.cpp
>
> video/sitelib/pub/platform/unix/miniandroidsurf.h
>
> datatype/mp4/video/renderer/mp4vdfmt.cpp
>
> datatype/mp4/payload/h264espyld.cpp
>
> datatype/mp4/payload/pub/h264espyld.h
>
> datatype/omx/video/decoder/CH263OmxDec.cpp
>
> build/umakepf/helix-client-android-msm7k.pf
>
> Image size and heap use impact: minimal
>
> Distribution Libraries Affected:
>
> aacff.so
>
> amrff.so
>
> audplin.so
>
> mp4arender.so
>
> mp4fformat.so
>
> mp4vrender.so
>
> omxv.so
>
> sipr.so
>
> sitelib.so
>
> vp6dec.so
>
> Profile affected: helix-client-android-msm7k
>
> Build settings for verifying the fix:
>
> SYSTEM_ID=android-2.3-arm-msm7x27
>
> Profile: helix-client-android-msm7k.pf
>
> Target: android_omx
>
> Branch: hxclient_3_6_1_atlas
>
> Copyright assignment: I am a RealNetworks employee
>
> QA Instructions:
>
> Update ribosome and compile helix for:
>
> Branch: hxclient_3_6_1_atlas_restricted
>
> Target: android_omx
>
> Profile: helix-client-android-msm7k
>
> SYSTEM_ID: android-2.3-arm-msm7x27
>
> Install on relevant target and play HLS content with multiple rates
> and perform seek operations.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111025/918acd18/attachment.html
From ext-suresh.dasari at nokia.com Wed Oct 26 08:39:46 2011
From: ext-suresh.dasari at nokia.com (Suresh Dasari)
Date: Wed Oct 26 08:41:34 2011
Subject: [datatype-dev] CR: ou1cimx1#654897: Video play back of Codenomicon
.avi format panic with Kern Exec 3
Message-ID: <00dc01cc93ba$d265f880$7731e980$@dasari@nokia.com>
Skipped content of type multipart/alternative-------------- next part --------------
diff -r cdcef755c8e5 ext/mw/helixext/helix_ren/src/datatype/avi/fileformat/aviffpln.cpp
--- a/ext/mw/helixext/helix_ren/src/datatype/avi/fileformat/aviffpln.cpp Wed Sep 21 14:08:53 2011 +0100
+++ b/ext/mw/helixext/helix_ren/src/datatype/avi/fileformat/aviffpln.cpp Thu Oct 20 13:22:23 2011 +0530
@@ -1330,6 +1330,10 @@
case AVI_STRH_CHUNK:
{
++m_usStreamTarget;
+ if(m_usStreamTarget > m_streamArray.GetSize())
+ {
+ return HXR_INVALID_FILE;
+ }
CAVIStream* pStream = (CAVIStream*) m_streamArray[m_usStreamTarget -1];
HX_ASSERT(pStream);
pStream->SetHeader(m_usStreamTarget, pBuffer);
From soma.gupta at sasken.com Wed Oct 26 10:17:55 2011
From: soma.gupta at sasken.com (Soma Gupta)
Date: Wed Oct 26 10:19:21 2011
Subject: [datatype-dev] CR: ou1cimx1# 897312:Music player's progress bar
can't be dragged backward when playing a WMA format song.
Message-ID: <653A85C7F32C4741880F71219266EA022C40CECA12@EXGMBX01.sasken.com>
Skipped content of type multipart/alternative-------------- next part --------------
Index: asf_index.cpp
===================================================================
RCS file: /cvsroot/datatype/wm/fileformat/asf_index.cpp,v
retrieving revision 1.3.14.6
diff -u -r1.3.14.6 asf_index.cpp
--- asf_index.cpp 10 Aug 2010 04:04:21 -0000 1.3.14.6
+++ asf_index.cpp 21 Oct 2011 04:53:40 -0000
@@ -553,26 +553,12 @@
{
j--;
}
- // Did we find an initialized value? If j
- if (m_ppIndexEntry[usWMStreamNumber][j].m_ullFileOffset == HXASF_INDEX_INVALID_ENTRY_VALUE)
- {
- // We must have gone back to the beginning
- HX_ASSERT(j == 0);
- // We searched back to the beginning, but we still
- // didn't find an initialized value. Therefore, we need
- // to fill in from 0 to ulEntry - 1 with the value
- // we just put into ulEntry.
- for (UINT32 k = j; k < ulEntry; k++)
- {
- m_ppIndexEntry[usWMStreamNumber][k].m_ulPresentationTime = ulPresentationTime;
- m_ppIndexEntry[usWMStreamNumber][k].m_ullFileOffset = ullFileOffset;
- }
- }
- else
- {
- // We found an initialized value. Therefore, we need
- // to fill from j to ulEntry - 1 with the initialized
- // value at j.
+ // If we found an initialized value, we need to fill
+ // from j to ulEntry - 1 with the initialized value at j.
+ // If we have searched back to the begining and didn't
+ // find any initialized value, we will not fill the entries.
+ if (m_ppIndexEntry[usWMStreamNumber][j].m_ullFileOffset != HXASF_INDEX_INVALID_ENTRY_VALUE)
+ {
UINT32 ulPresTime = m_ppIndexEntry[usWMStreamNumber][j].m_ulPresentationTime;
UINT64 ullOffset = m_ppIndexEntry[usWMStreamNumber][j].m_ullFileOffset;
for (UINT32 k = j + 1; k < ulEntry; k++)
From cchen at real.com Wed Oct 26 16:23:30 2011
From: cchen at real.com (Charles Chen)
Date: Wed Oct 26 16:24:51 2011
Subject: [datatype-dev] RE: [Android-port-dev] CR: Fix bug# 13998 HLS: Helix
crashes after rate switching on m920 phone
In-Reply-To: <4EA7A1CD.3010800@real.com>
References: <766B5A29D28DA442AB229AAEE2AFC4450D9EDD3934@SEAMBX.corp.real.com>
<4EA7A1CD.3010800@real.com>
Message-ID: <766B5A29D28DA442AB229AAEE2AFC4450D9EDD3BF2@SEAMBX.corp.real.com>
Checked in hxclient_3_6_1_atlas for the code, and main for the profile.
From: Qiang Luo
Sent: Tuesday, October 25, 2011 11:00 PM
To: Charles Chen
Cc: datatype-dev@lists.helixcommunity.org; android-port-dev@lists.helixcommunity.org
Subject: Re: [Android-port-dev] CR: Fix bug# 13998 HLS: Helix crashes after rate switching on m920 phone
Looks good.
Qiang
On 10/25/2011 4:32 PM, Charles Chen wrote:
Modified by: cchen@real.com
Date: 10/25/2011
Project: HLS-m920
Bug# 13998
Synopsis:
HLS playback on m920 phone (MSM7627t on Android 2.3.4) crashes after rate switch. The crash is due to incorrect releasing of destination buffer after rate switch.
Seek during HLS playback freezes QC H.264 DSP core until reboot phone. The issue is due to logic error in determining video size change which forces decoder reinitialization in h264 es payload class.
Incorrect build profile setting generated wrong Helix binary files
Overview:
Added new ANDROID_MSM7627T_SURF definition for m920 build to invoke the releasing of destination buffer at the right time
Added last frame width and height member variables in H264ESPayloadFormat class for the H264ESPayloadFormat::SetAssemblerConfig() to correctly determine whether video size has changed or not
Modified helix-client-android-msm7k.pf to select the correct build settings, also fixed compilation errors exposed by the new profile
File added: none
Files modified (patch files attached):
video/sitelib/platform/unix/miniandroidsite.cpp
video/sitelib/platform/unix/miniandroidsurf.cpp
video/sitelib/pub/platform/unix/miniandroidsurf.h
datatype/mp4/video/renderer/mp4vdfmt.cpp
datatype/mp4/payload/h264espyld.cpp
datatype/mp4/payload/pub/h264espyld.h
datatype/omx/video/decoder/CH263OmxDec.cpp
build/umakepf/helix-client-android-msm7k.pf
Image size and heap use impact: minimal
Distribution Libraries Affected:
aacff.so
amrff.so
audplin.so
mp4arender.so
mp4fformat.so
mp4vrender.so
omxv.so
sipr.so
sitelib.so
vp6dec.so
Profile affected: helix-client-android-msm7k
Build settings for verifying the fix:
SYSTEM_ID=android-2.3-arm-msm7x27
Profile: helix-client-android-msm7k.pf
Target: android_omx
Branch: hxclient_3_6_1_atlas
Copyright assignment: I am a RealNetworks employee
QA Instructions:
Update ribosome and compile helix for:
Branch: hxclient_3_6_1_atlas_restricted
Target: android_omx
Profile: helix-client-android-msm7k
SYSTEM_ID: android-2.3-arm-msm7x27
Install on relevant target and play HLS content with multiple rates and perform seek operations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111026/8c0d3c76/attachment-0001.html
From qluo at real.com Wed Oct 26 16:26:40 2011
From: qluo at real.com (Qiang Luo)
Date: Wed Oct 26 16:28:06 2011
Subject: [datatype-dev] Re: [Android-port-dev] CR: Fix bug# 13998 HLS: Helix
crashes after rate switching on m920 phone
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC4450D9EDD3BF2@SEAMBX.corp.real.com>
References: <766B5A29D28DA442AB229AAEE2AFC4450D9EDD3934@SEAMBX.corp.real.com>
<4EA7A1CD.3010800@real.com>
<766B5A29D28DA442AB229AAEE2AFC4450D9EDD3BF2@SEAMBX.corp.real.com>
Message-ID: <4EA834C0.1020702@real.com>
Please merge the h264espyld.cpp resolution change fix to the head and
310 branches.
Thanks,
Qiang
On 10/26/2011 9:23 AM, Charles Chen wrote:
>
> Checked in hxclient_3_6_1_atlasfor the code, and main for the profile.
>
> *From:*Qiang Luo
> *Sent:* Tuesday, October 25, 2011 11:00 PM
> *To:* Charles Chen
> *Cc:* datatype-dev@lists.helixcommunity.org;
> android-port-dev@lists.helixcommunity.org
> *Subject:* Re: [Android-port-dev] CR: Fix bug# 13998 HLS: Helix
> crashes after rate switching on m920 phone
>
> Looks good.
>
> Qiang
>
> On 10/25/2011 4:32 PM, Charles Chen wrote:
>
> Modified by: cchen@real.com
>
> Date: 10/25/2011
>
> Project: HLS-m920
>
> Bug# 13998
>
> Synopsis:
>
> HLS playback on m920 phone (MSM7627t on Android 2.3.4) crashes after
> rate switch. The crash is due to incorrect releasing of destination
> buffer after rate switch.
>
> Seek during HLS playback freezes QC H.264 DSP core until reboot phone.
> The issue is due to logic error in determining video size change which
> forces decoder reinitialization in h264 es payload class.
>
> Incorrect build profile setting generated wrong Helix binary files
>
> Overview:
>
> Added new ANDROID_MSM7627T_SURF definition for m920 build to invoke
> the releasing of destination buffer at the right time
>
> Added last frame width and height member variables in
> H264ESPayloadFormat class for the
> H264ESPayloadFormat::SetAssemblerConfig() to correctly determine
> whether video size has changed or not
>
> Modified helix-client-android-msm7k.pf to select the correct build
> settings, also fixed compilation errors exposed by the new profile
>
> File added: none
>
> Files modified (patch files attached):
>
> video/sitelib/platform/unix/miniandroidsite.cpp
>
> video/sitelib/platform/unix/miniandroidsurf.cpp
>
> video/sitelib/pub/platform/unix/miniandroidsurf.h
>
> datatype/mp4/video/renderer/mp4vdfmt.cpp
>
> datatype/mp4/payload/h264espyld.cpp
>
> datatype/mp4/payload/pub/h264espyld.h
>
> datatype/omx/video/decoder/CH263OmxDec.cpp
>
> build/umakepf/helix-client-android-msm7k.pf
>
> Image size and heap use impact: minimal
>
> Distribution Libraries Affected:
>
> aacff.so
>
> amrff.so
>
> audplin.so
>
> mp4arender.so
>
> mp4fformat.so
>
> mp4vrender.so
>
> omxv.so
>
> sipr.so
>
> sitelib.so
>
> vp6dec.so
>
> Profile affected: helix-client-android-msm7k
>
> Build settings for verifying the fix:
>
> SYSTEM_ID=android-2.3-arm-msm7x27
>
> Profile: helix-client-android-msm7k.pf
>
> Target: android_omx
>
> Branch: hxclient_3_6_1_atlas
>
> Copyright assignment: I am a RealNetworks employee
>
> QA Instructions:
>
> Update ribosome and compile helix for:
>
> Branch: hxclient_3_6_1_atlas_restricted
>
> Target: android_omx
>
> Profile: helix-client-android-msm7k
>
> SYSTEM_ID: android-2.3-arm-msm7x27
>
> Install on relevant target and play HLS content with multiple rates
> and perform seek operations.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111026/e1906649/attachment.html
From ext-debashis.2.panigrahi at nokia.com Thu Oct 27 05:07:27 2011
From: ext-debashis.2.panigrahi at nokia.com (ext-debashis.2.panigrahi@nokia.com)
Date: Thu Oct 27 05:09:22 2011
Subject: [datatype-dev] CR: 908398: SPPR_PERF Phone is freeze when opening
some special WMA format files in File Manager
Message-ID: <099BCA98809A10489DC52CB686AA7364056692@008-AM1MPN1-027.mgdnok.nokia.com>
"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-debashis.2.panigrahi@nokia.com
Reviewed by: ext-prasoon.jaiswal@nokia.com
TSW Id: ou1cimx1#908398
Date: 10/27/2011
Project: symbian_client_apps
Synopsis: SPPR_PERF Phone is freeze when opening some special WMA format files in File Manager
Overview: These are specially crafted Windows Media Player content that potentially allows remote code execution if a user visits a malicious Web site or opens an e-mail message with malicious content. An attacker who successfully exploited this vulnerability could take complete control of an affected system.
This Trojan exploits the ASF Codec Entries Count(as described in Microsoft Security Bulletin MS06-078 : http://technet.microsoft.com/en-us/security/bulletin/ms06-078). The invalid Codec Entries causes the heap to overflow resulting in USER-47 panic/freeze.
Fix: This is fixed by detecting for invalid Codec Entries Count, by checking for a limiting value: HX_MAX_NUM_CODEC_ENTRIES = 0xFFFF, as the codec entries type is 16 bit.
Files modified & changes:
/cvsroot/datatype/wm/common/parse_asf_objects.cpp
/cvsroot/datatype/wm/common/pub/parse_asf_objects.h
Image Size and Heap Use impact: No major impact
Module Release testing (STIF): Done
Test case(s) Added: No
Memory leak check performed: Passed, No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-symbian-4
Platforms and Profiles Functionality verified: armv5
Branch: 420Brizo and HEAD
Diff:
Index: parse_asf_objects.cpp
===================================================================
RCS file: /cvsroot/datatype/wm/common/parse_asf_objects.cpp,v
retrieving revision 1.13.14.1
diff -u -w -r1.13.14.1 parse_asf_objects.cpp
--- parse_asf_objects.cpp 7 Jul 2010 23:22:45 -0000 1.13.14.1
+++ parse_asf_objects.cpp 20 Oct 2011 09:39:05 -0000
@@ -920,7 +920,7 @@
// Clear the return value
retVal = HXR_OK;
// Do we have any codec entries?
- if (m_ulNumCodecEntries)
+ if((m_ulNumCodecEntries > 0) && (m_ulNumCodecEntries < HX_ASF_MAX_NUM_CODEC_ENTRIES))
{
// Set the return value
retVal = HXR_OUTOFMEMORY;
Index: pub/parse_asf_objects.h
===================================================================
RCS file: /cvsroot/datatype/wm/common/pub/parse_asf_objects.h,v
retrieving revision 1.7.66.1
diff -u -w -r1.7.66.1 parse_asf_objects.h
--- pub/parse_asf_objects.h 7 Jul 2010 23:22:45 -0000 1.7.66.1
+++ pub/parse_asf_objects.h 20 Oct 2011 09:39:06 -0000
@@ -46,6 +46,7 @@
#define HX_ASF_HEADER_EXTENSION_SIZE 22
#define HX_ASF_DATA_OBJECT_SIZE 26
#define HX_INVALID_STREAM_NUMBER 255
+#define HX_MAX_NUM_CODEC_ENTRIES 0xFFFF
// The standard way of representing GUIDs as strings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/412dee95/attachment-0001.html
From zlin at real.com Thu Oct 27 07:02:49 2011
From: zlin at real.com (zlin)
Date: Thu Oct 27 07:04:16 2011
Subject: [datatype-dev] CR:Fix Bug 13449: Some avi video files can not be
playback
Message-ID: <4EA90219.1000504@real.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: avistrm.cpp.diff
Type: text/x-patch
Size: 1841 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/bd966c88/avistrm.cpp-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: COmxVideoDec_smdkc110.cpp.diff
Type: text/x-patch
Size: 10245 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/bd966c88/COmxVideoDec_smdkc110.cpp-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: COmxVideoDec_smdkc110.h.diff
Type: text/x-patch
Size: 1228 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/bd966c88/COmxVideoDec_smdkc110.h-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp4apyld.h.diff
Type: text/x-patch
Size: 1202 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/bd966c88/mp4apyld.h-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp4apyld.cpp.diff
Type: text/x-patch
Size: 8328 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/bd966c88/mp4apyld.cpp-0001.bin
From hxing at real.com Thu Oct 27 07:31:38 2011
From: hxing at real.com (Henry Xing)
Date: Thu Oct 27 07:32:41 2011
Subject: [datatype-dev] CR:Fix Bug 13449: Some avi video files can not
be playback
In-Reply-To: <4EA90219.1000504@real.com>
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA0B6767DFCB@SEAMBX.corp.real.com>
Looks good to me!
henry
________________________________
From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Dinel Lin
Sent: Thursday, October 27, 2011 3:03 PM
To: datatype-dev@helixcommunity.org
Subject: [datatype-dev] CR:Fix Bug 13449: Some avi video files can not be playback
Modified by:zlin@real.com
Date: 10/27/2011
Project: RealPlayer for Android Smartphones
Synopsis:Some avi video files can not be playback
Overview:When playing some avi video files,it may fail due to some reasons.
1.> 1.100_H264_mp3_176x144_148Kbps_30fps_BP.avi
It was caused by failing to initialize decoder with opaque data.When initializing
the decoder,opaque data is always important,but not essential,because maybe the
decoder has the capability of initializing itself with following input data.Finally,
update the logic to conceal the error when parsing opaque data.It will give decoder
a chance to initializing itself.It is reasonable and adoptable.
2.>1.112_toystory_h264_aac+.avi
It was caused by initializing the aac audio render failure with the opaque data.For
avi files,if the chunk named "strd" miss,we will try to read the first frame as opaque
data.This behavior is reasonable,however,failure may occur due the the first frame is not
appropriate to regard as opaque data.
In order to conquer this issue,firstly,adding the functionality for validate the opaque data.
If it is invalid,try to initialize the decoder with default audio specific config.Secondly,
try to separate the aac mime type by checking the adts sync word.
3.> Update the method for extracting the resolution of H.264 and MPEG4.
The is some shortcomings of the resolution extraction of H.264 if the profile is high profile.
Meanwhile,for MPEG4 files,adding the functionality to extract the resolution.
Files Added:
None
Files Modified:
/datatype/omx/video/decoder/pub/android/2.3/COmxVideoDec_smdkc110.h
/datatype/omx/video/decoder/android/2.3/COmxVideoDec_smdkc110.cpp
datatype/mp4/payload/pub/mp4apyld.h
datatype/mp4/payload/mp4apyld.cpp
datatype/avi/fileformat/avistrm.cpp
Image Size and Heap Use impact (Client -Only): None
Platforms and Profiles Affected:
Platform: android-2.3-arm-smdk_c110
Profile: helix-client-android-LePhoneTD-C110
Distribution Libraries Affected:None
Distribution library impact and planned action:None
Platforms and Profiles Build Verified:
Platform: android-2.3-arm-smdk_c110
Profile: helix-client-android-LePhoneTD-C110
Platforms and Profiles Functionality verified:
Platform: android-2.3-arm-smdk_c110
Profile: helix-client-android-LePhoneTD-C110
Branch: 361atlas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/83fbae74/attachment.html
From zlin at real.com Thu Oct 27 07:50:07 2011
From: zlin at real.com (zlin)
Date: Thu Oct 27 07:51:28 2011
Subject: [datatype-dev] CR:Fix Bug 13449: Some avi video files can not
be playback
In-Reply-To: <7ECCEA249B7CDC49A079EC0075E999AA0B6767DFCB@SEAMBX.corp.real.com>
References: <7ECCEA249B7CDC49A079EC0075E999AA0B6767DFCB@SEAMBX.corp.real.com>
Message-ID: <4EA90D2F.7070905@real.com>
Thanks,henry.
Committed to 361 branch.
br
zlin
On 10/27/2011 03:31 PM, Henry Xing wrote:
>
> Looks good to me!
>
> henry
>
> ------------------------------------------------------------------------
>
> *From:*datatype-dev-bounces@helixcommunity.org
> [mailto:datatype-dev-bounces@helixcommunity.org] *On Behalf Of *Dinel Lin
> *Sent:* Thursday, October 27, 2011 3:03 PM
> *To:* datatype-dev@helixcommunity.org
> *Subject:* [datatype-dev] CR:Fix Bug 13449: Some avi video files can
> not be playback
>
> Modified by:zlin@real.com
> Date: 10/27/2011
> Project: RealPlayer for Android Smartphones
> Synopsis:Some avi video files can not be playback
>
> Overview:When playing some avi video files,it may fail due to some
> reasons.
> *1.>**1.100_H264_mp3_176x144_148Kbps_30fps_BP.avi*
> It was caused by failing to initialize decoder with opaque data.When
> initializing
> the decoder,opaque data is always important,but not essential,because
> maybe the
> decoder has the capability of initializing itself with following input
> data.Finally,
> update the logic to conceal the error when parsing opaque data.It will
> give decoder
> a chance to initializing itself.It is reasonable and adoptable.
>
> *2.>1.112_toystory_h264_aac+.avi**
> *It was caused by initializing the aac audio render failure with the
> opaque data.For
> avi files,if the chunk named "strd" miss,we will try to read the first
> frame as opaque
> data.This behavior is reasonable,however,failure may occur due the the
> first frame is not
> appropriate to regard as opaque data.
> In order to conquer this issue,firstly,adding the functionality for
> validate the opaque data.
> If it is invalid,try to initialize the decoder with default audio
> specific config.Secondly,
> try to separate the aac mime type by checking the adts sync word.
>
> *3.> Update the method for extracting the resolution of H.264 and MPEG4.**
> *The is some shortcomings of the resolution extraction of H.264 if the
> profile is high profile.
> Meanwhile,for MPEG4 files,adding the functionality to extract the
> resolution.
>
> Files Added:
> None
>
> Files Modified:
> /datatype/omx/video/decoder/pub/android/2.3/COmxVideoDec_smdkc110.h
> /datatype/omx/video/decoder/android/2.3/COmxVideoDec_smdkc110.cpp
> datatype/mp4/payload/pub/mp4apyld.h
> datatype/mp4/payload/mp4apyld.cpp
> datatype/avi/fileformat/avistrm.cpp
>
> Image Size and Heap Use impact (Client -Only): None
>
> Platforms and Profiles Affected:
> Platform: android-2.3-arm-smdk_c110
> Profile: helix-client-android-LePhoneTD-C110
>
> Distribution Libraries Affected:None
>
> Distribution library impact and planned action:None
>
> Platforms and Profiles Build Verified:
> Platform: android-2.3-arm-smdk_c110
> Profile: helix-client-android-LePhoneTD-C110
>
> Platforms and Profiles Functionality verified:
> Platform: android-2.3-arm-smdk_c110
> Profile: helix-client-android-LePhoneTD-C110
>
> Branch: 361atlas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/5fdc18df/attachment-0001.html
From xzhao at real.com Thu Oct 27 08:43:46 2011
From: xzhao at real.com (Xiaolu Zhao)
Date: Thu Oct 27 08:45:06 2011
Subject: [datatype-dev] CR: Enhance the frame width and height of H264
decoder parameter
In-Reply-To:
References:
Message-ID: <766B5A29D28DA442AB229AAEE2AFC4450D9EF15379@SEAMBX.corp.real.com>
Joe,
Here is my comments:
1. About: - if((pMofIn->submoftag == 0x4d503456) || (pMofIn->submoftag == 0x4d504756))
Remove this sentence will cause m_pVideoFormat->GetStreamHeader(pHeader) exec the second time in vain. I think should take above if block into consideration. Possible add more 4cc judge will be better.
BTW, during the code exam, I find out some place leak the IHXValues* pHeader out. CMP4VideoFormat::GetStreamHeader have inc its ref count, so this is memory leak. Please fix them too.
Otherwise look good to me.
Best Regards
Zhao Xiaolu
________________________________________
From: datatype-dev-bounces@helixcommunity.org [datatype-dev-bounces@helixcommunity.org] On Behalf Of Joe Li
Sent: Monday, October 17, 2011 5:45 PM
To: datatype-dev@helixcommunity.org
Subject: [datatype-dev] CR: Enhance the frame width and height of H264 decoder parameter
Modified by: joeli@real.com
Date: 10/17/2011
Project: RealPlayer for Android Smartphones
Synopsis: Enhance the frame width and height of H264 decoder parameter
For some h264 contents, due to missing opaque data or having wrong opaque data.
The frame size can?t be extracted from the opaque data.
While Qualcom 8060 chipset allocate the output port definition with default size 1920x1080( while some times, its 1920x1084, 1920x1088)
If we initial the mof with the default size, it will break the resolution checking of HW decoding(not more than 1920x1080).
So we used the tradition rule, get the framesize from streamheader or file header. And set it to decoder by PNStream_SetProperty.
Then if decoder not agree it, then a port reconfig event will happened.
Files Added:
N/A
File Modified:
datatype/omx/video/decoder/COmxVideoDec.cpp
datatype/mp4/video/renderer/mp4vdec.cpp
datatype/mp4/video/renderer/mp4vdfmt.cpp
Image Size and Heap Use impact (Client -Only):
None
Platforms and Profiles Affected:
Platform: hxclient_3_6_1_atlas
Profile: helix-client-android-full
Distribution Libraries Affected:
None
Distribution library impact and planned action:
None
Thanks
Joe
From hxing at real.com Thu Oct 27 09:28:38 2011
From: hxing at real.com (Henry Xing)
Date: Thu Oct 27 09:29:44 2011
Subject: [datatype-dev] CR: Add DTS & AC3 for avi fileformat
In-Reply-To: <4E939FEE.6050602@real.com>
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA0B6767E000@SEAMBX.corp.real.com>
Looks good
henry
________________________________
From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Dinel Lin
Sent: Tuesday, October 11, 2011 9:46 AM
To: datatype-dev@helixcommunity.org
Subject: [datatype-dev] CR: Add DTS & AC3 for avi fileformat
Modified by:zlin@real.com
Date: 10/11/2011
Project: RealPlayer for Android Smartphones
Synopsis:Add DTS and AC3 for avi fileformat
Overview:According to the requirements for Lenovo,the playback of avi which contains DTS and AC3 should be supported.Therefore,add relevant mime types to AVI fileformat(NOTE:Some format tag defined in the file seems wrong and update them all to fulfill customers' requirments). Meanwhile,the content has video type x264,add it as well.
Files Added:
None
Files Modified:
datatype/avi/fileformat/avistrm.cpp
Image Size and Heap Use impact (Client -Only): None
Platforms and Profiles Affected:
Platform: android-2.3-arm-smdk_c110
Profile: helix-client-android-LePhoneTD-C110
Distribution Libraries Affected:None
Distribution library impact and planned action:None
Platforms and Profiles Build Verified:
Platform: android-2.3-arm-smdk_c110
Profile: helix-client-android-LePhoneTD-C110
Platforms and Profiles Functionality verified:
Platform: android-2.3-arm-smdk_c110
Profile: helix-client-android-LePhoneTD-C110
Branch: 361atlas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/6b7b14f8/attachment.html
From zlin at real.com Thu Oct 27 09:38:11 2011
From: zlin at real.com (zlin)
Date: Thu Oct 27 09:39:30 2011
Subject: [datatype-dev] CR: Add DTS & AC3 for avi fileformat
In-Reply-To: <7ECCEA249B7CDC49A079EC0075E999AA0B6767E000@SEAMBX.corp.real.com>
References: <7ECCEA249B7CDC49A079EC0075E999AA0B6767E000@SEAMBX.corp.real.com>
Message-ID: <4EA92683.60303@real.com>
thanks,henry
committed to 361 branch.
br
zlin
On 10/27/2011 05:28 PM, Henry Xing wrote:
>
> Looks good
>
> henry
>
> ------------------------------------------------------------------------
>
> *From:*datatype-dev-bounces@helixcommunity.org
> [mailto:datatype-dev-bounces@helixcommunity.org] *On Behalf Of *Dinel Lin
> *Sent:* Tuesday, October 11, 2011 9:46 AM
> *To:* datatype-dev@helixcommunity.org
> *Subject:* [datatype-dev] CR: Add DTS & AC3 for avi fileformat
>
> Modified by:zlin@real.com
> Date: 10/11/2011
> Project: RealPlayer for Android Smartphones
> Synopsis:Add DTS and AC3 for avi fileformat
>
> Overview:According to the requirements for Lenovo,the playback of avi
> which contains DTS and AC3 should be supported.Therefore,add relevant
> mime types to AVI fileformat(NOTE:Some format tag defined in the file
> seems wrong and update them all to fulfill customers' requirments).
> Meanwhile,the content has video type x264,add it as well.
>
> Files Added:
> None
>
> Files Modified:
> datatype/avi/fileformat/avistrm.cpp
>
> Image Size and Heap Use impact (Client -Only): None
>
> Platforms and Profiles Affected:
> Platform: android-2.3-arm-smdk_c110
> Profile: helix-client-android-LePhoneTD-C110
>
> Distribution Libraries Affected:None
>
> Distribution library impact and planned action:None
>
> Platforms and Profiles Build Verified:
> Platform: android-2.3-arm-smdk_c110
> Profile: helix-client-android-LePhoneTD-C110
>
> Platforms and Profiles Functionality verified:
> Platform: android-2.3-arm-smdk_c110
> Profile: helix-client-android-LePhoneTD-C110
>
> Branch: 361atlas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/061ad8fe/attachment.html
From Joeli at real.com Thu Oct 27 09:47:44 2011
From: Joeli at real.com (Joe Li)
Date: Thu Oct 27 09:49:04 2011
Subject: [datatype-dev] CR: Enhance the frame width and height of H264
decoder parameter
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC4450D9EF15379@SEAMBX.corp.real.com>
Message-ID:
Thanks Lu
Diff updated.
Thanks
Joe
-----Original Message-----
From: Xiaolu Zhao
Sent: Thursday, October 27, 2011 4:44 PM
To: Joe Li; datatype-dev@helixcommunity.org
Subject: RE: [datatype-dev] CR: Enhance the frame width and height of H264 decoder parameter
Joe,
Here is my comments:
1. About: - if((pMofIn->submoftag == 0x4d503456) || (pMofIn->submoftag == 0x4d504756))
Remove this sentence will cause m_pVideoFormat->GetStreamHeader(pHeader) exec the second time in vain. I think should take above if block into consideration. Possible add more 4cc judge will be better.
BTW, during the code exam, I find out some place leak the IHXValues* pHeader out. CMP4VideoFormat::GetStreamHeader have inc its ref count, so this is memory leak. Please fix them too.
Otherwise look good to me.
Best Regards
Zhao Xiaolu
________________________________________
From: datatype-dev-bounces@helixcommunity.org [datatype-dev-bounces@helixcommunity.org] On Behalf Of Joe Li
Sent: Monday, October 17, 2011 5:45 PM
To: datatype-dev@helixcommunity.org
Subject: [datatype-dev] CR: Enhance the frame width and height of H264 decoder parameter
Modified by: joeli@real.com
Date: 10/17/2011
Project: RealPlayer for Android Smartphones
Synopsis: Enhance the frame width and height of H264 decoder parameter
For some h264 contents, due to missing opaque data or having wrong opaque data.
The frame size can't be extracted from the opaque data.
While Qualcom 8060 chipset allocate the output port definition with default size 1920x1080( while some times, its 1920x1084, 1920x1088)
If we initial the mof with the default size, it will break the resolution checking of HW decoding(not more than 1920x1080).
So we used the tradition rule, get the framesize from streamheader or file header. And set it to decoder by PNStream_SetProperty.
Then if decoder not agree it, then a port reconfig event will happened.
Files Added:
N/A
File Modified:
datatype/omx/video/decoder/COmxVideoDec.cpp
datatype/mp4/video/renderer/mp4vdec.cpp
datatype/mp4/video/renderer/mp4vdfmt.cpp
Image Size and Heap Use impact (Client -Only):
None
Platforms and Profiles Affected:
Platform: hxclient_3_6_1_atlas
Profile: helix-client-android-full
Distribution Libraries Affected:
None
Distribution library impact and planned action:
None
Thanks
Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp4.video.diff
Type: application/octet-stream
Size: 4458 bytes
Desc: mp4.video.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/b41e4b2b/mp4.video-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: COmxVideoDec.cpp.diff
Type: application/octet-stream
Size: 1020 bytes
Desc: COmxVideoDec.cpp.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/b41e4b2b/COmxVideoDec.cpp-0001.obj
From xzhao at real.com Thu Oct 27 09:53:59 2011
From: xzhao at real.com (Xiaolu Zhao)
Date: Thu Oct 27 09:55:26 2011
Subject: [datatype-dev] CR: Enhance the frame width and height of H264
decoder parameter
In-Reply-To:
References: <766B5A29D28DA442AB229AAEE2AFC4450D9EF15379@SEAMBX.corp.real.com>,
Message-ID: <766B5A29D28DA442AB229AAEE2AFC4450D9EF1537A@SEAMBX.corp.real.com>
Looks good to me now
Best Regards
Zhao Xiaolu
________________________________________
From: Joe Li
Sent: Thursday, October 27, 2011 5:47 PM
To: Xiaolu Zhao; datatype-dev@helixcommunity.org
Subject: RE: [datatype-dev] CR: Enhance the frame width and height of H264 decoder parameter
Thanks Lu
Diff updated.
Thanks
Joe
-----Original Message-----
From: Xiaolu Zhao
Sent: Thursday, October 27, 2011 4:44 PM
To: Joe Li; datatype-dev@helixcommunity.org
Subject: RE: [datatype-dev] CR: Enhance the frame width and height of H264 decoder parameter
Joe,
Here is my comments:
1. About: - if((pMofIn->submoftag == 0x4d503456) || (pMofIn->submoftag == 0x4d504756))
Remove this sentence will cause m_pVideoFormat->GetStreamHeader(pHeader) exec the second time in vain. I think should take above if block into consideration. Possible add more 4cc judge will be better.
BTW, during the code exam, I find out some place leak the IHXValues* pHeader out. CMP4VideoFormat::GetStreamHeader have inc its ref count, so this is memory leak. Please fix them too.
Otherwise look good to me.
Best Regards
Zhao Xiaolu
________________________________________
From: datatype-dev-bounces@helixcommunity.org [datatype-dev-bounces@helixcommunity.org] On Behalf Of Joe Li
Sent: Monday, October 17, 2011 5:45 PM
To: datatype-dev@helixcommunity.org
Subject: [datatype-dev] CR: Enhance the frame width and height of H264 decoder parameter
Modified by: joeli@real.com
Date: 10/17/2011
Project: RealPlayer for Android Smartphones
Synopsis: Enhance the frame width and height of H264 decoder parameter
For some h264 contents, due to missing opaque data or having wrong opaque data.
The frame size can?t be extracted from the opaque data.
While Qualcom 8060 chipset allocate the output port definition with default size 1920x1080( while some times, its 1920x1084, 1920x1088)
If we initial the mof with the default size, it will break the resolution checking of HW decoding(not more than 1920x1080).
So we used the tradition rule, get the framesize from streamheader or file header. And set it to decoder by PNStream_SetProperty.
Then if decoder not agree it, then a port reconfig event will happened.
Files Added:
N/A
File Modified:
datatype/omx/video/decoder/COmxVideoDec.cpp
datatype/mp4/video/renderer/mp4vdec.cpp
datatype/mp4/video/renderer/mp4vdfmt.cpp
Image Size and Heap Use impact (Client -Only):
None
Platforms and Profiles Affected:
Platform: hxclient_3_6_1_atlas
Profile: helix-client-android-full
Distribution Libraries Affected:
None
Distribution library impact and planned action:
None
Thanks
Joe
From Joeli at real.com Thu Oct 27 10:53:57 2011
From: Joeli at real.com (Joe Li)
Date: Thu Oct 27 10:55:24 2011
Subject: [datatype-dev] CR: Enhance the frame width and height of H264
decoder parameter
In-Reply-To: <766B5A29D28DA442AB229AAEE2AFC4450D9EF1537A@SEAMBX.corp.real.com>
Message-ID:
Checked in 361atlas, wolf and tiger.
Thanks
Joe
thanks
Joe
-----Original Message-----
From: Xiaolu Zhao
Sent: Thursday, October 27, 2011 5:54 PM
To: Joe Li; datatype-dev@helixcommunity.org
Subject: RE: [datatype-dev] CR: Enhance the frame width and height of H264 decoder parameter
Looks good to me now
Best Regards
Zhao Xiaolu
________________________________________
From: Joe Li
Sent: Thursday, October 27, 2011 5:47 PM
To: Xiaolu Zhao; datatype-dev@helixcommunity.org
Subject: RE: [datatype-dev] CR: Enhance the frame width and height of H264 decoder parameter
Thanks Lu
Diff updated.
Thanks
Joe
-----Original Message-----
From: Xiaolu Zhao
Sent: Thursday, October 27, 2011 4:44 PM
To: Joe Li; datatype-dev@helixcommunity.org
Subject: RE: [datatype-dev] CR: Enhance the frame width and height of H264 decoder parameter
Joe,
Here is my comments:
1. About: - if((pMofIn->submoftag == 0x4d503456) || (pMofIn->submoftag == 0x4d504756))
Remove this sentence will cause m_pVideoFormat->GetStreamHeader(pHeader) exec the second time in vain. I think should take above if block into consideration. Possible add more 4cc judge will be better.
BTW, during the code exam, I find out some place leak the IHXValues* pHeader out. CMP4VideoFormat::GetStreamHeader have inc its ref count, so this is memory leak. Please fix them too.
Otherwise look good to me.
Best Regards
Zhao Xiaolu
________________________________________
From: datatype-dev-bounces@helixcommunity.org [datatype-dev-bounces@helixcommunity.org] On Behalf Of Joe Li
Sent: Monday, October 17, 2011 5:45 PM
To: datatype-dev@helixcommunity.org
Subject: [datatype-dev] CR: Enhance the frame width and height of H264 decoder parameter
Modified by: joeli@real.com
Date: 10/17/2011
Project: RealPlayer for Android Smartphones
Synopsis: Enhance the frame width and height of H264 decoder parameter
For some h264 contents, due to missing opaque data or having wrong opaque data.
The frame size can't be extracted from the opaque data.
While Qualcom 8060 chipset allocate the output port definition with default size 1920x1080( while some times, its 1920x1084, 1920x1088)
If we initial the mof with the default size, it will break the resolution checking of HW decoding(not more than 1920x1080).
So we used the tradition rule, get the framesize from streamheader or file header. And set it to decoder by PNStream_SetProperty.
Then if decoder not agree it, then a port reconfig event will happened.
Files Added:
N/A
File Modified:
datatype/omx/video/decoder/COmxVideoDec.cpp
datatype/mp4/video/renderer/mp4vdec.cpp
datatype/mp4/video/renderer/mp4vdfmt.cpp
Image Size and Heap Use impact (Client -Only):
None
Platforms and Profiles Affected:
Platform: hxclient_3_6_1_atlas
Profile: helix-client-android-full
Distribution Libraries Affected:
None
Distribution library impact and planned action:
None
Thanks
Joe
From soma.gupta at sasken.com Thu Oct 27 15:14:53 2011
From: soma.gupta at sasken.com (Soma Gupta)
Date: Thu Oct 27 15:19:59 2011
Subject: [datatype-dev] FW: ou1cimx1# 897312:Music player's progress bar
can't be dragged backward when playing a WMA format song.
In-Reply-To: <653A85C7F32C4741880F71219266EA022C406DEC4F@EXGMBX01.sasken.com>
References: <653A85C7F32C4741880F71219266EA022C406DEC4F@EXGMBX01.sasken.com>
Message-ID: <653A85C7F32C4741880F71219266EA022C4098E9D5@EXGMBX01.sasken.com>
Skipped content of type multipart/alternative-------------- next part --------------
Index: asf_index.cpp
===================================================================
RCS file: /cvsroot/datatype/wm/fileformat/asf_index.cpp,v
retrieving revision 1.3.14.6
diff -u -r1.3.14.6 asf_index.cpp
--- asf_index.cpp 10 Aug 2010 04:04:21 -0000 1.3.14.6
+++ asf_index.cpp 21 Oct 2011 04:53:40 -0000
@@ -553,26 +553,12 @@
{
j--;
}
- // Did we find an initialized value? If j
- if (m_ppIndexEntry[usWMStreamNumber][j].m_ullFileOffset == HXASF_INDEX_INVALID_ENTRY_VALUE)
- {
- // We must have gone back to the beginning
- HX_ASSERT(j == 0);
- // We searched back to the beginning, but we still
- // didn't find an initialized value. Therefore, we need
- // to fill in from 0 to ulEntry - 1 with the value
- // we just put into ulEntry.
- for (UINT32 k = j; k < ulEntry; k++)
- {
- m_ppIndexEntry[usWMStreamNumber][k].m_ulPresentationTime = ulPresentationTime;
- m_ppIndexEntry[usWMStreamNumber][k].m_ullFileOffset = ullFileOffset;
- }
- }
- else
- {
- // We found an initialized value. Therefore, we need
- // to fill from j to ulEntry - 1 with the initialized
- // value at j.
+ // If we found an initialized value, we need to fill
+ // from j to ulEntry - 1 with the initialized value at j.
+ // If we have searched back to the begining and didn't
+ // find any initialized value, we will not fill the entries.
+ if (m_ppIndexEntry[usWMStreamNumber][j].m_ullFileOffset != HXASF_INDEX_INVALID_ENTRY_VALUE)
+ {
UINT32 ulPresTime = m_ppIndexEntry[usWMStreamNumber][j].m_ulPresentationTime;
UINT64 ullOffset = m_ppIndexEntry[usWMStreamNumber][j].m_ullFileOffset;
for (UINT32 k = j + 1; k < ulEntry; k++)
From sfu at real.com Thu Oct 27 15:33:26 2011
From: sfu at real.com (Sheldon Fu)
Date: Thu Oct 27 15:34:47 2011
Subject: [datatype-dev] Re: [Nokia-private-dev] CR: 908398: SPPR_PERF Phone
is freeze when opening some special WMA format files in File Manager
In-Reply-To: <099BCA98809A10489DC52CB686AA7364056692@008-AM1MPN1-027.mgdnok.nokia.com>
References: <099BCA98809A10489DC52CB686AA7364056692@008-AM1MPN1-027.mgdnok.nokia.com>
Message-ID: <4EA979C6.7040909@real.com>
This looks fine, though the limit value of 0xffff is arbitrary and not
mandated by the spec, right? In practice, it shouldn't matter which
limit value we use --- you won't have even 256 codec entries in a 'good'
asf file I think.
fxd
On 10/27/2011 01:07 AM, ext-debashis.2.panigrahi@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: ext-debashis.2.panigrahi@nokia.com
>
> Reviewed by: ext-prasoon.jaiswal@nokia.com
>
> TSW Id: ou1cimx1#908398
>
> Date: 10/27/2011
>
> Project: symbian_client_apps
>
> Synopsis: SPPR_PERF Phone is freeze when opening some special WMA
> format files in File Manager
>
> Overview: These are specially crafted Windows Media Player content
> that potentially allows remote code execution if a user visits a
> malicious Web site or opens an e-mail message with malicious content.
> An attacker who successfully exploited this vulnerability could take
> complete control of an affected system.
>
> This Trojan exploits the ASF Codec Entries Count(as described in
> Microsoft Security Bulletin MS06-078 :
> http://technet.microsoft.com/en-us/security/bulletin/ms06-078). The
> invalid Codec Entries causes the heap to overflow resulting in USER-47
> panic/freeze.
>
> Fix: This is fixed by detecting for invalid Codec Entries Count, by
> checking for a limiting value: HX_MAX_NUM_CODEC_ENTRIES = 0xFFFF, as
> the codec entries type is 16 bit.
>
> Files modified & changes:
>
> /cvsroot/datatype/wm/common/parse_asf_objects.cpp
>
> /cvsroot/datatype/wm/common/pub/parse_asf_objects.h
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF): Done
>
> Test case(s) Added: No
>
> Memory leak check performed: Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-symbian-4
>
> Platforms and Profiles Functionality verified: armv5
>
> Branch: 420Brizo and HEAD
>
> Diff:
>
> Index: parse_asf_objects.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/wm/common/parse_asf_objects.cpp,v
>
> retrieving revision 1.13.14.1
>
> diff -u -w -r1.13.14.1 parse_asf_objects.cpp
>
> --- parse_asf_objects.cpp 7 Jul 2010 23:22:45
> -0000 1.13.14.1
>
> +++ parse_asf_objects.cpp 20 Oct 2011 09:39:05 -0000
>
> @@ -920,7 +920,7 @@
>
> // Clear the return value
>
> retVal = HXR_OK;
>
> // Do we have any codec entries?
>
> - if (m_ulNumCodecEntries)
>
> + if((m_ulNumCodecEntries > 0) && (m_ulNumCodecEntries <
> HX_ASF_MAX_NUM_CODEC_ENTRIES))
>
> {
>
> // Set the return value
>
> retVal = HXR_OUTOFMEMORY;
>
> Index: pub/parse_asf_objects.h
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/wm/common/pub/parse_asf_objects.h,v
>
> retrieving revision 1.7.66.1
>
> diff -u -w -r1.7.66.1 parse_asf_objects.h
>
> --- pub/parse_asf_objects.h 7 Jul 2010 23:22:45
> -0000 1.7.66.1
>
> +++ pub/parse_asf_objects.h 20 Oct 2011 09:39:06 -0000
>
> @@ -46,6 +46,7 @@
>
> #define HX_ASF_HEADER_EXTENSION_SIZE 22
>
> #define HX_ASF_DATA_OBJECT_SIZE 26
>
> #define HX_INVALID_STREAM_NUMBER 255
>
> +#define HX_MAX_NUM_CODEC_ENTRIES 0xFFFF
>
> // The standard way of representing GUIDs as strings
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/1be386d9/attachment.html
From sfu at real.com Thu Oct 27 16:03:43 2011
From: sfu at real.com (Sheldon Fu)
Date: Thu Oct 27 16:05:04 2011
Subject: [datatype-dev] FW: ou1cimx1# 897312:Music player's progress bar
can't be dragged backward when playing a WMA format song.
In-Reply-To: <653A85C7F32C4741880F71219266EA022C4098E9D5@EXGMBX01.sasken.com>
References: <653A85C7F32C4741880F71219266EA022C406DEC4F@EXGMBX01.sasken.com>
<653A85C7F32C4741880F71219266EA022C4098E9D5@EXGMBX01.sasken.com>
Message-ID: <4EA980DF.7070000@real.com>
This looks good. The old logic of filling entries with backward values
doesn't seem to make sense at all.
fxd
On 10/27/2011 11:14 AM, Soma Gupta wrote:
> Can anyone pls review this fix as we need it urgently.
> Thanks,
> Soma
> ------------------------------------------------------------------------
> *From:* Soma Gupta
> *Sent:* Wednesday, October 26, 2011 3:47 PM
> *To:* 'datatype-dev@helixcommunity.org'
> *Subject:* CR: ou1cimx1# 897312:Music player's progress bar can't be
> dragged backward when playing a WMA format song.
>
> "Nokia submits this code under the terms of a commercial contribution
> agreement with Real Networks, and I am authorized to contribute this
> code under said agreement."
>
> Modified by: _ext-_soma.3.gupta@nokia.com
>
>
> Reviewed by: ext-dongsung.kim@nokia.com
>
>
> RC Id: ou1cimx1# 897312
>
> Date: 10/17/2011
>
> Project: symbian_client_apps
>
> Synopsis: Music player?s progress bar can?t be dragged backward when
> playing a WMA format song .
>
> Overview:When we start the playback from any non-zero position, if we
> seek backwards the playback always resumes from the playback start
> position and not the seeked position. This is because the data packet
> fetched from the playback start position is used to fill the first
> entry( fileoffset, timestamp) of the seek index table and all the
> previous entries in the table are set to that value. As a result if we
> seek backward, we are fetching the entry details of the first playback
> start entry and hence playback is resuming from there.
>
> Fix: When we add an entry in the index table in
> CHXASFIndex::SetIndexEntry(), we fill in all the uninitialized entries
> prior to it by searching backward till we find an initialized entry or
> reach the beginning of the table. From now while searching backwards
> for any initialized value in the CHXASFIndex::SetIndexEntry(), if we
> reach till the beginning of the table and cannot find any initialized
> entry, we will keep the entries uninitialized. This will ensure that
> we do not get any matching entry in the seek table built on-the-fly
> when we get a seek requestwhich corresponds to an index entry in that
> range. .
>
> Files modified:
>
> \datatype\wm\fileformat\Asf_index.cpp
>
> Image Size and Heap Use impact: NA
>
> Module Release testing (STIF) : Done
>
> Test case(s) Added : No
>
> Memory leak check performed : NA.
>
> Platforms and profiles build verified: helix-client-symbian-4
>
> Platforms and Profiles Functionality verified: armv5, winscw
>
> Branch: 420Brizo
>
> Diff files: Attached.
>
>
> ------------------------------------------------------------------------
> SASKEN BUSINESS DISCLAIMER: This message may contain confidential,
> proprietary or legally privileged information. In case you are not the
> original intended Recipient of the message, you must not, directly or
> indirectly, use, disclose, distribute, print, or copy any part of this
> message and you are requested to delete it and inform the sender. Any
> views expressed in this message are those of the individual sender
> unless otherwise stated. Nothing contained in this message shall be
> construed as an offer or acceptance of any offer by Sasken
> Communication Technologies Limited ("Sasken") unless sent with that
> express intent and with due authority of Sasken. Sasken has taken
> enough precautions to prevent the spread of viruses. However the
> company accepts no liability for any damage caused by any virus
> transmitted by this email.
> Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111027/f969333e/attachment-0001.html
From ext-suresh.dasari at nokia.com Fri Oct 28 04:18:47 2011
From: ext-suresh.dasari at nokia.com (Suresh Dasari)
Date: Fri Oct 28 04:20:38 2011
Subject: [datatype-dev] RE: ou1cimx1#654897: Video play back of Codenomicon
.avi format panic with Kern Exec 3
In-Reply-To: <653A85C7F32C4741880F71219266EA022C40636EC9@EXGMBX01.sasken.com>
References: <653A85C7F32C4741880F71219266EA022C40636EC9@EXGMBX01.sasken.com>
Message-ID: <002301cc9528$b2198870$164c9950$@dasari@nokia.com>
Any comments on this fix??
Regards,
Suresh
From: Suresh Dasari [mailto:ext-suresh.dasari@nokia.com]
Sent: Wednesday, October 26, 2011 2:10 PM
To: 'datatype-dev@helixcommunity.org';
'nokia-private-dev@helixcommunity.org'
Subject: CR: ou1cimx1#654897: Video play back of Codenomicon .avi format
panic with Kern Exec 3
"Nokia submits this code under the terms of a commercial contribution
agreement with Real Networks, and I am authorized to contribute this code
under said agreement."
Modified by: ext-suresh.dasari@nokia.com
Reviewed by: ext-maria.2.pascual-borrego@nokia.com,
ext-nadeem.wahid@nokia.com
RC Id: ou1cimx1#654897
Date: 26/10/2011
Project: SymbianMmf_wm
Synopsis: Video play back of Codenomicon .avi format panic with Kern Exec 3
Overview: In CAVIFileFormat::RIFFReadDone, no of elements in m_streamArray
is 2 but the value of m_usStreamTarget is going to 3 for this file, means
the array contains the data of two streams but we are trying to read the
data which is not available in stream array. This results in returning
NULL/Garbage value to the pointer pStream, which is later used to call a
method without checking against NULL.
Fix: For a valid file m_usStreamTarget cannot be more than the size of
m_streamArray, so value of m_usStreamTarget is checked and returned an error
code if it is greater than the size of m_streamArray.
File modified & changes:
datatype/avi/fileformat/aviffpln.cpp
Image Size and Heap Use impact: No Major impact
Module Release testing (STIF) : Passed
Test case(s) Added : No
Memory leak check performed : No Leaks
Platforms and Profiles Functionality verified: armv5
Branch: 420 Brizo
Diff: Attached
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111028/9613ef50/attachment.html
From zlin at real.com Fri Oct 28 04:26:51 2011
From: zlin at real.com (zlin)
Date: Fri Oct 28 04:28:07 2011
Subject: [datatype-dev] CR:Fix Bug 14064:C110-The aac audio file can not be
properly length.
Message-ID: <4EAA2F0B.1060100@real.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: aacff.h.diff
Type: text/x-patch
Size: 1095 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111028/1a1d6fb4/aacff.h.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aacff.cpp.diff
Type: text/x-patch
Size: 3156 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111028/1a1d6fb4/aacff.cpp.bin
From ext-debashis.2.panigrahi at nokia.com Fri Oct 28 05:15:40 2011
From: ext-debashis.2.panigrahi at nokia.com (ext-debashis.2.panigrahi@nokia.com)
Date: Fri Oct 28 05:16:58 2011
Subject: [datatype-dev] RE: [Nokia-private-dev] CR: 908398: SPPR_PERF Phone
is freeze when opening some special WMA format files in File Manager
In-Reply-To: <4EA979C6.7040909@real.com>
References: <099BCA98809A10489DC52CB686AA7364056692@008-AM1MPN1-027.mgdnok.nokia.com>
<4EA979C6.7040909@real.com>
Message-ID: <099BCA98809A10489DC52CB686AA736405C7DD@008-AM1MPN1-027.mgdnok.nokia.com>
Hi Sheldon,
According to specs Codec Entries count is DWORD of size 32 bit, but as the codec entries type is 16 bit, we don't expect number of entries to exceed that.
In a good asf file codec entries are generally 2 (one for audio and other for video), by limiting this value we are basically preventing Heap overflow.
Thanks and Regards,
Debashis.
From: ext Sheldon Fu [mailto:sfu@real.com]
Sent: Thursday, October 27, 2011 9:03 PM
To: Panigrahi Debashis.2 (EXT-Sasken/Bangalore)
Cc: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: Re: [Nokia-private-dev] CR: 908398: SPPR_PERF Phone is freeze when opening some special WMA format files in File Manager
This looks fine, though the limit value of 0xffff is arbitrary and not mandated by the spec, right? In practice, it shouldn't matter which limit value we use --- you won't have even 256 codec entries in a 'good' asf file I think.
fxd
On 10/27/2011 01:07 AM, ext-debashis.2.panigrahi@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: ext-debashis.2.panigrahi@nokia.com
Reviewed by: ext-prasoon.jaiswal@nokia.com
TSW Id: ou1cimx1#908398
Date: 10/27/2011
Project: symbian_client_apps
Synopsis: SPPR_PERF Phone is freeze when opening some special WMA format files in File Manager
Overview: These are specially crafted Windows Media Player content that potentially allows remote code execution if a user visits a malicious Web site or opens an e-mail message with malicious content. An attacker who successfully exploited this vulnerability could take complete control of an affected system.
This Trojan exploits the ASF Codec Entries Count(as described in Microsoft Security Bulletin MS06-078 : http://technet.microsoft.com/en-us/security/bulletin/ms06-078). The invalid Codec Entries causes the heap to overflow resulting in USER-47 panic/freeze.
Fix: This is fixed by detecting for invalid Codec Entries Count, by checking for a limiting value: HX_MAX_NUM_CODEC_ENTRIES = 0xFFFF, as the codec entries type is 16 bit.
Files modified & changes:
/cvsroot/datatype/wm/common/parse_asf_objects.cpp
/cvsroot/datatype/wm/common/pub/parse_asf_objects.h
Image Size and Heap Use impact: No major impact
Module Release testing (STIF): Done
Test case(s) Added: No
Memory leak check performed: Passed, No additional leaks introduced.
Platforms and Profiles Build Verified: helix-client-symbian-4
Platforms and Profiles Functionality verified: armv5
Branch: 420Brizo and HEAD
Diff:
Index: parse_asf_objects.cpp
===================================================================
RCS file: /cvsroot/datatype/wm/common/parse_asf_objects.cpp,v
retrieving revision 1.13.14.1
diff -u -w -r1.13.14.1 parse_asf_objects.cpp
--- parse_asf_objects.cpp 7 Jul 2010 23:22:45 -0000 1.13.14.1
+++ parse_asf_objects.cpp 20 Oct 2011 09:39:05 -0000
@@ -920,7 +920,7 @@
// Clear the return value
retVal = HXR_OK;
// Do we have any codec entries?
- if (m_ulNumCodecEntries)
+ if((m_ulNumCodecEntries > 0) && (m_ulNumCodecEntries < HX_ASF_MAX_NUM_CODEC_ENTRIES))
{
// Set the return value
retVal = HXR_OUTOFMEMORY;
Index: pub/parse_asf_objects.h
===================================================================
RCS file: /cvsroot/datatype/wm/common/pub/parse_asf_objects.h,v
retrieving revision 1.7.66.1
diff -u -w -r1.7.66.1 parse_asf_objects.h
--- pub/parse_asf_objects.h 7 Jul 2010 23:22:45 -0000 1.7.66.1
+++ pub/parse_asf_objects.h 20 Oct 2011 09:39:06 -0000
@@ -46,6 +46,7 @@
#define HX_ASF_HEADER_EXTENSION_SIZE 22
#define HX_ASF_DATA_OBJECT_SIZE 26
#define HX_INVALID_STREAM_NUMBER 255
+#define HX_MAX_NUM_CODEC_ENTRIES 0xFFFF
// The standard way of representing GUIDs as strings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111028/4cd94893/attachment-0001.html
From sfu at real.com Fri Oct 28 14:23:37 2011
From: sfu at real.com (Sheldon Fu)
Date: Fri Oct 28 14:25:09 2011
Subject: [datatype-dev] Re: [Nokia-private-dev] CR: 908398: SPPR_PERF Phone
is freeze when opening some special WMA format files in File Manager
In-Reply-To: <099BCA98809A10489DC52CB686AA736405C7DD@008-AM1MPN1-027.mgdnok.nokia.com>
References: <099BCA98809A10489DC52CB686AA7364056692@008-AM1MPN1-027.mgdnok.nokia.com>
<4EA979C6.7040909@real.com>
<099BCA98809A10489DC52CB686AA736405C7DD@008-AM1MPN1-027.mgdnok.nokia.com>
Message-ID: <4EAABAE9.5040900@real.com>
Not that it matters much but the 'type' field is not supposedly to be
unique I think -- it takes only 3 possible values anyway. Just because
the type field is 16 bit doesn't mean there can not be more than 2^16
entries.
Again this doesn't matte, since any other limit value is as well arbitrary.
Looks good and please check in.
fxd
On 10/28/2011 01:15 AM, ext-debashis.2.panigrahi@nokia.com wrote:
>
> Hi Sheldon,
>
> According to specs Codec Entries count is DWORD of size 32 bit, but as
> the codec entries type is 16 bit, we don?t expect number of entries to
> exceed that.
>
> In a good asf file codec entries are generally 2 (one for audio and
> other for video), by limiting this value we are basically preventing
> Heap overflow.
>
> Thanks and Regards,
>
> Debashis.
>
> *From:*ext Sheldon Fu [mailto:sfu@real.com]
> *Sent:* Thursday, October 27, 2011 9:03 PM
> *To:* Panigrahi Debashis.2 (EXT-Sasken/Bangalore)
> *Cc:* datatype-dev@helixcommunity.org;
> nokia-private-dev@helixcommunity.org
> *Subject:* Re: [Nokia-private-dev] CR: 908398: SPPR_PERF Phone is
> freeze when opening some special WMA format files in File Manager
>
> This looks fine, though the limit value of 0xffff is arbitrary and not
> mandated by the spec, right? In practice, it shouldn't matter which
> limit value we use --- you won't have even 256 codec entries in a
> 'good' asf file I think.
>
> fxd
>
> On 10/27/2011 01:07 AM, ext-debashis.2.panigrahi@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: ext-debashis.2.panigrahi@nokia.com
>
>
> Reviewed by: ext-prasoon.jaiswal@nokia.com
>
>
> TSW Id: ou1cimx1#908398
>
> Date: 10/27/2011
>
> Project: symbian_client_apps
>
> Synopsis: SPPR_PERF Phone is freeze when opening some special WMA
> format files in File Manager
>
> Overview: These are specially crafted Windows Media Player content
> that potentially allows remote code execution if a user visits a
> malicious Web site or opens an e-mail message with malicious content.
> An attacker who successfully exploited this vulnerability could take
> complete control of an affected system.
>
> This Trojan exploits the ASF Codec Entries Count(as described in
> Microsoft Security Bulletin MS06-078 :
> http://technet.microsoft.com/en-us/security/bulletin/ms06-078). The
> invalid Codec Entries causes the heap to overflow resulting in USER-47
> panic/freeze.
>
> Fix: This is fixed by detecting for invalid Codec Entries Count, by
> checking for a limiting value: HX_MAX_NUM_CODEC_ENTRIES = 0xFFFF, as
> the codec entries type is 16 bit.
>
> Files modified & changes:
>
> /cvsroot/datatype/wm/common/parse_asf_objects.cpp
>
> /cvsroot/datatype/wm/common/pub/parse_asf_objects.h
>
> Image Size and Heap Use impact: No major impact
>
> Module Release testing (STIF): Done
>
> Test case(s) Added: No
>
> Memory leak check performed: Passed, No additional leaks introduced.
>
> Platforms and Profiles Build Verified: helix-client-symbian-4
>
> Platforms and Profiles Functionality verified: armv5
>
> Branch: 420Brizo and HEAD
>
> Diff:
>
> Index: parse_asf_objects.cpp
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/wm/common/parse_asf_objects.cpp,v
>
> retrieving revision 1.13.14.1
>
> diff -u -w -r1.13.14.1 parse_asf_objects.cpp
>
> --- parse_asf_objects.cpp 7 Jul 2010 23:22:45
> -0000 1.13.14.1
>
> +++ parse_asf_objects.cpp 20 Oct 2011 09:39:05 -0000
>
> @@ -920,7 +920,7 @@
>
> // Clear the return value
>
> retVal = HXR_OK;
>
> // Do we have any codec entries?
>
> - if (m_ulNumCodecEntries)
>
> + if((m_ulNumCodecEntries > 0) && (m_ulNumCodecEntries <
> HX_ASF_MAX_NUM_CODEC_ENTRIES))
>
> {
>
> // Set the return value
>
> retVal = HXR_OUTOFMEMORY;
>
> Index: pub/parse_asf_objects.h
>
> ===================================================================
>
> RCS file: /cvsroot/datatype/wm/common/pub/parse_asf_objects.h,v
>
> retrieving revision 1.7.66.1
>
> diff -u -w -r1.7.66.1 parse_asf_objects.h
>
> --- pub/parse_asf_objects.h 7 Jul 2010 23:22:45
> -0000 1.7.66.1
>
> +++ pub/parse_asf_objects.h 20 Oct 2011 09:39:06 -0000
>
> @@ -46,6 +46,7 @@
>
> #define HX_ASF_HEADER_EXTENSION_SIZE 22
>
> #define HX_ASF_DATA_OBJECT_SIZE 26
>
> #define HX_INVALID_STREAM_NUMBER 255
>
> +#define HX_MAX_NUM_CODEC_ENTRIES 0xFFFF
>
> // The standard way of representing GUIDs as strings
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111028/dd774dad/attachment.html
From pbasic at real.com Fri Oct 28 16:10:11 2011
From: pbasic at real.com (Petar Basic)
Date: Fri Oct 28 16:11:51 2011
Subject: [datatype-dev] CR/CN: GMP Meta-editor fixes: Bug #18367,
Issue #18358. [GMPMetaEditor branch]
Message-ID:
Modified by: pbasic at real.com
Date: 2011/10/28
Project: GMPMetaEditor (meta3gp.exe)
Synopsis:
GMP Meta-editor fixes: Bug #18367, Issue #18358. [GMPMetaEditor branch]
Details:
1.) Fixed GMP Meta-editor (Redmine) Bug #18367: "meta3gp error with
artist/composer over 255 chars".
The code has been corrected to pass the value of meta-flavor parameter
to all the routines which check the length of meta-data string
parameters.
2.) Fixed GMP Meta-editor (Redmine) Issue #18358: "Metadata tool
increases filesize although no metadata is added".
The final output file contains a 'free' atom following the 'moov'
atom. The space required for sample tables contained by the 'moov'
atom seems to be overestimated by the mp4-filewriter. With this
strategy, the 'free' atom can sometimes account for more than 10% of
output file size which is not desirable. Quick fix is to employ
already existing mp4-filewriter's "ForceMoovFirst" option. In this
mode, mp4-filewriter uses a second temporary file to store the 'mdat'
samples while it builds the sample tables in the 'moov' atom. The
filewriter then simply appends 'mdat' atom right after the 'moov' atom
without putting an extraneous 'free' atom between them. Usage of a
second temporary file keeps the final output file size to the minimum,
but probably reduces Meta-editor tool's performance. Some testing on
larger files is required to determine whether more elaborate fixes are
required at this moment.
Files Modified:
datatype/tools/dtdriver/apps/meta3gp/main.cpp
datatype/tools/dtdriver/engine/ffdriver.cpp
datatype/tools/dtdriver/engine/pub/ffdriver.h
Platforms and Profiles Affected:
All
Image Size and Heap Use impact:
None
Platforms and Profiles Build Verified:
system id: win32-i386-vc7
profile: helix-client-all-defines
Platforms and Profiles Functionality Verified:
x86 Windows XP SP2
Branch:
GMPMetaEditor
Copyright assignment:
I am a RealNetworks employee or contractor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype_tools_dtdriver_apps_meta3gp.diff
Type: application/octet-stream
Size: 21621 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111028/113531b8/datatype_tools_dtdriver_apps_meta3gp-0001.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: datatype_tools_dtdriver_engine.diff
Type: application/octet-stream
Size: 10108 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111028/113531b8/datatype_tools_dtdriver_engine-0001.obj
From zlin at real.com Sun Oct 30 12:02:12 2011
From: zlin at real.com (zlin)
Date: Sun Oct 30 12:03:35 2011
Subject: [datatype-dev] CR:Fix Bug 14051:c110-the avi media file can not be
stoped
Message-ID: <4EAD3CC4.3010100@real.com>
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: avistrm.cpp.diff
Type: text/x-patch
Size: 693 bytes
Desc: not available
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111030/650e0088/avistrm.cpp.bin
From jgordon at real.com Sun Oct 30 22:50:54 2011
From: jgordon at real.com (Jamie Gordon)
Date: Sun Oct 30 22:52:47 2011
Subject: [datatype-dev] Re: [Nokia-private-dev] CR: ou1cimx1#859838 - Helix
panic detected in MobileCrash
In-Reply-To:
References:
Message-ID: <1320015054.4681.517.camel@franny>
ok
On Fri, 2011-10-28 at 03:59 -0700, ext-barry.2.alcock@nokia.com wrote:
> "Nokia submits this code under the terms of a commercial contribution
> agreement with Real Networks, and I am authorized to contribute this
> code under said agreement."
>
>
>
> Modified by: ext-barry.alcock@nokia.com
>
>
>
> Reviewed by:
>
>
>
> RC Id: ou1cimx1#859838
>
>
>
> Date: 28/10/2011
>
>
>
> Project: SymbianMmf_wm
>
>
>
> Synopsis: Helix panic detected in MobileCrash
>
>
>
> Overview:
>
> In CAVIStream::GetHeader() there is a memcpy that copies ulClrUsed
> number of RGBQuad?s into a BitmapInfo structure on the stack for avi?s
> with a usBitCount <= 8.
>
> The structure allows for at most 256 RGBQuads, but ulClrUsed is 32-bit
> and therefore if corrupted can cause the stack to be trashed.
>
> The memcpy is actually redundant since the BitmapInfo structure with
> the color table is copied by assignment a few lines earlier.
>
> In CAVIStream::SetFormat() there is a loop to populate the color table
> of the BitmapInfo structure where the usBitCount is <= 8.
>
> If uClrUsed is corrupt this loop can trash the heap. With the
> exception of zeroing the ubReserved member of the RGBQuad?s it is also
> redundant since the data has already copied by an ealier memcpy.
>
>
>
> Fix:
>
> In SetFormat() verify and set an appropriate value in ulClrUsed.
>
> In SetFormat() If the IHXBuffer does not contain enough data to
> satisfy the number of colors used return a failure.
>
> In SetFormat() Remove excess code from the loop.
>
> In GetHeader() Remove the redundant memcpy.
>
>
>
> File modified & changes:
> datatype/avi/fileformat/avistrm.cpp
>
>
> Image Size and Heap Use impact: No Major impact
>
>
>
> Module Release testing (STIF) : Passed
>
>
>
> Test case(s) Added : No
>
>
>
> Memory leak check performed : No Leaks
>
>
>
> Platforms and Profiles Functionality verified: armv5
>
>
>
> Branch: 420 Brizo
>
>
>
> Diff: Attached
>
>
>
>
From hxing at real.com Mon Oct 31 09:09:22 2011
From: hxing at real.com (Henry Xing)
Date: Mon Oct 31 09:10:48 2011
Subject: [datatype-dev] CR:Fix Bug 14051:c110-the avi media file can not
be stoped
In-Reply-To: <4EAD3CC4.3010100@real.com>
Message-ID: <7ECCEA249B7CDC49A079EC0075E999AA0B67A374ED@SEAMBX.corp.real.com>
Looks good to me.
Please add some comments in your patch when check in explain the reason.
henry
________________________________
From: datatype-dev-bounces@helixcommunity.org [mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of Dinel Lin
Sent: Sunday, October 30, 2011 8:02 PM
To: datatype-dev@helixcommunity.org
Subject: [datatype-dev] CR:Fix Bug 14051:c110-the avi media file can not be stoped
Modified by:zlin@real.com
Date: 10/30/2011
Project: RealPlayer for Android Smartphones
Synopsis:c110-the avi media file can not be stoped
Overview:When playing specific avi content,the playback can
not be stopped and the status will be buffering forever.After
investigation,I found this issue was caused by the length of
index table was shorter than the real length of the media
playback.In other words,some indexes are missing at the end
of the clip.Then it will cause method FindClosestChunk return
the maximum index.However,it still not what we need.Meanwhile,
the error code HXR_NOT_INDEXABLE will be returned and indicates
we have already reached the end of the index table.In order to
conquer this question,simply update the target chunk number
according to the parameter of FindClosestChunk.It will continue
the playback even the index table end reached.In deed,it is strange
to trust index table more than the real media content.
Files Added:
None
Files Modified:
datatype/avi/fileformat/avistrm.cpp
Image Size and Heap Use impact (Client -Only): None
Platforms and Profiles Affected:
Platform: android-2.3-arm-smdk_c110
Profile: helix-client-android-LePhoneTD-C110
Distribution Libraries Affected:None
Distribution library impact and planned action:None
Platforms and Profiles Build Verified:
Platform: android-2.3-arm-smdk_c110
Profile: helix-client-android-LePhoneTD-C110
Platforms and Profiles Functionality verified:
Platform: android-2.3-arm-smdk_c110
Profile: helix-client-android-LePhoneTD-C110
Branch: 361atlas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111031/cc75a31d/attachment.html
From ext-chandra.2.kumar at nokia.com Mon Oct 31 13:03:15 2011
From: ext-chandra.2.kumar at nokia.com (Chandra Bhushan Kumar)
Date: Mon Oct 31 13:04:55 2011
Subject: [datatype-dev] RE: ou1cimx1#654897: Video play back of
Codenomicon.avi format panic with Kern Exec 3
In-Reply-To: <002301cc9528$b2198870$164c9950$@dasari@nokia.com>
Message-ID:
[On behalf of Suresh Dasari]
Any comments?
Warm Regards,
Chandra Bhushan Kumar
_____
From: datatype-dev-bounces@helixcommunity.org
[mailto:datatype-dev-bounces@helixcommunity.org] On Behalf Of ext Suresh
Dasari
Sent: Friday, October 28, 2011 9:49 AM
To: datatype-dev@helixcommunity.org; nokia-private-dev@helixcommunity.org
Subject: [datatype-dev] RE: ou1cimx1#654897: Video play back of
Codenomicon.avi format panic with Kern Exec 3
Any comments on this fix??
Regards,
Suresh
From: Suresh Dasari [mailto:ext-suresh.dasari@nokia.com]
Sent: Wednesday, October 26, 2011 2:10 PM
To: 'datatype-dev@helixcommunity.org';
'nokia-private-dev@helixcommunity.org'
Subject: CR: ou1cimx1#654897: Video play back of Codenomicon .avi format
panic with Kern Exec 3
"Nokia submits this code under the terms of a commercial contribution
agreement with Real Networks, and I am authorized to contribute this code
under said agreement."
Modified by: ext-suresh.dasari@nokia.com
Reviewed by: ext-maria.2.pascual-borrego@nokia.com,
ext-nadeem.wahid@nokia.com
RC Id: ou1cimx1#654897
Date: 26/10/2011
Project: SymbianMmf_wm
Synopsis: Video play back of Codenomicon .avi format panic with Kern Exec 3
Overview: In CAVIFileFormat::RIFFReadDone, no of elements in m_streamArray
is 2 but the value of m_usStreamTarget is going to 3 for this file, means
the array contains the data of two streams but we are trying to read the
data which is not available in stream array. This results in returning
NULL/Garbage value to the pointer pStream, which is later used to call a
method without checking against NULL.
Fix: For a valid file m_usStreamTarget cannot be more than the size of
m_streamArray, so value of m_usStreamTarget is checked and returned an error
code if it is greater than the size of m_streamArray.
File modified & changes:
datatype/avi/fileformat/aviffpln.cpp
Image Size and Heap Use impact: No Major impact
Module Release testing (STIF) : Passed
Test case(s) Added : No
Memory leak check performed : No Leaks
Platforms and Profiles Functionality verified: armv5
Branch: 420 Brizo
Diff: Attached
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111031/957c7f97/attachment-0001.html
From ext-soma.3.gupta at nokia.com Fri Oct 21 05:02:46 2011
From: ext-soma.3.gupta at nokia.com (soma gupta)
Date: Sat Dec 3 00:10:54 2011
Subject: [datatype-dev] CR: ou1cimx1# 897312:Music player's progress bar
can't be dragged backward when playing a WMA format song.
Message-ID:
Index: asf_index.cpp
===================================================================
RCS file: /cvsroot/datatype/wm/fileformat/asf_index.cpp,v
retrieving revision 1.3.14.6
diff -u -r1.3.14.6 asf_index.cpp
--- asf_index.cpp 10 Aug 2010 04:04:21 -0000 1.3.14.6
+++ asf_index.cpp 21 Oct 2011 04:53:40 -0000
@@ -553,26 +553,12 @@
{
j--;
}
- // Did we find an initialized value? If j
- if (m_ppIndexEntry[usWMStreamNumber][j].m_ullFileOffset == HXASF_INDEX_INVALID_ENTRY_VALUE)
- {
- // We must have gone back to the beginning
- HX_ASSERT(j == 0);
- // We searched back to the beginning, but we still
- // didn't find an initialized value. Therefore, we need
- // to fill in from 0 to ulEntry - 1 with the value
- // we just put into ulEntry.
- for (UINT32 k = j; k < ulEntry; k++)
- {
- m_ppIndexEntry[usWMStreamNumber][k].m_ulPresentationTime = ulPresentationTime;
- m_ppIndexEntry[usWMStreamNumber][k].m_ullFileOffset = ullFileOffset;
- }
- }
- else
- {
- // We found an initialized value. Therefore, we need
- // to fill from j to ulEntry - 1 with the initialized
- // value at j.
+ // If we found an initialized value, we need to fill
+ // from j to ulEntry - 1 with the initialized value at j.
+ // If we have searched back to the begining and didn't
+ // find any initialized value, we will not fill the entries.
+ if (m_ppIndexEntry[usWMStreamNumber][j].m_ullFileOffset != HXASF_INDEX_INVALID_ENTRY_VALUE)
+ {
UINT32 ulPresTime = m_ppIndexEntry[usWMStreamNumber][j].m_ulPresentationTime;
UINT64 ullOffset = m_ppIndexEntry[usWMStreamNumber][j].m_ullFileOffset;
for (UINT32 k = j + 1; k < ulEntry; k++)
From ext-soma.3.gupta at nokia.com Mon Oct 24 05:17:18 2011
From: ext-soma.3.gupta at nokia.com (soma gupta)
Date: Sat Dec 3 00:10:57 2011
Subject: [datatype-dev] CR: ou1cimx1# 897312:Music player's progress bar
can't be dragged backward when playing a WMA format song.
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
Index: asf_index.cpp
===================================================================
RCS file: /cvsroot/datatype/wm/fileformat/asf_index.cpp,v
retrieving revision 1.3.14.6
diff -u -r1.3.14.6 asf_index.cpp
--- asf_index.cpp 10 Aug 2010 04:04:21 -0000 1.3.14.6
+++ asf_index.cpp 21 Oct 2011 04:53:40 -0000
@@ -553,26 +553,12 @@
{
j--;
}
- // Did we find an initialized value? If j
- if (m_ppIndexEntry[usWMStreamNumber][j].m_ullFileOffset == HXASF_INDEX_INVALID_ENTRY_VALUE)
- {
- // We must have gone back to the beginning
- HX_ASSERT(j == 0);
- // We searched back to the beginning, but we still
- // didn't find an initialized value. Therefore, we need
- // to fill in from 0 to ulEntry - 1 with the value
- // we just put into ulEntry.
- for (UINT32 k = j; k < ulEntry; k++)
- {
- m_ppIndexEntry[usWMStreamNumber][k].m_ulPresentationTime = ulPresentationTime;
- m_ppIndexEntry[usWMStreamNumber][k].m_ullFileOffset = ullFileOffset;
- }
- }
- else
- {
- // We found an initialized value. Therefore, we need
- // to fill from j to ulEntry - 1 with the initialized
- // value at j.
+ // If we found an initialized value, we need to fill
+ // from j to ulEntry - 1 with the initialized value at j.
+ // If we have searched back to the begining and didn't
+ // find any initialized value, we will not fill the entries.
+ if (m_ppIndexEntry[usWMStreamNumber][j].m_ullFileOffset != HXASF_INDEX_INVALID_ENTRY_VALUE)
+ {
UINT32 ulPresTime = m_ppIndexEntry[usWMStreamNumber][j].m_ulPresentationTime;
UINT64 ullOffset = m_ppIndexEntry[usWMStreamNumber][j].m_ullFileOffset;
for (UINT32 k = j + 1; k < ulEntry; k++)
From ext-barry.2.alcock at nokia.com Fri Oct 28 11:00:41 2011
From: ext-barry.2.alcock at nokia.com (ext-barry.2.alcock@nokia.com)
Date: Sat Dec 3 00:10:58 2011
Subject: [datatype-dev] CR: ou1cimx1#859838 - Helix panic detected in
MobileCrash
Message-ID:
Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: ou1cimx1_859838.diff
Type: application/octet-stream
Size: 2667 bytes
Desc: ou1cimx1_859838.diff
Url : http://lists.helixcommunity.org/pipermail/datatype-dev/attachments/20111028/6c10c99a/ou1cimx1_859838-0001.obj
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.