[MPlayer-dev-eng] [PATCH] hack x264_encoder_encode returns 0 incorrectly when flushing

[Reimar Döffinger]

On Wed, Jul 08, 2009 at 10:40:06AM +0200, Reimar Döffinger wrote:
> On Wed, Jul 08, 2009 at 03:31:14AM +0000, Loren Merritt wrote:
> > The correct implementation of end of stream flush is: Pass nulls until you 
> > have gotten some frames back, then pass nulls until x264 stops returning 
> > frames. (Unless you haven't encoded any frames at all, in which case that 
> > will hang.)
> 
> And have an endless loop if there isn't any delay? Apart from limiting
> the first wait for getting frames back to 255 that is what my patch
> does.
> 
> > If the above is too cumbersome, I suppose I can add a return value saying 
> > whether there are any remaining delayed frames.
> 
> I'd say that might be a good idea. Because at least mencoder and FFmpeg
> do it wrong, and I have some suspicion that nobody does it right
> actually, because given this code in x264.c:
>     /* Flush delayed B-frames */
>     do {
>         i_file +=
>         i_frame_size = Encode_frame( h, opt->hout, NULL );
>     } while( i_frame_size );
> I'd claim that not even x264 CLI gets it right.
> Maybe a little bit of documentation wouldn't hurt after all?

What about this? Does someone know if x264 gets this right or not?
Should my patch be applied?
Or will libx264 be extended?