[FFmpeg-devel] Maintainership question

[Nicolas George]

> On Sat, Feb 12, 2011 at 3:52 PM, Reimar D?ffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> > I admit I lost track, but the only technical objections I paid attention
> > to were refuted.
> > If that's not the case, someone should probably restate it, otherwise
> > I'm sure I'm not the only one only rembering "I don't like it, it's ugly
> > and it's only going in over my dead body no matter how wrong I am".

For what it's worth, I remember it like Reimar. I do not know if M?ns would
have been like that under normal circumstances, but in this particular case,
he obviously could not put aside his feud with Michael to answer other
people's questions and objections.


Le quartidi 24 pluvi?se, an CCXIX, Ronald S. Bultje a ?crit?:
> - lavc has no business touching pts, it's decoding/encoding lib, if
> anywhere this should be in lavf or so

There are two questions raised by this point: should the code exist at all,
and should it be in lavc.

For the second question: should the timestamp selection logic be in lavc, I
answer thus:

When you decode video frames, almost always you need their timestamp.
Keeping track of the timestamp is completely negligible compared to any
video decoding operation: it is therefore reasonable to ignore the "almost"
and always keep track of the timestamp. For that reason, I think the
timestamp tracking logic should always be called in avcodec_decode_videoX:
simpler API, less bugs in client applications.

Now, if someone suggests a scenario where the timestamp of the decoded frame
is useful without the decoded frame itself, I don't mind putting the
timestamp tracking logic somewhere else in the library set, as long as its
result is available with the decoded frame.


Now, the first question: should this timestamp guessing logic exist at all?

After a client application calls avcodec_decode_videoX, it has no less than
four potential timestamps for this frame:
- the packet PTS,
- the packet DTS,
- the reordered PTS,
- the codec timestamp.

The packet PTS is always wrong, of course, the reordered PTS supersedes it
completely. We know it because we have a good understanding of the problem.

But the three others are all valid candidates to be "the" frame timestamp.
And depending on the format, on the codec, on the actual file, etc., any
subset of them can be undefined. Plus, the codec timestamp is sometime in a
different time base than the PTS and DTS. And do not forget that the real
meaning of the DTS is hardly explained anywhere.

Do you expect all client applications to do the right thing with such a
complex mess? I do not: most will do things wrong and get jerky playback
when dealing with B-frames or VFR content.

Thus, I believe the decoding library should provide the client applications
a single timestamp with the documentation clearly stating "this is the
timestamp you are looking for", while the other timestamps stay available in
their respective fields for the rare case where an informed programmer needs
them.

> - if lavfilter wants to use it and lavfilter doesn't want to depend on
> lavc, then it again does not belong in lavc

AFAIK, the question arose only for the "movie" source in lavfi, which
perforce depends on lavc.

> - the logic used to "guess" pts values is highly questionable and
> should probably only be used for certain input formats, and possibly
> only some codecs in those input formats, and that logic is completely
> missing right now (and also from the original implementation in
> ffmpeg/ffplay.c)

Could you elaborate on this "highly questionable".

The logic of the current code is this: given the DTS and reordered PTS, if
only one of them is defined, use it; if both of them are defined, use the
one that has shown the less discontinuities in the past.

If I understand things correctly, when both the rPTS and DTS are available,
they should be equal. If they are, the "guessing" logic guesses nothing, it
just uses them. And if they are not, something is already wrong before the
guessing logic kicks in.

If the wrong timestamps are somehow generated/mangled by lavf, of course,
lavf should be fixed. M?ns suggested that this happens, but never answered
to my request of a sample (2011-02-01 21:09:21 +0100).

OTOH, if the wrong timestamps are in the file itself, because of a broken
muxer, we can do nothing about it, and only try to make the better of them.
Thus the "guessing" logic.

(A possible enhancement to help detect problems is to print a warning if
both rPTS and DTS are defined and they disagree.)

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/20110213/c5cd3c37/attachment.pgp>