What is DPB size?

[microchip8]

Hi,

I'm currently encoding a HD movie (1920x1080) with MEncoder to H.264 video (High@L4.1). When the encoding started, I saw this message below. What does it mean (DPB???) and how to avoid it?

x264 [info]: using SAR=1/1
x264 [warning]: DPB size (16128000) > level limit (12582912)

[Sharktooth]

decoded picture buffer size

edit: removed the non-sense...

[microchip8]

ok... so is that bad in some way? how to fix it without changing the level (is that possible at all?) I'd up the level to 5.1 but I don't know how many of the stand-alone players support Level 5.1

EDIT: @ Sharktooth... the bitrate was set to 2500 kbps

[Dark Shikari]

It has nothing to do with the bitrate: DECODED picture size. It has to do with (--ref * resolution) being too high.

[microchip8]

It has nothing to do with the bitrate: DECODED picture size. It has to do with (--ref * resolution) being too high.

--ref as in reference frames? if so, then I used only 4

any solutions on how to stay at Level 4.1 and avoid this DPB warning?

[Dark Shikari]

--ref as in reference frames? if so, then I used only 4

any solutions on how to stay at Level 4.1 and avoid this DPB warning?
1920*1080*12 bits per pixel*4 refs = 12 441 600... within the buffer size.

But let me guess... you've enabled --b-pyramid? That adds another ref to the mix :p

[microchip8]

lol, yes b-pyramid is enabled, I'll just up the level to 5.1

thanks for clarification on this :)

[Dark Shikari]

lol, yes b-pyramid is enabled, I'll just up the level to 5.1

thanks for clarification on this :)No standalones support 5.1 though, so watch out...

[microchip8]

ok, so if I ignore this DPB warning, is that bad? I mean will a hardware player choke on such an encode or something?

[Dark Shikari]

ok, so if I ignore this DPB warning, is that bad? I mean will a hardware player choke on such an encode or something?Yes, because hardware players have a DPB of a specific size, and if the data in the stream exceeds that, it probably just won't play. Many of them check the DPB that the stream requires before starting playback, and if it exceeds the amount of memory the device has in its DPB, it just fails to play.

[microchip8]

ok, do HW players support L4.2? or do I have to stick to L4.1 and decrease refs?

[Dark Shikari]

ok, do HW players support L4.2? or do I have to stick to L4.1 and decrease refs?I think most support 4.1 since that is the HD-DVD level.

Just toss --b-pyramid, its not very useful anyways.

[Sharktooth]

it seems i should stop smoking random stuff... DPB... yep... :D

[microchip8]

I think most support 4.1 since that is the HD-DVD level.

Just toss --b-pyramid, its not very useful anyways.

do they support High@L4.1 or just Main@L4.1 ?

[Dark Shikari]

do they support High@L4.1 or just Main@L4.1 ?High, I believe, since that's what HD-DVD uses.

[bond]

b-pyramid might also cause troubles on hardware (dunno if hddvd/bluray use it), so you might want to drop it and see if there is still the warning

[check]

b-pyramid might also cause troubles on hardwareWhich hardware? Or if you know of none, why do you suspect this will be so?

[cacepi]

Which hardware?
Xbox 360 for one; it can stutter sometimes with b-pyramid, possibly due to out-of-order b-frames. (But don't quote me on that, though.)

[Manao]

Just toss --b-pyramid, its not very useful anyways.B pyramid is far more usefull than 3->4 refs
b-pyramid might also cause troubles on hardware (dunno if hddvd/bluray use it), so you might want to drop it and see if there is still the warningB pyramids are supported. I haven't seen a hardware not supporting it.

[UsedUser]

B pyramid is far more usefull than 3->4 refs
B pyramids are supported. I haven't seen a hardware not supporting it.
My experience is that enabling B-pyramids actually costs 2 reference frames in the total num_ref_frames calculation. Using B-frames, period, costs 1 reference frame, and the rest is the --ref value. Are you saying using B-pyramids is worth sacrificing 2 reference frames?

For hardware and DXVA decoder compatibility, one needs to stay within Profile High@L4.1, which means num_ref_frames <=4 @ 1080p.

To accomplish num_ref_frames = 4 with B-pyramids:

--ref 1 --bframes 3 --b-adapt --b-pyramid

To accomplish num_ref_frames = 4 without B-pyramids:

--ref 3 --bframes 3 --b-adapt --no-b-pyramid

[akupenguin]

My experience is that enabling B-pyramids actually costs 2 reference frames in the total num_ref_frames calculation.
Yes, but that's not inherent in pyramid. It just means that x264 doesn't currently optimize for compression-per-memory-usage (http://forum.doom9.org/showthread.php?p=1081968#post1081968).

[CruNcher]

Heres a little Reallife test Scenario (for me it's real for some this is to heavy, but im a extreme compression guy allways was allways will be ;) )

Pass: 1 Pass
Input: 1280x720p 29.97 4000 Mbps WMV3 (source is of bad quality, settings are extreme to compensate for the problems, better (faster) solution would be visuall lossless clean source before and lower compression factor on the encoder side)
Output: 1920x1080 29.97 4000 Mbps AVC High Profile 4.1

--ref 1 --bframes 3 --b-adapt --b-pyramid:
Speed: 4.25fps (includeing upscaling 2 Cores 2.8 GHz X2)
FRF = 25.59
SSIM = 0.9740095
PSNR = Y:43.301 U:48.500 V:47.940 Avg:44.404 Global:44.243
Bitrate Hit = 4065.68

--ref 3 --bframes 3 --b-adapt --no-b-pyramid
Speed: 3.85fps (includeing upscaling 2 Cores 2.8 GHz X2)
FRF = 25.63
SSIM = 0.9737892
PSNR = Y:43.266 U:48.474 V:47.909 Avg:44.369 Global:44.200
Bitrate Hit = 4057.78

So you see UsedUser what Manao says is absolutely right people overestimate reference frames to much and that drove us right into this Problematic Hardware situation we are in now, but alot have warned for this a long time ago.

[akupenguin]

Input: 1280x720p 29.97 4000 Mbps WMV3
Output: 1920x1080 29.97 4000 Mbps AVC High Profile 4.1
Forgive me if I question the validity of a quality comparison which involves an upscaled transcode at the same bitrate as the source...

[CruNcher]

It's based on a simple assumption that officialy 1280x720p @ 29.97 isn't compatible with HD-DVD devices (could also have changed i dunno) and for those that wan't to keep at least the initial size and not shorten the playback time of the HD-DVD Media the only solution seems at least to encode it @ the same bitrate as the input was and that in a compatible resolution.
Those to my latest knowledge for the given framerate are 1280x1080, 1440x1080 and 1920x1080, for sure i would convert it to 1280x1080 and not 1920x1080, but this was a extreme example of this Scenario. Doubleing the Framerate is another Solution but im not quiet sure if it's the better one (Speed/Quality) wise. Or you might could even take the encoded 1280x720p bitstream change it's Framerate flag to 59,94 and set the 3/2 Pulldown flag, but im not sure if this is gonna work if it does then ofcourse lower bitrate encoding would be a better way to go.

[microchip8]

A bit off topic, but how many B-Frames one should use to stay compatible with HW players (High@L4.1). Can they use 8 for example or do they choke on too many B-Frames as well?

[Manao]

As much as you want. For the DPB, 1 bframe or 1000 bframes is identical.

[UsedUser]

As much as you want. For the DPB, 1 bframe or 1000 bframes is identical.
I concur, but 0 b-frames is also valid. DPB is what matters, so if you use 0 b-frames you can use 1 more reference frame; if you use 1-16 b-frames, you lose 1 reference frame.

Not arguing against b-frames, just stating that using them costs 1 reference frame in the DPB calculation, if you use 1 or more.

[akupenguin]

if you use 0 b-frames you can use 1 more reference frame; if you use 1-16 b-frames, you lose 1 reference frame.
That is also just an implementation detail of current x264, and is also fixed by my DPB patch.

[UsedUser]

That is also just an implementation detail of current x264, and is also fixed by my DPB patch.
Well, your patch hasn't been committed yet, but you got me there! Man, you're all over me in this thread! I'm just going to shut up.