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

[Loren Merritt]

On Tue, 7 Jul 2009, Reimar Döffinger wrote:

> the version of libx264 I have lying around (seems to be from 29.6.09)
> seems to have an issue with handling delayed frames and multiple threads: when
> x264_encoder_encode is called with NULL picture to get delayed frames, with n
> threads it returns n-1 times 0 before getting to the delayed frames (I admit
> I only tested with input consisting of 4 pngs and up to threads = 4).
> Attached patch hacks around the issue for threads values of up to 255
> without too much overhead I hope.
> Can someone make sure the x264 developers are informed about this? (and
> if this behaviour is intended I guess it should be better documented,
> FFmpeg should have the same issue).

What do you mean "before getting to the delayed frames"? Threads cause 
delays too. With b consecutive B-frames and t threads, the total delay is 
b+t-1. And this number is not guaranteed by the api; in fact there's 
another patch we'll probably commit soon which will increase it in some 
situations.
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.)
If the above is too cumbersome, I suppose I can add a return value saying 
whether there are any remaining delayed frames.

--Loren Merritt