Hi Eric,

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

Thanks & Regards,
Lovish

----- Original Message ----- 
From: "Eric Hyche" <ehyche at real.com>
To: "'Lovish Dhawan'" <ldhawan at real.com>
Cc: <helix-client-dev at helixcommunity.org>; "'Karl Lillevold'" 
<klillevold at real.com>; <ngokhale at real.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 (ehyche at real.com)
> Technical Lead
> RealNetworks, Inc.
>
>> -----Original Message-----
>> From: Lovish Dhawan [mailto:ldhawan at real.com]
>> Sent: Tuesday, September 25, 2007 6:34 AM
>> To: Lovish Dhawan; ehyche at real.com
>> Cc: helix-client-dev at helixcommunity.org; 'Karl Lillevold';
>> ngokhale at real.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:ldhawan at real.com>
>> To: ehyche at real.com
>> Cc: helix-client-dev at helixcommunity.org ; 'Karl
>> Lillevold' <mailto:klillevold at real.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" <ehyche at real.com <mailto:ehyche at real.com> >
>> To: "'Lovish Dhawan'" <ldhawan at real.com
>> <mailto:ldhawan at real.com> >
>> Cc: <helix-client-dev at helixcommunity.org
>> <mailto:helix-client-dev at helixcommunity.org> >; "'Karl
>> Lillevold'" <klillevold at real.com <mailto:klillevold at real.com>
>> >; <ngokhale at real.com <mailto:ngokhale at real.com> >
>> Sent: Tuesday, September 18, 2007 7:24 PM
>> Subject: RE: TimeStamp issue with Real Format SDK
>>
>>
>> >
>> >> -----Original Message-----
>> >> From: Lovish Dhawan [mailto:ldhawan at real.com]
>> >> Sent: Tuesday, September 18, 2007 7:24 AM
>> >> To: ehyche at real.com <mailto:ehyche at real.com>
>> >> Cc: helix-client-dev at helixcommunity.org
>> <mailto:helix-client-dev at helixcommunity.org> ; Karl Lillevold;
>> >> ngokhale at real.com <mailto:ngokhale at real.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" <ldhawan at real.com
>> <mailto:ldhawan at real.com> >
>> >> To: <ehyche at real.com <mailto:ehyche at real.com> >
>> >> Cc: <helix-client-dev at helixcommunity.org
>> <mailto:helix-client-dev at helixcommunity.org> >; "Karl Lillevold"
>> >> <klillevold at real.com <mailto:klillevold at real.com> >;
>> "Neelesh Gokhale" <ngokhale at real.com <mailto:ngokhale at real.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" <ehyche at real.com
>> <mailto:ehyche at real.com> >
>> >> > To: "'Lovish Dhawan'" <ldhawan at real.com
>> <mailto:ldhawan at real.com> >
>> >> > Cc: <helix-client-dev at helixcommunity.org
>> <mailto:helix-client-dev at helixcommunity.org> >; "Karl Lillevold"
>> >> > <klillevold at real.com <mailto:klillevold at real.com>
>> >; "Neelesh Gokhale" <ngokhale at real.com <mailto:ngokhale at real.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 (ehyche at real.com <mailto:ehyche at real.com> )
>> >> >> Technical Lead
>> >> >> RealNetworks, Inc.
>> >> >>
>> >> >>> -----Original Message-----
>> >> >>> From: Lovish Dhawan [mailto:ldhawan at real.com]
>> >> >>> Sent: Friday, September 14, 2007 10:04 AM
>> >> >>> To: ehyche at real.com <mailto:ehyche at real.com>
>> >> >>> Cc: helix-client-dev at helixcommunity.org
>> <mailto:helix-client-dev at helixcommunity.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-dev at helixcommunity.org
>>
>> http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev
>>
>>
>>
>