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

[Alexander Strange]

On Aug 19, 2010, at 1:00 PM, Pásztor Szilárd wrote:

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

I really don't want to see an error code returned for something not an error.

Does ffplay have problems with the same files? Its method is pretty good for most things, though it could be a bit better.
And it doesn't use any kind of pts buffering.