Muxing underflows with Scenarist/Blu-Print and possible solutions [resolved]

[shon3i]

UPDATE: After long testing, and Trahald's big help we found that my assumption about CBP Delay indeed is key solution for this problem

And we got confirmation that CBP delay indeed should not be greater than 1 second for Blu-Ray stream (9.5.1.3.4 in Blu-Ray specs). You can calculate simply dividing buffer and maxrate, which basicly means that buffer should never be greater than maxrate, but can be equal.

There is two soultion for this:

1. Use appropriate VBV settings (in Blu-Ray range), which means you need to use buffersize <=maxrate

2. Compile x264 with this patch x264_one_second_max_cpb_delay (http://forum.doom9.org/attachment.php?attachmentid=11255&d=1279050655) which do that math for you :)


I decided to open new thread for this to prevent OT in other.

Ok, what we have here is the situation where perfectly encoded stream with x264 (bd compatible), can't be muxed with one of famous Blu-Ray authoring tools, with error that stream have buffer underflow. After checking that stream with various tools, and all of them show that stream is completly underflow free, we arrive in a position to conclude the following:

1. muxing aplication have bug
2. there is something different when encode stream for blu-ray, some difference in HRD model and other stuff.

After five days of testing with various H264 encoders, i want to present observations.

Big thanks goes to jpsdr for sample that reproduce this situation.

On test i used 3 encoders, x264, Sony Blu-Code and Sonic Cinevision 3.0 which use Mainconcept SDK 8.4, i choose two Pro encoders that have function to encode only for Blu-Ray, and of course both passes muxing fine.

I use Elecard Buffer Analyser to measure HRD Graph.

x264

initial CBP removal relay : 1.80 sec
buffer size : 30 000 000 bits
declared bitrate : 15 000 000 bps
declared frame rate : 23.98 fps
bitrate type : VBR
padding : 0 bits

http://tom.niko.users.sbb.rs/hrd/hrd-x264.png

Cinevision

initial CBP removal relay : 1.00 sec
buffer size : 29 999 616 bits
declared bitrate : 14 999 808 bps
declared frame rate : 23.98 fps
bitrate type : VBR
padding : 0 bits

http://tom.niko.users.sbb.rs/hrd/hrd-cinevision.png

Blu-Code

initial CBP removal relay : 1.00 sec
buffer size : 30 000 000 bits
declared bitrate : 15 000 000 bps
declared frame rate : 23.98 fps
bitrate type : VBR
padding : 0 bits


http://tom.niko.users.sbb.rs/hrd/hrd-blucode.png

And i aslo test with Mainconcept SDK 8.5 encoder which give me same results as Cinevision, if i select bult-in Blu-Ray preset

initial CBP removal relay : 0.90 sec
buffer size : 29 999 616 bits
declared bitrate : 14 998 784 bps
declared frame rate : 23.98 fps
bitrate type : VBR
padding : 0 bits

http://tom.niko.users.sbb.rs/hrd/hrd-mainconceptbd.png

otherwise create HRD model simmilar to x264, and not pass muxing stage.

initial CBP removal relay : 1.80 sec
buffer size : 29 999 616 bits
declared bitrate : 14 998 784 bps
declared frame rate : 23.98 fps
bitrate type : VBR
padding : 0 bits

http://tom.niko.users.sbb.rs/hrd/hrd-mainconceptavc.png

it's obvious there is a some catch.

After searching i found that "initial CBP removal relay" is key for partial success. Values from 0.9-1.0 are acceptable.

I sucessfuly manage to change this with Mainconcept encoder and force 0.9, which make HRD model to have a smaller hump, also reducing buffer from 30000 to 15000 in x264 encode aslo creates 0.9 and make that encode sucessfully mux.

and this can maybe not work every time, because is not hard evidence, and is concluded based on only one source

Other Muxing applications like DoStudio or Tsmuxer, mux stream fine, but can have problem with BD verification tools, especialy tsmuxer.

If some want encoded stream with detailed parameters just p.m.

Thanks.

[Trahald]

initial cpb removal delay is setable.. its the buffer initial fullness. .9 (x264 default) on a 2 second gop is 1.8.. just set it to .50 for 1. I dont think it will help (would probably make it worse if the hard scene were closer to the beginning)

*edit* Should read 2 second buffer not 2 second GOP.

[shon3i]

initial cpb removal delay is setable.. its the buffer initial fullness. .9 (x264 default) on a 2 second gop is 1.8.. just set it to .50 for 1.
Well i tryed, but not work as i suppose. I don't think GOP length have no impact on this becuase if i set 1 sec gop or use x264 default gop (250) i will get CPB delay 1.80. But it has to do with the relationship between maxrate and buffersize. If i set buffer>maxrate i wil get higher than 1 sec of cpb removal delay, otherwise it's lower than 1 sec, or equal to 1 sec As you can see mc encoder produce same delay, when not touch fullness.

I dont think it will help (would probably make it worse if the hard scene were closer to the beginning) Exactly, even i get real underflows that reported in x264 log.

[shon3i]

Actually adjusting x264 cpb removal delay not change HRD model at all.

[chocolate elvis]

FYI, Sonic and Blu Print use the same muxer from Sony...

[Trahald]

What did you scan the cpb with (create the graph) I don't question the graph. Just curious.

As for main concept, it's hard to believe the initial fullness changed the curve somuch. The hard scene would still result in a spike unless some other setting were making bit allocation more conservative. At least I would think so.

[shon3i]

What did you scan the cpb with (create the graph) I don't question the graph. Just curious. Elecard Buffer Analyser, and Sony Stream Analyzer, both show same values/graphs.

it's hard to believe the initial fullness changed the curve somuchWell there is two options which control that. Inital Buffer Fullness and Target Buffer Fullness, through testing i didn't touch other settings, just these two. This options have impact on VBV model and because that HRD model is different. While x264 --vbv-init can change only cpb removal delay, but have no effect on encoder decisions.

btw this is aslo strange to me, that cpb removal delay with all encoders (x264, MC, Elecard, Ateme) if i set maxrate to 15000, and buffer 30000 come out as 1.80, while with BD encoders (Cinevision, Blu-Code, CCE-HDe) come out as 1.00 no matter what i set.

[shon3i]

After searching again, and find people who have similar problem, scenario is always same, low bitrate with suddenly spikes. These spikes should be somehow reduced.

[jpsdr]

On my sample, with a 28000kb buffer there is underflow error, but with 27000kb buffer, mux ok.

[Dark Shikari]

Is there or isn't there a buffer underflow error from x264? I'm finding it completely impossible to parse what you're saying.

[kieranrk]

What's bizzare is that shon3i has said in PM that it is the Transport Buffer that underflows which indicates it's a problem with the muxer.

[jpsdr]

Sorry, as we are in the thread about mux error in Scenarist, so, i wrongly think it was obvious that we are only talking about underflow error during mux in Scenarist.
I've until now NEVER had an underflow error reported by x264.

[shon3i]

New News:

I use stream that is muxed with DoStudio (kieranrk you sample) and i play on two BD Players (LG BD390, Panasonic BD35), both show little (hardly noticed) jitter on that position. I also notice that panasonic increase spinning of disc at this position, this basicly indicates problem in stream.

[jpsdr]

Was this message supposed to trig some kind of reaction...?:rolleyes:

[Trahald]

I think the issue is, even according to the cpb graphs that shon3i posted, x264 doesn't cause the cpb to overflow. The other encoders, probably to cater to scenarist have extremely conservative bitrate curves. The thing is unless there is definitive proof the stream is bad (and granted its hard to prove) the best we will do is a patch that will make a more conservative curve but likely wont be commited since it will be perceived as just to make scenarist (and anything that uses sonics engine) happy. I dunno when that patch will arrive. I dont know enough about the vbv code to quickly make one. Maybe someone else will. Until then, any stream causing the issue would require more conservative settings.

[shon3i]

just to make scenarist (and anything that uses sonics engine) happy.Not only problem with sonic engine, problem exist with all muxers, but only sonic engine prevent muxing because is to risky with high spikes/curves, and suttering is possible.

obviously that Blu-Ray need more smooth curves, and reason why "other" encoders folow that rule.

Maybe NAL-HRD switch need to get aslo sub option --nal-hrd bluray.

[kieranrk]

Maybe NAL-HRD switch need to get aslo sub option --nal-hrd bluray.

The problem is nobody has given us a definitive answer as to what's wrong. Everything in this thread is mere speculation.

Until we get a decent reason (e.g. from Blu-ray mailing list if such a thing exists or the likes) then there's not much we can really do.

[Trahald]

Here is a patch (i didnt test it in scenarist, just checked that it had a lower peak in elecard cpb analyzer) give it a shot...

all it does is lower the buffer size by 25% but writes sps and cpb values like its full size. There are no options attached so remember that if you decide to use it. Definition of hack below

[shon3i]

The problem is nobody has given us a definitive answer as to what's wrong. Everything in this thread is mere speculation.

Until we get a decent reason (e.g. from Blu-ray mailing list if such a thing exists or the likes) then there's not much we can really do. I know, but we here have four evidence from four completly different encoders, that workaround exist. For me that is enough, and if you willing to make something that can be ultimate resolution. This will can destroy x264 reputation as Blu-Ray encoder.

EDIT: Trahald please compile it, thanks.

[kieranrk]

I know, but we here have four evidence from four completly different encoders, that workaround exist. For me that is enough, and if you willing to make something that can be ultimate resolution. This will can destroy x264 reputation as Blu-Ray encoder.


I personally won't agree with a very dirty hack to fix this. I wouldn't consider it a workaround because a workaround "is a bypass of a recognized problem in a system" (wikipedia) and we don't actually know specifically what the problem is. You might say there's an "underflow" but in my opinion that's like trying to describe an engine fault as "car doesn't start". It's also worth saying it's the Transport Buffer that underflows which is only indirectly related to the bitstream x264 produces.

Elecard's reputation hasn't been destroyed. Bear in mind this is on a particularly difficult extended scene which most movies won't have.

[Trahald]

I want to make clear the patch I made shouldnt be patched for any type of general use (ie there should NOT be a build with it in it in the patches thread)... I'll put a binary out sometime tomorrow for anyone that wants to play w/it.

since this is seems to be relegated to 2 second gop, i dont think its as big an issue as you make it shoni3. And ultimately again, i could make a case for the changes in open gop based on the spec. I cant make a case for the changes for my hackity vbv patch for example.

can someone provide output from an established verifier that specifically says the stream is bad? (and more importantly what is bad about it)

[jpsdr]

Is there someone to give the stream to who can give a true technical answer ? Scenarist ? Elecard ? The ones who make the muxer used in Scenarist ?
Otherwise, as i've said, on the sample, with a buffer of 27000, there is no error during the mux (but there is still with 28000).
For me, the actual workaround is to encode with 27000. I hope it will still pass, beacause it's not beacause the sample pass, that the whole video will...

[kolak]

Is there someone to give the stream to who can give a true technical answer ? Scenarist ? Elecard ? The ones who make the muxer used in Scenarist ?
Otherwise, as i've said, on the sample, with a buffer of 27000, there is no error during the mux (but there is still with 28000).
For me, the actual workaround is to encode with 27000. I hope it will still pass, beacause it's not beacause the sample pass, that the whole video will...

Sony has made muxer and I don't think they are interested to make it working with x264. It does work, with no problems with all pro encoders and none of main authoring studios will use x264 untill we hear about possible problems, because no one will take responsibility for disc with jerky playback.

With all respect to x264 authors, I would look for a problem in the stream not in the muxer.

Andrew

[Trahald]

Tetras kieranks post. He's saying if it's x264, tell us what were doing wrong ( and more importantly back it up with a quote from the spec or output from a reputable analyzer) were stuck until someone does this. You must use 1 second GOP or conservative settings.

[jpsdr]

Sony has made muxer and I don't think they are interested to make it working with x264.
Andrew

I think x264 author don't ask Sony to make it work with x264, but to tell what is wrong.

[mp3dom]

I think x264 author don't ask Sony to make it work with x264, but to tell what is wrong.

Considering that Sony sell its own encoder, I don't think they will tell what's wrong.

[shon3i]

Elecard's reputation hasn't been destroyedWell elecard encoder i used earlier which aslo fail has no bult in Blu-Ray preset, and i am not sure if i maybe screw something, because some settings can't be adjusted through GUI which is very buggy.

But Mainconcept is good example that some difference or tecnical detail exist. If i not select Blu-Ray preset and if i use absolutely same setting, i will get stream that will not pass muxing. As we can see MC Blu-Ray preset reduce spikes. That's why i think we need something similar.

[kolak]

I think x264 author don't ask Sony to make it work with x264, but to tell what is wrong.

No chance.

Andrew

[Lyris]

Looks like we've run into a situation of "real world spec" versus "actual spec".

Remember the phrase "He who has the gold makes the rules"?

[mp3dom]

Looks like we've run into a situation of "real world spec" versus "actual spec".
Remember the phrase "He who has the gold makes the rules"?
Probably there are some reserved documents about in-depth technical specifications regarding ts muxing over/under flows or how to avoids it available only for certified companies or members of BD Association.
Surely if they allow low-price encoders to be "BD Certified" they wouldn't sell their encoder anymore at 40.000$. Anyway if you're making BD for money (aka it's your work) with 10-15 projects you can cover the cost of the pro-encoder and be on the "safe side".

[kolak]

Probably there are some reserved documents about in-depth technical specifications regarding ts muxing over/under flows or how to avoids it available only for certified companies or members of BD Association.
Surely if they allow low-price encoders to be "BD Certified" they wouldn't sell their encoder anymore at 40.000$. Anyway if you're making BD for money (aka it's your work) with 10-15 projects you can cover the cost of the pro-encoder and be on the "safe side".

I'm not aware of any hidden documentation- you need to implement exisiting one properly or work together with muxer developer.
I said this long time ago- BD compliant stream from x264 does not equal working muxing- welcome to real world of limitations :)


Andrew

[shon3i]

It's also worth saying it's the Transport Buffer that underflows which is only indirectly related to the bitstream x264 produces.Just one note, this is based on muxers that allow muxing, and have workaround for this, but can easily fail at verification process, which put this issue to beggining. Anyway i found earier mp3dom sample that after muxing with DoStudio or Tsmuxer (just checked), make muxing underflow (i can send you stream if mp3dom approves).

Probably there are some reserved documents about in-depth technical specifications regarding ts muxing over/under flows or how to avoids it available only for certified companies or members of BD Association.Here is what i found http://www.freepatentsonline.com/7139241.pdf but it's old and it's for MPEG2 only, i beleve something similar exist for new codecs. Since this is related to Transport Stream i pretty sure that BDA changed some rules for transport stream itself, and have some more restrictions like codecs have.

[jpsdr]

Yes !!!!!!!!!!!!
I've finaly been able to mux my whole blu-ray...

[shon3i]

Yes !!!!!!!!!!!!
I've finaly been able to mux my whole blu-ray...
What you do?

lower buffer or gop ?

[jpsdr]

I've lowered the buffer to 27000, all others settings stayed the same.

[Trahald]

http://www.mediafire.com/?mimznumzmon

Above is a binary with a patch that adds --one-sec-cpb-delay command. it limits the buffer to one second. blucode does the same thing (you can see from the graph in the first post it cuts off at 15k). blucode flags the stream at 2 seconds, but its cpb values all end at 1 second. Shon3i made an encode with a longer section of distortion and it basically flatlines at 1 second (15k) vbv. There is wording in the spec that may (or may not) explain the behavior.

The patch mimicks this. Since i dont see the point of having 2 seconds of vbv and only using 1 second, i simply make the vbv one second. (it would be simple to flag at 2 seconds but its honestly useless)

[Trahald]

P.S. This patch is based on observations of blucode and a guessed interpretation of a comment in the spec. Until i can substantiate it, it will remain un commitable.

oh and with the patch, '--open-gop bluray' automatically turns it on. (since the limitation is specific to bluray)

[shon3i]

Please compile it for testing :)

[Trahald]

There is a mediafire link in the post.

[shon3i]

It's not good i use bufsize 30000 and resulting stream at least in Elecard Buffer Analyser / Sony Stream Analyzer came as 15000 and with 0.9 sec buffer. But stream muxed/verifies successfully without errors/warnigns,same thing can be done if manualy set buffer to 15000, because on that way buffer is automatically ~1 sec.

[Trahald]

@shon3i
actually ..its working exactly as I intended. Look at blucodes cpb curve.. it only uses 15k (1 second) of the curve.. zoom in to see better. if all blucode does is use 1 second (15k) of cpb then having the other 15k there is wasted space.

if i hex edited the blucode stream buffer value to 15k, the elecard graph would look like x264s from the patch and yet the stream wouldnt decode any different. and the converse, I can easily make the patched x264 write 30k to the buffer size value, and the elecard cpb graph output would look similar to the original blucodes, but the actual video output when watching wouldnt be changed.

[shon3i]

I can easily make the patched x264 write 30k to the buffer size value, and the elecard cpb graph output would look similar to the original blucodes, but the actual video output when watching wouldnt be changed. You are absolutley right. But i would to see 30k buffer because i set it :), this can maybe confuse peoples, it's only cosmetics.

wow, it's look like we finaly have some logical answer for this.

[Trahald]

@shon3i
Thank you for your help in PM.

I still need to investigate further as my reasoning may be wrong, and even though if the ultimate answer produces results that are also <= 1 second, it is still best to solve the issue correctly.

[Trahald]

http://www.mediafire.com/?kajiikowdnz3uc0

Here is a version of the patch that flags buffer as the user requests but works with 1 second buffer max ala blucode. This is per shon3i's request

[Trahald]

validation of my suspicion by an industry insider (1 second vbv/cpb) -> https://forum.doom9.org/showthread.php?p=1125433#post1125433

[kieranrk]

validation of my suspicion by an industry insider (1 second vbv/cpb) -> https://forum.doom9.org/showthread.php?p=1125433#post1125433

This is very likely the reason behind all these problems and why there have been no reports using standard 1080p Blu-Ray settings (30mbit buffer/40mbit maxrate).

Also the restriction is mentioned implicitly in the spec as a 1-second STD delay as you mentioned.

[shon3i]

@Trahald many thanks, i tested patch and work like i expected. Just to confirm that sample now passes verification process without warnings/errors even with TsMuxer.

validation of my suspicion by an industry insider (1 second vbv/cpb) -> https://forum.doom9.org/showthread.p...33#post1125433

Also the restriction is mentioned implicitly in the spec as a 1-second STD delay as you mentioned.

Is this sufficient evidence? for making some workaround?

btw i need to more testning with 40k/30k maxrate/buffer. I currently found that comercial app's never go below 0.75 for vbv/cpb.
That's can explain why mp3dom sample underflows with 40k/30k maxrate/buffer

[Trahald]

The patch is a workaround. Version 2 should produce output like u want it. It has zero chance of being committed though. Since the issue is a special case for bluray.

As far as mp3doms case. It can only be addressed if a sample is produced that fails on a current version of x264.

[Trahald]

The patch is a workaround. Version 2 should produce output like u want it. It has zero chance of being committed though. Since the issue is a special case for bluray.

As far as mp3doms case. It can only be addressed if a sample is produced that fails on a current version of x264.

[jpsdr]

I don't understand : If it's something mandatory to be blu-ray compliant, specified on the spec, why can't it be commited ???
I mean, of course, activated only in some kind of Blu-Ray mode. Otherwise, you can't said that x264 produce Blu-Ray compliant stream, as this issue as been apparently identified. Note : I'm only talking about the 1 second thing, not the other point of 0.75 mentioned by shon3i.