[MPlayer-dev-eng] [PATCH] unified timing patch for H264

[Pásztor Szilárd]

Reimar Döffinger:
> I don't have any samples at hand, but 0 is returned in got_picture also
> if a 0-sized packet is passed, and 0-sized packets are used for timing
> in AVI (I however do not know if those 0-sized packets are ever passed
> up all the way to the decoder or not, but at least there would be a
sudden
> break of meaning of 0-sized packets between demuxer and decoder layer
> that needs to be documented).

Uhh, you are right again - unfortunately. The generic decoder wrapper of
libavcodec (in libavformat/utils.c) overwrites this value in got_picture to
0,
so it is the default behavior of lavc to return 0 - which does not help us
recognize the 0 from a first field.

> Given that libavcodec is broken in this case, not really.

Yes it is clearly a bug, as vital information gets lost. However, in
libavcodec/h264.c, if we return -1 instead of 0 (at "Wait for second
field"),
which may not be a pretty way of signalling this special case, it works.

There are other problems by the way. With nocorrect-pts, when timestamps
are
not reordered, frame times are calculated from fps and pts values are
ignored when displaying the image. But not when calculating a-v sync! This
leads to a-v sync constantly jumping around because of the mixed up pts
values, so the a-v sync correction algorithm makes picture jerky again. :(

I've started looking into the fixpts filter but it seems to me that pts
values don't get overwritten (calculated from framerate) which seems the
only
way to solve this problem.

s.

     ---------------------------------------------------------------------
     |  As long as we have each other, we'll never run out of problems.  |
     ---------------------------------------------------------------------