[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp
Thu Feb 17 20:06:00 CET 2011
Le nonidi 29 pluvi?se, an CCXIX, Luca Barbato a ?crit?:
> how many could be addressed having the demuxer call in parsers for help?
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?
As for myself, I would consider it a really bad idea.
> The problem with the current approach is that sometimes an heuristic is
> triggered by the codec in some common libavformat code breaking
> something while solving something else.
> What should be done is to make sure that demuxer specific workarounds
> stay next to the demuxer and they gets called in by the demuxer and not
> by "if (codec_id == CODEC_ID_FOO && generic_condition(pts, dts,
> something)) flip_pts_dts(...);" in the common code.
> So we would have the common code possibly cleaner and leaner and working
> fine with demuxers that do not have those quirks.
> Peculiar containers and/or codec should have workarounds stay next to
> them and have a clear way to trigger (and disable) them.
I agree. But that does say much about what lavc must work with.
Looking at the AVPacket structure, and considering the quirks of various
format, assuming a stupid (but correct) demuxer, the information that comes
to lavc as input is made of any subset of:
- a packet PTS;
- a packet DTS;
- a packet duration;
- possibly some global information (framerate, maybe).
With that, and the help of the packet reordering mechanism, lavc (or
possibly something called from lavc, but since the packet reordering is
needed, I do not see the point) should try to determine the frame PTS at
best as it can.
(By the way, is there a reason not to reorder pkt_duration like pkt_pts?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel