Understanding and calculating the VBV for MVC encoding (buffer underflows)

[RajaSteve]

Hi,

I think I'm doing something wrong in the VBV departement of encoding a MVC 3D Blu-ray. Please hear me out.

I was trying to author a 3D Blu-ray that I encoded myself. Muxing failed because of a buffer underflow. I did some reading up, and at first, I thought I needed to lower my bitrate, as buffer underflows are said to usually be caused by too high bitrates. My total transfer rate is 59,06 Mbps, 30 for the base left eye, 17 for the dependant right eye, 3900 Kbps each for 2 Atmos tracks, 768 Kbps for a Dolby Digital Plus 7.1 track, and 640 Kbps for a normal Dolby Digital 5.1 track, with the rest going to the subtitles.

So I started looking at the BDinfo for a couple existing 3D discs of about the same length to find what a good bitrate for my video would be, and one of them had an even higher bitrate and transfer rate! It had a little over 35 Mbps for the left eye, about 17 for the right eye, 3828 Kbps for a DTS-HD MA track, and 384 Kbps each for two Dolby Stereo tracks, totalling to 60,51 Mbps, with the rest going to the subtitles.

Then I read somewhere that for 3D Blu-ray, the max peak bitrate is 60 instead of the usual 40 for 2D discs. In which case I should be fine. So, at first I thought it was just the authoring program I used being more strict than what was used to author that disc. To find out if this was indeed the case, I demuxed the base and dependant views and the DTS-HD audio of that disc, and tried to author that the same way as my project. I expected to get the same buffer underflow error, but much to my surprise, I didn't! It actually worked.

So I started thinking it might be the VBV size. Maybe they were too small. I did some reading up, and found that usually, 30 Mbps VBV with a max bitrate of 40 is preferred for a 2D disc, but the thing is, I did actually used a VBV of 30 for both the base and dependant views. Shouldn't that be okay? Even a bit too high for the right eye?

I tried to find the answer through bitrate calculators and such, but none of them seem to take 3D into account. Anyone here knows a good way to find the right VBV size for a 3D encode? Or maybe something else I'm doing wrong? Is it maybe because of the higher number of audio channels? (The other disc had more stereo tracks, where with my project all audio is at least 5.1) My total transfer rate of 59,06 is lower than that existing disc's 60,51, so I'm kinda confused as to why my project gets the buffer underflow error. If I mux the project with TSMuxer, it muxes just fine. The result works fine in PowerDVD19, although I haven't tested it on hardware. But I wanted to make a nice 3D menu using professional software, so that's of little help to me...

In this case, I could just lower the bitrate a bit and re-encode the video, as the video isn't that great to begin with and would probably look the same with a lower bitrate, but I'm starting to think that might not even solve my problem, and also, I'd like to understand what's going on here, for any future projects.

[CDK]

As far as I know 48 is a maximum for all streams in 2D and 64 for 3D. Bufsize should not be more than 30 in 2D (I don't know about the 3D, but I think the same for each eye).
What is you max bitrate? I would recommend to try bitrate/maxrate/bufsize ~30/35/30 for left and may be 15/20/20(?) for right.
Anyway, as far as I know codecs are not strict. If you have a very active scene with a lot of various (active) sound at that scene - it may go upper all limits, so it's better to limit everything at 45/60 or sometimes at 40/55, than at 48/64.

[RajaSteve]

Since posting, I've delved a little more into what VBV actually is, and found out it should never be higher than the max bitrate, which it was for the right eye. Re encoding now with target bitrate 30, max bitrate 35, and VBV 30 for the right eye, and 17, 20, 17 for the left eye. Also doing 2-pass encoding this time, which I didn't before. Will let you know if it works. I think it might. VBV was almost twice the maxrate of the right eye before...

[RajaSteve]

Nope. Same buffer underflow, will try experimenting with the VBV a bit and lowering the bitrate if it doesn't work.

[CDK]

Using max-bitrate equal to the bitrate sometimes helps with underflows. You can try 30/30/30 and 15/15/15. If it works - try to increase max.

[RajaSteve]

Thanks for the tip, will try. But I think it might be peaks in the video bitrate that are causing this. During my last encoding attempt I noticed some very high spikes:


[Attachment 73011 - Click to enlarge]

As you can see, it spikes as high as 50 Mbps at some point!

Also, does VBV actually affect playback of the encoded file, or does it only affect the encoding bitrate? I thought it was only the rate at which it checks if the encoding exceeds the max bitrate, but I notice the BD specs have a maximum for it, so this made me wonder...

[CDK]

As far as I know (again) encoder should check that encoded stream will fit inside the buffer during the playback. So it can have peaks above the buffer size and max-rate, but before and after the peak itself the bitrate should be low enough.

[RajaSteve]

I see. I finally found a good explanation of what VBV actually is in the CineVision manual. Can't believe I overlooked it before. It said that VBV, or HRD buffer, as they call it, determines how much data can be stored in the decoder's memory at any given time, answering my earlier question if VBV affects the encoded file, or only being used to encode. It also stated, that when muxing with higher amounts of audio/subtitles, this value should be lowered, which also should decrease bitrate peaks.

Lowered it quite a bit, as my project might not have very large amounts of audio, but certainly, 2 of them are atmos... Tried again. Still no luck. Still noticed some pretty extreme peaks, too. Tried again with the original (higher) value, this time encoding with a CBR. There were still some peaks, albeit much less extreme. I also still did get a buffer underflow, but this time much later in the process (at 50% instead of a few seconds after starting muxing). So it definitely looks like it was the bitrate peaks going too far above the max rate.

Maybe the 2 Atmos tracks, 1 DDP track, and 1 DD track somehow take up more bitrate than MediaInfo/BDInfo reports them having (maybe also due to bitrate spikes? maybe the large number of channels?), and this is why I couldn't mux them before, despite slightly staying under a total 60 Mbps transfer rate.

Or maybe it's just that this particular video causes some extreme spikes?

Either way, this also explained for me why there is no universal way of calculating the ideal VBV, as it can depend of the number and bitrate of audio streams, and the severity of the video bitrate spikes, which can vary which each video.

Will keep experimenting, pretty confident I'll get it done, eventually.

Thanks for your help, CDK.