Encoding Video for Blu-Ray using H264/AVC

[laserfan]

Why does x264 sometimes whiff the target bitrate on a 2pass encode so badly?
I know you're not kidding, but... You're kidding, yes? That's 0.22%! :eek:

[Stereodude]

I know you're not kidding, but... You're kidding, yes? That's 0.22%! :eek:Ehh... poor choice of words there.

I'm just curious, not intended to be a whining complainer. It nails the bitrate as close as can be expected most of the time. Sometimes it less precise than it usually is. I'm wondering what causes the difference.

[laserfan]

Ehh... poor choice of words there.
No, it was a very careful choice of words. :p

Rejoice--0.22% is amazingly good, and in no way should be considered a "whiff" of the target.

[rapscallion]

It nails the bitrate as close as can be expected most of the time. Sometimes it less precise than it usually is. I'm wondering what causes the difference.
I imagine the complexity of the video source, the length, the quality and the amount of light vs dark scenes all play a role. I'm sure there are others as well. Considering it's VBR, it amazes me that it gets it as close a it does.

[Stereodude]

Rejoice--0.22% is amazingly good, and in no way should be considered a "whiff" of the target.Okay, let me reword so we can all be friends again... :p

Most of the time in my experience x264 hits the target bitrate within ~0.02%, which is fantastic. Sometimes it only hits the target bitrate within ~.20% which is still very good, but can be a little problematic when you're used to the typical .02% and are trying to use nearly every MB on a Blu-Ray. What factors affect this?
I imagine the complexity of the video source, the length, the quality and the amount of light vs dark scenes all play a role. I'm sure there are others as well. Considering it's VBR, it amazes me that it gets it as close a it does.Isn't that what the first pass is sorting out though? Where to allocate the bitrate on the 2nd pass to hit the desired target bitrate while maintaining a constant perceived image quality across the whole clip (within the max and minimum bitrates allowed)?

[laserfan]

Most of the time in my experience x264 hits the target bitrate within ~0.02%, which is fantastic.
Indeed. I have never (ever) seen it that close; maybe it has to do with your "veryslow" preset which I have only used once or twice.

In any case IMO even 0.2% will get lost in the muxing i.e. it seems audio type/bitrate and subs are what make it tricky to try to "fill a disc to the edge" and not x264.

EDIT: Ok I found an old encoding where I'd used "veryslow" and it was accurate to 0.036% so I'll assume your numbers are correct and are owed to your settings. I tend to use normal settings and get a (wonderful) "0.11-0.12% below" result most of the time. BTW I dunno what this has to do with the thread topic. :confused:

[sneaker_ger]

http://forum.doom9.org/showthread.php?p=1410022

[Stereodude]

http://forum.doom9.org/showthread.php?p=1410022Thanks for the link.

[Sagittaire]

Why does x264 sometimes whiff the target bitrate on a 2pass encode so badly?

Most of the time I've found it gets within a few kbit/sec (usually on the low side) when I'm encoding at a target bitrate to fill a Blu-Ray disc. However, I've found that ocassionally x264 will miss the bitrate by a lot more, generally on the low side but not always.

Here's the command line I used:I asked for a bitrate of 19110kbit/sec and I got a file with a bitrate of 19067.15kbit/sec. :confused: It's not the end of the world, but I'm curious.

If you want best possible target (and constant quality), you must use the best possible accurate stat pass and for that only one solution: 3 pass encoding ...

[Stereodude]

If you want best possible target (and constant quality), you must use the best possible accurate stat pass and for that only one solution: 3 pass encoding ...Wouldn't a --slow-firstpass do the same thing in 2 passes?

[sneaker_ger]

The question is: is investing time in more than 1 or 2 passes a good idea?
Might be better to spend it on filtering or otherwise slower/better encoding settings.

And I'm not even sure whether a third pass results in increased accuracy - has anyone tested that?

[Stereodude]

And I'm not even sure whether a third pass results in increased accuracy - has anyone tested that?FWIW on my single test, a --slow-firstpass actually resulted in an even lower bitrate. It yielded 19050kbit/sec. :scared:

I don't have any plan to try a 3 pass encode. The encodes are close enough to the target size to not spend 12-16 hours doing them again.

[Audionut]

Why does x264 sometimes whiff the target bitrate on a 2pass encode so badly?

I don't have any plan to try a 3 pass encode. The encodes are close enough to the target size to not spend 12-16 hours doing them again.

:confused: Which one is it?

[Stereodude]

:confused: Which one isit?It's whichever one you want it to be. :rolleyes:

I asked why x264 sometimes doesn't nail the bitrate. I never asked anyone to fix it claiming it was broken. I also never said I was re-encoding files because of the variance. Would I rather x264 nail the bitrate all the time? Sure. My statements are in no way contradictory. Why does everyone have to be so contentious on forums these days. :confused:

[Audionut]

Why does everyone have to be so contentious on forums these days. :confused:

Try searching and not taking a thread off-topic next time.

[iSeries]

Hi,

I have quite a few mkv's which I have ripped from my blu rays. I'm looking to re-encode to save space. Reading through this thread I have learned that the encoded stream needs to be muxed into a blu ray structure to retain compliance (and not to mkv). My question is can I encode a blu ray compliant stream from an mkv or do I have to re-rip? (I think I can, just need some reassurance!)

[nm]

My question is can I encode a blu ray compliant stream from an mkv or do I have to re-rip? (I think I can, just need some reassurance!)

You can encode compliant streams from MKVs, just like from any other source.

[Sharc]

Does --sar 64:45 for 720x576 break blu-ray specs? Do I have to use --sar 16:11 always for blu-ray compliance?
I am asking because many 16:9 PAL DVDs come with a PAR of 64:45. I would prefer avoiding a slight resizing and keep the par as is (64:45 in this case) for my backups.

[shon3i]

Does --sar 64:45 for 720x576 break blu-ray specs? Do I have to use --sar 16:11 always for blu-ray compliance?Yes. Should not be a big difference to eye.

[Sharc]

ok, thanks.
My standalone player+TV will directly map it to 16:9 anyway for playback and not follow the --sar. Only the software player (MPC-HC) applies the --sar for playback, unless I force it to use 16:9.

[newsky]

I think that I'm doing wrong :(. Please confirm or disprove my doubts. Encoding the home video shot with Canon 5D Mark II (1920x1080, 29,97fps) in these settings Xvid4PSP x264:

--crf 18.0 --level 4.1 --tune film --bluray-compat --open-gop --bframes 3 --ref 4 --deblock -2:-1 --merange 26 --slices 4 --aud --nal-hrd vbr --b-pyramid strict --trellis 2 --no-fast-pskip --no-dct-decimate --keyint 30 --partitions all --subme 9 --me umh --vbv-bufsize 30000 --vbv-maxrate 40000 --weightp 1 --fake-interlaced --pic-struct --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1

1. Is it permissible to encode for Blu-ray in the mode of CRF, or only 2 pass?
2. Save the above settings in x264 MKV demux and then do a tsMuxer (that's probably completely wrong? And this video is not suitable for the Blu-ray? Although Adobe Encore CS5 makes Blu-ray with this file, and plays on the Dune HD Max.
That too much in my settings? What is missing? What are they wrong? That correct?

[sneaker_ger]

1. Is it permissible to encode for Blu-ray in the mode of CRF, or only 2 pass?

Both CRF and 2pass are allowed.

2. Save the above settings in x264 MKV demux and then do a tsMuxer (that's probably completely wrong? And this video is not suitable for the Blu-ray?

That is not allowed, encode directly to .h264 raw ES.

That too much in my settings?

A few settings are redundant/not needed (but don't hurt anyways):
--bframes 3 --aud --nal-hrd vbr --b-pyramid strict --weightp 1 --pic-struct

What is missing? What are they wrong? That correct?

They should be correct.

See following for good examples, in case you don't have already:
http://www.x264bluray.com

[newsky]

Thank you so much sneaker_ger!
--bframes 3 --aud --nal-hrd vbr --b-pyramid strict --weightp 1 --pic-struct = --bluray-compat Therefore, these values ​​are unnecessary? yes? or not?

in the presence of --fake-interlaced and without--pic-struct Adobe Encore CS5 an error terminates Authoring

[sneaker_ger]

Not exactly (http://git.videolan.org/gitweb.cgi?p=x264.git;a=blobdiff;f=encoder/encoder.c;h=b0fc7b907ea55e93ab2903a06e48ba02d71db4bb;hp=fd2c877373a72497e7ee0fe1462b48f547cbbc18;hb=f9e7f531048df7219a44203031c8f79bae6170d0;hpb=f422ec93254ed3f9883acac0bb3f67e3b4ea960c), but yes, "--aud --nal-hrd vbr --b-pyramid strict --weightp 1" will in this case be used because of "--bluray-compat". "--bframes 3" is x264's standard setting and "--pic-struct" should be implied by "--fake-interlaced".

[newsky]

I heard that when encoding CRF, VBV may extend beyond the established value, and encoding Pass2 not, is it true? And are there any nuances in the use of CRF to Blu-ray?

[sneaker_ger]

I heard that when encoding CRF, VBV may extend beyond the established value, and encoding Pass2 not, is it true?

No. If VBV limit should get exceeded, x264 would display a warning, but this should very rarely - if ever - happen.

And are there any nuances in the use of CRF to Blu-ray?

You can use CRF for Blu-Ray, just as you can use 2pass. Nothing to look out for.

[newsky]

low bow to you for help, sneaker_ger!

[newsky]

Output file must be in raw 264 elementary stream (extension .264) otherwise settings will not applied correctly. DO NOT USE MKV OR MP4.
packed in a container m2ts unacceptable?

[shon3i]

This is for internal x264 output format, not outside x264.

[newsky]

Handle a BD player with value --partitions all?
I want to re-encode all my home videos, tell me everything is right and justified in my settings? source: 1920x1080p 29,97
--crf 18.0 --level 4.1 --bluray-compat --ref 4 --deblock -2:-1 --merange 26 --slices 4 --trellis 2 --no-fast-pskip --no-dct-decimate --keyint 30 --partitions all --subme 9 --me umh --vbv-bufsize 30000 --vbv-maxrate 40000 --fake-interlaced --pic-struct --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1
Maybe we should change something for better quality?

[Stereodude]

Is there any particular reason the suggested x264 command lines on http://www.x264bluray.com don't include --b-adapt 2 as part of the command line?

[Kurtnoise]

preset veryslow includes --b-adapt 2

[Stereodude]

preset veryslow includes --b-adapt 2Oh. Thanks. I guess that's what I get for relying on the documentation on http://mewiki.project357.com/wiki/X264_Settings which said the default was 1.

[sneaker_ger]

1 is the default, but preset veryslow is not, preset medium is.

Use --fullhelp for detailed preset view.

[Stereodude]

1 is the default, but preset veryslow is not, preset medium is.Point taken, but IMHO the wiki should note that the --preset setting changes the setting. I'd edit the wiki myself, but it's locked.

[Groucho2004]

IMHO the wiki should note that the --preset setting changes the setting
from the wiki (under presets):
For information on what options these settings toggle, check the output of x264.exe --fullhelp

[djmasturbeat]

images on first page are dead
can we get those rehosted please? =)
or am i just having some issue on my end?

[jpsdr]

No, no pictures for me also.

[shon3i]

Pictures work here..

[QBhd]

They were down here, but as stated above, are now back up...

QB

[wiseant]

Hi
I just did a transcode to x264 for Blu-ray compatibility on DVD - I am hoping that someone can confirm my encode settings

Here is my commandline:
x264.exe --fps 24000/1000 --force-cfr --level 4 --keyint 48 --crf 18 --vbv-maxrate 15000 --vbv-bufsize 15000 --bluray-compat --sar 1:1 --pic-struct --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" -o xxx.264 xxx.avs

and here is some media info:
Encoding settings: cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=48 / keyint_min=4 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=15000 / vbv_bufsize=15000 / crf_max=0.0 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00
Buffer size: 1875000

Since I did not use a preset, by default it uses the medium preset - will Blu-ray compatibility still apply if I use fast, faster, veryfast, superfast, or ultrafast?
I am also wondering since presets are "Overridden by user settings", if using any of these presets will cause conflicts/problems with compatibilty?

TIA

[sneaker_ger]

Do you want "--fps 24000/1001" (=23.976) or "--fps 24000/1000"="--fps 24" (=24.000)? Rest of the settings is fine.
It should still be compatible with the faster presets, though I'm not sure about ultrafast's "--no-cabac". But since CABAC is never mentioned as a requirement, that one is probably also OK.

[wiseant]

Thanks sneaker_ger

I wanted 24 fps - looks like I should have just used "--fps 24"
It does appear that blu-ray can use CABAC or CAVLC:

from: http://www.mainconcept.com/products/apps-plug-ins/transcoding/reference/blu-ray-codec-bundle.html

"MainConcept Reference Blu-ray Codec Bundle supports all standard and advanced features of the H.264 specifications including Baseline, Main and High Profiles as well as CABAC and CAVLC."

[Stereodude]

if you're transcoding a commercial Blu-Ray you should use 24000/1001 since that's what on the disc.

[chompy]

if you're transcoding a commercial Blu-Ray you should use 24000/1001 since that's what on the disc.

Not always, at least here in Europe we have quite blu-rays that are 24 fps.

[djmasturbeat]

i have seen the rare true 24 fps too

anyhow

thanks for this thread
i come here for reference all of the time
just want to make sure to thank you

sometime I think i might take all this info here and http://www.x264bluray.com/ and make a pdf if that is okay?
certainly would be easier for me.

[DiKey]

Please, help. I was read all, that I could, but my problem is still here.

I am encoding my video using x264. For example:

x264.exe --bitrate 22500 --tune film --pass 1 --preset slow --bluray-compat
--vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 25 --slices 4 --tff
--colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --ssim --sar 1:1 -
o filename.264 01.avs

x264.exe --bitrate 22500 --tune film --pass 2 --preset slow --bluray-compat
--vbv-maxrate 40000 --vbv-bufsize 30000 --level 4.1 --keyint 25 --slices 4 --tff
--colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --ssim --sar 1:1 -
o filename.264 01.avs

Here is no --open-gop because "http://www.x264bluray.com/issues-with-certain-players" says "Adobe Encode CS5 has poor performance when --open-gop is enabled"
But Encore CS5 still can not work with this file. It freezes, hangs and closes.
Of course, 24Gb is very big, but my system is not very old: Core i7-920, 24Gb Ram and so on...

But if I remux this .264 file using tsMuxer to .m2ts - everything is ok. Is it only method, or i can do something else?
Thank you.
P.S. Encore CS5 sometimes works perfectly with --open-gop, but I do not understand, "why", and "when" it happens.
P.P.S. Sorry for my English.

[rallymax]

CS5.5 fixed some bugs in the 264 decoder - so update to that.
I use the settings you are using and CS5.5 Encore is happy. I also have --open-gop turned on.
A work around would be to change to x264_L-SMASH and output to .m4v* instead of .264. That muxing might help.
* I don't recommend that because I think it might break the blu-ray compatibility. It'll work but it won't pass bluray conformance tests.

But as I said, I have no problem doing exactly what you're doing using CS5.5 Encore.

[DiKey]

Thank you.
My Encore is 5.1.0.342 it is "CS 5.5" as I see...

I did not understand: soon programmers will be add .m4v export support to x264? Sounds good!

[Vurbal]

I've looked both here and on the x264 Blu-ray page for a definitive answer to this but haven't come up with anything. If I've just missed it feel free to call me an idiot and point me to the relevant information. :stupid:

I'm encoding 480p24 (720x480 @ 23.976fps) widescreen video. Since this doesn't require a significant bitrate I figure there's no reason not to set vbv-buffer to 15000 so I can also use a 2 second GOP. What I'm not sure about is what (if anything) needs to be adjusted to account for the required pulldown. I see 3 possible answers to this, and perhaps it's something else I haven't considered.

1. I'm over thinking the whole thing. The VBV buffer setting should be 15000 (or anything lower) and the field duplication from pulldown doesn't matter.

2. I need to reduce the VBV buffer by whatever amount is dictated by the duplicate fields because the buffer model comes into play after that point in the decoding process.

3. I need to reduce the VBV buffer even though the duplicated fields don't really have a practical effect on playback because authoring software may still reject them since it can't tell the difference between real fields and fields created using pulldown.

My experience with DVD authoring suggests either #2 or #3 is probably correct so I'm currently assuming I need to lower the buffer. On the other hand if there's one thing I've learned about Blu-ray authoring it's that sometimes you need to forget what you know about DVD to make sense of it.

Theoretically it shouldn't really make any difference because the bitrate should never need to approach 15000kbps for decent quality SD video. I could probably use a buffer size of 8000 most of the time without any visible difference and then pulldown should never matter. However that's at odds with my general philosophy on encoding which is to set the fewest restrictions possible and give the encoder maximum latitude in making its own decisions. Any video encoder that doesn't make better decisions than I would probably isn't worth using. If my video includes an outlier case where x264 just needs to throw more bits at a scene I'd like to make sure it has as much freedom to do that as possible.