Fw: TimeStamp issue with Real Format SDK

Hi,
Seems this missed your attention
Sending again.

Thanks & Regards,
Lovish
----- Original Message ----- 
From: "Lovish Dhawan" <ldhawanreal.com>
To: <ehychereal.com>
Cc: <helix-client-devhelixcommunity.org>;
"Karl Lillevold" 
<klillevoldreal.com>; "Neelesh Gokhale"
<ngokhalereal.com>
Sent: Friday, September 14, 2007 7:58 PM
Subject: Re: TimeStamp issue with Real Format SDK


> Hi Eric,
>
> I am not very sure as to why the decoder is failing for
second frame.
>
> Even if the second frame failed to get decoded,
shouldn't the third frame 
> and consequent frames would have come
> and played at their time and not at the time of the
previous frame.
>
> In case 2nd frame decode is failing, do we need to
render the 3rd sample 
> at 119ms or 239ms? If we need to render it at 239ms,
then decoder should 
> take care of updating the timestamp value in case of
the failure?
>
> For a 10 FPS clip, timestamps are as below from the
real parser.
> 0, 119, 239, 359, 479, 599, 719, 839, 959, 1079, 1199,
1319
>
> Timestamps from the decoder are as below.
> 0, FAILURE, 119, 239, 359, 479, 599, 719, 839, 959,
1079, 1199
>
>
> It seems that dst.sequence_number is updated properly,
but the time 
> rv_decode_frame_valid() method fails, decoder is not
flushing the frame 
> and in the next call to rv_decode_stream_decode method,
it is giving the 
> prev frame and thus, from there onwards,
src.sequence_number is greater 
> than of dst.sequence_number.
>
>
> Thanks & Regards,
> Lovish
>
> ----- Original Message ----- 
> From: "Eric Hyche" <ehychereal.com>
> To: "'Lovish Dhawan'" <ldhawanreal.com>
> Cc: <helix-client-devhelixcommunity.org>;
"Karl Lillevold" 
> <klillevoldreal.com>; "Neelesh Gokhale"
<ngokhalereal.com>
> Sent: Friday, September 14, 2007 7:43 PM
> Subject: RE: TimeStamp issue with Real Format SDK
>
>
>>
>> Lovish,
>>
>> Why is the decoding failing? Is this a corrupted
file?
>> As far as the problem of the timestamps getting out
of
>> sync, this may be a codec issue, so I'm copying
>> Karl and Neelesh on this.
>>
>> Eric
>>
>> =============================================
>> Eric Hyche (ehychereal.com)
>> Technical Lead
>> RealNetworks, Inc.
>>
>>> -----Original Message-----
>>> From: Lovish Dhawan [mailto:ldhawanreal.com]
>>> Sent: Friday, September 14, 2007 10:04 AM
>>> To: ehychereal.com
>>> Cc: helix-client-devhelixcommunity.org
>>> Subject: TimeStamp issue with Real Format SDK
>>>
>>> Hi Eric,
>>>
>>> There is an issue with one of our client which
is as follows:
>>>
>>> If a frame is not decoded correctly and at the
check of
>>> rv_decode_frame_valid() method returns failure
code. then
>>> subsequent all the frames
>>> display the video which should be of their
previous timestamp.
>>>
>>> Timestamps from the decoder are as below.
>>> 0, FAILURE, 119, 239, 359, 479, 599, 719, 839,
959, 1079, 1199
>>>
>>> and not
>>>
>>> For a 10 FPS clip, timestamps are as below from
the real parser.
>>> 0, 119, 239, 359, 479, 599, 719, 839, 959,
1079, 1199, 1319
>>>
>>> In the case above, decoder fails for 2nd frame,
but the 3rd
>>> frame timestamp value corresponds to the 2nd
frame timestamp.
>>> In case decoder is failing for 10 frames (for
any reason)
>>> after first frame decoding,
>>> then the 12th frame (decoded successfully)
timestamp value
>>> from the decoder will be 1199,
>>>  but it should be 1319 to play the file with
proper A/V sync
>>>
>>> After taking logs (displayed under) we found
that the
>>> src.sequence_number remains ahead of
dst.sequence_number
>>>
>>> Some logs that were taken from the function
_RV40toYUV420Transform()
>>>
>>>     /* Assign the presentation time for the
display frame */
>>>     pRV20Out->timestamp =
dst.sequence_number + temporal_offset;
>>>  gives output as
>>>
>>> pRV20Out->timestamp : 0 dst.sequence_number
: 0
>>> src.sequence_number : 0 temporal_offset : 0
>>> pRV20Out->timestamp : 119
dst.sequence_number : 119
>>> src.sequence_number : 119 temporal_offset : 0
>>> rv_decode_frame_valid Failed
>>> pRV20Out->timestamp : 119
dst.sequence_number : 119
>>> src.sequence_number : 239 temporal_offset : 0
>>> pRV20Out->timestamp : 239
dst.sequence_number : 239
>>> src.sequence_number : 359 temporal_offset : 0
>>> pRV20Out->timestamp : 359
dst.sequence_number : 359
>>> src.sequence_number : 479 temporal_offset : 0
>>> pRV20Out->timestamp : 479
dst.sequence_number : 479
>>> src.sequence_number : 599 temporal_offset : 0
>>> ...
>>> ...
>>>
>>> Now one more thing that is found is
>>>
>>> it seems that dst.sequence_number is updated
properly, but
>>> the time rv_decode_frame_valid method fails,
decoder is not
>>> flushing the frame and in the next call to
>>> rv_decode_stream_decode method, it is giving
the prev frame
>>> and thus, from there onwards,
src.sequence_number is greater
>>> than of dst.sequence_number.
>>>
>>> API: Decoder_prepareDecodeBuffers
>>> (t->m_pCurrentFrame->m_pPreviousFrame ==
NULL)
>>> t->m_pCurrentFrame->m_timeStamp =
src->sequence_number (0 = 0)
>>> API: Decoder_prepareDecodeBuffers
dst->sequence_number =
>>> pDisplayFrame->m_timeStamp (0 = 0)
>>> pRV20Out->timestamp : 0 dst.sequence_number
: 0
>>> src.sequence_number : 0 temporal_offset : 0
>>> API: Decoder_prepareDecodeBuffers
>>> t->m_pCurrentFrame->m_timeStamp =
src->sequence_number (119 = 119)
>>> pRV20Out->timestamp : 119
dst.sequence_number : 119
>>> src.sequence_number : 119 temporal_offset : 0
>>> rv_decode_frame_valid Failed
>>> API: Decoder_prepareDecodeBuffers
t->m_pDisplayFrame = pPreviousTail
>>> API: Decoder_prepareDecodeBuffers
dst->sequence_number =
>>> pDisplayFrame->m_timeStamp (119 = 119)
>>> API: Decoder_prepareDecodeBuffers
>>> t->m_pCurrentFrame->m_timeStamp =
src->sequence_number (239 = 239)
>>>
>>>
>>> Please tell how to go about this issue.
>>>
>>> Thanks & Regards,
>>> Lovish
>>>
>>
> 


_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev

> -----Original Message-----
> From: Lovish Dhawan [mailto:ldhawanreal.com]

> Sent: Tuesday, September 18, 2007 7:24 AM
> To: ehychereal.com
> Cc: helix-client-devhelixcommunity.org; Karl
Lillevold; 
> ngokhalereal.com
> Subject: Fw: TimeStamp issue with Real Format SDK
> 
> Hi,
> Seems this missed your attention
> Sending again.
> 
> Thanks & Regards,
> Lovish
> ----- Original Message ----- 
> From: "Lovish Dhawan" <ldhawanreal.com>
> To: <ehychereal.com>
> Cc: <helix-client-devhelixcommunity.org>;
"Karl Lillevold" 
> <klillevoldreal.com>; "Neelesh Gokhale"
<ngokhalereal.com>
> Sent: Friday, September 14, 2007 7:58 PM
> Subject: Re: TimeStamp issue with Real Format SDK
> 
> 
> > Hi Eric,
> >
> > I am not very sure as to why the decoder is
failing for 
> second frame.
> >
> > Even if the second frame failed to get decoded,
shouldn't 
> > the third frame and consequent frames would have
come
> > and played at their time and not at the time of
the previous frame.
> >
> > In case 2nd frame decode is failing, do we need to
render 
> > the 3rd sample at 119ms or 239ms? If we need to
render it at 239ms, then 
> > decoder should take care of updating the timestamp
value in case of the failure?
> >

Yes, the 3rd sample should still have a decoded timestamp
of 239ms. I don't know without looking at the code whether:

a) decoder properly tells the RealFormat SDK code that
decoding
   of the 2nd sample failed, and the RealFormat SDK is not
   properly flushing that frame; or
b) decoder is not telling RealFormat SDK code that decoding
   of the 2nd sample failed.

I'll try and take a look in the RealFormat SDK code to
see which it is.

Can you get a copy of the clip for which this occurs?
Does this repro using the rm2yuv sample app?

In practice, decoding failure should be extremely rare,
and should probably only happen on: a) corrupted files; or
b) network playback if there's a bug in their loss-handling
code.

Eric

> > For a 10 FPS clip, timestamps are as below from
the real parser.
> > 0, 119, 239, 359, 479, 599, 719, 839, 959, 1079,
1199, 1319
> >
> > Timestamps from the decoder are as below.
> > 0, FAILURE, 119, 239, 359, 479, 599, 719, 839,
959, 1079, 1199
> >
> >
> > It seems that dst.sequence_number is updated
properly, but the time 
> > rv_decode_frame_valid() method fails, decoder is
not 
> flushing the frame 
> > and in the next call to rv_decode_stream_decode
method, it 
> is giving the 
> > prev frame and thus, from there onwards, 
> src.sequence_number is greater 
> > than of dst.sequence_number.
> >
> >
> > Thanks & Regards,
> > Lovish
> >
> > ----- Original Message ----- 
> > From: "Eric Hyche" <ehychereal.com>
> > To: "'Lovish Dhawan'" <ldhawanreal.com>
> > Cc: <helix-client-devhelixcommunity.org>;
"Karl Lillevold" 
> > <klillevoldreal.com>; "Neelesh
Gokhale" <ngokhalereal.com>
> > Sent: Friday, September 14, 2007 7:43 PM
> > Subject: RE: TimeStamp issue with Real Format SDK
> >
> >
> >>
> >> Lovish,
> >>
> >> Why is the decoding failing? Is this a
corrupted file?
> >> As far as the problem of the timestamps
getting out of
> >> sync, this may be a codec issue, so I'm
copying
> >> Karl and Neelesh on this.
> >>
> >> Eric
> >>
> >> =============================================
> >> Eric Hyche (ehychereal.com)
> >> Technical Lead
> >> RealNetworks, Inc.
> >>
> >>> -----Original Message-----
> >>> From: Lovish Dhawan [mailto:ldhawanreal.com]
> >>> Sent: Friday, September 14, 2007 10:04 AM
> >>> To: ehychereal.com
> >>> Cc: helix-client-devhelixcommunity.org
> >>> Subject: TimeStamp issue with Real Format
SDK
> >>>
> >>> Hi Eric,
> >>>
> >>> There is an issue with one of our client
which is as follows:
> >>>
> >>> If a frame is not decoded correctly and at
the check of
> >>> rv_decode_frame_valid() method returns
failure code. then
> >>> subsequent all the frames
> >>> display the video which should be of their
previous timestamp.
> >>>
> >>> Timestamps from the decoder are as below.
> >>> 0, FAILURE, 119, 239, 359, 479, 599, 719,
839, 959, 1079, 1199
> >>>
> >>> and not
> >>>
> >>> For a 10 FPS clip, timestamps are as below
from the real parser.
> >>> 0, 119, 239, 359, 479, 599, 719, 839, 959,
1079, 1199, 1319
> >>>
> >>> In the case above, decoder fails for 2nd
frame, but the 3rd
> >>> frame timestamp value corresponds to the
2nd frame timestamp.
> >>> In case decoder is failing for 10 frames
(for any reason)
> >>> after first frame decoding,
> >>> then the 12th frame (decoded successfully)
timestamp value
> >>> from the decoder will be 1199,
> >>>  but it should be 1319 to play the file
with proper A/V sync
> >>>
> >>> After taking logs (displayed under) we
found that the
> >>> src.sequence_number remains ahead of
dst.sequence_number
> >>>
> >>> Some logs that were taken from the
function 
> _RV40toYUV420Transform()
> >>>
> >>>     /* Assign the presentation time for
the display frame */
> >>>     pRV20Out->timestamp =
dst.sequence_number + temporal_offset;
> >>>  gives output as
> >>>
> >>> pRV20Out->timestamp : 0
dst.sequence_number : 0
> >>> src.sequence_number : 0 temporal_offset :
0
> >>> pRV20Out->timestamp : 119
dst.sequence_number : 119
> >>> src.sequence_number : 119 temporal_offset
: 0
> >>> rv_decode_frame_valid Failed
> >>> pRV20Out->timestamp : 119
dst.sequence_number : 119
> >>> src.sequence_number : 239 temporal_offset
: 0
> >>> pRV20Out->timestamp : 239
dst.sequence_number : 239
> >>> src.sequence_number : 359 temporal_offset
: 0
> >>> pRV20Out->timestamp : 359
dst.sequence_number : 359
> >>> src.sequence_number : 479 temporal_offset
: 0
> >>> pRV20Out->timestamp : 479
dst.sequence_number : 479
> >>> src.sequence_number : 599 temporal_offset
: 0
> >>> ...
> >>> ...
> >>>
> >>> Now one more thing that is found is
> >>>
> >>> it seems that dst.sequence_number is
updated properly, but
> >>> the time rv_decode_frame_valid method
fails, decoder is not
> >>> flushing the frame and in the next call
to
> >>> rv_decode_stream_decode method, it is
giving the prev frame
> >>> and thus, from there onwards,
src.sequence_number is greater
> >>> than of dst.sequence_number.
> >>>
> >>> API: Decoder_prepareDecodeBuffers
> >>>
(t->m_pCurrentFrame->m_pPreviousFrame == NULL)
> >>> t->m_pCurrentFrame->m_timeStamp =
src->sequence_number (0 = 0)
> >>> API: Decoder_prepareDecodeBuffers
dst->sequence_number =
> >>> pDisplayFrame->m_timeStamp (0 = 0)
> >>> pRV20Out->timestamp : 0
dst.sequence_number : 0
> >>> src.sequence_number : 0 temporal_offset :
0
> >>> API: Decoder_prepareDecodeBuffers
> >>> t->m_pCurrentFrame->m_timeStamp =
src->sequence_number (119 = 119)
> >>> pRV20Out->timestamp : 119
dst.sequence_number : 119
> >>> src.sequence_number : 119 temporal_offset
: 0
> >>> rv_decode_frame_valid Failed
> >>> API: Decoder_prepareDecodeBuffers
t->m_pDisplayFrame = 
> pPreviousTail
> >>> API: Decoder_prepareDecodeBuffers
dst->sequence_number =
> >>> pDisplayFrame->m_timeStamp (119 = 119)
> >>> API: Decoder_prepareDecodeBuffers
> >>> t->m_pCurrentFrame->m_timeStamp =
src->sequence_number (239 = 239)
> >>>
> >>>
> >>> Please tell how to go about this issue.
> >>>
> >>> Thanks & Regards,
> >>> Lovish
> >>>
> >>
> > 
> 


_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev

Lovish,

This is inside the codec team's code, so I'll have
to defer to them on what the proper fix for this.
I've exchanged an email yesterday with Karl and 
am waiting to hear back from him.

Eric

=============================================
Eric Hyche (ehychereal.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: Lovish Dhawan [mailto:ldhawanreal.com]

> Sent: Tuesday, September 25, 2007 6:34 AM
> To: Lovish Dhawan; ehychereal.com
> Cc: helix-client-devhelixcommunity.org; 'Karl
Lillevold'; 
> ngokhalereal.com
> Subject: Re: [Helix-client-dev] Re: TimeStamp issue
with Real 
> Format SDK
> 
> Hi Eric,
>  
> I have found that in the file Decoder.c 
> (src/codecs/video/rv89combo/cdeclib) , there is a
function
> 
> Decoder_prepareDecodeBuffers()
>  
> Here there is some code as
>  
> pPreviousTail = t->m_referenceFrames.m_pTail;
>  
> if (!t->m_isLatencyEnabled || !pPreviousTail)
>     t->m_pDisplayFrame = t->m_pCurrentFrame;
>  
> For the first frame we have pPreviousTail as NULL so
when it 
> comes here it sets t->m_pDisplayFrame as
t->m_pCurrentFrame 
> and it is added in the list using
>  
> DecodedFrameList_append(&t->m_referenceFrames,
pFrame);
>  
> and for further frames we have frames in the list 
> t->m_referenceFrames and so pPreviousTail is *not*
NULL.
>  
> Therefore it does not set t->m_pDisplayFrame.
>  
> Now t->m_pDisplayFrame is checked in
>  
> if (ps != RV_S_OK || (flags & RV_DDF_DONT_DRAW)
> || (!t->m_pDisplayFrame &&
!wasFrameDisplayedBeforeDecode)
> )
> {
> *notes |= RV_DDN_DONT_DRAW;
> t->m_pDisplayFrame = 0;
> }
>  
> later in the same function and so this flag is set for
the frame.
>  
> I have tried setting 
> if (!t->m_isLatencyEnabled || !pPreviousTail)
>  t->m_pDisplayFrame = t->m_pCurrentFrame;
> else
>  t->m_pDisplayFrame = t->m_pCurrentFrame;
>  
> basically removing the if condition. We can remove this
if 
> altogether and can always set the value for 
>  
> t->m_pDisplayFrame.
>  
> After this change the value of sequence_numbers are
correctly 
> coming when we print it in 
> in the function _RV40toYUV420Transform()
>  
> using 
>  
> pRV20Out->timestamp = dst.sequence_number +
temporal_offset; 
> at the end of the function.
>  
> Please provide some pointers in this regards.
>  
> Thanks & Regards,
> Lovish
> 
> 	----- Original Message ----- 
> 	From: Lovish Dhawan <mailto:ldhawanreal.com>  
> 	To: ehychereal.com 
> 	Cc: helix-client-devhelixcommunity.org ; 'Karl

> Lillevold' <mailto:klillevoldreal.com>  
> 	Sent: Monday, September 24, 2007 5:34 PM
> 	Subject: [Helix-client-dev] Re: TimeStamp issue with 
> Real Format SDK
> 
> 	Hi Eric, 
> 	 
> 	I have got the test clip from the client. Sending you

> the FTP details in a separate mail.
> 	They have checked this issue with rm2yuv sample app
and 
> it is happening there as well. 
> 	
> 	pRV20Out->timestamp : 0 dst.sequence_number : 0 
> src.sequence_number : 0 temporal_offset : 0 
> 	pRV20Out->timestamp : 119 dst.sequence_number : 119

> src.sequence_number : 119 temporal_offset : 0 
> 	!rv_decode_frame_valid 
> 	pRV20Out->timestamp : 119 dst.sequence_number : 119

> src.sequence_number : 239 temporal_offset : 0 
> 	pRV20Out->timestamp : 239 dst.sequence_number : 239

> src.sequence_number : 359 temporal_offset : 0 
> 	pRV20Out->timestamp : 359 dst.sequence_number : 359

> src.sequence_number : 479 temporal_offset : 0 
> 	pRV20Out->timestamp : 479 dst.sequence_number : 479

> src.sequence_number : 599 temporal_offset : 0 
> 	pRV20Out->timestamp : 599 dst.sequence_number : 599

> src.sequence_number : 719 temporal_offset : 0 
> 	pRV20Out->timestamp : 719 dst.sequence_number : 719

> src.sequence_number : 839 temporal_offset : 0 
> 	
> 	Also it is with local playback only (no network 
> playback is done).
> 
> 	Thanks & Regards,
> 	Lovish
> 	 
> 	----- Original Message ----- 
> 	From: "Eric Hyche" <ehychereal.com
<mailto:ehychereal.com> >
> 	To: "'Lovish Dhawan'" <ldhawanreal.com

> <mailto:ldhawanreal.com> >
> 	Cc: <helix-client-devhelixcommunity.org 
> <mailto:helix-client-devhelixcommunity.org>
>; "'Karl 
> Lillevold'" <klillevoldreal.com
<mailto:klillevoldreal.com> 
> >; <ngokhalereal.com <mailto:ngokhalereal.com> >
> 	Sent: Tuesday, September 18, 2007 7:24 PM
> 	Subject: RE: TimeStamp issue with Real Format SDK
> 	
> 	
> 	> 
> 	>> -----Original Message-----
> 	>> From: Lovish Dhawan [mailto:ldhawanreal.com]

> 	>> Sent: Tuesday, September 18, 2007 7:24 AM
> 	>> To: ehychereal.com
<mailto:ehychereal.com> 
> 	>> Cc: helix-client-devhelixcommunity.org 
> <mailto:helix-client-devhelixcommunity.org> ;
Karl Lillevold; 
> 	>> ngokhalereal.com <mailto:ngokhalereal.com> 
> 	>> Subject: Fw: TimeStamp issue with Real Format
SDK
> 	>> 
> 	>> Hi,
> 	>> Seems this missed your attention
> 	>> Sending again.
> 	>> 
> 	>> Thanks & Regards,
> 	>> Lovish
> 	>> ----- Original Message ----- 
> 	>> From: "Lovish Dhawan"
<ldhawanreal.com 
> <mailto:ldhawanreal.com> >
> 	>> To: <ehychereal.com
<mailto:ehychereal.com> >
> 	>> Cc: <helix-client-devhelixcommunity.org 
> <mailto:helix-client-devhelixcommunity.org>
>; "Karl Lillevold" 
> 	>> <klillevoldreal.com
<mailto:klillevoldreal.com> >; 
> "Neelesh Gokhale" <ngokhalereal.com
<mailto:ngokhalereal.com> >
> 	>> Sent: Friday, September 14, 2007 7:58 PM
> 	>> Subject: Re: TimeStamp issue with Real Format
SDK
> 	>> 
> 	>> 
> 	>> > Hi Eric,
> 	>> >
> 	>> > I am not very sure as to why the decoder
is failing for 
> 	>> second frame.
> 	>> >
> 	>> > Even if the second frame failed to get
decoded, shouldn't 
> 	>> > the third frame and consequent frames
would have come
> 	>> > and played at their time and not at the
time of 
> the previous frame.
> 	>> >
> 	>> > In case 2nd frame decode is failing, do
we need to render 
> 	>> > the 3rd sample at 119ms or 239ms? If we
need to 
> render it at 239ms, then 
> 	>> > decoder should take care of updating the
timestamp 
> value in case of the failure?
> 	>> >
> 	> 
> 	> Yes, the 3rd sample should still have a decoded
timestamp
> 	> of 239ms. I don't know without looking at the
code whether:
> 	> 
> 	> a) decoder properly tells the RealFormat SDK code

> that decoding
> 	>   of the 2nd sample failed, and the RealFormat
SDK is not
> 	>   properly flushing that frame; or
> 	> b) decoder is not telling RealFormat SDK code
that decoding
> 	>   of the 2nd sample failed.
> 	> 
> 	> I'll try and take a look in the RealFormat SDK
code to
> 	> see which it is.
> 	> 
> 	> Can you get a copy of the clip for which this
occurs?
> 	> Does this repro using the rm2yuv sample app?
> 	> 
> 	> In practice, decoding failure should be extremely
rare,
> 	> and should probably only happen on: a) corrupted
files; or
> 	> b) network playback if there's a bug in their 
> loss-handling code.
> 	> 
> 	> Eric
> 	> 
> 	>> > For a 10 FPS clip, timestamps are as
below from 
> the real parser.
> 	>> > 0, 119, 239, 359, 479, 599, 719, 839,
959, 1079, 1199, 1319
> 	>> >
> 	>> > Timestamps from the decoder are as
below.
> 	>> > 0, FAILURE, 119, 239, 359, 479, 599,
719, 839, 
> 959, 1079, 1199
> 	>> >
> 	>> >
> 	>> > It seems that dst.sequence_number is
updated 
> properly, but the time 
> 	>> > rv_decode_frame_valid() method fails,
decoder is not 
> 	>> flushing the frame 
> 	>> > and in the next call to
rv_decode_stream_decode method, it 
> 	>> is giving the 
> 	>> > prev frame and thus, from there onwards,

> 	>> src.sequence_number is greater 
> 	>> > than of dst.sequence_number.
> 	>> >
> 	>> >
> 	>> > Thanks & Regards,
> 	>> > Lovish
> 	>> >
> 	>> > ----- Original Message ----- 
> 	>> > From: "Eric Hyche"
<ehychereal.com 
> <mailto:ehychereal.com> >
> 	>> > To: "'Lovish Dhawan'"
<ldhawanreal.com 
> <mailto:ldhawanreal.com> >
> 	>> > Cc: <helix-client-devhelixcommunity.org 
> <mailto:helix-client-devhelixcommunity.org>
>; "Karl Lillevold" 
> 	>> > <klillevoldreal.com
<mailto:klillevoldreal.com> 
> >; "Neelesh Gokhale" <ngokhalereal.com
<mailto:ngokhalereal.com> >
> 	>> > Sent: Friday, September 14, 2007 7:43
PM
> 	>> > Subject: RE: TimeStamp issue with Real
Format SDK
> 	>> >
> 	>> >
> 	>> >>
> 	>> >> Lovish,
> 	>> >>
> 	>> >> Why is the decoding failing? Is this
a corrupted file?
> 	>> >> As far as the problem of the
timestamps getting out of
> 	>> >> sync, this may be a codec issue, so
I'm copying
> 	>> >> Karl and Neelesh on this.
> 	>> >>
> 	>> >> Eric
> 	>> >>
> 	>> >>
=============================================
> 	>> >> Eric Hyche (ehychereal.com
<mailto:ehychereal.com> )
> 	>> >> Technical Lead
> 	>> >> RealNetworks, Inc.
> 	>> >>
> 	>> >>> -----Original Message-----
> 	>> >>> From: Lovish Dhawan
[mailto:ldhawanreal.com]
> 	>> >>> Sent: Friday, September 14, 2007
10:04 AM
> 	>> >>> To: ehychereal.com
<mailto:ehychereal.com> 
> 	>> >>> Cc: helix-client-devhelixcommunity.org 
> <mailto:helix-client-devhelixcommunity.org> 
> 	>> >>> Subject: TimeStamp issue with
Real Format SDK
> 	>> >>>
> 	>> >>> Hi Eric,
> 	>> >>>
> 	>> >>> There is an issue with one of
our client which 
> is as follows:
> 	>> >>>
> 	>> >>> If a frame is not decoded
correctly and at the check of
> 	>> >>> rv_decode_frame_valid() method
returns failure code. then
> 	>> >>> subsequent all the frames
> 	>> >>> display the video which should
be of their 
> previous timestamp.
> 	>> >>>
> 	>> >>> Timestamps from the decoder are
as below.
> 	>> >>> 0, FAILURE, 119, 239, 359, 479,
599, 719, 839, 
> 959, 1079, 1199
> 	>> >>>
> 	>> >>> and not
> 	>> >>>
> 	>> >>> For a 10 FPS clip, timestamps
are as below from 
> the real parser.
> 	>> >>> 0, 119, 239, 359, 479, 599, 719,
839, 959, 1079, 
> 1199, 1319
> 	>> >>>
> 	>> >>> In the case above, decoder fails
for 2nd frame, 
> but the 3rd
> 	>> >>> frame timestamp value
corresponds to the 2nd 
> frame timestamp.
> 	>> >>> In case decoder is failing for
10 frames (for any reason)
> 	>> >>> after first frame decoding,
> 	>> >>> then the 12th frame (decoded
successfully) 
> timestamp value
> 	>> >>> from the decoder will be 1199,
> 	>> >>>  but it should be 1319 to play
the file with 
> proper A/V sync
> 	>> >>>
> 	>> >>> After taking logs (displayed
under) we found that the
> 	>> >>> src.sequence_number remains
ahead of dst.sequence_number
> 	>> >>>
> 	>> >>> Some logs that were taken from
the function 
> 	>> _RV40toYUV420Transform()
> 	>> >>>
> 	>> >>>     /* Assign the presentation
time for the 
> display frame */
> 	>> >>>     pRV20Out->timestamp =
dst.sequence_number + 
> temporal_offset;
> 	>> >>>  gives output as
> 	>> >>>
> 	>> >>> pRV20Out->timestamp : 0
dst.sequence_number : 0
> 	>> >>> src.sequence_number : 0
temporal_offset : 0
> 	>> >>> pRV20Out->timestamp : 119
dst.sequence_number : 119
> 	>> >>> src.sequence_number : 119
temporal_offset : 0
> 	>> >>> rv_decode_frame_valid Failed
> 	>> >>> pRV20Out->timestamp : 119
dst.sequence_number : 119
> 	>> >>> src.sequence_number : 239
temporal_offset : 0
> 	>> >>> pRV20Out->timestamp : 239
dst.sequence_number : 239
> 	>> >>> src.sequence_number : 359
temporal_offset : 0
> 	>> >>> pRV20Out->timestamp : 359
dst.sequence_number : 359
> 	>> >>> src.sequence_number : 479
temporal_offset : 0
> 	>> >>> pRV20Out->timestamp : 479
dst.sequence_number : 479
> 	>> >>> src.sequence_number : 599
temporal_offset : 0
> 	>> >>> ...
> 	>> >>> ...
> 	>> >>>
> 	>> >>> Now one more thing that is found
is
> 	>> >>>
> 	>> >>> it seems that
dst.sequence_number is updated 
> properly, but
> 	>> >>> the time rv_decode_frame_valid
method fails, 
> decoder is not
> 	>> >>> flushing the frame and in the
next call to
> 	>> >>> rv_decode_stream_decode method,
it is giving the 
> prev frame
> 	>> >>> and thus, from there onwards, 
> src.sequence_number is greater
> 	>> >>> than of dst.sequence_number.
> 	>> >>>
> 	>> >>> API:
Decoder_prepareDecodeBuffers
> 	>> >>>
(t->m_pCurrentFrame->m_pPreviousFrame == NULL)
> 	>> >>>
t->m_pCurrentFrame->m_timeStamp = 
> src->sequence_number (0 = 0)
> 	>> >>> API:
Decoder_prepareDecodeBuffers dst->sequence_number =
> 	>> >>> pDisplayFrame->m_timeStamp (0
= 0)
> 	>> >>> pRV20Out->timestamp : 0
dst.sequence_number : 0
> 	>> >>> src.sequence_number : 0
temporal_offset : 0
> 	>> >>> API:
Decoder_prepareDecodeBuffers
> 	>> >>>
t->m_pCurrentFrame->m_timeStamp = 
> src->sequence_number (119 = 119)
> 	>> >>> pRV20Out->timestamp : 119
dst.sequence_number : 119
> 	>> >>> src.sequence_number : 119
temporal_offset : 0
> 	>> >>> rv_decode_frame_valid Failed
> 	>> >>> API:
Decoder_prepareDecodeBuffers t->m_pDisplayFrame = 
> 	>> pPreviousTail
> 	>> >>> API:
Decoder_prepareDecodeBuffers dst->sequence_number =
> 	>> >>> pDisplayFrame->m_timeStamp
(119 = 119)
> 	>> >>> API:
Decoder_prepareDecodeBuffers
> 	>> >>>
t->m_pCurrentFrame->m_timeStamp = 
> src->sequence_number (239 = 239)
> 	>> >>>
> 	>> >>>
> 	>> >>> Please tell how to go about this
issue.
> 	>> >>>
> 	>> >>> Thanks & Regards,
> 	>> >>> Lovish
> 	>> >>>
> 	>> >>
> 	>> > 
> 	>> 
> 	> 
> 
> 	
> ________________________________
> 
> 
> 	
> 
> 	_______________________________________________
> 	Helix-client-dev mailing list
> 	Helix-client-devhelixcommunity.org
> 	
> http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev
> 	
> 
> 


_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev

Hi Eric,

Please if you could tell if you got any information on
this.

Thanks & Regards,
Lovish

----- Original Message ----- 
From: "Eric Hyche" <ehychereal.com>
To: "'Lovish Dhawan'" <ldhawanreal.com>
Cc: <helix-client-devhelixcommunity.org>;
"'Karl Lillevold'" 
<klillevoldreal.com>; <ngokhalereal.com>
Sent: Tuesday, September 25, 2007 9:55 PM
Subject: RE: [Helix-client-dev] Re: TimeStamp issue with
Real Format SDK


>
> Lovish,
>
> This is inside the codec team's code, so I'll have
> to defer to them on what the proper fix for this.
> I've exchanged an email yesterday with Karl and
> am waiting to hear back from him.
>
> Eric
>
> =============================================
> Eric Hyche (ehychereal.com)
> Technical Lead
> RealNetworks, Inc.
>
>> -----Original Message-----
>> From: Lovish Dhawan [mailto:ldhawanreal.com]
>> Sent: Tuesday, September 25, 2007 6:34 AM
>> To: Lovish Dhawan; ehychereal.com
>> Cc: helix-client-devhelixcommunity.org; 'Karl
Lillevold';
>> ngokhalereal.com
>> Subject: Re: [Helix-client-dev] Re: TimeStamp issue
with Real
>> Format SDK
>>
>> Hi Eric,
>>
>> I have found that in the file Decoder.c
>> (src/codecs/video/rv89combo/cdeclib) , there is a
function
>>
>> Decoder_prepareDecodeBuffers()
>>
>> Here there is some code as
>>
>> pPreviousTail = t->m_referenceFrames.m_pTail;
>>
>> if (!t->m_isLatencyEnabled || !pPreviousTail)
>>     t->m_pDisplayFrame = t->m_pCurrentFrame;
>>
>> For the first frame we have pPreviousTail as NULL
so when it
>> comes here it sets t->m_pDisplayFrame as
t->m_pCurrentFrame
>> and it is added in the list using
>>
>>
DecodedFrameList_append(&t->m_referenceFrames,
pFrame);
>>
>> and for further frames we have frames in the list
>> t->m_referenceFrames and so pPreviousTail is
*not* NULL.
>>
>> Therefore it does not set t->m_pDisplayFrame.
>>
>> Now t->m_pDisplayFrame is checked in
>>
>> if (ps != RV_S_OK || (flags &
RV_DDF_DONT_DRAW)
>> || (!t->m_pDisplayFrame &&
!wasFrameDisplayedBeforeDecode)
>> )
>> {
>> *notes |= RV_DDN_DONT_DRAW;
>> t->m_pDisplayFrame = 0;
>> }
>>
>> later in the same function and so this flag is set
for the frame.
>>
>> I have tried setting
>> if (!t->m_isLatencyEnabled || !pPreviousTail)
>>  t->m_pDisplayFrame = t->m_pCurrentFrame;
>> else
>>  t->m_pDisplayFrame = t->m_pCurrentFrame;
>>
>> basically removing the if condition. We can remove
this if
>> altogether and can always set the value for
>>
>> t->m_pDisplayFrame.
>>
>> After this change the value of sequence_numbers are
correctly
>> coming when we print it in
>> in the function _RV40toYUV420Transform()
>>
>> using
>>
>> pRV20Out->timestamp = dst.sequence_number +
temporal_offset;
>> at the end of the function.
>>
>> Please provide some pointers in this regards.
>>
>> Thanks & Regards,
>> Lovish
>>
>> ----- Original Message ----- 
>> From: Lovish Dhawan <mailto:ldhawanreal.com>
>> To: ehychereal.com
>> Cc: helix-client-devhelixcommunity.org ; 'Karl
>> Lillevold' <mailto:klillevoldreal.com>
>> Sent: Monday, September 24, 2007 5:34 PM
>> Subject: [Helix-client-dev] Re: TimeStamp issue
with
>> Real Format SDK
>>
>> Hi Eric,
>>
>> I have got the test clip from the client. Sending
you
>> the FTP details in a separate mail.
>> They have checked this issue with rm2yuv sample app
and
>> it is happening there as well.
>>
>> pRV20Out->timestamp : 0 dst.sequence_number : 0
>> src.sequence_number : 0 temporal_offset : 0
>> pRV20Out->timestamp : 119 dst.sequence_number :
119
>> src.sequence_number : 119 temporal_offset : 0
>> !rv_decode_frame_valid
>> pRV20Out->timestamp : 119 dst.sequence_number :
119
>> src.sequence_number : 239 temporal_offset : 0
>> pRV20Out->timestamp : 239 dst.sequence_number :
239
>> src.sequence_number : 359 temporal_offset : 0
>> pRV20Out->timestamp : 359 dst.sequence_number :
359
>> src.sequence_number : 479 temporal_offset : 0
>> pRV20Out->timestamp : 479 dst.sequence_number :
479
>> src.sequence_number : 599 temporal_offset : 0
>> pRV20Out->timestamp : 599 dst.sequence_number :
599
>> src.sequence_number : 719 temporal_offset : 0
>> pRV20Out->timestamp : 719 dst.sequence_number :
719
>> src.sequence_number : 839 temporal_offset : 0
>>
>> Also it is with local playback only (no network
>> playback is done).
>>
>> Thanks & Regards,
>> Lovish
>>
>> ----- Original Message ----- 
>> From: "Eric Hyche" <ehychereal.com
<mailto:ehychereal.com> >
>> To: "'Lovish Dhawan'" <ldhawanreal.com
>> <mailto:ldhawanreal.com> >
>> Cc: <helix-client-devhelixcommunity.org
>> <mailto:helix-client-devhelixcommunity.org>
>; "'Karl
>> Lillevold'" <klillevoldreal.com
<mailto:klillevoldreal.com>
>> >; <ngokhalereal.com
<mailto:ngokhalereal.com> >
>> Sent: Tuesday, September 18, 2007 7:24 PM
>> Subject: RE: TimeStamp issue with Real Format SDK
>>
>>
>> >
>> >> -----Original Message-----
>> >> From: Lovish Dhawan [mailto:ldhawanreal.com]
>> >> Sent: Tuesday, September 18, 2007 7:24 AM
>> >> To: ehychereal.com
<mailto:ehychereal.com>
>> >> Cc: helix-client-devhelixcommunity.org
>> <mailto:helix-client-devhelixcommunity.org> ;
Karl Lillevold;
>> >> ngokhalereal.com
<mailto:ngokhalereal.com>
>> >> Subject: Fw: TimeStamp issue with Real
Format SDK
>> >>
>> >> Hi,
>> >> Seems this missed your attention
>> >> Sending again.
>> >>
>> >> Thanks & Regards,
>> >> Lovish
>> >> ----- Original Message ----- 
>> >> From: "Lovish Dhawan"
<ldhawanreal.com
>> <mailto:ldhawanreal.com> >
>> >> To: <ehychereal.com
<mailto:ehychereal.com> >
>> >> Cc: <helix-client-devhelixcommunity.org
>> <mailto:helix-client-devhelixcommunity.org>
>; "Karl Lillevold"
>> >> <klillevoldreal.com
<mailto:klillevoldreal.com> >;
>> "Neelesh Gokhale" <ngokhalereal.com
<mailto:ngokhalereal.com> >
>> >> Sent: Friday, September 14, 2007 7:58 PM
>> >> Subject: Re: TimeStamp issue with Real
Format SDK
>> >>
>> >>
>> >> > Hi Eric,
>> >> >
>> >> > I am not very sure as to why the
decoder is failing for
>> >> second frame.
>> >> >
>> >> > Even if the second frame failed to
get decoded, shouldn't
>> >> > the third frame and consequent frames
would have come
>> >> > and played at their time and not at
the time of
>> the previous frame.
>> >> >
>> >> > In case 2nd frame decode is failing,
do we need to render
>> >> > the 3rd sample at 119ms or 239ms? If
we need to
>> render it at 239ms, then
>> >> > decoder should take care of updating
the timestamp
>> value in case of the failure?
>> >> >
>> >
>> > Yes, the 3rd sample should still have a
decoded timestamp
>> > of 239ms. I don't know without looking at the
code whether:
>> >
>> > a) decoder properly tells the RealFormat SDK
code
>> that decoding
>> >   of the 2nd sample failed, and the RealFormat
SDK is not
>> >   properly flushing that frame; or
>> > b) decoder is not telling RealFormat SDK code
that decoding
>> >   of the 2nd sample failed.
>> >
>> > I'll try and take a look in the RealFormat SDK
code to
>> > see which it is.
>> >
>> > Can you get a copy of the clip for which this
occurs?
>> > Does this repro using the rm2yuv sample app?
>> >
>> > In practice, decoding failure should be
extremely rare,
>> > and should probably only happen on: a)
corrupted files; or
>> > b) network playback if there's a bug in their
>> loss-handling code.
>> >
>> > Eric
>> >
>> >> > For a 10 FPS clip, timestamps are as
below from
>> the real parser.
>> >> > 0, 119, 239, 359, 479, 599, 719, 839,
959, 1079, 1199, 1319
>> >> >
>> >> > Timestamps from the decoder are as
below.
>> >> > 0, FAILURE, 119, 239, 359, 479, 599,
719, 839,
>> 959, 1079, 1199
>> >> >
>> >> >
>> >> > It seems that dst.sequence_number is
updated
>> properly, but the time
>> >> > rv_decode_frame_valid() method fails,
decoder is not
>> >> flushing the frame
>> >> > and in the next call to
rv_decode_stream_decode method, it
>> >> is giving the
>> >> > prev frame and thus, from there
onwards,
>> >> src.sequence_number is greater
>> >> > than of dst.sequence_number.
>> >> >
>> >> >
>> >> > Thanks & Regards,
>> >> > Lovish
>> >> >
>> >> > ----- Original Message ----- 
>> >> > From: "Eric Hyche"
<ehychereal.com
>> <mailto:ehychereal.com> >
>> >> > To: "'Lovish Dhawan'"
<ldhawanreal.com
>> <mailto:ldhawanreal.com> >
>> >> > Cc: <helix-client-devhelixcommunity.org
>> <mailto:helix-client-devhelixcommunity.org>
>; "Karl Lillevold"
>> >> > <klillevoldreal.com
<mailto:klillevoldreal.com>
>> >; "Neelesh Gokhale" <ngokhalereal.com
<mailto:ngokhalereal.com> >
>> >> > Sent: Friday, September 14, 2007 7:43
PM
>> >> > Subject: RE: TimeStamp issue with
Real Format SDK
>> >> >
>> >> >
>> >> >>
>> >> >> Lovish,
>> >> >>
>> >> >> Why is the decoding failing? Is
this a corrupted file?
>> >> >> As far as the problem of the
timestamps getting out of
>> >> >> sync, this may be a codec issue,
so I'm copying
>> >> >> Karl and Neelesh on this.
>> >> >>
>> >> >> Eric
>> >> >>
>> >> >>
=============================================
>> >> >> Eric Hyche (ehychereal.com
<mailto:ehychereal.com> )
>> >> >> Technical Lead
>> >> >> RealNetworks, Inc.
>> >> >>
>> >> >>> -----Original Message-----
>> >> >>> From: Lovish Dhawan
[mailto:ldhawanreal.com]
>> >> >>> Sent: Friday, September 14,
2007 10:04 AM
>> >> >>> To: ehychereal.com
<mailto:ehychereal.com>
>> >> >>> Cc: helix-client-devhelixcommunity.org
>> <mailto:helix-client-devhelixcommunity.org>
>> >> >>> Subject: TimeStamp issue with
Real Format SDK
>> >> >>>
>> >> >>> Hi Eric,
>> >> >>>
>> >> >>> There is an issue with one of
our client which
>> is as follows:
>> >> >>>
>> >> >>> If a frame is not decoded
correctly and at the check of
>> >> >>> rv_decode_frame_valid()
method returns failure code. then
>> >> >>> subsequent all the frames
>> >> >>> display the video which
should be of their
>> previous timestamp.
>> >> >>>
>> >> >>> Timestamps from the decoder
are as below.
>> >> >>> 0, FAILURE, 119, 239, 359,
479, 599, 719, 839,
>> 959, 1079, 1199
>> >> >>>
>> >> >>> and not
>> >> >>>
>> >> >>> For a 10 FPS clip, timestamps
are as below from
>> the real parser.
>> >> >>> 0, 119, 239, 359, 479, 599,
719, 839, 959, 1079,
>> 1199, 1319
>> >> >>>
>> >> >>> In the case above, decoder
fails for 2nd frame,
>> but the 3rd
>> >> >>> frame timestamp value
corresponds to the 2nd
>> frame timestamp.
>> >> >>> In case decoder is failing
for 10 frames (for any reason)
>> >> >>> after first frame decoding,
>> >> >>> then the 12th frame (decoded
successfully)
>> timestamp value
>> >> >>> from the decoder will be
1199,
>> >> >>>  but it should be 1319 to
play the file with
>> proper A/V sync
>> >> >>>
>> >> >>> After taking logs (displayed
under) we found that the
>> >> >>> src.sequence_number remains
ahead of dst.sequence_number
>> >> >>>
>> >> >>> Some logs that were taken
from the function
>> >> _RV40toYUV420Transform()
>> >> >>>
>> >> >>>     /* Assign the
presentation time for the
>> display frame */
>> >> >>>     pRV20Out->timestamp =
dst.sequence_number +
>> temporal_offset;
>> >> >>>  gives output as
>> >> >>>
>> >> >>> pRV20Out->timestamp : 0
dst.sequence_number : 0
>> >> >>> src.sequence_number : 0
temporal_offset : 0
>> >> >>> pRV20Out->timestamp : 119
dst.sequence_number : 119
>> >> >>> src.sequence_number : 119
temporal_offset : 0
>> >> >>> rv_decode_frame_valid Failed
>> >> >>> pRV20Out->timestamp : 119
dst.sequence_number : 119
>> >> >>> src.sequence_number : 239
temporal_offset : 0
>> >> >>> pRV20Out->timestamp : 239
dst.sequence_number : 239
>> >> >>> src.sequence_number : 359
temporal_offset : 0
>> >> >>> pRV20Out->timestamp : 359
dst.sequence_number : 359
>> >> >>> src.sequence_number : 479
temporal_offset : 0
>> >> >>> pRV20Out->timestamp : 479
dst.sequence_number : 479
>> >> >>> src.sequence_number : 599
temporal_offset : 0
>> >> >>> ...
>> >> >>> ...
>> >> >>>
>> >> >>> Now one more thing that is
found is
>> >> >>>
>> >> >>> it seems that
dst.sequence_number is updated
>> properly, but
>> >> >>> the time
rv_decode_frame_valid method fails,
>> decoder is not
>> >> >>> flushing the frame and in the
next call to
>> >> >>> rv_decode_stream_decode
method, it is giving the
>> prev frame
>> >> >>> and thus, from there
onwards,
>> src.sequence_number is greater
>> >> >>> than of dst.sequence_number.
>> >> >>>
>> >> >>> API:
Decoder_prepareDecodeBuffers
>> >> >>>
(t->m_pCurrentFrame->m_pPreviousFrame == NULL)
>> >> >>>
t->m_pCurrentFrame->m_timeStamp =
>> src->sequence_number (0 = 0)
>> >> >>> API:
Decoder_prepareDecodeBuffers dst->sequence_number =
>> >> >>> pDisplayFrame->m_timeStamp
(0 = 0)
>> >> >>> pRV20Out->timestamp : 0
dst.sequence_number : 0
>> >> >>> src.sequence_number : 0
temporal_offset : 0
>> >> >>> API:
Decoder_prepareDecodeBuffers
>> >> >>>
t->m_pCurrentFrame->m_timeStamp =
>> src->sequence_number (119 = 119)
>> >> >>> pRV20Out->timestamp : 119
dst.sequence_number : 119
>> >> >>> src.sequence_number : 119
temporal_offset : 0
>> >> >>> rv_decode_frame_valid Failed
>> >> >>> API:
Decoder_prepareDecodeBuffers t->m_pDisplayFrame =
>> >> pPreviousTail
>> >> >>> API:
Decoder_prepareDecodeBuffers dst->sequence_number =
>> >> >>> pDisplayFrame->m_timeStamp
(119 = 119)
>> >> >>> API:
Decoder_prepareDecodeBuffers
>> >> >>>
t->m_pCurrentFrame->m_timeStamp =
>> src->sequence_number (239 = 239)
>> >> >>>
>> >> >>>
>> >> >>> Please tell how to go about
this issue.
>> >> >>>
>> >> >>> Thanks & Regards,
>> >> >>> Lovish
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >
>>
>>
>> ________________________________
>>
>>
>>
>>
>> _______________________________________________
>> Helix-client-dev mailing list
>> Helix-client-devhelixcommunity.org
>>
>> http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev
>>
>>
>>
> 


_______________________________________________
Helix-client-dev mailing list
Helix-client-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev

I'll forward the reply I got from Karl, but I plan
on moving this thread to realformat-sdk-dev since
it's either internal to the RealFormat SDK or internal
to the codec.

Eric

=============================================
Eric Hyche (ehychereal.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: Lovish Dhawan [mailto:ldhawanreal.com]

> Sent: Thursday, September 27, 2007 8:50 PM
> To: ehychereal.com
> Cc: helix-client-devhelixcommunity.org; 'Karl
Lillevold'; 
> ngokhalereal.com
> Subject: Re: [Helix-client-dev] Re: TimeStamp issue
with Real 
> Format SDK
> 
> Hi Eric,
> 
> Please if you could tell if you got any information on
this.
> 
> Thanks & Regards,
> Lovish
> 
> ----- Original Message ----- 
> From: "Eric Hyche" <ehychereal.com>
> To: "'Lovish Dhawan'" <ldhawanreal.com>
> Cc: <helix-client-devhelixcommunity.org>;
"'Karl Lillevold'" 
> <klillevoldreal.com>; <ngokhalereal.com>
> Sent: Tuesday, September 25, 2007 9:55 PM
> Subject: RE: [Helix-client-dev] Re: TimeStamp issue
with Real 
> Format SDK
> 
> 
> >
> > Lovish,
> >
> > This is inside the codec team's code, so I'll
have
> > to defer to them on what the proper fix for this.
> > I've exchanged an email yesterday with Karl and
> > am waiting to hear back from him.
> >
> > Eric
> >
> > =============================================
> > Eric Hyche (ehychereal.com)
> > Technical Lead
> > RealNetworks, Inc.
> >
> >> -----Original Message-----
> >> From: Lovish Dhawan [mailto:ldhawanreal.com]
> >> Sent: Tuesday, September 25, 2007 6:34 AM
> >> To: Lovish Dhawan; ehychereal.com
> >> Cc: helix-client-devhelixcommunity.org; 'Karl
Lillevold';
> >> ngokhalereal.com
> >> Subject: Re: [Helix-client-dev] Re: TimeStamp
issue with Real
> >> Format SDK
> >>
> >> Hi Eric,
> >>
> >> I have found that in the file Decoder.c
> >> (src/codecs/video/rv89combo/cdeclib) , there
is a function
> >>
> >> Decoder_prepareDecodeBuffers()
> >>
> >> Here there is some code as
> >>
> >> pPreviousTail =
t->m_referenceFrames.m_pTail;
> >>
> >> if (!t->m_isLatencyEnabled ||
!pPreviousTail)
> >>     t->m_pDisplayFrame =
t->m_pCurrentFrame;
> >>
> >> For the first frame we have pPreviousTail as
NULL so when it
> >> comes here it sets t->m_pDisplayFrame as
t->m_pCurrentFrame
> >> and it is added in the list using
> >>
> >>
DecodedFrameList_append(&t->m_referenceFrames,
pFrame);
> >>
> >> and for further frames we have frames in the
list
> >> t->m_referenceFrames and so pPreviousTail
is *not* NULL.
> >>
> >> Therefore it does not set
t->m_pDisplayFrame.
> >>
> >> Now t->m_pDisplayFrame is checked in
> >>
> >> if (ps != RV_S_OK || (flags &
RV_DDF_DONT_DRAW)
> >> || (!t->m_pDisplayFrame &&
!wasFrameDisplayedBeforeDecode)
> >> )
> >> {
> >> *notes |= RV_DDN_DONT_DRAW;
> >> t->m_pDisplayFrame = 0;
> >> }
> >>
> >> later in the same function and so this flag is
set for the frame.
> >>
> >> I have tried setting
> >> if (!t->m_isLatencyEnabled ||
!pPreviousTail)
> >>  t->m_pDisplayFrame =
t->m_pCurrentFrame;
> >> else
> >>  t->m_pDisplayFrame =
t->m_pCurrentFrame;
> >>
> >> basically removing the if condition. We can
remove this if
> >> altogether and can always set the value for
> >>
> >> t->m_pDisplayFrame.
> >>
> >> After this change the value of
sequence_numbers are correctly
> >> coming when we print it in
> >> in the function _RV40toYUV420Transform()
> >>
> >> using
> >>
> >> pRV20Out->timestamp = dst.sequence_number +
temporal_offset;
> >> at the end of the function.
> >>
> >> Please provide some pointers in this regards.
> >>
> >> Thanks & Regards,
> >> Lovish
> >>
> >> ----- Original Message ----- 
> >> From: Lovish Dhawan <mailto:ldhawanreal.com>
> >> To: ehychereal.com
> >> Cc: helix-client-devhelixcommunity.org ; 'Karl
> >> Lillevold' <mailto:klillevoldreal.com>
> >> Sent: Monday, September 24, 2007 5:34 PM
> >> Subject: [Helix-client-dev] Re: TimeStamp
issue with
> >> Real Format SDK
> >>
> >> Hi Eric,
> >>
> >> I have got the test clip from the client.
Sending you
> >> the FTP details in a separate mail.
> >> They have checked this issue with rm2yuv
sample app and
> >> it is happening there as well.
> >>
> >> pRV20Out->timestamp : 0 dst.sequence_number
: 0
> >> src.sequence_number : 0 temporal_offset : 0
> >> pRV20Out->timestamp : 119
dst.sequence_number : 119
> >> src.sequence_number : 119 temporal_offset : 0
> >> !rv_decode_frame_valid
> >> pRV20Out->timestamp : 119
dst.sequence_number : 119
> >> src.sequence_number : 239 temporal_offset : 0
> >> pRV20Out->timestamp : 239
dst.sequence_number : 239
> >> src.sequence_number : 359 temporal_offset : 0
> >> pRV20Out->timestamp : 359
dst.sequence_number : 359
> >> src.sequence_number : 479 temporal_offset : 0
> >> pRV20Out->timestamp : 479
dst.sequence_number : 479
> >> src.sequence_number : 599 temporal_offset : 0
> >> pRV20Out->timestamp : 599
dst.sequence_number : 599
> >> src.sequence_number : 719 temporal_offset : 0
> >> pRV20Out->timestamp : 719
dst.sequence_number : 719
> >> src.sequence_number : 839 temporal_offset : 0
> >>
> >> Also it is with local playback only (no
network
> >> playback is done).
> >>
> >> Thanks & Regards,
> >> Lovish
> >>
> >> ----- Original Message ----- 
> >> From: "Eric Hyche" <ehychereal.com
<mailto:ehychereal.com> >
> >> To: "'Lovish Dhawan'"
<ldhawanreal.com
> >> <mailto:ldhawanreal.com> >
> >> Cc: <helix-client-devhelixcommunity.org
> >> <mailto:helix-client-devhelixcommunity.org> >; "'Karl
> >> Lillevold'" <klillevoldreal.com
<mailto:klillevoldreal.com>
> >> >; <ngokhalereal.com
<mailto:ngokhalereal.com> >
> >> Sent: Tuesday, September 18, 2007 7:24 PM
> >> Subject: RE: TimeStamp issue with Real Format
SDK
> >>
> >>
> >> >
> >> >> -----Original Message-----
> >> >> From: Lovish Dhawan
[mailto:ldhawanreal.com]
> >> >> Sent: Tuesday, September 18, 2007
7:24 AM
> >> >> To: ehychereal.com
<mailto:ehychereal.com>
> >> >> Cc: helix-client-devhelixcommunity.org
> >> <mailto:helix-client-devhelixcommunity.org> ; Karl Lillevold;
> >> >> ngokhalereal.com
<mailto:ngokhalereal.com>
> >> >> Subject: Fw: TimeStamp issue with
Real Format SDK
> >> >>
> >> >> Hi,
> >> >> Seems this missed your attention
> >> >> Sending again.
> >> >>
> >> >> Thanks & Regards,
> >> >> Lovish
> >> >> ----- Original Message ----- 
> >> >> From: "Lovish Dhawan"
<ldhawanreal.com
> >> <mailto:ldhawanreal.com> >
> >> >> To: <ehychereal.com
<mailto:ehychereal.com> >
> >> >> Cc: <helix-client-devhelixcommunity.org
> >> <mailto:helix-client-devhelixcommunity.org> >; "Karl
Lillevold"
> >> >> <klillevoldreal.com
<mailto:klillevoldreal.com> >;
> >> "Neelesh Gokhale" <ngokhalereal.com
<mailto:ngokhalereal.com> >
> >> >> Sent: Friday, September 14, 2007 7:58
PM
> >> >> Subject: Re: TimeStamp issue with
Real Format SDK
> >> >>
> >> >>
> >> >> > Hi Eric,
> >> >> >
> >> >> > I am not very sure as to why the
decoder is failing for
> >> >> second frame.
> >> >> >
> >> >> > Even if the second frame failed
to get decoded, shouldn't
> >> >> > the third frame and consequent
frames would have come
> >> >> > and played at their time and not
at the time of
> >> the previous frame.
> >> >> >
> >> >> > In case 2nd frame decode is
failing, do we need to render
> >> >> > the 3rd sample at 119ms or
239ms? If we need to
> >> render it at 239ms, then
> >> >> > decoder should take care of
updating the timestamp
> >> value in case of the failure?
> >> >> >
> >> >
> >> > Yes, the 3rd sample should still have a
decoded timestamp
> >> > of 239ms. I don't know without looking at
the code whether:
> >> >
> >> > a) decoder properly tells the RealFormat
SDK code
> >> that decoding
> >> >   of the 2nd sample failed, and the
RealFormat SDK is not
> >> >   properly flushing that frame; or
> >> > b) decoder is not telling RealFormat SDK
code that decoding
> >> >   of the 2nd sample failed.
> >> >
> >> > I'll try and take a look in the
RealFormat SDK code to
> >> > see which it is.
> >> >
> >> > Can you get a copy of the clip for which
this occurs?
> >> > Does this repro using the rm2yuv sample
app?
> >> >
> >> > In practice, decoding failure should be
extremely rare,
> >> > and should probably only happen on: a)
corrupted files; or
> >> > b) network playback if there's a bug in
their
> >> loss-handling code.
> >> >
> >> > Eric
> >> >
> >> >> > For a 10 FPS clip, timestamps
are as below from
> >> the real parser.
> >> >> > 0, 119, 239, 359, 479, 599, 719,
839, 959, 1079, 1199, 1319
> >> >> >
> >> >> > Timestamps from the decoder are
as below.
> >> >> > 0, FAILURE, 119, 239, 359, 479,
599, 719, 839,
> >> 959, 1079, 1199
> >> >> >
> >> >> >
> >> >> > It seems that
dst.sequence_number is updated
> >> properly, but the time
> >> >> > rv_decode_frame_valid() method
fails, decoder is not
> >> >> flushing the frame
> >> >> > and in the next call to
rv_decode_stream_decode method, it
> >> >> is giving the
> >> >> > prev frame and thus, from there
onwards,
> >> >> src.sequence_number is greater
> >> >> > than of dst.sequence_number.
> >> >> >
> >> >> >
> >> >> > Thanks & Regards,
> >> >> > Lovish
> >> >> >
> >> >> > ----- Original Message ----- 
> >> >> > From: "Eric Hyche"
<ehychereal.com
> >> <mailto:ehychereal.com> >
> >> >> > To: "'Lovish Dhawan'"
<ldhawan