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]

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]

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. :eek:

-mcg

[Dark Shikari]

Or that there are non-compliant discs out there. :eek: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]

Could you explain why this is required?More slices, smother decoding, even on PC

[Dark Shikari]

More slices, smother decoding, even on PCHow 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]

[...] 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?

[Dark Shikari]

... still waiting for libavcodec to become a "good software decoder."Indeed :p Do we know when Alexander Strange's work will be completed (if necessary) and merged?Talk to him about it. I know he recently updated it to patch on latest ffmpeg trunk.

[LoRd_MuldeR]

... 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?

Check out ffmpeg-mt, there is some great speed improvement in ffdshow-mt builds already! :cool:

E:\HD\Crowd Run 2160p UHD CRF22 x264-CtrlHD.mkv

[ffdshow r2301]
User: 7s, kernel: 2s, total: 10s, real: 80s, fps: 50.0, dfps: 6.2
User: 8s, kernel: 1s, total: 9s, real: 87s, fps: 50.8, dfps: 5.7
User: 7s, kernel: 2s, total: 9s, real: 79s, fps: 50.2, dfps: 6.3

[ffdshow-mt r2307]
User: 8s, kernel: 0s, total: 8s, real: 37s, fps: 61.8, dfps: 13.4
User: 8s, kernel: 0s, total: 8s, real: 37s, fps: 61.5, dfps: 13.5
User: 7s, kernel: 0s, total: 8s, real: 37s, fps: 62.5, dfps: 13.5

[DivX H.264 Dec Beta-3]
User: 3s, kernel: 0s, total: 4s, real: 28s, fps: 122.1, dfps: 17.4
User: 3s, kernel: 0s, total: 3s, real: 28s, fps: 126.0, dfps: 17.4
User: 3s, kernel: 0s, total: 4s, real: 28s, fps: 125.0, dfps: 17.3

[CoreAVC Decoder 1.8.5]
No numbers available, because CoreAVC refuses to play this file

[shon3i]

@Dark Shikari, what about slice patch which done by Mojtaba Hosseini/Etienne Bomcke?, can be improved?

[Dark Shikari]

@Dark Shikari, what about slice patch which done by Mojtaba Hosseini/Etienne Bomcke?, can be improved?I will not probably commit a slicing patch until ffmpeg-mt is merged to trunk.

I do not want people using slicing for parallelism.

[Snowknight26]

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

[LoRd_MuldeR]

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.

[shon3i]

I will not probably commit a slicing patch until ffmpeg-mt is merged to trunk.

I do not want people using slicing for parallelism.
Why? ffmpeg-mt is usless because we have cheap and very powerfull dual Core Processors, and very cheap DXVA graphics card's, which can handle all HD material easly. Slices encoding is needed for Blu-Ray, and their parallelism on SAP.

[Dark Shikari]

Why? ffmpeg-mt is usless because we have cheap and very powerfull dual Core Processors, and very cheap DXVA graphics card's, which can handle all HD material easly. Slices encoding is needed for Blu-Ray, and their parallelism on SAP.Because you know that the primary use of it will be by people who want to improve performance of their encoders on lower-end machines.

And so everyone will start using it, people will start requiring it for rips of various sorts, and we'll never get ffmpeg-mt merged to trunk.

[LoRd_MuldeR]

Why? ffmpeg-mt is usless because we have cheap and very powerfull dual Core Processors,
Uhm? ffmpeg-mt is great, because we have cheap Dual Core and Quad Core processors! It doesn't require slices...

[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...

[LoRd_MuldeR]

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 will suddenly become useless (coz they already have slice based threaded decoding) and will be not completed/commited.

I really hope we won't see slicing back in x264 :eek:

[Sharktooth]

slicing is usefull, but ffmpeg-mt is more important.
first they release frame based threaded decoding, then slices could be implemented into x264.

[LoRd_MuldeR]

slicing is usefull, but ffmpeg-mt is more important.
first they release frame based threaded decoding, then slices could be implemented into x264.

Why is slicing useful?

We already have frame-based multi-threading on the encoder side, which scales excellent and compresses more efficient than any sliced-based multi-threading.
And thanks to ffmpeg-mt we will have an OpenSource H.264 decoder with frame-based multi-threading very soon (in fact you can use ffdshow-mt right now).

I really see no reason to support slices nowadays...

[Dark Shikari]

Why is slicing useful?

We already have frame-based multi-threading on the encoder side, which scales excellent and compresses more efficient than any sliced-based multi-threading.
And thanks to ffmpeg-mt we will have an OpenSource H.264 decoder with frame-based multi-threading very soon (in fact you can use ffdshow-mt right now).

I really see no reason to support slices nowadays..."Slicing" does not imply "slice-based multithreading."

[LoRd_MuldeR]

"Slicing" does not imply "slice-based multithreading."

Yes. But what would be the reason to use slices if you don't need/use them for multi-threading, which we definitely do not (neither on the encoder nor on the decoder side) ??? :confused:

Also slices hurt encoding efficiency even if you don't use them for multi-threading, right?

[Sharktooth]

error resilience

[LoRd_MuldeR]

error resilience

That really would only be of interest for broadcasting...

[Sharktooth]

not only for that. one of the blu-ray big points is error resistence/resilience.

[LoRd_MuldeR]

not only for that. one of the blu-ray big points is error resistence/resilience.

Damn, how prone to damage are those discs?

[kolak]

As far as I know all PRO encoders do 4 slices.
Scenarist/Blu-print won't flag (99% sure) slicing problem, but Sony's verifier will.
I think all players will play fine AVC with 1 slice.


Andrew

[toboda]

I now got some feedback from the replication plant and that's what their video verifier had to say about th x264 encoded material (lvl4.1 single sliced)

Error1: Fail to read NAL unit of MPEG4 AVC stream
Error2: Fail to parse access unit of MPEG4 AVC stream

Can anyone clarify these error messages for me? Could error1 be due to the slicing thingie?

Thanks for your help!

[Sharktooth]

no... you produced the stream without a NAL/HRD patched x264 build.
x264 does NOT produce blu-ray compatible streams by default...

[LoRd_MuldeR]

no... you produced the stream without a NAL/HRD patched x264 build.
x264 does NOT produce blu-ray compatible streams by default...

Toboda, try this build, which contains the patch:
http://forum.doom9.org/showpost.php?p=1213911&postcount=1360

[check]

[CoreAVC Decoder 1.8.5]
No numbers available, because CoreAVC refuses to play this file[/CODE]
What's the point of this test if you won't compare ffdshow against its main competitor?

[LoRd_MuldeR]

What's the point of this test if you won't compare ffdshow against its main competitor?

It proves that ffdhow-mt handles files that CoreAVC cannot decode at all. Also I had DivX in the test, which is a pretty fast competitor too.

But to complete the test, I will run a new test with another sample...

[LoRd_MuldeR]

Here we go:

E:\HD\PlanetEarthSample_1080p.mkv

[ffdshow ICL r2335]
User: 42s, kernel: 10s, total: 53s, real: 277s, fps: 188.7, dfps: 36.1
User: 42s, kernel: 8s, total: 50s, real: 282s, fps: 197.4, dfps: 35.4 <-- 100%
User: 41s, kernel: 9s, total: 51s, real: 285s, fps: 194.6, dfps: 35.0

[ffdshow-mt r2333]
User: 40s, kernel: 0s, total: 40s, real: 93s, fps: 246.2, dfps: 106.8
User: 41s, kernel: 0s, total: 41s, real: 93s, fps: 240.3, dfps: 106.8 <-- 302%
User: 39s, kernel: 0s, total: 39s, real: 93s, fps: 251.5, dfps: 106.7

[CoreAVC v1.8.5]
User: 17s, kernel: 0s, total: 17s, real: 70s, fps: 586.1, dfps: 142.0
User: 18s, kernel: 0s, total: 18s, real: 70s, fps: 542.8, dfps: 142.3 <-- 402%
User: 17s, kernel: 0s, total: 17s, real: 70s, fps: 566.9, dfps: 142.4

[DivX H.264 Decoder Beta-3]
User: 26s, kernel: 0s, total: 26s, real: 62s, fps: 375.8, dfps: 160.6
User: 22s, kernel: 0s, total: 22s, real: 62s, fps: 441.1, dfps: 160.9 <-- 455%
User: 20s, kernel: 0s, total: 20s, real: 61s, fps: 478.3, dfps: 163.6


Conclusion:
DivX H.264 > CoreAVC > ffdshow-mt >> ffdshow

Surprising that DivX H.264 is actually faster than CoreAVC on that sample. Again we see the enormous improvements in ffdshow-mt/ffmpeg-mt :cool:

Also ffdshow-mt allows "real time" playback of this 1080p sample, which is the most important point I think :)

[toboda]

Thanks Lord Mulder for the link. :thanks: I'm testing Inlets Fathom encoder atm although I'd love to use x264 for this project.

[toboda]

Do I have to set special options to enable NAL or is it just happening when I use the patched version with megui?
Thx

[shon3i]

Do I have to set special options to enable NAL or is it just happening when I use the patched version with megui?
Thx
you need to put on extra commandline options -nal-hrd ;)

[kemuri-_9]

you need to put on extra commandline options -nal-hrd ;)

--nal-hrd also depends on vbv being active,
but you should already have that enabled if you're encoding for BD

[Sharktooth]

Do I have to set special options to enable NAL or is it just happening when I use the patched version with megui?
Thx
if you're going to use megui, it already comes with a patched version of x264 AND blu-ray presets ... ;)

[Willyfan]

As far as I know all PRO encoders do 4 slices.
Scenarist/Blu-print won't flag (99% sure) slicing problem, but Sony's verifier will.


Scenarist check during the import file step the file compliance, and x264 files are NOT COMPLIANT with bluray specs, because bluray need 4 slices in 4.1 level. I not understand why the people here don't want slices in x264: Is possible to add a parameter for number of slices. For all people don't like slices, the default can be "1". Beside, is not necessary to use slices for multithread encoding (but is necessary for decoding, I guess, expecially on first generation bluray player).
William

[Dark Shikari]

Scenarist check during the import file step the file compliance, and x264 files are NOT COMPLIANT with bluray specs, because bluray need 4 slices in 4.1 level. I not understand why the people here don't want slices in x264: Is possible to add a parameter for number of slices. For all people don't like slices, the default can be "1". Beside, is not necessary to use slices for multithread encoding (but is necessary for decoding, I guess, expecially on first generation bluray player).
WilliamAs I have said, I will consider adding slicing support to x264 when ffmpeg-mt is committed. I simply do not want to risk creating an environment where people consider slicing to be an obligatory part of creating an ordinary video with x264. Such a thing creates even less of an incentive for decoder developers to include useful multithreading capabilities and needlessly cripples compression, if only a little.

I might reconsider if someone can find me a Blu-ray player that can't play an unsliced stream.

[Willyfan]

As I have said, I will consider adding slicing support to x264 when ffmpeg-mt is committed.
......
I might reconsider if someone can find me a Blu-ray player that can't play an unsliced stream.

It's hard to find a bluray player that can't play unsliced stream, because actually is impossible (with professional products) author a bluray with unsliced stream. I'm using Scenarist, and Scenarist DON'T IMPORT in the scenario a x264 file, so I can't try to make a bluray disk in order to find the bluray player that don't work with that disk.
Anyway, when slicing support will be added to x264 I'll be very happy to try H264 files generated with x264. I'm very interested to x264 for speed and quality. Actually I'm using a VC1 encoder, written "in house" using mainconcept SDK, And I'll like to compare the quality of this 2 encoders.