HCenc and VBV underflows

[linx05]

I'm having a lot of VBV underflows during my encode. On this pass right now, it is up to 39 (all fixed though). I don't know what could have caused this. As far as I know, it happens on processed and unprocessed rips. At first I thought it was the drive it was on. So I've tried it from the normal C: but the same thing occurs.

Funny thing is, when I abort the encode and resume it. It happens again, with the same number of underflows. So I'm thinking it has to be the source? I've defragmented my drive too.

DVD-Rebuilder 1.10.2
HCenc 018

So I did a search here and found this: http://forum.doom9.org/showthread.php?p=740634&highlight=underflow#post740634

So what I am understanding is, because the film has a higher biterate in certain parts, it causes the overflow (read the bucket story). Is this normal? There isn't any way to stop the over flows? I'm just worried that HCenc won't be able to fix one and I wouldn't know until I've watched the whole thing.

So in closing, is there any way to prevent the overflows?

[foxyshadis]

Yes, it's very normal. HC encodes segments first without worrying seriously about the VBV, then checks them aginst the VBV requirements, and only then reports a warning. If it says "fixed" that means it re-encoded the segment to fit within MPEG-2 specs and your maximum buffer size. You can totally ignore them, the only way to prevent them is to lower the average bitrate a lot or filter detail out of your show, neither one good options. The only reason HC wouldn't be able to fix one, I assume, is if encoding the entire segment at q31 still overflowed - something almost impossible.

You can also think of a buffer underflow as being an out-of-spec bitrate spike, as if encoding one group of frames resulted in 15Mbps. (But VBV is much more precise and lower-level than bitrate.)

[hank315]

@foxishadis
Thanks for the explanation ;)

Some additional info how HC handles bitrate and VBV:
Bitrate in HC is controlled on a GOP basis, depending on the results of the first pass quantizers are estimated to get the desired GOP length in the second pass.
If it overshoots the max. bitrate (simple summation of all GOP bits), quantizers are adjusted and the GOP is quantized again until it satisfies max. bitrate.
On some difficult scenes it can be a bit slow but it is effective.
VBV is another issue, it's based on the fact frames have to arrive in time and have to fit in the buffer (224 kB for DVD) for prediction.

The only reason HC wouldn't be able to fix one, I assume, is if encoding the entire segment at q31 still overflowed - something almost impossible.
That should indeed be very rare, HC uses non-linear quantization, q31 means a real quantizer of 112...

[linx05]

Thanks for the reply guys. I needed the confirmation. I'm also glad to hear that HC not being able to fix the problem is very rare. I use to get worried when there would be 20+ errors (all fixed though). Does it happen to any more people?

Thank you again for a wonderful encoder hank315!