[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

[Alexander Strange]

On Feb 18, 2011, at 5:53 AM, Peter Ross wrote:

> 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!

Xvid and x264 do set FPS properly in the codec headers. It's safe to use that to play raw streams.
I wouldn't use it as a fallback, because if the file is meant to be VFR the codec information will be useless.

Current behavior: for .h264 r_frame_rate is set, but packet pts/dts isn't, and ffplay doesn't use FPS for timing.

> 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)
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel