x264 and slicing

[toboda]

Hi,

can anyone enlighten me about slicing in x264 encodes?
As already mention in a former post, I'm trying to generate
BR compliant streams from DPX files in 1920x1080.
After analysing material encoded with x264, one of the probs
that occured was, that the encoded pics consisted of only 1 slice but were supposed to consist of 4 (according to BR spec).
Is there any "switch" in x264 that let's me configure slicing? What could be the problem with a stream that only contains 1 slice per picture instead of 4? The encodes I made so far played fine on SA-Players and even Scenerists MUI Generator parses them without errors...

Thanks for your help!

[akupenguin]

There is no problem with 1 slice. Regardless of what you might have been told, even if you have read the spec with your own eyes, I don't believe multislice is really required. And if it is, I still won't consider that any reason to include support in x264.

[Gabriel_Bouvigne]

Could you please point us to the BR spec which requires the use of 4 slices?

[toboda]

I had a short file analysed by a replication facility and they reported back the problem with slicing. I questioned them as well, what exactly could happen to the final disc, if the pictures in the videostream have only 1 slice and not 4.
I'll let you know when they answer me.
The reason for all this is that quite a few people seemed to have probs to replicate their BRs due to uncomplianed video so I thought it would be a good idea to check beforehand.
I haven't seen the spec sheet myself thus I can just give to you what they told me.

Greetz

[Sagekilla]

The main reasons I can think of for an uncompliant stream is bad ref or B-Frame number choice, VBV over/underflows, and improper keyint / min keyint. I don't think slicing has anything to really do with it.

[LoRd_MuldeR]

Originally Posted by Sagekilla

The main reasons I can think of for an uncompliant stream is bad ref or B-Frame number choice, VBV over/underflows, and improper keyint / min keyint. I don't think slicing has anything to really do with it.

Well, maybe slices are required on BlueRay, because they want to make sure that decoders, which use slice-based multi-threading, can make use of their multi-threading capabilities. Such decoders may fail to decode 1-slice streams fast enough for smooth playback. That's at least the only reason I can think of to make 4 slices mandatory in the specs. However I don't know anything about the actual BR specs, so this is just a guess...

Are all "original" BR releases multi-sliced? If there's at least one that is not, we know that I can't be mandatory

[MrCommunistGen]

Originally Posted by LoRd_MuldeR

Are all "original" BR releases multi-sliced? If there's at least one that is not, we know that I can't be mandatory

Or that there are non-compliant discs out there.

-mcg

[Dark Shikari]

Originally Posted by MrCommunistGen

Or that there are non-compliant discs out there.

Oh, we already know this to be true. Many Blu-ray discs violate the MV range restriction in the spec.

[LoRd_MuldeR]

Standard compliant or not: If there's a significant number of none-sliced BR discs out there, then players will have to support them or customers will complain

And in that case it should be okay to produce none-sliced discs with "as-is" x264 ...

[benwaggoner]

Blu-ray does require slices with H.264 (VC-1 doesn't have that requirement for Bluray, which is one reason VC-1 is so popular with HD pogo stick competition highlight discs).

IIRC, it H.264 on Blu-ray requries at least 3 slices. It always struck me as odd that it was an odd number.

[Sulik]

Blu-ray requires 4 slices for level 4.1 content (less than 4 is allowed for level 4.0 and below)

[toboda]

Could you explain why this is required? As I already mentioned:
My encodes with x264 play without probs on SA-Players. The only reason I can think of is the following:
The copy protection on the replicated disc is so heavy on the decoding unit that it requires the picture to be sliced in order to allow fluent decoding of 4.1 material. Note that this is only
wild speculation. I still haven't got any feedback from the repliction facility, execpt that they're looking into it...

Greetz

[shon3i]

Originally Posted by toboda

Could you explain why this is required?

More slices, smother decoding, even on PC

[Dark Shikari]

Originally Posted by shon3i

More slices, smother decoding, even on PC

How so? DXVA decoding doesn't care about slices, and all good software decoders use frame-based multithreading, which is strictly superior to slice-based multithreading, performance-wise.

[shon3i]

Well nowdays on PC decoding is much easy, and most decoders know to use all resources, but on Blu-Ray SAP's slices are required.

[Tack]

Originally Posted by Dark Shikari

[...] and all good software decoders use frame-based multithreading, which is strictly superior to slice-based multithreading, performance-wise.

... still waiting for libavcodec to become a "good software decoder." Do we know when Alexander Strange's work will be completed (if necessary) and merged?

[Snowknight26]

dfps is the one that matters in LoRd_MuldeR's chart, right?

[LoRd_MuldeR]

Originally Posted by Snowknight26

dfps is the one that matters in LoRd_MuldeR's chart, right?

I think so. Also "real:" tells you how much time it actually took to decode the entire file. The less, the better.

[Willyfan]

As yoy say, the patch is not cleanly. Tomorrow morning I'll try to modify by hand the part unsuccesful.
Many thanks

[Sharktooth]

D_S is right. open source developement is quite different than commercial developement. ppl tend to not code stuff unless that stuff is strictly necessary.
if they add slicing to x264, ffmpeg-mt (frame based threaded decoding) will suddenly become useless (coz they already have slice based threaded decoding) and will be not completed/commited.
and since slicing will reduce the encoding quality, it's not an optimal solution since ppl will start to use slicing for multithreaded DECODING...