[Ffmpeg-devel] Frame rates and time_base

[Rich Felker]

On Sat, May 07, 2005 at 11:33:58AM +0200, M?ns Rullg?rd wrote:
> Rich Felker <dalias at aerifal.cx> writes:
> 
> > On Sat, May 07, 2005 at 12:00:46AM +0200, M?ns Rullg?rd wrote:
> >> Bill May <wmay at cisco.com> writes:
> >> 
> >> > M?ns Rullg?rd wrote:
> >> >> OK, I'll try to rephrase it.  Where does libavcodec get the values it
> >> >> puts in AVFrame.pts?  If the demuxer supplies a pts with a frame, I'd
> >> >> like that pts to appear in the corresponding AVFrame.  How do I tell
> >> >> libavcodec about the pts of the encoded frames I'm feeding it?
> >> >
> >> > I'd like to know if:
> >> >
> >> > for the encoder, if it is possible to put a DTS, then get the PTS
> >> > of the returned frame ?  (x264 has this).
> >> >
> >> > for the decoder, pass in a PTS, and get a DTS from the decoded frame.
> >> 
> >> If PTS and DTS are different for an encoded frame, there is no way to
> >> determine one from the other.  While decoding a sequence of frames, it
> >> is of course possible to determine any PTS, given the PTS of one of
> >> the frames.
> >
> > Huh? Given a sequence of frames and their order, it's possible (and
> > easy -- see the NUT spec) to convert PTS to DTS.
> 
> The NUT spec is irrelevant.  Most containers don't give the display
> order explicitly.

NUT does not either. RMFM (read my fucking mail) and RTFNS (nut spec)!
The point is that, given the frames in DECODE ORDER (which any sane
container uses) and given PTS for each frame, you can reconstruct DTS.

Obviously you cannot go the other way around (which is what you're
arguing and what I already said) unless the frames are stored in
display order, which, I repeat, is stupid.

Rich