[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

[Nicolas George]

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.

I agree.

> 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?)

Regards,

-- 
  Nicolas George
-------------- 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/20110217/6e8522c6/attachment.pgp>