x264, show current average bitrate in crf mode?

[smok3]

is there an option for that? if not, could this be implemented?

when would that be usefull;
a. if crf is generaly better than 1 pass vbr, but you don't care 'that much' about final size
b. when you want to possible abort encoding if bitrate gets out of control

[J_Darnley]

It might be possible to have x264 print out the current file size divided by the length of the video processed so far. Let me look at x264.c

[EDIT] That was actually very easy. I stole the code from the final bitrate calculation and didn't have to change a thing.
http://users.telenet.be/darnley/x264_bitrate-progress_01.diff

[smok3]

pretty cool, if this wont change anything speed related, can this go to main branch?

[Sagekilla]

It should not change speed (significantly) It may be fractionally slower (Think 1 second slower on a 2 hour movie) but there's no reason why it wouldn't be.

[Dark Shikari]

This would actually be nice even in bitrate mode. I like it.

[Sagekilla]

Could we expect this to be added to the main branch soon then? :)

[J_Darnley]

One more suggestion: if PSNR is disabled then could x264 print some spaces after the I slice stats to cover the end of the progress line?

[CruNcher]

Now only the final encoding time in h:m:s is missing :)

[Dark Shikari]

One more suggestion: if PSNR is disabled then could x264 print some spaces after the I slice stats to cover the end of the progress line?done. (http://pastebin.com/d49ea532a)

[CruNcher]

Hmm something is strange @ first some frames it works ok but later after some 500 frames encoded it changes like into a Debugview Mode here (CMD WinXP SP3)


encoded frames: 517/3634 (14.2%), 41.52 fps, bitrate 1002.89 kb/s, eta 0:01:15
encoded frames: 520/3634 (14.3%), 41.44 fps, bitrate 1004.58 kb/s, eta 0:01:15
encoded frames: 524/3634 (14.4%), 41.20 fps, bitrate 1025.14 kb/s, eta 0:01:15
encoded frames: 527/3634 (14.5%), 41.13 fps, bitrate 1034.90 kb/s, eta 0:01:15
encoded frames: 531/3634 (14.6%), 41.04 fps, bitrate 1044.35 kb/s, eta 0:01:15
encoded frames: 535/3634 (14.7%), 40.91 fps, bitrate 1053.88 kb/s, eta 0:01:15
encoded frames: 538/3634 (14.8%), 40.70 fps, bitrate 1058.39 kb/s, eta 0:01:16
encoded frames: 542/3634 (14.9%), 40.67 fps, bitrate 1065.98 kb/s, eta 0:01:16
encoded frames: 546/3634 (15.0%), 40.49 fps, bitrate 1075.32 kb/s, eta 0:01:16
encoded frames: 549/3634 (15.1%), 40.34 fps, bitrate 1086.02 kb/s, eta 0:01:16
encoded frames: 553/3634 (15.2%), 40.31 fps, bitrate 1088.80 kb/s, eta 0:01:16
encoded frames: 557/3634 (15.3%), 40.28 fps, bitrate 1090.94 kb/s, eta 0:01:16
encoded frames: 560/3634 (15.4%), 40.22 fps, bitrate 1091.60 kb/s, eta 0:01:16
encoded frames: 564/3634 (15.5%), 40.11 fps, bitrate 1093.21 kb/s, eta 0:01:16


Hmm as soon as it reaches 7 characters i guess i need to change the command windows size ;)

[Dark Shikari]

Let me guess, the instant "bitrate" broke 1000, it overflowed the line, and thus spilled onto the next one? :p

[J_Darnley]

done. (http://pastebin.com/d49ea532a)
Thanks (that's where I should have put my attempt), but 80 spaces is not enough to cover it all with the bitrate printed and either frames > 100000 or bitrate >= 10000.

Perhaps the word "bitrate" needs to be removed?

[kemuri-_9]

is this going to go into the GIT or can i integrate it into the progress indication patch (so it doesn't reject)?
for my own particular uses, i add a "\n" after the progress ends, makes grep -v "encoded frames:" work without stripping out slice I

[CruNcher]

jep window buffer of 81 is needed for 1000 (standard XP is 80) :)

[wyti]

but a standard dos window have only 80 char length so a buffer of 81 will be displayed on 2 lines

[kemuri-_9]

just remove the word 'bitrate'
it should be obvious to anyone who knows what they're doing what the kb/s means without the word 'bitrate' there

[CruNcher]

yes i changed the size of both to 81 (buffer/window size) then it works tough sure it wont work imidiatly the way it is currently so better i guess would be removing characters of the fprintf as J_Darnley said so it works without changeing anything tough people who use CMD i guess know what they're doing so i don't think it is that of a big issue :D

[J_Darnley]

Removing "bitrate" leaves a maximum of 31 chars for the current frame, number of frames, percentage, framerate, and hours eta. I think this is just enough for 6 digit frames, 3 digit framerate, 5 digit bitrate and two digit hours eta.

[EDIT] Only if you remove the two spaces at the end of the string. Now you can fit:
encoded frames: 123456/123456 (100.0%), 123.12 fps, 30814.06 kb/s, eta 12:01:53
and the carriage return at the end.

[fields_g]

Frame: 1234567/1234567 (12.3%), 123.4 fps, 123456.78 kb/s, ETA 12:34:56

71 characters
7 digit frame: 1000000 frame video at 120fps is only 138 minutes long
4 digits+decmal fps: Hope to have encoding this fast someday!
DD:HH:MM time: Seconds are not useful.

Additional 9 characters for overflow of any of the above.

Really don't think going beyond 80 will really be necessary.

[kemuri-_9]

[EDIT] Only if you remove the two spaces at the end of the string. Now you can fit:
encoded frames: 123456/123456 (100.0%), 123.12 fps, 30814.06 kb/s, eta 12:01:53
and the carriage return at the end.

the spaces at the end are for 'clearing' previous lines:

i.e.
progress change from
encoded frames: 90000/100000 (90.0%), 101.00 fps, 30000 kb/s, eta 5:00:09
to
encoded frames: 90100/100000 (90.1%), 99.50 fps, 30100 kb/s, eta 4:50:45

without the spaces the second line would appear as
encoded frames: 90100/100000 (90.1%), 99.50 fps, 30100 kb/s, eta 4:50:459

it needs the spaces to clear the previous line so it doesn't display the last character(s) when the display line grows shorter.

[LoRd_MuldeR]

Why not change "encoded frames:" to "frame:" in order to save same space?

[J_Darnley]

Now only the final encoding time in h:m:s is missing :)
Ask and ye shall receive: http://users.telenet.be/darnley/x264_total-time_01.diff
Calculated in a similar manner as the eta

Why not change "encoded frames:" to "frame:" in order to save same space?
The patch as it was committed cuts it pretty close but if more space does need to be squeezed out the beginning of the line could be changed.

[ImmortAlex]

What about "reverse" task - show ratefactor for 1st (or any bitrate-based) pass encoding?
I'm dreaming about watching full info while encoding, but I know it's need much more programming, than one-line printf() with '\r' sign :)

[CruNcher]

Ask and ye shall receive: http://users.telenet.be/darnley/x264_total-time_01.diff
Calculated in a similar manner as the eta


The patch as it was committed cuts it pretty close but if more space does need to be squeezed out the beginning of the line could be changed.

Superb thx J_Darnley :)

[akupenguin]

What about "reverse" task - show ratefactor for 1st (or any bitrate-based) pass encoding?
internal ratecontrol value, not available to the cli. and the wrappers required to export it would be ugly.

[DarkZell666]

What about "reverse" task - show ratefactor for 1st (or any bitrate-based) pass encoding?
I'm dreaming about watching full info while encoding, but I know it's need much more programming, than one-line printf() with '\r' sign :)

Did you mean to say "average QP achieved so far" ? :p
At least I know I'd like to have that shown during encoding when using bitrate-based mode :)

The average bitrate achieved is a good tweak anyway, thx a lot !

[ImmortAlex]

I mean value that is printed after the 1st pass encoding. AFAIR it is printed like "final ratefactor: nn.nn" and AFAIK it is "average QP". At least in CRF mode this value results more or less the same bitrate.
I want to watch it for one reason: stop encoding somewhere at the middle of 1st pass if I see something unexpected, usually too high values. Than change input, usually resize to something smaller, and make reencode.

[J_Darnley]

Pengvado, no sorry, Akupenguin said it wasn't available to the cli. When the pass finishes that value is printed by the encoder core not the cli.

[DarkZell666]

Pengvado, no sorry, Akupenguin said it wasn't available to the cli. When the pass finishes that value is printed by the encoder core not the cli.

Oh well nevermind ^^