Blu Ray compatibility

[iSeries]

Hi all,

Just wondered if someone could reassure me that the following is completely blu ray compatible, before I start getting serious about backing everything up (and maybe some suggestions if it could be improved):

--preset slow --level 4.1 --tune film --ref 4 --b-pyramid strict --open-gop bluray --weightp 0 --qpmin=0 --sar 1:1 --aud --nal-hrd vbr --pic-struct --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 40000 --threads auto --slices 4 --thread-input

Thanks!

[nurbs]

You are missing --bframes 3. Apart from that it should work if the resolution is correct and you output .264.

edit: OK, --preset slow only uses 3 b-frames so you aren't actually missing anything.

[rack04]

You are missing --bframes 3. Apart from that it should work if the resolution is correct and you output .264.

edit: OK, --preset slow only uses 3 b-frames so you aren't actually missing anything.

I would recommend setting --brames 3. That way you wont have to worry later on if you decide to use --preset veryslow or placebo or --tune animation.

[shon3i]

You can remove --min-keyint 1 from cmd.

[poisondeathray]

and pbratio doesn't do anything when mbtree is used , so you could remove --pbratio 1.1

[iSeries]

Thanks guys!

@ shon3i - is --min-keyint 1 automatically set, or is just because I don't need to worry about this (I was under the impression that it was needed).

So - to summarise: remove --min-keyint 1 and --pbratio 1.1, add --bframes 3, and I'm good to go?

[nurbs]

--min-keyint 1 isn't needed and with --keyint 24 you automatically get --min-keyint 2.

[iSeries]

Nurbs - I thought you could only use --min-keyint 2 with a --vbv-maxrate of <15000?

[nurbs]

No. You can only use a keyint of 2 seconds (--keyint 48 for instance) if --vbv-maxrate <15000. There are no requirements for the minimum at all. Look at the sticky (http://forum.doom9.org/showthread.php?t=154533).

[iSeries]

Ok thanks Nurbs - is there any difference really between --min-keyint 1 and --min-keyint 2? I had noticed that BD Rebuilder uses --min-keyint 1.

[nurbs]

Even if you set it to 1 it's unlikely that there would be two I frames next to each other. You can set it to 1 if you want. It's just one of the things that don't really matter and leaving it out makes the command line shorter :)

[shon3i]

You should newer touch --min-keyint option, leave it on default, x264 encoder will decide what is best for you.

[iSeries]

Thanks again all. So - going forward, the following will give me a decent blu ray compatible encode?

--preset slow --level 4.1 --tune film --ref 4 --bframes 3 --b-pyramid strict --open-gop bluray --weightp 0 --qpmin=0 --sar 1:1 --aud --nal-hrd vbr --pic-struct --keyint 24 --ipratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 40000 --threads auto --slices 4 --thread-input

[poisondeathray]

--ipratio 1.1 -- --vbv-bufsize 30000


you forgot to delete the extra "--" in between ipration and vbv-bufsize

[iSeries]

Poisondeathray - yep, edited. How about now.

[henryho_hk]

"--keyint 24" is really pumping up the encoded size by a vast amount. That's why we need over 20GB for a Bluray encode.

[Blue_MiSfit]

All in the name of top notch seeking / trick play performance 0_0 fail...

[nurbs]

It also helps with fast forwarding, as does --b-pyramid strict. I can remember reading here that the loss of compression efficiency from the short keyframe interval is not much more than 10%. That's not that bad.

[iSeries]

Sorry, one more question - is '--partitions all' ok to use when encoding for blu ray?

[nurbs]

Yes. (filler)

[henryho_hk]

the loss of compression efficiency from the short keyframe interval is not much more than 10%.

I've just tested a TGMC-placebo-bobbed DVD source with:

--crf 20.5 --profile high --preset veryslow --tune film --weightp 0 --ref 3 --bframes 3 --nal-hrd vbr --vbv-maxrate 31250 --vbv-bufsize 30000 --level 4.1 --b-pyramid strict --open-gop bluray --slices 4 --pic-struct --aud --ipratio 1.1 --pbratio 1.1

1975kbps with "--keyint 24" and 1678kbps without it. That's nearly 18%.

[nurbs]

The meaning of CRF changes when you change options, so the change in bitrate doesn't really tell you anything. We've had the discussion about not being able to tell how much compression efficiency changes with CRF encodes literally a hundred times already.

Furthermore I was only talking about the short keyframe interval. Slices had been removed, --b-pyramid strict wasn't implemented yet and --weightp and --open-gop didn't exist at all when I read this.

[poisondeathray]

Also, there is a maximum limit (2sec gop) for blu-ray , with appropriate adjusted settings including changes in vbv . Default --keyint would be 250 which is illegal . And a bit besides the point , but a bobbed source wouldn't be SD blu-ray legal either

[iSeries]

Hi,

I took out --min-keyint 1 as advised and encoded. When done I checked in Media Info and it says keyint_min=13 and not 2 as I was led to expect when setting --keyint 24. This is ok, right?

[Blue_MiSfit]

Hi,

I took out --min-keyint 1 as advised and encoded. When done I checked in Media Info and it says keyint_min=13 and not 2 as I was led to expect when setting --keyint 24. This is ok, right?


Yes, I believe that's fine. Of course, only running the stream through a BluRay analyzer will tell you FOR SURE if it's OK ;)

When comparing compression efficiency from an objective perspective, switch --tune film to --tune psnr or --tune ssim. Also make sure you add --psnr or --ssim so that x264 will actually calculate these metrics.

Of course the outputs won't look as good as --tune film since you're disabling all Psy optimizations, but you're trying to measure the efficiency impact of short GOPs.

Cheers!
Derek

[Dark Shikari]

Hi,

I took out --min-keyint 1 as advised and encoded. When done I checked in Media Info and it says keyint_min=13 and not 2 as I was led to expect when setting --keyint 24. This is ok, right?No, this means your x264 is too old.

[Blue_MiSfit]

BTW, I did a test with Parkjoy using BluRay settings from kieranrk http://sites.google.com/site/x264bluray/home/1080i-p and then another test using the same settings except allowing keyint 500, and got about an 8% difference in PSNR using --preset medium.

This test was with the source simply slowed down to 25p. To get BluRay compatible 50hz motion, I interlace the source to 1080i50 and again used kieranrk's settings, and got a 4% difference.

Granted, Parkjoy is a very short test clip, but it's at least a data point :p

Derek

[nurbs]

@iSeries:
You should definitely update your x264 version. Yours is older than r1537. That means it doesn't include open-gop, unless it's patched, but in that case don't expect it to be really Blu Ray compatible.

[iSeries]

Too old? Hmm its the one that came with the latest version of RipBot264. How can I tell what version it is?

[Groucho2004]

How can I tell what version it is?

x264 --version

Too old? Hmm its the one that came with the latest version of RipBot264.

Why on earth would you use that version???

[iSeries]

Why on earth wouldn't I?

Here's what I get when I run --version:


C:\Program Files\RipBot264\Tools\x264>x264_
x264 0.105.1732 2b04482
built on Sep 28 2010, gcc: 4.4.4
configuration: --bit-depth=8
x264 license: GPL version 2 or later
libavformat license: GPL version 2 or later

[Groucho2004]

Why on earth wouldn't I?

It's like a box of chocolates...


Just download the latest version (1745) from http://x264.nl/

[iSeries]

Ok I can download the latest version no problem - however as you can see the version I have is clearly not older than r1537?

[Groucho2004]

however as you can see the version I have is clearly not older than r1537?

I didn't say that. :)

[iSeries]

Nurbs did - and you didn't disagree :D

[Groucho2004]

Nurbs did - and you didn't disagree :D

Post the complete MediaInfo report where it reports "keyint_min=13".

[iSeries]

cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=9 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=2 / weightp=0 / keyint=24 / keyint_min=13 / scenecut=40 / intra_refresh=0 / rc_lookahead=24 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / vbv_maxrate=40000 / vbv_bufsize=30000 / crf_max=0.0 / ip_ratio=1.10 / aq=1:1.00 / nal_hrd=vbr

I used this command:

--preset medium --level 4.1 --tune film --ref 4 --b-pyramid strict --weightp 0 --direct auto --partitions all --open-gop bluray --qpmin=0 --sar 1:1 --aud --nal-hrd vbr --pic-struct --keyint 24 --ipratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 40000 --threads auto --slices 4 --thread-input

If I just explicitly state min keyint in the command, whats better, min keyint 1 or min keyint 2?

[Groucho2004]

What does it say under "writing library"?

[iSeries]

Writing library : x264 core 105 r1732 2b04482

[Groucho2004]

Hm, no idea. "keyint_min" should be something like 2 @"keyint=24" with that version.
Maybe DS can shed some light on this.

[iSeries]

What would be the difference between explicility stating --min-keyint 2 which apparently is the default for keyint=24 (except for me lol), and --min-keyint 1 (which is what BD Rebuilder uses)?

[nurbs]

There would be no real difference.
The default minimum keyframe interval is keyint/10 ever since rev 1537.

[kemuri-_9]

obviously something else is setting the min-keyint parameter as when keyint is 24, the maximum allowed min-keyint value is 13 (keyint/2+1), which is what you're experiencing.

[iSeries]

No idea whats going on but I've added min keyint 2 to the command line and all is good. I wouldn't mind any suggestions as to why BD Rebuilder uses min keyint 1 and not the default though?

[nurbs]

You'll have to ask jdobbs.
My guess would be it was added before x264 automatically chose the minimum keyframe interval and simply not changed afterwards since it doesn't really matter.

[laserfan]

Often I find that the chapter markers on BD discs are off by a frame (or two) from the scene change point. Then if you use these same chapter points following a re-encode with x264, x264 will place an I-frame at the exact scene change point, and if using qpfile and original chapter points it wants to put another I frame immediately adjacent to the scene change I frame. Maybe --min-keyint 1 intends to allow that?

[MasterNobody]

Often I find that the chapter markers on BD discs are off by a frame (or two) from the scene change point. Then if you use these same chapter points following a re-encode with x264, x264 will place an I-frame at the exact scene change point, and if using qpfile and original chapter points it wants to put another I frame immediately adjacent to the scene change I frame. Maybe --min-keyint 1 intends to allow that?
IIRC forced frame-types (by using QP-file) not influenced by --min-keyint value so it would be IDR-frame even if distance from previous is smaller then --min-keyint.