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

[Reimar Döffinger]

On Thu, Aug 19, 2010 at 06:49:09PM +0200, Pásztor Szilárd wrote:
> Reimar Döffinger:
> > You just used it for !got_picture, however that doesn't help any,
> > got_picture will be 0 regardless of whether the frame was skipped
> > because it is a single field or for some other reason.
> > Libavcodec to my knowledge just does not provide that information,
> > which is why I was surprised how this was supposed to work.
> 
> To my understanding (after looking at decode_frame() in libavcodec/h264.c),
> got_picture is set to 0 only if we have a single but correct field. The value
> remains untouched in the case of a frame error. So if we supply a negative
> value before calling the function, we could in theory know the reason: if it
> remains negative after returning, we have an error.
> Other decoders never set the new NULL image type so there should be no change
> in effect at codecs other than h264.
> 
> Could you point me to a buggy h264 file sampledir -rt

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).
Then for MPEG-4 (SP/ASP) there is the special case of a non-coded VOP
(e.g. a B-frame when there is no movement), search for FRAME_SKIPPED
in libavcodec.

> > And btw. you said that the patch gets the information from the
> > "parser", however it seems to only get information from the
> > decoder, the parser is either part of the demuxer or comes in-between
> > the demuxer and the decoder.
> 
> Yes, it's actually in vd_ffmpeg.c but it's good that libavcodec remained
> unchanged.

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