Maximum bitrate, CCE and muxman

[PAL sucks]

As you probably know, and I just learned, VBR mpeg2 sometimes spikes above the set max bitrate. How strict is muxman in this regard? Does it allow single frame spikes just above the limit? I have been blissfully ignorant of max bitrate spec and just left the default of 9000 up till now.

I just ran into this problem trying to mux a dvd with free muxman that had 5 audio (192x3, 448, and 112) and two subtitle streams so I reencoded setting max at 8500. I didn't try to mux it yet but I want to know if muxman is strict enough not to worry, or if the max bitrate can be broken for a frame or two and the player will be ok with it (ie the spec is a safety margin).
Or if I misunderstand max bitrate of entire mpeg vs gop, if that's even a thing.

When looking through the txt log I see spikes just above the max. Also when looking at the bit allocation window, it seems on a third pass the encoder tries to cap the spikes that are more pronounced on a second pass. (The first pass is a VBR analysis pass.)

[manono]

How strict is muxman in this regard?

Very. It follows the specs.

I just ran into this problem trying to mux a dvd with free muxman that had 5 audio (192x3, 448, and 112) and two subtitle streams so I reencoded setting max at 8500.

What problem, since you said you hadn't tried to mux it yet? My guess is you should be OK, but the more passes you run the better CCE is about keeping the max below what you set. I run 5 or 6. If you're trying to cut it close, run more passes. And don't forget the muxing overhead.

Or if I misunderstand max bitrate of entire mpeg vs gop, if that's even a thing.

Screwing up the GOPs is a different problem and will result in a different error message from Muxman.

[jman98]

It's been years since I used it as HCenc meets my needs better now, but I never had CCE ever, not even once, exceed the maximum bit rate I fed into it. TMPGenc, on the other hand, was rather infamous for routinely ignoring the max bit rate you gave it. I'm honestly not sure that I ever did an encode with TMPGenc where it didn't exceed the max bit rate, sometimes by as much as 1000 Kbps over the max value I gave it.

You are really pushing the envelope with 5 audio streams and that bit rate but it should be OK.

[PAL sucks]

@jman98: woops, 8300 is the max, not 8500, average is somewhere in the 5000s. SP3 is the spiker.
I hope that's right, the calculator on this site says 8418 for 6 192s.

Also, muxman didn't stop at the first violation, it stopped halfway through the mux. That's why I was wondering about how strict it is. Here is the log sans stream list:

18:16:33 Begin multiplex VTS01.
Title Segment List
Segment_1
Encoded stream 20 is script stream 1.
Encoded stream 21 is script stream 2.
Maximum audio duration 319462 fields.
Starting scene Segment_1_scn1 at 00:00:00:00
P-STD buffer underflow by 1311 bytes at 15468219, sector 66675.
P-STD buffer underflow by 3158 bytes at 15490742, sector 66829.
P-STD buffer underflow by 1462 bytes at 15495246, sector 66860.
P-STD buffer underflow by 10386 bytes at 15498249, sector 66880.
P-STD buffer underflow by 3840 bytes at 15505757, sector 66931.
P-STD buffer underflow by 3403 bytes at 15540291, sector 67167.
P-STD buffer underflow by 23600 bytes at 15543294, sector 67188.
P-STD buffer underflow by 1555 bytes at 15588339, sector 67496.
P-STD buffer underflow by 1233 bytes at 15625877, sector 67753.
P-STD buffer underflow by 19063 bytes at 15640892, sector 67855.
P-STD buffer underflow by 92 bytes at 15675426, sector 68091.
P-STD buffer underflow by 12089 bytes at 15678429, sector 68112.
P-STD buffer underflow by 2817 bytes at 15693444, sector 68214.
P-STD buffer underflow by 4135 bytes at 15761012, sector 68676.
P-STD buffer underflow by 7772 bytes at 15768519, sector 68728.
P-STD buffer underflow by 1579 bytes at 15773024, sector 68758.
P-STD buffer underflow by 2496 bytes at 15783534, sector 68830.
P-STD buffer underflow by 223 bytes at 17442692, sector 79372.
P-STD buffer underflow by 4998 bytes at 17450199, sector 79423.
P-STD buffer underflow by 6482 bytes at 17487737, sector 79679.
P-STD buffer underflow by 2411 bytes at 17495244, sector 79731.
P-STD buffer underflow by 195 bytes at 17525274, sector 79936.
P-STD buffer underflow by 3249 bytes at 17570319, sector 80246.
P-STD buffer underflow by 5620 bytes at 17577827, sector 80295.
P-STD buffer underflow by 15340 bytes at 17622872, sector 80603.
Starting scene Segment_1_scn2 at 00:09:14:27, requested for 00:09:14:13
Starting scene Segment_1_scn3 at 00:17:44:15, requested for 00:17:44:04
Starting scene Segment_1_scn4 at 00:25:12:15
Starting scene Segment_1_scn5 at 00:34:08:09
Starting scene Segment_1_scn6 at 00:44:49:06, requested for 00:44:48:23
P-STD buffer underflow by 2325 bytes at 273220214, sector 1276590.
P-STD buffer underflow by 13015 bytes at 273223217, sector 1276611.
P-STD buffer underflow by 13558 bytes at 273268262, sector 1276919.
Starting scene Segment_1_scn7 at 00:55:50:02, requested for 00:55:49:18

...just in case someone wants to see it.

I haven't tried muxing my new lowered max reencode. I suppose if it fails this time I can redo high segments to further put the spikes in line but it seems like more passes might be better for quality.

I read on another forum someone tried to test the highest cbr bitrate with lpcm to see if various players could handle it and it took some pushing to make them react, more recent models, but I certainly don't want to push that envelope so if I see some frames over the line I will try to fix them.

[PAL sucks]

The saga continues...

Max bitrate 9000, at least 4 passes, I see this in the verbose log:
...
13/04/11 02:53:32.874 00:23:28:24 (42264 (84528)) cur 6.63, avg 6.30, I 1.11, P 1.06, B 1.10 (open)
13/04/11 02:53:36.171 00:23:29:06 (42276 (84552)) cur 7.10, avg 6.30, I 1.00, P 0.94, B 0.98 (open)
13/04/11 02:53:39.308 00:23:29:18 (42288 (84576)) cur 8.12, avg 6.30, I 0.91, P 0.84, B 0.89 (open)
13/04/11 02:53:42.841 00:23:30:00 (42300 (84600)) cur 10.20, avg 6.30, I 0.64, P 0.55, B 0.58 (open)
13/04/11 02:53:46.012 00:23:30:12 (42312 (84624)) cur 4.50, avg 6.30, I 1.48, P 1.48, B 1.63 (closed)
13/04/11 02:53:49.532 00:23:30:24 (42324 (84648)) cur 4.84, avg 6.30, I 1.45, P 1.41, B 1.58 (open)
13/04/11 02:53:52.992 00:23:31:06 (42336 (84672)) cur 4.75, avg 6.30, I 1.48, P 1.47, B 1.62 (open)
...

which didn't happen on the previous passes, they kept it below 9000. I think it has something to do with the final encode being the slowest since it's the only one to use my true denoise settings instead of substituting a faster process.

I figure out these are for each GOP and not every frame. :duh:
(I also figured out that I have to use 1000kbps scale instead of 1024 in bitrate calculator for CCE.)

And when I preview that sequence in dgindex it reports two different max bitrates each time but they were close and not over 9000kbps.

Is there a dead accurate tool to see if there are spikes or not in the final encode?
(I could scroll through the CCE bitrate viewer even though it's a pain if that's the best way)

[poisondeathray]

EDIT: sorry , nevermind...

[PAL sucks]

I know you told me so but not so explicitly as this:

http://www.innobits.com/newsletter_2/br_art.html

There exists no definition of any certain duration, at which an average, max, peak or momentary bitrate should be calculated and/or measured. This is why bitrate graphs are of very limited value, in particular for deciding the max bitrate of a certain MPEG-2 video stream. The actual peaks in such a graph will occur at different points in time, for the same MPEG-2 file, depending on the duration chosen for the bitrate calculation. And, again, there exists no such definition. The peaks could therefore be plotted at higher values than the max bitrate, while the file is still perfectly within the specifications.

So a buffer analyser is what I want. Muxman already does it but I wanted to analyse before applying pulldown and muxing but I already did a few with more than one audio stream, they played fine so CCE doesn't spike, I imagine. I wonder how jman 98 knew TMPGenc spiked.

[manono]

Also, muxman didn't stop at the first violation, it stopped halfway through the mux. That's why I was wondering about how strict it is.

I said it's very strict, and it is. Even had you only one or two buffer underflows it still wouldn't have given you a playable DVD, but would have thrown an error at the very end. Because you had so many buffer underflows it quit in the middle.

they played fine so CCE doesn't spike, I imagine.

It can spike. I've had quite a number of single-pass encodes where CCE actually aborted. I've had a few multiple-pass ones with very high average bitrates (8-8500) when it wouldn't mux all the way until I did it over again with a lower max bitrate or a lower average bitrate or both.

I wonder how jman 98 knew TMPGenc spiked.

It's common knowledge.