[FFmpeg-devel] About guess_correct_pts / AVFrame.best_effort_timestamp

[Nicolas George]

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.

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.

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

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.

> Why?

See above, I hope it clears the misunderstanding.

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

> > (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.

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/1ea2a985/attachment.pgp>