[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

[Peter Ross]

On Thu, Feb 17, 2011 at 12:13:31PM +0000, M?ns Rullg?rd wrote:
> Peter Ross <pross at xvid.org> writes:
> 
> > On Wed, Feb 16, 2011 at 09:15:07PM +0000, M?ns Rullg?rd wrote:
> >> Peter Ross <pross at xvid.org> writes:
> >> 
> >> > On Wed, Feb 16, 2011 at 05:47:15PM +0000, M?ns Rullg?rd wrote:
> >> >> Martin Storsj? <martin at martin.st> writes:
> >> >> 
> >> >> > On Wed, 16 Feb 2011, M?ns Rullg?rd wrote:
> >> >> >
> >> >> >> Nicolas George <nicolas.george at normalesup.org> writes:
> >> >> >> 
> >> >> >> > L'octidi 28 pluvi?se, an CCXIX, M?ns Rullg?rd a ?crit?:
> >> >> >> >> AVI doesn't have timestamps, so the first decoded frame has PTS 0, and
> >> >> >> >> the following ones increment it by 1/framerate.  Simple.
> >> >> >> >
> >> >> >> > Are you saying that Mr X should put a special case in his code for AVI?
> >> >> >> 
> >> >> >> No, he should put a special case for no PTS on an input frame:
> >> >> >> 
> >> >> >> pts = frame.pkt_pts != AV_NOPTS_VALUE? frame.pkt_pts : prev_pts + 1/framerate;
> >> >> >> prev_pts = pts;
> >> >> >> 
> >> >> >> This code will always work.
> >> >> >
> >> >> > Wouldn't this break for VFR-streams? That is, shouldn't it prefer 
> >> >> > frame.pkt_dts over the calculated pts, if pkt_dts is present (and 
> >> >> > reliable, assuming that all guessing code is disabled).
> >> >> 
> >> >> A VFR stream obviously needs timestamps.  I'm not aware of any
> >> >> VFR-capable container providing only DTS.  In fact, I'm not aware of
> >> >> _any_ container providing only DTS.  Even if such a container did exist,
> >> >> DTS is not PTS.  PTS can, of course, be derived from DTS, decoder delay,
> >> >> and frame reordering, but that is not what any code in ffmpeg does, at
> >> >> least not correctly.
> >> >
> >> > Re your first sentence. It depends on the codec. MPEG-4 includes timestamps
> >> > within the codec payload (AVPacket.data).
> >> 
> >> Where?
> >
> > MPEG-4 encodes timebase and PTS within the VOL and VOP headers
> > respectively. The PTS information is used by the decoder to calculate
> > B-frame motion vectors. Its integral to the codec. You can find more
> > information in ISO/IEC 14496-2; search for 'vop_time' and 'time_base'.
> 
> Those are timecodes, not PTS.  They provide a temporal reference for
> direct mode blocks in B-frames, but they have no relation to PTS used
> for presentation timing.

If the container format provides no DTS or PTS, as is the case with a raw
MPEG-4 Visual stream, then why shouldn't FFmpeg use of this information?
That's what FFmpeg does right now!

There is nothing in the spec to say you can't use them as PTS. e.g. ISO/IEC
14496-2 Annex A, regarding decoder complexity modelling, considers VOP time
to be presentation time.

| ?i is the composition time (or presentation time in a no-compositor decoder) of VOP i. For a video object plane,
| ?i defined by vop_time_increment (in units of 1/vop_time_increment_resolution seconds) plus the cumulative
| number of whole seconds specified by module_time_base.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110218/905c58dc/attachment.pgp>