[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

Luca Barbato lu_zero
Thu Feb 17 21:36:15 CET 2011


On 02/17/2011 08:57 PM, Nicolas George wrote:
> Le nonidi 29 pluvi?se, an CCXIX, Luca Barbato a ?crit :
>>> Having the demuxer call in parsers for help means that lavc can only work
>>> with lavf or a demuxer at least as smart as lavf.
>>>
>>> Do you consider that acceptable?
>> I assume that the decoder can trust what it gets from the demuxer,
>> what's wrong with that assumption?
> 
> We have a misunderstanding here.
> 
> With a valid input file, if the demuxer outputs wrong values, that is a bug
> in the demuxer, and should be fixed there, not worked around in lavc. In
> that sense, lavc supposes it can trust the demuxer.

Here we are fine.

> But what Ronald wanted went beyond that: he wanted lavf to do the hard work,
> for example in AVI, deriving the PTS using a parser to handle reordering.
> Indeed, lavf manages to do it, but a more lightweight AVI demuxer would not
> be able to do it.

And that demuxer is lacking then...

> I think we want lavc to be able to work both with lavf and with a
> lightweight AVI demuxer.

I don't see why. Cramming half demuxer in libavcodec doesn't sound
correct. What if I have a smarter-than-lavf demuxer and the proposed
lavc+heuristics just gets confused? (note, we have many users that are
in this scenario)

> Therefore, since there are formats where the PTS can not be derived by a
> lightweight demuxer, lavc can not "trust" the demuxer to have already done
> it.

The main flaw is assuming that libavcodec, with the data it has, can do
something reliable.

> See above, I hope it clears the misunderstanding.

I understood your point of view but please understand that gst, vlc,
tcvp and even mplayer might rather have lavc not do this kind of work.

>> what the decoder should do is decode and possibly make easy for the
>> caller know which is the mapping between the input packets and the
>> output packets and that's all.
>>
>> Code to provide hints about the right timestamp should be something
>> optional since we don't know what the caller would trust better.
> 
> Note that my patch does exactly that: the result is in a new field,
> best_effort_timestamp; all the information that was already there is still
> there. If the caller wants to trust it, it uses it, if not, it uses
> something else.

> Why that rather than an additional function call? Simply because it is
> extremely cheap, compared to the actual decoding.

Because even if cheap it isn't that reliable and isn't something many
users would like to use (for the already mentioned reasons).

>>> (By the way, is there a reason not to reorder pkt_duration like pkt_pts?)
>> Eh?
> 
> Recently, Michael committed a patch that took the pts field from the input
> packet and stored it in the decoded frame across decoding and reordering. I
> wonder if there is a reason not to do the same thing with the duration
> field.

It should be already that way.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero




More information about the ffmpeg-devel mailing list