Calculating Target File Size

[bnshrdr]

I've been searching through forum after forum trying to find a way to accurately encode video with an expected resulting file size. The only problem is, I am using ffmpeg via command line.

I really only found one guide and followed it to the teeth, but it didn't come out right and my resulting video bitrate was only half of that I had expected, and you could definitely tell.
http://www.helyar.net/2009/how-to-set-target-file-sizes-in-ffmpeg/

I have a film that is 1h:31m. I thought by doing the calculations below would give me exactly what I needed.
Target - 700 MB

Audio Bitrate
->Set to 96kbps
->96 * .125 * 60 * 91 / 1024 = 63.984375 MB
->Remaining Size = 636.015625 MB

Video Bitrate
->636.015625 * 1024 / 60 / 91 / .125 = 954.256410256 kbps
Here is the command line I tried (1 pass for now, until I get it working...)
ffmpeg -i movie.vob -vcodec libx264 -b 954k -bt 954k -acodec libfaac -ab 96k -threads 0 movie.mp4
From this command line, I get a video with a 450 kbps video bitrate average.

Here are my questions:
Is this actually the correct way to do it?
->If so what have I done wrong?
Do my calculations mean nothing and I have been going about this completely wrong?

All help greatly appreciated!

[LoRd_MuldeR]

1. If you want to hit a specific file size (or avarage bitrate), then it's highly recommended to use 2-Pass mode!

2. If the resulting average bitrate is significant lower than the specified target bitrate, the encoder probably was saturated (look at the x264 log for details).

[bnshrdr]

Thanks for the reply.

I want to use 2-pass, but if I can't even get a single pass to even have a decent bitrate, I need to fix that problem first.

Also, I am kind of new to the whole encoding scene, is there a link explaining my saturation problem, and how to fix it? I don't even know what that means, lol.

Edit: I am not sure how to get an x264 log since I am on linux using ffmpeg. Any suggestions?
Thanks!

[LoRd_MuldeR]

I want to use 2-pass, but if I can't even get a single pass to even have a decent bitrate, I need to fix that problem first.

2-Pass will hit the target bitrate more accurate than single-pass ABR ;)

Anyway, even single-pass ABR should not produce a 954 kbps vs. 450 kbps difference, except for extremely short clips maybe.

So I suspect that the encoder is simply saturated at ~450 kbps...

Edit: I am not sure how to get an x264 log since I am on linux using ffmpeg. Any suggestions?

x264 prints out all the relevant info to the screen. Doesn't x264's output appear in the console when using ffmpeg ???

[bnshrdr]

Here is what I get on my console:
ben@ben-laptop:~/Desktop$ ffmpeg -i movie.vob -vcodec libx264 -b 954k -bt 954k -acodec libfaac -ab 96k -threads 1 movie.mp4
FFmpeg version 0.5, Copyright (c) 2000-2009 Fabrice Bellard, et al.
configuration: --enable-gpl --enable-nonfree --enable-pthreads --enable-libfaac --enable-libfaad --enable-libmp3lame --enable-libtheora --enable-libx264 --enable-libxvid --enable-x11grab
libavutil 49.15. 0 / 49.15. 0
libavcodec 52.20. 0 / 52.20. 0
libavformat 52.31. 0 / 52.31. 0
libavdevice 52. 1. 0 / 52. 1. 0
built on Jul 28 2009 17:45:05, gcc: 4.3.3
Input #0, mpeg, from 'movie.vob':
Duration: 01:31:02.40, start: 120.987811, bitrate: 4880 kb/s
Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480 [PAR 32:27 DAR 16:9], 9800 kb/s, 59.94 tbr, 90k tbn, 59.94 tbc
Stream #0.1[0x80]: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s
Stream #0.2[0x82]: Audio: ac3, 48000 Hz, stereo, s16, 192 kb/s
Output #0, mp4, to 'movie.mp4':
Stream #0.0: Video: libx264, yuv420p, 720x480 [PAR 32:27 DAR 16:9], q=2-31, 954 kb/s, 90k tbn, 59.94 tbc
Stream #0.1: Audio: libfaac, 48000 Hz, stereo, s16, 96 kb/s
Stream mapping:
Stream #0.0 -> #0.0
Stream #0.1 -> #0.1
[libx264 @ 0x987b2e0]using SAR=32/27
[libx264 @ 0x987b2e0]using cpu capabilities: MMX2 Cache64
[libx264 @ 0x987b2e0]profile Baseline, level 3.1
Press [q] to stop encoding
[ac3 @ 0x987ba20]frame sync error
Error while decoding stream #0.1
frame= 52 fps= 35 q=-1.0 Lsize= 222kB time=1.98 bitrate= 915.4kbits/s


But this is misleading as that bitrate quickly drops after ffmpeg has been running for a couple seconds. There are a couple errors there so that I suppose could be an issue. Maybe you guys could better decipher this.

Thanks for the help so far.

[LoRd_MuldeR]

We'd need the info that x264 prints out when the encoding process is completed. Like this:

x264 [info]: slice I:5 Avg QP:17.70 size: 14142
x264 [info]: slice P:56 Avg QP:17.36 size: 3693
x264 [info]: slice B:89 Avg QP:18.28 size: 758
x264 [info]: consecutive B-frames: 13.6% 2.7% 44.9% 19.0% 3.4% 16.3%
x264 [info]: mb I I16..4: 58.2% 39.9% 1.9%
x264 [info]: mb P I16..4: 4.5% 5.6% 0.1% P16..4: 16.8% 3.6% 4.7% 0.0% 0.0% skip:64.5%
x264 [info]: mb B I16..4: 0.2% 0.2% 0.0% B16..8: 10.6% 0.0% 0.1% direct: 3.7% skip:85.1% L0:34.6% L1:63.3% BI: 2.2%
x264 [info]: 8x8 transform intra:47.7% inter:85.7%
x264 [info]: direct mvs spatial:95.5% temporal:4.5%
x264 [info]: coded y,uvDC,uvAC intra:39.5% 68.1% 49.1% inter:2.7% 9.6% 2.2%
x264 [info]: ref P L0 54.0% 20.6% 10.7% 4.2% 3.2% 2.5% 3.6% 1.2%
x264 [info]: ref B L0 72.7% 17.4% 5.2% 1.9% 1.2% 0.7% 0.9%
x264 [info]: ref B L1 85.2% 14.8%
x264 [info]: kb/s:460.0

More specifically you should look at the "Avg QP" values. If these are near 10, then x264 is saturated (with standard "--qpmin" value).

[bnshrdr]

Well, I don't think it will really spit that kind of info out since it is being used through ffmpeg, although I guess I can try to wait it out, its a big file. If it is getting saturated, what can I do to prevent this?

[LoRd_MuldeR]

Well, I don't think it will really spit that kind of info out since it is being used through ffmpeg

Why not use x264 CLI instead of ffmpeg?

although I guess I can try to wait it out, its a big file.

Use a shorted file for testing ;)

If it is getting saturated, what can I do to prevent this?

If it's really saturated, then you can be happy that the lower bitrate is sufficient for your video :D

Anyway, you could lower "--qpmin" (default is 10) to allow x264 to waste more bits...

[bnshrdr]

I was wrong, it does give some helpful output:
video:2933kB audio:880kB global headers:0kB muxing overhead 0.752700%
[libx264 @ 0x9c6f7e0]slice I:75 Avg QP:20.43 size: 12260
[libx264 @ 0x9c6f7e0]slice P:823 Avg QP:25.43 size: 2532
[libx264 @ 0x9c6f7e0]mb I I16..4: 61.3% 0.0% 38.7%
[libx264 @ 0x9c6f7e0]mb P I16..4: 5.8% 0.0% 0.0% P16..4: 29.7% 0.0% 0.0% 0.0% 0.0% skip:64.6%
[libx264 @ 0x9c6f7e0]final ratefactor: 30.86
[libx264 @ 0x9c6f7e0]SSIM Mean Y:0.9744475
[libx264 @ 0x9c6f7e0]kb/s:1603.9


Is 20.43 a bad avg qp?

[LoRd_MuldeR]

video:2933kB audio:880kB global headers:0kB muxing overhead 0.752700%
[libx264 @ 0x9c6f7e0]slice I:75 Avg QP:20.43 size: 12260
[libx264 @ 0x9c6f7e0]slice P:823 Avg QP:25.43 size: 2532
[libx264 @ 0x9c6f7e0]mb I I16..4: 61.3% 0.0% 38.7%
[libx264 @ 0x9c6f7e0]mb P I16..4: 5.8% 0.0% 0.0% P16..4: 29.7% 0.0% 0.0% 0.0% 0.0% skip:64.6%
[libx264 @ 0x9c6f7e0]final ratefactor: 30.86
[libx264 @ 0x9c6f7e0]SSIM Mean Y:0.9744475
[libx264 @ 0x9c6f7e0]kb/s:1603.9
Is 20.43 a bad avg qp?

Nope, it's not bad at all. But it doesn't indicate that the encoder is saturated either.

This time it came out at an average bitrate if 1603.9 kbps. So in contrast to your previous post that means the resulting bitrate is higher than desired, not lower :confused:

BTW: Form that output it seems you don't even use B-Frames. Is that intentionally ???

[bnshrdr]

Like I said, I am rather new. I have some commands I am going to try. Also I just noticed, I get different results from when I encode the original 3.1 GB vs 22 MB file. It seems to only give the lower bitrate with the big file, and not the smaller, even if I set qpmin=1. Why would this be?

Also, when it said the bitrate was 1603.9 kbps, it wasn't quiet that high. I would say it was around 1000.

[LoRd_MuldeR]

Also, when it said the bitrate was 1603.9 kbps, it wasn't quiet that high. I would say it was around 1000.

How did you measure the average bitrate? I'd believe in the value that x264 prints out ;)

[bnshrdr]

vlc can show the current bitrate the movie is playing at and it barely reached 1000. Maybe this is just a movie player issue.

[LoRd_MuldeR]

vlc can show the current bitrate the movie is playing at and it barely reached 1000. Maybe this is just a movie player issue.

We talk about the average bitrate here! Of course the video bitrate can fluctuate throughout the video. VLC only shows the local bitrate at the current position ;)

But the "target" bitrate, for single-pass ABR and 2-Pass mode, always refers to the average bitrate of the video. The local bitrate may be much higher or much lower than that.

That's the whole idea of ABR and 2-Pass rate control. Using strict CBR would result in horrible video quality...

[bnshrdr]

Ok, gotcha. I'm getting much more predictable results with b-frames now. Also the quality has gone way up. Thanks for your direction through this, now I know what a lot of this stuff means. :P

video:4578kB audio:883kB global headers:1kB muxing overhead 0.454324%
[libx264 @ 0x9332620]slice I:11 Avg QP:20.38 size: 34100
[libx264 @ 0x9332620]slice P:325 Avg QP:21.51 size: 9437
[libx264 @ 0x9332620]slice B:413 Avg QP:23.52 size: 3017
[libx264 @ 0x9332620]consecutive B-frames: 7.9% 39.0% 43.1% 6.5% 2.7% 0.8% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
[libx264 @ 0x9332620]mb I I16..4: 13.3% 0.0% 86.7%
[libx264 @ 0x9332620]mb P I16..4: 1.6% 0.0% 6.4% P16..4: 48.1% 15.4% 10.4% 0.0% 0.0% skip:18.2%
[libx264 @ 0x9332620]mb B I16..4: 0.2% 0.0% 0.6% B16..8: 53.5% 2.7% 4.5% direct: 2.6% skip:35.9% L0:33.6% L1:56.1% BI:10.3%
[libx264 @ 0x9332620]final ratefactor: 19.52
[libx264 @ 0x9332620]ref P L0 75.6% 10.2% 6.0% 2.9% 2.6% 2.7%
[libx264 @ 0x9332620]ref B L0 87.8% 6.2% 3.3% 1.5% 1.3%
[libx264 @ 0x9332620]SSIM Mean Y:0.9836430
[libx264 @ 0x9332620]kb/s:1001.5

[LoRd_MuldeR]

[libx264 @ 0x9332620]consecutive B-frames: 7.9% 39.0% 43.1% 6.5% 2.7% 0.8% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

It seems you are using 16 B-Frames now. That's overkill. As you can see, x264 never actually used more than 5 B-Frames in your clip!

Lower B-Frames to a reasonable value, such as 3 or 4, but make sure that B-Adapt mode 2 is used...

[nm]

Thanks for your direction through this, now I know what a lot of this stuff means. :P
In that case you should really use presets when calling libx264 through ffmpeg. See this guide: http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/