[x264-devel] libx264 x264_encoder_encode question

[chris at crazyfool.org]

Hi Guys

Firstly thanks for providing such a great open source project, secondly I hope you can help with a question I have.

I have an application which uses FFMPEG/X264 via the API, and specifically the function x264_encoder_encode to encode. Since updating the x264 lib to pick the various improvements I have come across an issue in my application. Briefly, my app receives video from the network and encodes it on the fly, in real time. Since the update I have noticed that the encode call seems to be delaying the encode until a specific number of frames have been buffered, in my case 40. This delay only appears to occur at the start of the stream. 

I believe the relevant code is :

if( h->frames.i_input <= h->frames.i_delay + 1 - h->i_thread_frames ) inside x264_encoder_encode.

Now I realise from looking at the GIT logs this is not new code, but rather the initialisation of the variable i_delay has changed.

In my old x264 code, we never seemed to perform this buffering at the start, however now in the new code we do. I believe this is due to the i_delay being different.

You are probably wondering what the problem is, well when i use the latest x264 code and it buffers the frames at the start, for some reason I am losing frames at the end of my output stream. When I use the older x264 code, I dont loose any frames. To investigate more I have commented out the above if statement (in latest code) so no buffering occurs, and when doing this the end of my stream is fine, no frames are missing. 

Now I understand commenting out the above code is not acceptable, so my question to the board is this, there seems to be various influences on the i_delay variable, can someone expand on their meaning? Its likely I will try to set i_delay to 1 via the config, but im not 100% on what config to set, and what other influences this will have on the system. FYI im not utilising the multi threading.

I hope you can provide some advice / info

Thanks
Chris






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20101223/0f4869d5/attachment.html>