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 (ehyche at real.com)
Technical Lead
RealNetworks, Inc.  

> -----Original Message-----
> From: Lovish Dhawan [mailto:ldhawan at real.com] 
> Sent: Thursday, September 27, 2007 8:50 PM
> To: 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,
> 
> 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
> >>
> >>
> >>
> > 
>