View Full Version : VBV in x264
Doom9
28th October 2005, 17:00
MeGUI-x264 still doesnt support levelsIf somebody could break them down to what MeGUI understands.... I'm getting confused with number of macroblocks and the likes and have a really hard time breaking that down to features x264 actually supports.
akupenguin
28th October 2005, 20:07
If somebody could break them down to what MeGUI understands.... I'm getting confused with number of macroblocks and the likes and have a really hard time breaking that down to features x264 actually supports.
These are the properties listed in the levels tables in the standard, and how they should limit x264 settings:
MaxMBPS >= width*height*fps. (w&h measured in macroblocks, i.e. pixels/16 round up in each dimension)
MaxFS >= width*height
sqrt(MaxFS*8) >= width
sqrt(MaxFS*8) >= height
MaxDPB >= (bytes in a frame) * min(16, ref + (pyramid ? 2 : bframes ? 1 : 0))
MaxBR >= vbv_maxrate. It isn't strictly required since we don't write the VCL HRD parameters, but this satisfies the intent.
MaxCPB >= vbv_bufsize. Likewise.
MaxVmvR >= max_mv_range. (Not exposed in the cli, I'll add it if people care.)
MaxMvsPer2Mb, MinLumaBiPredSize, direct_8x8_inference_flag : are not enforced by x264. The only way to ensure compliance is to disable p4x4 at level>=3.1, or at level>=3 w/ B-frames.
MinCR : is not enforced by x264. Won't ever be an issue unless you use lossless.
SliceRate : I don't know what this limits.
Sagittaire
28th October 2005, 21:23
Yes level are very complex ...
Possible to incorporate specific command line in x264 (for example -- level 4.1) with automatic compliant level setting (VBV, max_mv_range ...)
Doom9
28th October 2005, 21:31
here's the pickle I'm having with levels: where do I warn the user that his chosen level doesn't fly with his chosen input (resolution wise that is)? Ideally, the input is configured when the codec is configured, but that may not always be the case. Especially in one click mode that turns into a real pain because at the time you configure the codec, the output resolution is not known yet (I need a dgindex project for autocrop and resolution selection to work, and once the dgindex job has been started, everything is fully automatic).
btw, what the heck is pyramid ? 2 : bframes ? 1 : 0I much prefer to write out if then else even if it takes more time.. it's much more third party friendly because everybody that understands basic ifs immediately gets the message.
akupenguin
28th October 2005, 22:34
if(pyramid)
MaxDPB >= (bytes in a frame) * min(16, ref + 2)
else if(bframes)
MaxDPB >= (bytes in a frame) * min(16, ref + 1)
else
MaxDPB >= (bytes in a frame) * ref
(ref being already limited to <=16)
bond
30th October 2005, 13:05
These are the properties listed in the levels tables in the standard, and how they should limit x264 settings:
MaxMBPS >= width*height*fps. (w&h measured in macroblocks, i.e. pixels/16 round up in each dimension)
MaxFS >= width*height
sqrt(MaxFS*8) >= width
sqrt(MaxFS*8) >= height
MaxDPB >= (bytes in a frame) * min(16, ref + (pyramid ? 2 : bframes ? 1 : 0))
MaxBR >= vbv_maxrate. It isn't strictly required since we don't write the VCL HRD parameters, but this satisfies the intent.
MaxCPB >= vbv_bufsize. Likewise.
MaxVmvR >= max_mv_range. (Not exposed in the cli, I'll add it if people care.)
MaxMvsPer2Mb, MinLumaBiPredSize, direct_8x8_inference_flag : are not enforced by x264. The only way to ensure compliance is to disable p4x4 at level>=3.1, or at level>=3 w/ B-frames.
MinCR : is not enforced by x264. Won't ever be an issue unless you use lossless.
SliceRate : I don't know what this limits.latexxx once posted the values needed for these factors:
http://forum.doom9.org/showthread.php?t=101345
edit:
in what way is --vbv-init related to this?
bond
30th October 2005, 15:17
actually i dont seem able to get the vbv to work
no matter what values i set in --vbv-maxrate and --vbv-bufsize it seems the framesizes stay the same
i use mplayer with the following cmdl to readout the sizes of each frame:
mplayer -v -v -frames 0 input.mp4do i get something wrong with vbv?
splitted from megui profile thread (still no own vbv discussion thread it seems...)
Doom9
1st November 2005, 16:29
there's one thing I'm wondering wrt levels: is there any mapping between levels and profiles?
akupenguin
1st November 2005, 18:16
No. Levels = cpu/memory/bitrate needed by a decoder. Profiles = pieces of the standard implemented by a decoder.
Doom9
2nd November 2005, 08:17
Regarding MaxDPB: How do I know (bytes in a frame) ? It's not constant and we only know after encoding, so how can I limit that?
akupenguin
2nd November 2005, 08:47
Bytes in an uncompressed frame. = (pixel width)*(pixel height)*1.5 since we only support 4:2:0.
Doom9
4th November 2005, 08:48
W*H*1.5is that the same width and height as above (as in macroblocks, not actual pixels)
And what's the deal with MaxBR and MaxCPB and using two bases (1000kbit/s or 1200kbit/s).. it makes a huge difference what base you're using.
akupenguin
4th November 2005, 09:53
Base 1000kbit is used for the video data itself. Base 1200kbit is the total bitstream, including: video data, NAL startcodes, SPS, PPS, SEI, redundant slices, and so on. x264 doesn't generate a noticeable amount of extradata, and doesn't support separate limits for the two, so 1000kbit is the one you want.
ToS_Maverick
22nd November 2006, 16:37
i have a few questions regarding the vbv-buffer in x264:
1. does anyone have information about what values one has to set to be compliant with the h264 levels?
2. is there a program to display the value of the vbv buffer which x264 uses when in auto (0) mode?
x264 displays the vbv buffer warning when encoding with the "--level" switch
x264 [warning]: VBV maxrate specified, but no bufsize.
i want to encode my files to be level-compliant. the quality won't really change, so why not? the buffer is the only value i'm not sure about. is it ok to leave it at "0" or are there any recommendations?
akupenguin
22nd November 2006, 22:49
"x264 [warning]: VBV maxrate specified, but no bufsize." Means that it didn't use VBV at all. i.e. buffer size = infinity.
ToS_Maverick
23rd November 2006, 03:16
@akupenguin: thx for the info, but i need your help to solve the next mystery :cool:
i did some testencodes with CRF 20 from a 1200 frame source in 1024x576, to evaluate the impact of the VBV Buffer setting.
commandline was:
--crf 20 --level 3.1 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-maxrate 14000 --me umh --threads 2 --thread-input --progress --no-psnr
i got the following filesizes:
VBV buf Filesize
0 14.498.250
224 74.134.822
1835 73.953.284
7340 73.917.074
9781 73.761.702
now i'm asking myself: WTF?!
am i supid or does x264 just have a bug?
i got another interesting log. i did a 2pass encode with vbv buffer 1835 (DVD standard). 1st pass log looks like this:
Starting job job10-1 at 02:51:31
encoder commandline:
--pass 1 --bitrate 2350 --stats "E:\Video\24 - Season 4\E01\24.S04E01 OD.stats" --level 3.1 --bframes 3 --b-pyramid --direct auto --filter -2,-1 --subme 1 --analyse none --vbv-bufsize 1835 --vbv-maxrate 14000 --me dia --threads 2 --thread-input --progress --no-psnr --output NUL "E:\Video\24 - Season 4\E01\24.S04E01 OD.avs"
successfully started encoding
Processing ended at 02:52:50
----------------------------------------------------------------------------------------------------------
Log for job job10-1
avis [info]: 1024x576 @ 23.98 fps (1200 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [info]: slice I:22 Avg QP:11.59 size: 95911
x264 [info]: slice P:622 Avg QP:17.00 size: 82392
x264 [info]: slice B:556 Avg QP:13.50 size: 36412
x264 [info]: mb I I16..4: 23.3% 0.0% 76.7%
x264 [info]: mb P I16..4: 43.4% 0.0% 0.0% P16..4: 54.8% 0.0% 0.0% 0.0% 0.0% skip: 1.8%
x264 [info]: mb B I16..4: 6.1% 0.0% 0.0% B16..8: 53.3% 0.0% 0.0% direct:31.6% skip: 9.0%
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: SSIM Mean Y:0.9887772
x264 [info]: kb/s:11764.7
encoded 1200 frames, 15.50 fps, 11765.90 kb/s
the I P and B Quants look somehow strange to me.
now if i did something in the wrong way, please correct me. the whole thing is kind of weird. especially the thing with the very different filesizes.
akupenguin
23rd November 2006, 04:14
Maybe fixed. I don't personally have any use for vbv other than 1pass cbr, so the other vbv modes don't get any rigorous testing.
giandrea
24th November 2006, 00:29
I am interested too, and I would like to know wich are the restrictions of the most commonly used levels (the one of the iPod, the one of the PSP and the one of the PS3).
Sharktooth
24th November 2006, 14:35
Those you mentiones are not levels. Those are proprietary profiles.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.