x264 not respecting VBV Max and VBV Max buffer

[lithiumus]

I'm not 100% sure if it's isolated to just Anime but that's what I've been working on. I've done many encodes and tests again with various settings but it seems that when I encode this VC-1 Anime using x264, the bit rate spikes up to 60Mbs in certain spots but definitely breaks the 40000 / 40000 restrictions I placed.

I tried threads set to 2 instead of 0 to see if it makes any difference but it doesn't. I'm using an Core2Duo E6600.

I'm uploading a 20 second sample clip. At the 7 second mark it spikes to 50Mbits and at 12 seconds it spikes to 58Mbits and at 14 seconds it goes to 48Mbits. The original VC-1 source doesn't break 25-28 Mbits. Any idea?

-----------------
program --pass 2 --bitrate 10700 --stats ".stats" --level 4.1 --keyint 24 --min-keyint 2 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --weightb --direct auto --subme 9 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 40000 --vbv-maxrate 40000 --me umh --threads 2 --thread-input --progress --no-ssim --output "output" "input" --mvrange 511 --aud --nal-hrd
-----------------

Here is the encoded sample
http://www.mediafire.com/file/ywijuyyyjtm/00001.track_4113.264

[Dark Shikari]

x264 will never, ever silently break the restrictions you place on it. Violations will result in the printing of warning messages.

If you are measuring buffer underflows without associated warning messages, it means one of two things:

1. Your tool for measuring underflows is not using the correct bufsize or initial buffer occupancy.

2. You're passing the wrong fps to x264. The fps required for VBV compliance is equal to the max framerate in a source if your source is VFR.

[lithiumus]

You speak in advanced terms! Let me see if I understand what you are saying because I've checked the logs and there are no warning messages aside from a blank line between the "using CPI capabilties" and "slice" (I'm using Megui).

I think I know what you are saying and that's helped point me in the right possible direction. I looked at the raw stream again and it seems to be ok. I then looked at a muxed m2ts done by TsMuxer and the bitrate went nuts so it has to be a setting in TsMuxer causing this. Thanks for looking that this. The FPS in the source is 24000/1001 which is the same that I am feeding x264.

[lithiumus]

I must be on drugs... I looked at the raw sample and no I was wrong, the bit rate does spike like I indicated. What tool is being used to measure underflows when x264 is encoding under Megui?

[LoRd_MuldeR]

What tool is being used to measure underflows when x264 is encoding under Megui?

No tool. x264 itself takes care of VBV when it's instructed to do so. And it will drops warnings when it overflows or underflows.

[akupenguin]

Spikes do not violate VBV.
There is no such thing as instantaneous bitrate of a video file. You can talk about instantaneous bitrate of a network connection, because there each bit has a well-defined timestamp. But there are many possible schedules for any given file, and each schedule complies with some subset of all possible VBV constraints.
Therefore, you can't determine VBV compliance just by eyeballing a graph of frame sizes. You can't even determine it by taking a rolling average of frame sizes (this could find really egregious violations, but not merely factors of 2). You have to actually run the VBV model.
In this case, you asked for 40mbit/s and 40mbit buffer. My script (http://akuvian.org/src/x264/vbv.pl) says your file complies. In particular, assuming a bufsize of 40000kbit it can get away with any maxrate >=39281kbit/s, and assuming a maxrate of 40000kbit/s it can get away with any buffer >=36252kbit. And I could give a whole graph of the other points on the maxrate-vs-buffer pareto curve, but you probably aren't interested.

[lithiumus]

hmmm.. Maybe I am interested as I don't fully understand what you are saying here.

"In particular, assuming a bufsize of 40000kbit it can get away with any maxrate >=39281kbit/s, and assuming a maxrate of 40000kbit/s it can get away with any buffer >=36252kbit."

Are you saying that because my bufsize is 40000kbit that the maxrate can be ANY rate greater than or equal to 39281kbit i.e. maxrate can go well beyond 39821 because of my buffer?

Would that mean that the theoretical max is really 80000 due to the combination of maxrate and the buffer available?

[Dark Shikari]

hmmm.. Maybe I am interested as I don't fully understand what you are saying here.

"In particular, assuming a bufsize of 40000kbit it can get away with any maxrate >=39281kbit/s, and assuming a maxrate of 40000kbit/s it can get away with any buffer >=36252kbit."

Are you saying that because my bufsize is 40000kbit that the maxrate can be ANY rate greater than or equal to 39281kbit i.e. maxrate can go well beyond 39821 because of my buffer?No, he's saying that in your clip, if the bufsize is 40000kbit, the "actual" max rate used in your clip is 39281 kilobits per second. Or, equivalently, it complies with any vbv-maxrate greater than or equal to 39281.

[Sagittaire]

1) if you want BD compliant profil 40 000 Kbits is not compliant with BD. Max buffer is 30 000 Kbits.

2) Max bitrate is not the max local bitrate. With vbv you can have max local bitrate really higher than "Max Bitrate" setting. With your vbv setting max local bitrate can be potentialy very higher than 40 000 Kbps for a single frame or short part.

[blizzbit]

1) if you want BD compliant profil 40 000 Kbits is not compliant with BD. Max buffer is 30 000 Kbits.
Does it mean MeGUI x264 presets (http://forum.doom9.org/showthread.php?t=139765) (v81) are wrong with its "Standalone-Blu-ray" profile?

"--pass 2 --bitrate 8000 --stats ".stats" --level 4.1 --keyint 24 --min-keyint 2 --ref 3 --mixed-refs --bframes 3 --b-adapt 2 --weightb --direct auto --filter -1:-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 40000 --vbv-maxrate 40000 --qcomp 0.5 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" --mvrange 511 --aud --nal-hrd --sar 1:1"

[Sagittaire]

Does it mean MeGUI x264 presets (http://forum.doom9.org/showthread.php?t=139765) (v81) are wrong with its "Standalone-Blu-ray" profile?

"--pass 2 --bitrate 8000 --stats ".stats" --level 4.1 --keyint 24 --min-keyint 2 --ref 3 --mixed-refs --bframes 3 --b-adapt 2 --weightb --direct auto --filter -1:-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 40000 --vbv-maxrate 40000 --qcomp 0.5 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" --mvrange 511 --aud --nal-hrd --sar 1:1"

Yes it's wrong. Max bitrate is 40 Mbps for 1080p24 primary stream but 30 Kbits for max buffer (you can use smaller value if you want).

Moreover it's better for compliancy to use 2 bframes without pyramid and with 4 ref. qcomp setting is now useless with AQ actived by default.

[Dark Shikari]

qcomp setting is now useless with AQ actived by default.I don't see how the two are related...

[Quark.Fusion]

Why you want to limit b-frames to 2 for compliancy? Isn't max number of b-frames is 16 for main profile?

[Dark Shikari]

Why you want to limit b-frames to 2 for compliancy? Isn't max number of b-frames is 16 for main profile?There is no max number of B-frames in any H.264 profile (except obviously Baseline). x264's limit of 16 is simply arbitrary for technical reasons.

[G_M_C]

Max bitrate is not the max local bitrate. With vbv you can have max local bitrate really higher than "Max Bitrate" setting. With your vbv setting max local bitrate can be potentialy very higher than 40 000 Kbps for a single frame or short part.

Sorry to "butt in", but this remark reminds me that I had a small question about this;

In my commandline I allways have --vbv-bufsize higher than --vbv-maxrate. In light of you remark, Sagittaire, it sort of sounds logical; but did I have my reasoning-cap on the right way when I thought this up ?

To be exact; For my BD9 projects I use --vbv-bufsize 22000 higher than --vbv-maxrate 16000.

And the reasoning came down to --vbv-bufsize beeing releted to the frame-memory used by the player, in wich b-frames and refs need to be stored too. So thats why --vbv-maxrate has to be lower, cause beside the bitrate of the stream, there has to be room left for stored b-frames and/or refs.

But don't hate me when this reasoning is totally stupid; I'm not actually knowledgeable on the subject of the inner workings of the encoders, but I try to understand as best i can ... By asking questions like this one ;)

[Dark Shikari]

Sorry to "butt in", but this remark reminds me that I had a small question about this;

In my commandline I allways have --vbv-bufsize higher than --vbv-maxrate. In light of you remark, Sagittaire, it sort of sounds logical; but did I have my reasoning-cap on the right way when I thought this up ?

To be exact; For my BD9 projects I use --vbv-bufsize 22000 higher than --vbv-maxrate 16000.

And the reasoning came down to --vbv-bufsize beeing releted to the frame-memory used by the player, in wich b-frames and refs need to be stored too. So thats why --vbv-maxrate has to be lower, cause beside the bitrate of the stream, there has to be room left for stored b-frames and/or refs.

But don't hate me when this reasoning is totally stupid; I'm not actually knowledgeable on the subject of encoding, but I try to understand as best i can ...The coded picture buffer (vbv buffer) and decoded picture buffer (dpb) are separate.

[akupenguin]

And the reasoning came down to --vbv-bufsize beeing releted to the frame-memory used by the player, in wich b-frames and refs need to be stored too.
In hardware players, the dpb and vbv memory are statically allocated. Reducing one doesn't allow you any more space in the other. (The hardware designer had a tradeoff, but that only affects the Levels in the standard(s), it doesn't affect any decisions you get to make.)
In software players, yes there's a common memory pool. But any sane software player will have enough memory for 16 refs and a ginormous vbv buffer, so there's really no tradeoff.

Plus, maxrate is unrelated to dpb.

[Sagittaire]

Why you want to limit b-frames to 2 for compliancy? Isn't max number of b-frames is 16 for main profile?

Perhaps for main profil but not for BD profil. Max bframe is 3 bframe with 4 ref. If you use pyramid bframe you must use max ref at 3. 3 pyramid bframe with 3 ref seem to be problematic with x264. Anyway BD is particular profil (generaly high bitrate, low quantizer, high quality, short gop) and you must use particular setting in this area:

- With short gop you must reduce ipratio (too high relative bitrate for iframe and high local quality flick with no-scene-cut frame).
- High quality with high bframe number and high ratio produce high local quality flick. IBbBPBbBP produce better overall quality than IBBPBBPBBP but with higher local quality flick (for BD at high quality IBBPBBPBBP with low ratio is really better HVS choice for me).

[G_M_C]

OK, thx Dark Shikari and akupenguin for your answers. Clearly I was wrong in my reasoning. I've been searching around using Google to find out exactly what the VBV & cpb actually are. But the links i do find aren't helping, they are either non-related or to high-fetched for me.

Can you point me to somewhere where i can read up on this, somewhere that is less high-fetched (read: For the less knowledgeable ;) ), cause i am still interested in understanding more (about the workings / terms used in encoders).

PS: I did find an online vbv calculator that might help clearing up lithiumus' question;
http://handbrake.dynaflashtech.net/cgi-bin/vbv_calculator.cgi

The spike he mentioned could be of a really short duration. According to this calculator spikes of short duration can be higher than the max bitrate specified, and still not break vbv-buffer limits. At least if I (at least) understand this right ;)

[foxyshadis]

If you want a conceptual understanding: Hardware specs always have minimum transfer rates (from disc or network) (vbv-maxrate), reading into the Coded Picture Buffer, which also has a minimum size specified (vbv-bufsize). It starts writing from disc to memory a little before the decoder starts reading from it (vbv-init), but if the decoder ever catches up before the reader is done transferring a full frame, because there's too much to transfer in time, the decoding stalls, and you have an underflow. In the meantime the used buffer grows and shrinks but stays in the bounds. An overflow is when you read too fast for the decoding, but that's normally only a problem with software decoders that can't decode in realtime, though the time spent not reading from media does have to be accounted for by the verifier.

[G_M_C]

If you want a conceptual understanding: Hardware specs always have minimum transfer rates (from disc or network) (vbv-maxrate), reading into the Coded Picture Buffer, which also has a minimum size specified (vbv-bufsize). It starts writing from disc to memory a little before the decoder starts reading from it (vbv-init), but if the decoder ever catches up before the reader is done transferring a full frame, because there's too much to transfer in time, the decoding stalls, and you have an underflow. In the meantime the used buffer grows and shrinks but stays in the bounds. An overflow is when you read too fast for the decoding, but that's normally only a problem with software decoders that can't decode in realtime, though the time spent not reading from media does have to be accounted for by the verifier.

Ok, after reading this (a few times and "milling it over" a few times ;) ) i relate it this way to my situation where I make BD9's; The vbv-maxrate i set is based on the max 18mbps transferrate of the player (~2x DVD speed); Including audio. When audio-bitrate is subtracted I round it off to 16 mbps, thats my value of --vbv-maxrate explained.

--vbv-bufsize i set to 22mbps, but I allowed for audio here too; That's wrong, the vbv-buffer only stores coded video-frames ("comes after the demuxing"), and according to specs I could set it to 24 mbps (AVCHD specs suggest 24mbps as max I read on several sites, but I have the feeling it should be the same as the 40 mbps BR specification, as it is essentialy the same buffer ...).

And if I understand your post correctly, setting vbv-bufsize higher than vbv-maxrate, might help preventing underflows. A situation where the decoder catches up before the reader is done transferring a full frame, wouldn't happen because the --vbv-bufsize is larger than the full frame (maxrate) AND the max rate the disc can deliver (also maxrate).

[blizzbit]

The vbv-maxrate i set is based on the max 18mbps transferrate of the player (~2x DVD speed); Including audio. When audio-bitrate is subtracted I round it off to 16 mbps, thats my value of --vbv-maxrate explained.
Yep, for VBV Max bitrate I would say
- it's recommended to set values, which are equal to ABR multiplied 2-4 times
- VBV Max bitrate for AVCHD compatibility (on DVD) =: 22 (16) Mbps (+2 Mbps for audio and subs)
- VBV Max bitrate for Blu-Ray compatibility =: 40 Mbps (+14 Mbps for audio and subs)

--vbv-bufsize i set to 22mbps, but I allowed for audio here too; That's wrong, the vbv-buffer only stores coded video-frames ("comes after the demuxing"), and according to specs I could set it to 24 mbps (AVCHD specs suggest 24mbps as max I read on several sites, but I have the feeling it should be the same as the 40 mbps BR specification, as it is essentialy the same buffer ...).
For Blu-Ray compatibility it's 30 Mbps. Take a look here (http://forum.doom9.org/showthread.php?p=1192939#post1192939). :)
Max bitrate is 40 Mbps for 1080p24 primary stream but 30 Kbits for max buffer (you can use smaller value if you want).

[Sergey A. Sablin]

If you want a conceptual understanding: Hardware specs always have minimum transfer rates (from disc or network) (vbv-maxrate), reading into the Coded Picture Buffer, which also has a minimum size specified (vbv-bufsize). It starts writing from disc to memory a little before the decoder starts reading from it (vbv-init), but if the decoder ever catches up before the reader is done transferring a full frame, because there's too much to transfer in time, the decoding stalls, and you have an underflow. In the meantime the used buffer grows and shrinks but stays in the bounds. An overflow is when you read too fast for the decoding, but that's normally only a problem with software decoders that can't decode in realtime, though the time spent not reading from media does have to be accounted for by the verifier.

very close, it'll be closer if you'll change minimum to maximum.
and overflow is kinda incorrect as well - it has nothing to do with software decoding at all, but it is certainly connected to maximum buffer size and real-time decoding (but in reverse to your explanation), ie if decoder decodes in real-time and data is read faster than removed from buffer (after decoding) - buffer simply overflows.

[akupenguin]

--vbv-bufsize i set to 22mbps
mb, not mbps.

vbv-buffer only stores coded video-frames ("comes after the demuxing")
That's really strange. Whatever is read from the disc (at maxrate) needs to be stored in the buffer, including audio. Unless... is blu-ray not strictly time-interleaved, but rather muxed such that CBR audio can be played immediately without going through the buffer?

A situation where the decoder catches up before the reader is done transferring a full frame, wouldn't happen because the --vbv-bufsize is larger than the full frame (maxrate) AND the max rate the disc can deliver (also maxrate).
Maxrate doesn't limit the size of a single frame. One frame can use up the whole buffer. And then you'd be screwed if the next frame were that big too (which is far more than maxrate replenishes in one frame's time interval), except that the encoder won't do that because it knows that wouldn't be vbv compliant. So no matter what values you set for maxrate and buffer, you have only the encoder's decisions keeping you from underflow.

- it's recommended to set values, which are equal to ABR multiplied 2-4 times
The recommended value is the maximum value your standard allows. In any situation where you even have a choice about maxrate, the correct solution is not to enable vbv at all, and just use unrestricted abr.
Same with bufsize (except for software streaming, where the tradeoff for huge bufsize is huge preload, so I guess there's some value which is too much.)

[blizzbit]

The recommended value is the maximum value your standard allows. In any situation where you even have a choice about maxrate, the correct solution is not to enable vbv at all, and just use unrestricted abr.
Same with bufsize (except for software streaming, where the tradeoff for huge bufsize is huge preload, so I guess there's some value which is too much.)
Is there any recommended ratio between VBV Max bitrate and VBV buffer? I remember, I read anything, anywhere that the stream to be inputted to CPB must decode within 1,5 seconds. Is there a grain of truth in it?

[akupenguin]

Is there any recommended ratio between VBV Max bitrate and VBV buffer?
In general, no. Maxrate is determined by the available bandwidth, buffer is determined by the available memory, and both are just incidental facts about the hardware. Or intentionally designed facts about the hardware, whatever.
I remember, I read anything, anywhere that the stream to be inputted to CPB must decode within 1,5 seconds. Is there a grain of truth in it?
A specific standard such as Blu-ray may impose such a constraint, but that's not a general property of vbv. Anyway, that's not something for an encoder to worry about. If a stream's bit distribution complies with the right vbv, then there will always be some schedule which complies with the delay constraint as well, and it's up to the streamer (or muxer or whatever it is that determines schedules) to find it. This will tend to involve not trying to keep the buffer full, but rather delaying any given bit read as long as possible such that it can still be read in time for decoding.

[blizzbit]

OK, thank you for your explanations, Sagittaire and akupenguin. I learned a lot again. :)

[foxyshadis]

very close, it'll be closer if you'll change minimum to maximum.
The spec specifies a minimum buffer size and transfer speed, so for the purposes of encoding, those are the maximum strictly compatible values. I was just trying to point out the link between the values you give x264 and the actual hardware reasons behind it.
and overflow is kinda incorrect as well - it has nothing to do with software decoding at all, but it is certainly connected to maximum buffer size and real-time decoding (but in reverse to your explanation), ie if decoder decodes in real-time and data is read faster than removed from buffer (after decoding) - buffer simply overflows.
That's an issue encoders never have to worry about, decoders deal with it, so I considered mentioning it but left it off.

[foxyshadis]

That's really strange. Whatever is read from the disc (at maxrate) needs to be stored in the buffer, including audio. Unless... is blu-ray not strictly time-interleaved, but rather muxed such that CBR audio can be played immediately without going through the buffer?

It's possible in TS, every packet is timestamped, but I don't think I've ever heard of that being intentionally done for that reason. G_M_C just assumed wrongly, since the actual decoding can work any number of ways, raw stream buffered or demuxed or hierarchical buffers, as long as it meets the minimums for its hardware specs.

[Sergey A. Sablin]

The spec specifies a minimum buffer size and transfer speed, so for the purposes of encoding, those are the maximum strictly compatible values.
yes, right - encoder/decoder definition mixture...

That's an issue encoders never have to worry about, decoders deal with it, so I considered mentioning it but left it off.
here I've lost you. Overflow might occur only in CBR and that's the case when encoder have to ensure that stream being transmitted with constant rate won't overflow decoder' buffer.
So that's an issue encoders have to deal with - as decoders can't work this out unless they have more memory than that minimum on which encoder relies on. (and even if they have more memory - it is not infinite anyway)