The new B-frame decision (--bframes 16 and you)

[burfadel]

Ah ok! thats fair enough then :) I'm currently using 6 b-frames with skystrife's build, the speed loss is quite significant. The cpu use is less, as suggested that it may be, but even if it were back to ~98 percent say, it would still be significantly slower than the current method. That said, the results are worth it! Are there many speed optimisations in the works for this patch?

[Dark Shikari]

Sorry getting a little confused now so should --weightb be in both passes? and should --b-adapt 2 be in just the first pass or both? :-)Weightb should be in both passes.

--b-adapt can be in both, but it'll only affect the first.

[gav1577]

Weightb should be in both passes.

--b-adapt can be in both, but it'll only affect the first.

Thanks Dark Shikari So having --b-adapt 2 in the second pass will have no benefit whatsoever ? :)

[LoRd_MuldeR]

Thanks Dark Shikari So having --b-adapt 2 in the second pass will have no benefit whatsoever ? :)

Since b-frame decision is made in first pass, using "--b-adpat 2" in second pass should have no effect at all...

[gav1577]

Since b-frame decision is made in first pass, using "--b-adpat 2" in second pass should have no effect at all...

Ok thanks LoRd_MuldeR ;)

[tetsuo55]

i have some questions, hope you can answer them and correct me if i am wrong.

First i am assuming that B-frames are not limited by Levels.

So from what i read in this thread i can conclude the following:

-The new decision method leads to better phychovisual results
-The new decision method leads to better psnr in most cases, regardless of this phycovisually it looks better
-The new decision method leads to a better compression rate
-All of this gets better and better as the number of b frames increase from 1-16
-This all comes at a base slowness cost that increases exponentially from 1-16 at every 4 steps.


If what i'm saying is correct the only reason not to always use b-frames 16 is the speed-hit, and if that could be fixed then b-frames 16 could be the default right?

[LoRd_MuldeR]

If what i'm saying is correct the only reason not to always use b-frames 16 is the speed-hit, and if that could be fixed then b-frames 16 could be the default right?

If you read the very beginning of this thread, it was clearly said that with the new method 16 b-frames will be a speed killer.
Also you will see that most sources won't use more then ~6 b-frames anyway, even with the new method.
Therefore it makes sens to use the new method, but limit the number of b-frames to a sane value, such as 6 b-frames.

Dark Shikari also mentioned that he might add some heuristics to speed-up the new method ...

[Dark Shikari]

-This all comes at a base slowness cost that increases exponentially from 1-16 at every 4 steps.Linearly, not exponentially.

[bkman]

So is the whole 1st pass 16x slower at 16 b-frames then, or just the b-frame portion of it?

Btw, I've done a full encode with Skystrife's latest build and b-adapt 2. No crashes :)

[Dark Shikari]

So is the whole 1st pass 16x slower at 16 b-frames then, or just the b-frame portion of it?Just the B-frame portion.

[akupenguin]

Quadratic, not linear. The B-frame part is 147 times slower with 16 B-frames than with 1.
It will be linear when I'm done reusing all the motion estimation data.

[kemuri-_9]

actually i'm experiencing a unique phenomenon on my computer for the increase of b-frames on --b-adapt 2:

well firstly, i got 7.37 fps for --bframes 6 which ended up with
x264 [info]: consecutive B-frames: 0.0% 0.4% 0.0% 0.0% 0.0% 0.0% 99.6%
so i got interested and ramped it up all the way to --bframes 16 to see what it would generate on this anime (there's numerous fades and --weightb is on)
and ended up with
avis [info]: 720x480 @ 23.98 fps (29731 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast
x264 [info]: slice I:61 Avg QP:13.75 size: 25590
x264 [info]: slice P:1784 Avg QP:13.98 size: 16537
x264 [info]: slice B:27886 Avg QP:16.20 size: 3135
x264 [info]: consecutive B-frames: 0.0% 0.0% 0.0% 0.0% 0.0% 1.2% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 98.7%
x264 [info]: mb I I16..4: 14.1% 67.5% 18.5%
x264 [info]: mb P I16..4: 3.3% 20.0% 4.3% P16..4: 35.2% 22.1% 13.1% 0.2% 0.1% skip: 1.9%
x264 [info]: mb B I16..4: 0.4% 1.4% 0.3% B16..8: 31.5% 1.4% 1.8% direct: 6.7% skip:56.6% L0:51.6% L1:45.2% BI: 3.2%
x264 [info]: final ratefactor: 15.26
x264 [info]: 8x8 transform intra:68.7% inter:56.4%
x264 [info]: direct mvs spatial:99.8% temporal:0.2%
x264 [info]: ref P L0 42.3% 20.4% 11.3% 6.2% 4.1% 3.9% 2.5% 1.6% 1.3% 1.2% 0.9% 1.0% 0.8% 0.9% 0.8% 0.9%
x264 [info]: ref B L0 58.2% 14.9% 8.1% 5.1% 3.1% 2.5% 2.1% 1.2% 0.9% 0.9% 0.7% 0.6% 0.6% 0.7% 0.3%
x264 [info]: ref B L1 88.5% 11.5%
x264 [info]: kb/s:764.4

encoded 29731 frames, 9.61 fps, 764.42 kb/s

it encoded faster with more max bframes!

but i originally get about a 66% average cpu usage on the original with 6 bframes across my 4 cores and now i get about 85% usage with 16 bframes on my phenom 9850
(i have pthreads built in and have use -threads 4)
so.... even though it's actually faster it's also due to actually using more of my cores, so it's an interesting situation for me.

[Soichiro]

What confuses me more is that thing with 98.7% of bframes being in 16-frame sequences. What clip did you use? A still image repeated 29731 times? :p

In all seriousness though, are you sure you're using the latest version of the bframe patch? The old version had an odd bug that would cause long strings of bframes (though I had never seen 98.7% of a clip at 16 o.O).

[kemuri-_9]

it's an r2 dvdrip of the first episode of an anime called mushi-uta without the OP/ED since i plan on using matroska's segmentation feature to handle that.
I handed x264 an avs that loads an ffvh encoded lossless, this particular lossless is 3.67 GB
and yes, this is the 3rd revision of the patch that has been working for people as of late, which is the latest from what I've been reading as of yet.

[Ranguvar]

Any word yet on how and how much this increases subjective quality; anybody willing to upload sample clips? :D

I'm guessing that short clips will be much better than single frame comparisons for this patch :)

[tetsuo55]

thanks for the replies.


kemuri-_9's post basically explains why 16 can be a good idea, in sources that don't need them they simply aren't used.

As soon as the b-frame picker finds the upper limit, and is sure it could abort further efforts, just keep trying till it finds the upper limit.

In that case it would stop at 6 most of the time for live action and go all the way to 16 for static images and fades in antimated videos.

If done correctly assuming its even possible, the speed hit for 16 would only be noticeable on encodes that actually need that many....

Kinda like dynamic b-frames

[Dark Shikari]

thanks for the replies.


kemuri-_9's post basically explains why 16 can be a good idea, in sources that don't need them they simply aren't used.

As soon as the b-frame picker finds the upper limit, and is sure it could abort further efforts, just keep trying till it finds the upper limit.The algorithm doesn't work this way though; there's no obvious way to do such a thing.

[kemuri-_9]

to actually perform something like that, x264 would have to run through a full pass then would look at the produced consecutive b-frame statistics and if it's over some threshold percentage of the given max bframes, it would then rerun it again with an increased count of some arbitrary/semi-arbitrary amount, which the new pass may do the same thing again depending on the increase amount and whether the 16 max bframe maximum was encountered.

so in other wounds, not very feasible for x264 to do this itself.

it can't do this midstream either as it's still accumulating data with frames encoded in the future are not guaranteed to produce statistics similar to ones already encountered

all in all, it's best to do nothing and leave it to the user discretion.

[Avenger007]

Any advice for choosing B-frame mode (--direct spatial or auto) in CRF and 2-pass modes for the new B-frame decision?

[Dark Shikari]

Any advice for choosing B-frame mode (--direct spatial or auto) in CRF and 2-pass modes for the new B-frame decision?Auto is always best, of course.

[Sharktooth]

auto isnt so efficient for 1 pass encodings. i dont think this was ever changed.

[chainring]

auto isnt not so efficient for 1 pass encodings. i dont think this was ever changed.
Is that the reason for Spatial being chosen in the meGUI CRF presets?

[Sharktooth]

yes, and in all 1 pass presets.

[TheRyuu]

Any advice for choosing B-frame mode (--direct spatial or auto) in CRF and 2-pass modes for the new B-frame decision?

As said by DS himeself:
auto is almost surely going to be better
the speed vs quality tradeoff in onepass is not as good as is in twopass though

[kemuri-_9]

Quadratic, not linear. The B-frame part is 147 times slower with 16 B-frames than with 1.
It will be linear when I'm done reusing all the motion estimation data.

any progress coming along on that or have you been too busy from working on other aspects of x264?

[wata]

previously i am using bframes 16 with all my crf encode
so now i have update x264 to build 937 - Jarod's patched build,
should i stay at bframes 16 or lower to it
and to what value?

[DarkZell666]

previously i am using bframes 16 with all my crf encode
so now i have update x264 to build 937 - Jarod's patched build,
should i stay at bframes 16 or lower to it
and to what value?

Read the first post ... :mad:

[wata]

i have read dont understand
it said coming soon
so is the new b-frame decision in build 937 - Jarod's patched build?

[DarkZell666]

i have read dont understand
it said coming soon
so is the new b-frame decision in build 937 - Jarod's patched build?

http://forum.doom9.org/showthread.php?p=1171274#post1171274

Edit : + http://forum.doom9.org/showthread.php?p=1172240#post1172240

[kemuri-_9]

if you are using 16 bframes w/ b-adapt 1 (the default) then you don't have to worry about anything.
However, if you are using 16 bframes w/ b-adapt 2 (the new patch) then just be prepared for it to go incredibly slow:
i do encodes with 16 bframes w/ b-adapt 2 and it makes pass 1 go about 25% the speed of pass 2 on my quad-core system.
the code murders threading efficiency and the processing will mostly reside on a single core, or at least as far as I've seen from my own usage.

so if you are using b-adapt 2 with an 'absurdly high' bframe count, then i would recommend just using a single thread on pass1 to not have --pre-scenecut be active.
for 16 bframes there was only a minor speed decrease from using several threads to just 1 (again as far as my own usage has gone).

[burfadel]

Once the patch is finalised I'm guessing the threading issue will be (for the most part) resolved. DS has stated that the patch does require efficiency tuning, at the moment I'm guessing it to be classified as a 'proof of concept' patch. 'Proof of concept' means it just shows the capability of the patch, and is in no part tuned for efficiency in terms of speed! That said, with the new patch 16 will be slower than say 6 even with the optimisations, but ideally for those concerned with a good b-frame number without sacrificing too much speed 6 is the suggested consecutive b-frame number. If the speed optimisations go to the extent that a higher number doesn't have so much of an impact then a higher number may be suggested in the future for speed vs efficiency :)

[Avenger007]

ideally for those concerned with a good b-frame number without sacrificing too much speed 6 is the suggested consecutive b-frame number.
Since when?

From first post:
in the interests of speed you may want to lower the --bframes value to 3-5 or something otherwise reasonable.
--bframes 3 seems to be the most practical for most videos.
I'm guessing going from --bframes 3 to --bframes 6 would generally offer much less quality improvement when compared with --ref 3 to --ref 6, for example.

[Sharktooth]

no... refs gain is usually less than b-frames gain.
obviously much depends on the source.

[Sagekilla]

If you check the number of b-frames used, 6 is more or less the point where more B's is useless. Anything beyond that and I generally see around 0 - 0.5% usage.

[Dark Shikari]

no... refs gain is usually less than b-frames gain.
obviously much depends on the source.wrong again... bframes 3 to 6 give almost no benefit for the vast majority of sources, while ref 3 to 6 is guaranteed to help at least a bit.

[Sharktooth]

not from the test i did some time ago.
in low and very low motion movies (long scenes, almost no action...etc) b-frames are very helpfull.
obviously, as i said, much depends on the source and what you're used to encode.

[burfadel]

With the official b-frame decision there isn't much benefit going from 3 to 6, but with the new method there does seem to be a good benefit between 3 and 6 :) although as DS said it depends on the source. I concur that the speed loss of going higher than 6 is not worth it given the small benefit of doing so gives. Sunjectively I didn't notice any picture quality differences, but the file sizes were slighly smaller with each higher number of b-frames (say 6,8, 10, 12, 16) out of interest! This doesn't really affect crf mode, but may improve the quality ever so fractionally in ABR mode.

It was mentioned by someone somewhere that 6 was a good figure, and I agree with that! 6 for both ref and b-frames covers most sources, although animation can benefit from setting the ref frames even higher from my experience.

[kemuri-_9]

I mostly work with animation sources and have noticed significant percentage of 14+ bframe sections with the new patch often.

but yes, it's all source dependent, that fact has never changed

[Sagekilla]

In that case 16 B-frames is highly useful for you ;) I tend to use 16/16 on refs/B's for anime anyway, since I want to get it compressed as small as possible and I don't mind waiting the extra time.

[Soichiro]

I mostly work with animation sources and have noticed significant percentage of 14+ bframe sections with the new patch often.

but yes, it's all source dependent, that fact has never changed

I have reason to believe that's a bug, actually. It was supposedly fixed, but there was at least one report (post-bugfix) where something like 98% of b-frames were in 16-frame sequences, which is something that should really only occur in a 98%-still video.

And yes, b-frames are much more beneficial than ref frames on many sources (at least according to my tests), however once you get above 6 for each the benefits become unnoticeable except at low bitrates/high crf.

[Sagekilla]

It sounds unlikely to be a bug, as anime can easily use up a huge number of B's. If this was real life video, then I'd have reason to believe something is fishy.

[Avenger007]

Quadratic, not linear. The B-frame part is 147 times slower with 16 B-frames than with 1.
It will be linear when I'm done reusing all the motion estimation data.
Is efficiency the reason why the B-frame decision patch hasn't been committed as yet?

[wyti]

i think it's one of the reason, the second may be that --b-adapt-2 brake multithreading efficiency (about 60% on a quad core)

[Dark Shikari]

i think it's one of the reason, the second may be that --b-adapt-2 brake multithreading efficiency (about 60% on a quad core)Sure, if you insist on doing retarded things like --bframes 16 with it...

[Adub]

What's this? It's not smart to use --bframes 16? I was going under the impression that 16 bframes works quite well for anime (which is why I would use 16 bframes).

[Dark Shikari]

What's this? It's not smart to use --bframes 16? I was going under the impression that 16 bframes works quite well for anime (which is why I would use 16 bframes).Hint: read the original post in threads you respond to.

[Adub]

Ah, see I thought you were saying that it negatively affected quality or something. I knew about the speed hit, and I am perfectly okay with it. I have encountered numerous instances where the full 16 bframes were used a majority of the time, and I have time, so I let my encodes run on "retarded" settings from time to time.

[Comatose]

What are you running on? (CPU)

I was encoding at seconds per frame with my "retarded" settings :\ (C2D E6420)

[Sagekilla]

Sounds extremely excessive.. I use very, VERY slow settings on 720p sources with heavy prefiltering and I still get 2-3 fps on my Opteron 170 (2 GHz) and closer to 4+ on my C2D @ 2.16 GHz. Something is definitely wrong with your settings if you're going by seconds by frame.

[cogman]

Sure, if you insist on doing retarded things like --bframes 16 with it...

:P What, you should have made B-Frames multithreaded. 1 Thread for every b-frame... (Yes, I am kidding)