[New Patch] use first pass stats file for second pass eta when using fifo pipes

[morph166955]

I've had the problem for a while now that when using a fifo pipe to feed x264 on linux it wouldn't be able to generate any sort of an eta on either pass since it couldn't calculate the number of frames from the file size. So instead I decided to add another cli option that would force x264 to use the number of frames read in from the stats file as a base for generating the eta on the second pass. In theory your second pass should have the same number of frames as the first pass so it should be accurate enough to generate a rough eta. You can get the patch at http://www.benswebs.com/public/x264/x264_r678_fp-eta.diff if you want to test/use it. This patch was generated off of revision 678 from the svn that i fetched this morning.

Please note, I have only tested this on raw yuv input however I see no reason that it wouldn't work for all of the others since its basing its numbers on what the rate control is seeing when it reads the file. To enable this feature you need to use "--fp-eta" on the command line. It is safe (although useless) for you to have this enabled on the first pass since it wont do anything if it doesn't detect that your on the second pass.

If anyone finds any problems please let me know and I'll look into why its doing what ever it is that its doing wrong.

Enjoy!

[akupenguin]

This shouldn't be an option. If you can compute the number of frames, do it always. It doesn't need a new variable either, just set frame_total.
x264cli should only access libx264 via the public api. So you can't pass data out of libx264 via h->param, you have to set the original param_t from x264_encoder_open().

[morph166955]

i updated my patch to just set i_frame_total with the value from the rate control file. i also removed the cli so it will just do it automatically if it can.

[morph166955]

file moved to different directory on web server, link updated