H264/AVC B-frames in cartoons

[DrDeceit]

I have quite a few seasons of South Park at HD resolutions

Knowing B-frames encode the difference between frames... wouldn't setting the max consecutive b-frames to 16 during encoding allow for EXTREMELY efficient compression, allowing for very low bitrates to be used at HD resolutions such as 1280x720?

I'm about to test this out using H264 lossless (yes, h264 lossless exists)

Media Info for the H264 LOSSY files


Encoding settings for H264 LOSSY, CRF 0.25
#1 Reference Frames = 16, Maximum B-frames = 16

Media Info for the H264 LOSSLESS files

Video
Format                                   : AVC
Format profile                           : High 4:4:4 Predictive@L3.1
Duration                                 : 22mn 10s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive

Encoding settings for H264 LOSSLESS
#1 Reference Frames = 1, Maximum B-frames = 0
2.43GB

cabac=0 / ref=1 / deblock=1:-6:-6 / analyse=0x1:0 / me=dia / subme=0 / psy=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0

#2 Reference Frames = 1, Maximum B-frames = 6
2.43GB
0% increase in encoding time

cabac=0 / ref=1 / deblock=1:-6:-6 / analyse=0x1:0 / me=dia / subme=0 / psy=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0

#3 Reference Frames = 3, Maximum B-frames = 6
2.30GB (5.35% more compression)
0% increase in encoding time

cabac=0 / ref=3 / deblock=1:-6:-6 / analyse=0x1:0 / me=dia / subme=0 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0

#4 Reference Frames = 6, Maximum B-frames = 6
2.25GB (7.40% more compression)
20% increase in encoding time

cabac=0 / ref=6 / deblock=1:-6:-6 / analyse=0x1:0 / me=dia / subme=0 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0

#5 Reference Frames = 6, Maximum B-frames = 16
2.25GB (7.40% more compression)
20% increase in encoding time

cabac=0 / ref=6 / deblock=1:-6:-6 / analyse=0x1:0 / me=dia / subme=0 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0

Encoding settings for H264 LOSSLESS, More than just ref and b-frames changed
#1 Reference Frames = 6, Maximum B-frames = 6, CABAC
2.04GB (16.05% more compression)
25% increase in encoding time

cabac=1 / ref=6 / deblock=1:-6:-6 / analyse=0x1:0 / me=dia / subme=0 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0

#2 Reference Frames = 16, Maximum B-frames = 16, CABAC, 8x8 Transform, Weighted P-frames
2.03GB (16.46% more compression)
105% increase in encoding time

cabac=1 / ref=16 / deblock=1:-6:-6 / analyse=0x3:0 / me=dia / subme=0 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0

#3 Reference Frames = 16, Maximum B-frames = 16, CABAC, 8x8 Transform, Weighted P-frames, Trellis = Encode Only, Motion Estimation Method = Hexagon, Subpixel ME & Mode Decision = 6 RD in all I/P-frames
1.81GB (25.51% more compression)
500% increase in encoding time

cabac=1 / ref=16 / deblock=1:-6:-6 / analyse=0x3:0 / me=hex / subme=6 / psy=0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=0

[Selur]

yes, boosting the max number of b-frames will help compression in those cases where the encoder decides to use b-frame. -> with growing max b-frame count the b-frame count will help less (relatively), since i.e. more than 6 b-frames are normally not so often. So the difference between 6 and 16 b-frames will not be that 'EXTREMLY'. Same goes for max references; yes, higher numbers can help but the gain from 6 to 16 isn't really that much. (+ using such high references numbers or max b-frames really hurts hardware compatibility)

as a side note, here are the effects of '--tune animation':

animation (psy tuning):
                                    --bframes {+2} --deblock 1:1
                                    --psy-rd 0.4:<unset> --aq-strength 0.6
                                    --ref {Double if >1 else 1}

[DrDeceit]

updated info
still doing more tests

[Selur]

would be nice if you could also post the encoding times needed for the different encodes,.. (I mean not everybody would be happy with a X% if it 'costs' Y% in speed)

[DrDeceit]

would be nice if you could also post the encoding times needed for the different encodes,.. (I mean not everybody would be happy with a X% if it 'costs' Y% in speed)

So far I've done 5 encodes

doing more

[Selur]

doing more

Nice

here some premature* conclusions:
1. #1 Reference Frames = 1, Maximum B-frames = 0 -> 2.43GB
okay, now we got a basis
2. #2 Reference Frames = 1, Maximum B-frames = 6 -> 2.43GB
-> boosting maximum b-frames doesn't help at all
3. #3 Reference Frames = 3, Maximum B-frames = 6 -> 2.30GB (5.35% more compression, 0% increase in encoding time)
-> boosting the number of references (while using CAVLC) gives ~5% better compression without loosing speed
4. #4 Reference Frames = 6, Maximum B-frames = 6, CABAC -> 2.04GB (16.05% more compression, 25% increase in encoding time)
-> atm. useless on it's own, since it can't be compared to others since more than one parameter changed,...
5. #5 Reference Frames = 16, Maximum B-frames = 16, CABAC, 8x8 Transform, Weighted P-frames -> 2.03GB (16.46% more compression, 105% increase in encoding time)
-> atm. useless on it's own, since it can't be compared to others since more than one parameter changed,...

*premature because:
a. comparisons need to be done one multiple sources to be sure
b. 4.-6. don't help atm. to gain any conclusion, since more than one parameter changes (one can only say that the encodings get slower and produce smaller files)

[DrDeceit]

Doin some more encodes

[jagabo]

All your encodings show bframes=0. You're looking at P frames (forward prediction only), not B frames.

[DrDeceit]

All my encodings just don't show the amount of b-frames
not 0

[poisondeathray]

All my encodings just don't show the amount of b-frames
not 0

x264 lossless doesn't use b-frames (they are disabled)

http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=6a4a9beae060d69bbeaeb8c1c3056fb6ae6765f6


Also, for lossy encoding , just because you enter "x" b-frames doesn't mean they are actually used. (e.g. if you enter 8, maybe a string of 5 might be used) . Do you recall I mentioned to look at the log file in one of your other threads? The details are listed there .

--b-adapt 2 is not multithreaded very well (but it's more accurate), so raising max consec b-frames tends to dramatically increase encoding times . By looking at your log file, you can customize your settings and select the proper number of b-frames in a 2pass encode (You only have to look at the 1st pass)

[jagabo]

Another thing you should keep in mind -- when you are using b-frames -- is that b-frames are normally encoded with higher quantizers (lower quality). That is responsible for most most of their bitrate savings (compared to p-frames which are only forward predicted), not the bidirectional encoding. Use the --pbratio option and you'll see.

[DrDeceit]

All my encodings just don't show the amount of b-frames
not 0

x264 lossless doesn't use b-frames (they are disabled)

http://git.videolan.org/gitweb.cgi/x264.git/?a=commit;h=6a4a9beae060d69bbeaeb8c1c3056fb6ae6765f6


Also, for lossy encoding , just because you enter "x" b-frames doesn't mean they are actually used. (e.g. if you enter 8, maybe a string of 5 might be used) . Do you recall I mentioned to look at the log file in one of your other threads? The details are listed there .

--b-adapt 2 is not multithreaded very well (but it's more accurate), so raising max consec b-frames tends to dramatically increase encoding times . By looking at your log file, you can customize your settings and select the proper number of b-frames in a 2pass encode (You only have to look at the 1st pass)

I was really beginning to suspect as much

Well, I shall do just a few more H264 lossless encodes, and then I shall do some lossy encodes so I can figure out this b-frame sitation

And yes I know, the B-frames setting is just for the "maximum" consecutive b frames

just like if you set the max bitrate for something, it might never even reach that level, its just an encoding setting that sets the limit