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

[Reimar Döffinger]

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?