Activate trellis in p8x8 qpel RD

[gav1577]

Hi guys has anyone else noticed quite a big speed hit since
Activate trellis in p8x8 qpel RD was added is it normal for me me to lose about 2 to 3 fps second since this was added ?

Thanks

[Soichiro]

It does say in the changelog that it will cause a large speedhit when subme 7 + trellis 2 is on.

[LoRd_MuldeR]

As the log says:

commit 3c3dc3cde75e72b7c212a9a9ddd623ef8a617e41 r950
Author: Jason Garrett-Glaser <darkshikari@gmail.com>
Date: Tue Aug 26 14:51:29 2008 -0400

Activate trellis in p8x8 qpel RD
Also clean up macroblock.c with some refactoring
Note that this change significantly reduces subme7+trellis2 performance, but improves quality.
Issue originally reported by Alex_W.

[gav1577]

Thanks guys i know this just wasn't expecting it to be that much of a hit and wanted to know if others were experiencing the same type of speed hit as i have

[Dark Shikari]

Yes, the lack of trellis in p8x8 RD was a bug/omission, and while fixing it helps quality, it does hurt speed a good deal.

[gav1577]

Yes, the lack of trellis in p8x8 RD was a bug/omission, and while fixing it helps quality, it does hurt speed a good deal.

Thanks for the answer and thanks for the good work :)

[Sagekilla]

How much of a quality increase do we gain for this? Or bitrate reduction at same crf? :)

[wyti]

Depend of the source.
p8x8 i used about 5-10% of the time so i think you can hope about 3-5% quality gain (plz correct me if i'm wrong)

[Dark Shikari]

Depend of the source.
p8x8 i used about 5-10% of the time so i think you can hope about 3-5% quality gain (plz correct me if i'm wrong)Certainly not, since the whole of trellis 2 gives nowhere near that kind of quality gain... also note this patch affects 8x16 and 16x8 also.

[Comatose]

So, um, is there a way to turn it off (other than turning Trellis off)? If the gain isn't amazing, the speed trade off doesn't seem worth it... most of us are already running masochistically slow encodes, so... :\

Probably not, but then, may I suggest that if a quality improvement (even if it's a bug fix) isn't similar in significance to the speed hit it causes, then there should be a way to disable it from the CLI?

x264 already achieves very good quality, but right now when you use trellis 2 it's a package deal: comes with this slow down or you have to disable trellis (yeah, obvious)... but by the sound of OP's post, the speed hit is huge, and I don't want that speed hit nor do I want to disable the rest of Trellis, so... yup.

I hope my logic makes sense, even though it's kinda retarded :\

[wyti]

sorry for the mistake.

@Comatose :
You can try to use trellis 1 which is not used every time (only on the final encode of a macroblock)

[Dark Shikari]

So, um, is there a way to turn it off (other than turning Trellis off)? If the gain isn't amazing, the speed trade off doesn't seem worth it... most of us are already running masochistically slow encodes, so... :\

Probably not, but then, may I suggest that if a quality improvement (even if it's a bug fix) isn't similar in significance to the speed hit it causes, then there should be a way to disable it from the CLI?

x264 already achieves very good quality, but right now when you use trellis 2 it's a package deal: comes with this slow down or you have to disable trellis (yeah, obvious)... but by the sound of OP's post, the speed hit is huge, and I don't want that speed hit nor do I want to disable the rest of Trellis, so... yup.

I hope my logic makes sense, even though it's kinda retarded :\Your logic doesn't make sense; Trellis 2 is slow, if you don't like it, don't use trellis 2. It got slower because we had forgotten to put trellis in a place it was supposed to be according to the description of trellis 2.

[J_Darnley]

I have done some (quick) testing between r949 and r950 (was that correct?) and I could not notice much speed loss or quality gain. I used two pass encoding with identical settings and the final speed differences were all between 2% and <1% slower for the first pass and 5% and 1% slower on the second. The PSNRs were all between 37.95 and 38.02 of each other and the SSIMs were also between 0.921 and 0.922.

Settings : -bframes 16 --b-pyramid --ref 8 --deblock -1,-1 --partitions all --direct auto --weightb --me umh --subme 7 --b-rdo --mixed-refs --bime --8x8dct --trellis 2 --no-dct-decimate --progress --threads 3
If there are any comments about these then please say.

[gav1577]

I also just run some tests of a 200mb cut from a 1920x1080 bluray movie. I resized to Spline36Resize(1280,720).msharpen(10,15,true) and made a 2 pass with the same exact settings between both revisions of x264

Pass 1] --level 4.1 --ref 3 --mixed-refs --bframes 3 --bime --weightb --direct auto --filter -1,-1 --subme 5 --partitions none --vbv-bufsize 14000 --vbv-maxrate 18000 --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --aud --nal-hrd --sar 1:1 --output

Pass2] --level 4.1 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --filter -1,-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --chroma-qp-offset -2 --vbv-bufsize 14000 --vbv-maxrate 18000 --me umh --merange 32 --threads auto --thread-input --progress --no-psnr --no-ssim --psy-rd 1.0:0.0 --aud --nal-hrd --sar 1:1 --output

results for 2nd pass r949 = 9.56 fps
results for 2nd Pass r951 = 8.79 fps

Correct me if im wrong but i make it a speed decrease of 8.759954493742905% for second pass. Obviously i was mistaken in my first post
with the hit being 2 to 3 fps so it looks like its not as much of a decrease as i first thought.

[Comatose]

That's okay then >:3

Your logic doesn't make sense; Trellis 2 is slow, if you don't like it, don't use trellis 2. It got slower because we had forgotten to put trellis in a place it was supposed to be according to the description of trellis 2.
My logic was that, yeah, Trellis 2 is slow, but Trellis 2 without this still provides an improvement, and I thought that this change provided a rather small quality improvement but had a huge hit on speed, so it wasn't worth it - but I still wanted the rest of Trellis. "Sort of Trellis 2", I guess XD

[Dark Shikari]

That's okay then >:3


My logic was that, yeah, Trellis 2 is slow, but Trellis 2 without this still provides an improvement, and I thought that this change provided a rather small quality improvement but had a huge hit on speed, so it wasn't worth it - but I still wanted the rest of Trellis. "Sort of Trellis 2", I guess XDUse trellis 1 then...

[Comatose]

But it's not what I wanted - I wanted to turn off what you added in this patch, and still have trellis run on all instances :x
It's kinda stubborn and retarded, but yeah. And nevermind, since I'm encoding with it myself now and the speed is reasonable.

[wyti]

In that case x264 devs should create a new option called --trellis-bug (sound nice isn't ?)
trellis 2 should be used on ALL decision mode, this include p8x8.
And with the small speed gains here and here, in some revisions you will not notice the speed down, but a quality gain at the same speed.
or you can modify one other parameter on your command line to reach the same speed.

[J_Darnley]

Comatose, if you want to use x264 without this commit then I suggest you build it yourself.

[Comatose]

What I suggested was that if something is added (even if it's a bugfix) and it has a large impact on speed, then you should be able to disable it...

But:
And nevermind, since I'm encoding with it myself now and the speed is reasonable.

[LoRd_MuldeR]

Why should it be possible to disable a bugfix? You get a bug fixed, you get some extra quality and you pay for it with some speed-loss. That sounds pretty good to me!
If at all, a new Trellis mode that lies between Trellis=1 and Trellis=2 could be added. But I highly doubt this will happen, because Trellis=0, Trellis=1 and Trellis=2 give enough choice already...

[Comatose]

The thing is that I was under the impression that it wasn't some speed loss, but a lot of speed loss, and it didn't seem worth it.

[IgorC]

Correct me if im wrong but i make it a speed decrease of 8.759954493742905% for second pass.
You will be good to calculate speed of light. :p
But here to say "9%" is already more than enough good approximation. The difference will be even bigger/smaller for different videos.

[gav1577]

You will be good to calculate speed of light. :p
But here to say "9%" is already more than enough good approximation. The difference will be even bigger/smaller for different videos.

lol it was a online percentage calculator i used guess it was a bit ott .Yes it was just a small test obviously different sources would would be variable :)

[Quark.Fusion]

I also just run some tests of a 200mb cut from a 1920x1080 bluray movie. I resized to Spline36Resize(1280,720).msharpen(10,15,true) and made a 2 pass with the same exact settings between both revisions of x264

[…]

results for 2nd pass r949 = 9.56 fps
results for 2nd Pass r951 = 8.79 fps

Correct me if im wrong but i make it a speed decrease of 8.759954493742905% for second pass. Obviously i was mistaken in my first post
with the hit being 2 to 3 fps so it looks like its not as much of a decrease as i first thought.
IMHO, you should measure speed on already preprocessed fast-to-read-and-decompress source.

[gav1577]

IMHO, you should measure speed on already preprocessed fast-to-read-and-decompress source.

Hey why don't you do some tests have a go and let us know what your findings are i have no idea what you are on about to be honest im still a noob ;)

[Quark.Fusion]

Hey why don't you do some tests have a go and let us know what your findings are i have no idea what you are on about to be honest im still a noob ;)
Sorry, currently encoding 1.3 fps source… Guess what? x264 uses only 23% of cpu from that process, even if it will be 2 times slower encoding time will increase only by that 23%.

[Comatose]

"1.3 fps source" meaning you are doing heavy Avisynth filtering?
If you're doing multipass, you should really, really filter to lossless then encode from that.

Plus you might not be satisfied with the quality, and having to go through 1.3 fps again is... shrug.

[LOGiC]

I also just run some tests of a 200mb cut from a 1920x1080 bluray movie. I resized to Spline36Resize(1280,720).msharpen(10,15,true) and made a 2 pass with the same exact settings between both revisions of x264

Pass 1] --level 4.1 --ref 3 --mixed-refs --bframes 3 --bime --weightb --direct auto --filter -1,-1 --subme 5 --partitions none --vbv-bufsize 14000 --vbv-maxrate 18000 --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --aud --nal-hrd --sar 1:1 --output

Pass2] --level 4.1 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --filter -1,-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --chroma-qp-offset -2 --vbv-bufsize 14000 --vbv-maxrate 18000 --me umh --merange 32 --threads auto --thread-input --progress --no-psnr --no-ssim --psy-rd 1.0:0.0 --aud --nal-hrd --sar 1:1 --output

results for 2nd pass r949 = 9.56 fps
results for 2nd Pass r951 = 8.79 fps

Correct me if im wrong but i make it a speed decrease of 8.759954493742905% for second pass. Obviously i was mistaken in my first post
with the hit being 2 to 3 fps so it looks like its not as much of a decrease as i first thought.

GAV,

which CPU do you use ? I just opened another thread this morning. I was testing with a 1920x1080 re-encode yesterday with my new Q9400 CPU. I also tried to use Subme7 together with Trellis2, but I just get around 3,5fps, which is in my opinion too slow. It is not overclocked. As my Vista64 hasn't been delivered yet, I did install my old XP32, dunno if this can cause any speed differences with 4GB RAM ?

[nurbs]

He encodes 720p, you encode 1080p so you get about half the speed he has. If his source is easier to decode that also gives him some edge. The ram shouldn't make any difference for the encoding itself, but some of the avisynth plugins require a lot, especially with HD content. That is only important if you plan on doing heavy preprocessing and in that case you can count on a serious drop in encoding speed.

[Rumbah]

lol it was a online percentage calculator i used guess it was a bit ott .Yes it was just a small test obviously different sources would would be variable :)

Actually, the speed decrease is just about 8% with your numbers, you calculated the speed increase of the old method over the new (8.8%). Yeah, I know, nit-picker ;) .

[gav1577]

GAV,

which CPU do you use ? I just opened another thread this morning. I was testing with a 1920x1080 re-encode yesterday with my new Q9400 CPU. I also tried to use Subme7 together with Trellis2, but I just get around 3,5fps, which is in my opinion too slow. It is not overclocked. As my Vista64 hasn't been delivered yet, I did install my old XP32, dunno if this can cause any speed differences with 4GB RAM ?

Hi logic i use a q6600 overclocked to 3.6Ghz and XP x86