[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp
Fri Feb 18 18:31:02 CET 2011
On Thu, Feb 17, 2011 at 10:23:24PM +0100, Luca Barbato wrote:
> I tried to explain my reasoning, do you find something that wrong with it?
I do not remember what you argued but everything I heard ranges from
"complete nonsense" to "I don't see that happening any time soon and
I doubt it won't work worse".
The issue with doing it in libavformat is that you need to have
AVParsers that can do both pts->dts and dts->pts fillup.
This is a good bit of code, and for dts->pts we at best have something
we can reuse in some encoders, but generally we really don't.
It also means running parsers, parsing headers and stuff twice when
decoding, and running AVParsers for basically any and all formats, even
mkv and mov that currently do not need it.
On top of that, at least some people seemed to mainly complain about
the "guessing" part, however that will still be required to play files
where pts and dts were messed up or where the timestamps were mangled
(if you do not fix up mangled timestamps that results in jitter,
bad timestamps also for formats that support something better which
makes it completely impossible to detect that the issue was really
timestamp mangling due to container constraints and significant container
overhead for formats that do VFR badly like AVI or not at all like some
mov formats, e.g. for psp IIRC).
It also means that the output of libavformat will even more depend on
with what codec support libav_codec_ was compiled, unless you force
all parsers to be always compiled in - and note that those parsers
will pull in a significant amount of code since they will contain
frame header parsers and reordering code as a minimum.
As for the issues with stream copy if the goal is just to fix them
they are probably possible to hack to work if someone really wants.
For example to get dts just sorting the pts values is likely to work
And for stream copy from "trusted" formats that provide pts the checks
could probably just be disabled.
For stream copy from e.g. AVI it would be possible to either warn or even
test and refuse to copy formats with B-frames or similar.
However honestly I think the interest in FFmpeg for stream copy of video
is rather low so I don't see much of a point in holding things up for that.
More information about the ffmpeg-devel