Has anyone used X264 to produce a replicated BD title?

[Lyris]

First of all: I apologize if this question has already been asked. However, I don't think there has ever been a central thread asking this question.

Have any Blu-ray Disc authors out there produced titles encoded using X264 (perhaps one of the various patched versions), and had its output verified and passed by a replication facility? The reason I ask is because in the coming months, I will be working on a retail BD title and if it's possible to use X264, I would absolutely love to do it due to the quality of its output.

My other option is the upcoming Netblender DoStudio Workflow Edition, comes with an integrated AVC encoder. Even although at BD bitrates, the differences can be less obvious, I still want to use the absolute best quality option within the allocated budget. The big draw of this is that its output is guaranteed to be compatible.

Lastly, to the developers of x264: thank you for this wonderful encoder and everything that you do for free. I realise that as a highly scalable system, BD compliance is not at the top of you priorities in producing an h.264 encoder. But if anyone can pitch in, I'd be very grateful!

[LoRd_MuldeR]

x264 can't produce streams that are 100% conform to the BD specs, because as far as we know the BD specs say that at least 4 slices are required. But x264 doesn't use slices currently.

[Dark Shikari]

Originally Posted by LoRd_MuldeR

x264 can't produce streams that are 100% conform to the BD specs, because as far as we know the BD specs say that at least 4 slices are required. But x264 doesn't use slices currently.

There's a patch that adds slicing support, though the author still hasn't sent to me the version he promised...

[Lyris]

Could it be the versions found here? I've used it to produce streams that certainly play on the players I have here, but not with consistent success...

http://skystrife.com/x264/?C=M;O=A

[Chengbin]

Are you telling me that I can't encode a video with x264 in the BD's allowed maximum H.264 settings and it won't play on a Blu-ray player?

Lyris, THANK YOU for choosing x264 to encode your next blu-ray title. After you're done with it, could you tell us the title of the movie you produced? I might buy that Blu-ray just to see what "real" 1080p looks like without low passing.

[LoRd_MuldeR]

Originally Posted by Lyris

Could it be the versions found here? I've used it to produce streams that certainly play on the players I have here, but not with consistent success...

http://skystrife.com/x264/?C=M;O=A

I don't think so. I guess the patch mention by Dark Shikari was never released to the public -or- the (early) version released was not working properly yet.

Originally Posted by Chengbin

Are you telling me that I can't encode a video with x264 in the BD's allowed maximum H.264 settings and it won't play on a Blu-ray drive?

The drive shouldn't be the problem

However a H.264 decoder that is strictly limited to the BD specs may fail to decode streams produced by current x264.

Consequently a BD authoring software, which checks the H.264 streams against the BD specs (and not against "real" implementations), would have to reject x264's streams.

Anyway, as far as I know most (all?) the BD players that exist in reality would handle those streams just fine. It only can't be guaranteed...

[nixo]

You could always use level 4.0. I've been told that doesn't require slices to be BD compliant.

--
Nikolaj

[JEEB]

The patch for 1195 can be found on the mailing list here, but since D_S says "...though the author still hasn't sent to me the version he promised..." I'd think it'd be ok for you to be somewhat wary of it albeit he says he has been using it for a while...

Anyways, nice to hear that people are interested in using x264 with blu-ray manufacturing.

[Lyris]

Chengbin: I'll gladly share details and the production process once it's out there, yes. However, there are thankfully a lot of unfiltered AVC titles out there - all of the Disney titles I've seen seem to have got through unmolested. Low-passed BD titles are thankfully the exception rather than the norm.

Are you telling me that I can't encode a video with x264 in the BD's allowed maximum H.264 settings and it won't play on a Blu-ray drive?

Professional authoring software scrutinizes every part of the input file. By default, the output of X264 is rejected. Lord_Mulder has explained the whole situation.

When you're stamping out thousands of discs for a title that is probably going to get some attention, it "maybe" working fine on "most" BD players isn't enough for me to sleep easy!

Nixo: is 4.0 allowed on BD? What are the limitations of it when compared to 4.1?

[Guest]

Originally Posted by nixo

You could always use level 4.0. I've been told that doesn't require slices to be BD compliant.

Correct. From the spec:

9.5.1.3.1 Parameter limits

[...]
If level_idc in SPS indicates level 4.1, each picture shall be encoded as multi-slice picture with 4 or
more slices per picture. The number of macroblocks in any slice shall not exceed 1/2 of the total
number of macroblocks. The number of macroblock rows in every slice in the picture should be as
equal as possible for the current picture height and interlace coding mode.

* In case of 1920x1080 video format with frame_mbs_only_flag=1, it is recommended that
each slice has 17 macroblock rows (17/17/17/17 configuration).

* In case of 1920x1080 video format with frame_mbs_only_flag=0 and
mb_adaptive_frame_field_flag=0, it is recommended that in each field, odd numbered slices
have 8 macroblock rows each and even numbered slices have 9 macroblock rows each
(8/9/8/9 configuration) or some similar configuration.

* In case of 1920x1080 video format with frame_mbs_only_flag=0 and
mb_adaptive_frame_field_flag=1, it is recommended that odd numbered slices have 16
macroblock rows each and even numbered slices have 18 macroblock rows each
(16/18/16/18 configuration) or some similar configuration.

* In case of 1280x720 video format, it is recommended that four slices have 11/11/11/12 or
some similar configuration.

[nixo]

Originally Posted by Lyris

Nixo: is 4.0 allowed on BD? What are the limitations of it when compared to 4.1?

As far as I know the limitations are really just a bit lower max bitrate (--vbv-maxrate 25000).

--
Nikolaj

[Lyris]

Very interesting - but according to x264, Level 4.0 has an upper bitrate limit of 25mbps, which I'd like to avoid.

Edit: you got there before me - 4.1 is something I'd really like to use, but your suggestion is one possibility.

[Lyris]

Well, here's hoping that the quality of the AVC encoder in DoStudio Workflow will be comparable to x264 at BD bitrates. The coded material is going to be razor-sharp (4K DI sourced from a RED One) and probably handheld and free-moving so hopefully things can hold up. I'll post some comparisons of the two encoders' output when I can.

[Chengbin]

In case if you don't know, weight-p will be available soon (hopefully), and according to Dark Shikari on the SoC page, it has the "potential to significantly improve encoding quality"

I want to ask a question. BD specs say the video needs 4 slices. When they refer to slices, do they mean the multithreading technique? If it is, I thought at 4 slices, PSNR is already -1dB?

BTW, lyris, you're the man. Thanks for doing this for us. I'm curious of how a $3000 (!!!) software compare with x264. If you don't mind asking, does the company provide you with software, or do you have to pay for the software yourself?

[Lyris]

Will that do anything to help compatibility, though?

[Chengbin]

Originally Posted by Lyris

Will that do anything to help compatibility, though?

No, just picture quality (especially with mb-tree during fades)

[LoRd_MuldeR]

Originally Posted by Chengbin

I want to ask a question. BD specs say the video needs 4 slices. When they refer to slices, do they mean the multithreading technique? If it is, I thought at 4 slices, PSNR is already -1dB?

With "Slices" they mean that each frame should consist of at least 4 slices (parts), that can be decoded/processed independently.

If a stream consists of several slices, this allows (but doesn't enforce) slice-level multi-threading.

So if an encoder relies on slice-level multi-threading, but the stream doesn't consist of several slices, that encoder will fail to decode the stream (at an acceptable speed).

I guess they included the "4 slices" requirement in the BD specs, because they wanted to make sure that even such decoders will be able to decode the BD streams.

Anyway, all the state-of-the-art H.264 decoders (ffmpeg-MT, CoreAVC, DivX H.264, etc.) use frame-level multi-treading and hence work with single-slice streams just fine.

It appears that also the hardware decoders used in "stand-alone" BD players are capable of decoding Level 4.1 H.264 streams without multiple slices.

Also it was found that slices reduce compressibility. In case of x264 the loss was around -0.1 PSNR for 4 slices (link). And: The more slices/threads, the bigger the loss!

Frame-based multi-threading not only gives more speed-up, also the loss in quality/compressibility is very small - even at high number of threads.

[Lyris]

If you don't mind asking, does the company provide you with software, or do you have to pay for the software yourself?

There's the possibility of both (or a combination). I'm a freelance author right now so there's nothing set in stone.

Regarding how a $3000 encoder is going to compare to x264: one of the most respected names in the video world said that none of the main studio's encoders matched the quality of x264. Certainly, on most BD titles, I can see small compression artefacts that I don't see on (quite grainy) test encodes I've done. I imagine this is the "speed over quality" argument again.

Oh, if anyone wants to buy me a copy of Cinema Craft HD, I will gladly try that out

[Chengbin]

Could the quality difference be the fact that x264 does not use slices, where the commercial encoders must?

[Sagekilla]

No, slices can make a difference but they shouldn't be that huge of a difference. If it is, they're doing their slicing horribly wrong.

Most of the difference comes from the various rate control and RDO algorithms x264 uses: MB Tree, trellis, psy-rd, aq, etc.