Advantages of Trellis RD?

[temporance]

I can't see any improvements from this feature - in fact, it occasionally creates 8x8 artifacts in my video. Does anyone have any test results, or annecdotal evidence that this is worth enabling?

Also, how can it possibly improve anything? The default quantizer is surely pretty good, IMHO.

I don't mean to be too negative in this post, it's great to see more and more great features in xvid. I guess I'm just hoping to learn :)

[Nibor]

I did a couple of tests with this feature...
Did two two pass encodes (at same filesize of course, bitrate at about 800) one with and one without trellis r-d. Than I compared the two with the ultimate comparing tool called "human eye" :p :D
I found that the quality of the trellis one was definitely better!
Ok, sometimes (but quite rare (or what's the opposite of often?)) it has this "inverted luma block" artifact, but that's something I can live with...

-> In my encodes I turn this fancy thing always on :)

Cheers!

[shirka]

there's something I don't understand, ok for using Treillis RD with H.263 quantizer, but with MPEG quantizer ? does it change anything ? does it worth using it ?
++

[Koepi]

It only works with h263 quant.

Regards
Koepi

[Selur]

Are there any plans to support RD with other matrices (normally I use a custom matrix), in upcoming releases?
Or is this not possible, for some reason?

Cu Selur

[Koepi]

If I understood it correctly, trellis r-d is only defined for h263 quant matrix. If the concept is portable to other matrices is still investigated, but noone is seriously coding that ATM, there are other priorities AFAIK ;)

Regards
Koepi

[sysKin]

Originally posted by Koepi
If I understood it correctly, trellis r-d is only defined for h263 quant matrix. If the concept is portable to other matrices is still investigated, but noone is seriously coding that ATM, there are other priorities AFAIK ;)Actually no ;) Trellis R-D can be done for mpeg-type quant just as easly (lol, it's not easy at all) as for h263. Gruel just hasn't done it yet, because the code we have needs to prove stable and working. As we can see with this luma thingy, it's not perfect yet.
BTW you don't have to 'live' with inverted luma blocks, it's definitely a bug, not a side-effect.

Radek

[Koepi]

Thanks for clearing that up sysKin :)

Regards
Koepi

[Selur]

yeah thx, and nice to read/hear that trellis might also come for mpeg-type matrices, somewhere in the future ;)

Cu Selur

[Teegedeck]

Indeed. I just like the MPEG-quant's look much more than that of H.263.

Praise the devels...

[Sigmatador]

any chance for the HVS-good matrix (my prefer's :D)

[sysKin]

Originally posted by Sigmatador
any chance for the HVS-good matrix (my prefer's :D) MPEG quant type includes both default and any non-default matrix, of course :)

[dimzon]

Is Trellis Quantizer safe for MPEG4 specs or not?

[CruNcher]

yes it is btw crystal player isn't the "best player" gee allways those advertisers :rolleyes:

[DevilsChild]

What happens if I try to use Trellis with an MPEG type quant like HVS-good? Does XviD just disable Trellis?

[Alxemi]

What happens if I try to use Trellis with an MPEG type quant like HVS-good? Does XviD just disable Trellis?

Devilschild: please read the thread more carefully before posting, Syskin answered that question just three posts before yours.

[Soulhunter]

Source:

The Matrix - Lobby Shootout / 3:07 min. @ 25fps / 1024x576 pix. (Lanczos)


Results:

Quantizer2 / No B-Frames / H.263 / VHQ 0
Size: 123.623.424 Bytes / Avg. PSNR: 47.97 / Time: About 04:58 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 1
Size: 124.694.528 Bytes / Avg. PSNR: 48.57 / Time: About 06:29 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 2
Size: 123.168.768 Bytes / Avg. PSNR: 48.57 / Time: About 09:48 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 3
Size: 122.978.304 Bytes / Avg. PSNR: 48.56 / Time: About 13:05 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 4
Size: 121.458.688 Bytes / Avg. PSNR: 48.54 / Time: About 16:43 min. (2600XP)


Quantizer2 / No B-Frames / MPEG / VHQ 0
Size: 142.090.240 Bytes / Avg. PSNR: 47.89 / Time: About 04:59 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 1
Size: 143.366.144 Bytes / Avg. PSNR: 48.16 / Time: About 06:53 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 2
Size: 140.619.776 Bytes / Avg. PSNR: 48.18 / Time: About 10:53 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 3
Size: 140.079.104 Bytes / Avg. PSNR: 48.18 / Time: About 14:47 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 4
Size: 136.732.672 Bytes / Avg. PSNR: 48.17 / Time: About 19:43 min. (2600XP)


Quantizer2 / No B-Frames / H.263 / VHQ 0 / Trellis
Size: 122.200.064 Bytes / Avg. PSNR: 48.00 / Time: About 05:30 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 1 / Trellis
Size: 122.939.392 Bytes / Avg. PSNR: 48.57 / Time: About 07:10 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 2 / Trellis
Size: 121.387.008 Bytes / Avg. PSNR: 48.56 / Time: About 10:10 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 3 / Trellis
Size: 121.141.248 Bytes / Avg. PSNR: 48.56 / Time: About 13:35 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 4 / Trellis
Size: 119.625.728 Bytes / Avg. PSNR: 48.53 / Time: About 17:26 min. (2600XP)


Quantizer2 / No B-Frames / MPEG / VHQ 0 / Trellis
Size: 139.116.544 Bytes / Avg. PSNR: 47.85 / Time: About 05:42 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 1 / Trellis
Size: 140.228.608 Bytes / Avg. PSNR: 48.11 / Time: About 07:35 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 2 / Trellis
Size: 137.605.120 Bytes / Avg. PSNR: 48.14 / Time: About 11:40 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 3 / Trellis
Size: 137.111.552 Bytes / Avg. PSNR: 48.14 / Time: About 15:34 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 4 / Trellis
Size: 133.941.248 Bytes / Avg. PSNR: 48.13 / Time: About 20:30 min. (2600XP)


Quantizer2 / No B-Frames / H.263 / VHQ 0 / QPel
Size: 129.626.112 Bytes / Avg. PSNR: 47.80 / Time: About 06:56 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 1 / QPel
Size: 129.744.896 Bytes / Avg. PSNR: 48.62 / Time: About 09:03 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 2 / QPel
Size: 128.079.872 Bytes / Avg. PSNR: 48.61 / Time: About 16:32 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 3 / QPel
Size: 128.034.816 Bytes / Avg. PSNR: 48.60 / Time: About 23:10 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 4 / QPel
Size: 127.442.944 Bytes / Avg. PSNR: 48.59 / Time: About 26:42 min. (2600XP)


Quantizer2 / No B-Frames / MPEG / VHQ 0 / QPel
Size: 152.709.120 Bytes / Avg. PSNR: 47.52 / Time: About 07:05 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 1 / QPel
Size: 158.093.312 Bytes / Avg. PSNR: 48.13 / Time: About 09:16 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 2 / QPel
Size: 154.347.520 Bytes / Avg. PSNR: 48.14 / Time: About 19:00 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 3 / QPel
Size: 153.978.880 Bytes / Avg. PSNR: 48.13 / Time: About 27:03 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 4 / QPel
Size: 152.594.432 Bytes / Avg. PSNR: 48.12 / Time: About 31:23 min. (2600XP)


Quantizer2 / No B-Frames / H.263 / VHQ 0 / QPel / Trellis
Size: 128.229.376 Bytes / Avg. PSNR: 47.82 / Time: About 08:00 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 1 / QPel / Trellis
Size: 127.983.616 Bytes / Avg. PSNR: 48.62 / Time: About 09:43 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 2 / QPel / Trellis
Size: 126.255.104 Bytes / Avg. PSNR: 48.60 / Time: About 16:12 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 3 / QPel / Trellis
Size: 126.142.464 Bytes / Avg. PSNR: 48.59 / Time: About 23:52 min. (2600XP)

Quantizer2 / No B-Frames / H.263 / VHQ 4 / QPel / Trellis
Size: 125.497.344 Bytes / Avg. PSNR: 48.58 / Time: About 27:23 min. (2600XP)


Quantizer2 / No B-Frames / MPEG / VHQ 0 / QPel / Trellis
Size: 150.673.408 Bytes / Avg. PSNR: 47.49 / Time: About 08:19 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 1 / QPel / Trellis
Size: 155.584.512 Bytes / Avg. PSNR: 48.09 / Time: About 10:34 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 2 / QPel / Trellis
Size: 151.709.696 Bytes / Avg. PSNR: 48.10 / Time: About 19:50 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 3 / QPel / Trellis
Size: 151.121.920 Bytes / Avg. PSNR: 48.09 / Time: About 28:07 min. (2600XP)

Quantizer2 / No B-Frames / MPEG / VHQ 4 / QPel / Trellis
Size: 149.676.032 Bytes / Avg. PSNR: 48.08 / Time: About 33:45 min. (2600XP)


Bye

[thejho]

@Alexmi: No he didn't, all syskin and koepi said was that currently Trellis RD doesn't work with mpeg and custom matrices. What Devilschild and I would like to know is whether enabling trellis with mpeg (or other) harms the encode, or has no effect at all. That's because I already encoded a DVD with both features on :p , and I'd like to know if it'd be worth to redo the encode ;) (which is quite feasible now, thanks to xvid amazing speed :D 25-30 fps on average)

[Koepi]

SysKin wrote that it IS possible to use trellis with any quant matrix now.

A single short test of cruncher showed no positive effect though - but that's just one sample, don't take that for real -it's not at all scientific/empiric :-)

Regards
Koepi

[thejho]

Ummm ?... :confused: seems I didn't get anything... well I'll take your word, I'm just too lazy to redo the encode after all... Thanks anyway !
Btw, it seems vhq higher than 2 or 3 doesn't help or even harms the encode, can anyone confirm that (sorry, a bit OT)?

[Nibor]

Originally posted by thejho
Btw, it seems vhq higher than 2 or 3 doesn't help or even harms the encode, can anyone confirm that (sorry, a bit OT)?
Are you referring to Soulhunter's post?
Then take a closer look!
You'll notice that the PSNR stays about the same the higher the VHQ setting goes, but filesize decreases
-> if it would use the same filesize, quality would be higher :)

Well, of course this is only an assumption of mine, so do your own testing ;)

Regards!
Nibor

[thejho]

Thanks, I indeed overlooked that... Anyway I heard that with recent builds vhq could only improve quality, so it was kind of a dumb question :p .

[dimzon]

Originally posted by CruNcher
yes it is btw crystal player isn't the "best player" gee allways those advertisers :rolleyes:
Please answer "Yes, it safe" or "No. it's not safe"

[Teegedeck]

No, it isn't. It will explode in your face and sell your car to a hoodlum from Mars.

What do you expect? It is fine, what more do you want to know? Cruncher has answered your question already and just because you ask twice none of the developers will come forward and swear an oath that it is safe. :D This is just free and funky software, nothing that steers an aeroplane. Use it and have fun. It is safe, really.

[ivanova]

According to Soulhunter's post, VHQ1 only increases filesize and takes longer. So it's better to use VHQ0 unless you use VHQ2 or more. Could you do the same test with a low motion scene?

Edit: Just saw that PSNR also increases with VHQ1 - VHQ4. So it is not so simple. But PSNR does not realy tell you if it's better quality?

[Koepi]

PSNR can be misleading, right, but we tested VHQ with our eyes as well. It wouldn't have make it into the betas/release candidate if it weren't working as this.

Regards
Koepi

[ivanova]

I agree, I still would use VHQ because it looks better. I just didn't realise that VHQ1 results in bigger filesizes than VHQ0.

[Koepi]

ivanova:

a single test file doesn't tell the whole story. We tested different samples. It _always_ produced a smaller file with higher PSNR and better visual quality there. So we could say, nice sample found where this isn't the case (file size grew). Though in 2pass, you'll still have a higher quality at the same filesize.

Koepi

[sysKin]

As much as PSNR can be misleading, looking at the filesize is completely and absolutely wrong.

The test was made at fixed quantizer and therefore is pretty useles. Two-pass encoding for fixed filesize, with PSNR, would be the way to do that.

Radek

[Kb_cruncher]

I always use Trellis.I have done many visual tests with it and to me it defianatly gives better overall quality and brings back a little sharpness to H.263 matrix.It also increases compressability by quite a bit too.Actually Adaptive Quantisation give the smallest file size but introduces too many artifacts for me.

[crusty]

Actually Adaptive Quantisation give the smallest file size but introduces too many artifacts for me.
Really, artifacts? I thought that was fixed? Are you talking about RC1 or earlier builds?

What type of artifacts exactly?

[Teegedeck]

I regard AQ safe, too. The only occasion where you should not use AQ under any circumstances is cartoons/anime. It does not look good with plain, uniformously coloured areas.

Apart from that, I've checked those scenes that once were 'dangerous' with AQ, like very dark scenes or rays of light, and typically AQ is not used on such frames, from what I saw. Seems all A-OK to me.

[Soulhunter]

Originally posted by sysKin
As much as PSNR can be misleading, looking at the filesize is completely and absolutely wrong.

The test was made at fixed quantizer and therefore is pretty useles. Two-pass encoding for fixed filesize, with PSNR, would be the way to do that.

Radek
Is looking at the filesize really completely and absolutely wrong ???

Lot ppl make a comp. test to see how good a movie are to compress...

AFAIK its calculated with a fixed q2 encode as indicator...

So if settings increase the size of a fixed q2 encode, they also drop the compressibility this way !!!

I thought this way...

Settings that would give a 150MB file @ quantizer 2, would more tend to produce artifacts when compressing it to 50MB than settings that would give a 100MB file @ quantizer 2 !!!


Only done this tests because I mostly do fixed quant2 encodes !!!

Thought its nice to share the results... :rolleyes:

But of course, anyone can do test with other settings self... ;)


Bye

[ivanova]

Originally posted by Soulhunter
Settings that would give a 150MB file @ quantizer 2, would more tend to produce artifacts when compressing it to 50MB than settings that would give a 100MB file @ quantizer 2 !!!


Well put. I agree.
I also tested a clip with more low motion frames, and the filesizes decreased smoothly with VHQ0-VHQ4 as expected.

[Assault]

@ Soulhunter, ivanova

Originally posted by Soulhunter
Settings that would give a 150MB file @ quantizer 2, would more tend to produce artifacts when compressing it to 50MB than settings that would give a 100MB file @ quantizer 2 !!!

Generally you can't say that this is the case. Don't forget that the 100MB will mostly have worse quality than the 150MB file! So you can't assume that the 100MB file will have better quality than the 150MB file when compressed to 50MB. ;)

Assault

[MfA]

Originally posted by Soulhunter
Is looking at the filesize really completely and absolutely wrong ???

Yes, if you are doing it to test the efficiency of mechanisms which actually change the quantization it is stupid. We might call it fixed quant, but in reality it is far from it. Adaptive-quantization/trellis-search/quantizer-matrices/b-frames all change quantization, there is nothing fixed about it (would a quantizer matrix be better just for producing smaller files at quant2 coding?).

Lot ppl make a comp. test to see how good a movie are to compress...

If you have a little experience you can predict the level of artifacting you will get for a given filesize and a given level of pre-processing (resizing/blurring/etc). This is just another form of multipass coding, here it is usefull.

So if settings increase the size of a fixed q2 encode, they also drop the compressibility this way !!!

I can change the code in the trellis search to give you any level of compressibility you want, using just quant2 !!!

As soon as you start dicking around with the quantization process the fact that quant2 is used becomes utterly meaningless, it is just one factor in the process.

[ivanova]

Originally posted by Assault
@ Soulhunter, ivanova



Generally you can't say that this is the case. Don't forget that the 100MB will mostly have worse quality than the 150MB file! So you can't assume that the 100MB file will have better quality than the 150MB file when compressed to 50MB. ;)

Assault

You can say it because the 100MB and 150MB file should be nearly the same (both at Q2) This is confirmed by the PSNR tests.

[Assault]

Originally posted by ivanova
You can say it because the 100MB and 150MB file should be nearly the same (both at Q2) This is confirmed by the PSNR tests.

I think MfA explained it much better than I'm able to but I'll try nevertheless. ;)
You can't infer the quality of an encode from the quanitzer used. Make one encode with the h.263 matrix and a constant quantizer of 2 and another one with the Andreas_87er Matrix and a constant quantizer of 2. You'll soon realize that the quality of the encodes is different.
Furthermore don't judge an encode by its PSNR but make you own tests and use your eyes instead. You'll be surprised about the results. :)

Assault

[ivanova]

Originally posted by MfA
Yes, if you are doing it to test the efficiency of mechanisms which actually change the quantization it is stupid. We might call it fixed quant, but in reality it is far from it. Adaptive-quantization/trellis-search/quantizer-matrices/b-frames all change quantization, there is nothing fixed about it (would a quantizer matrix be better just for producing smaller files at quant2 coding?).

I can change the code in the trellis search to give you any level of compressibility you want, using just quant2 !!!

As soon as you start dicking around with the quantization process the fact that quant2 is used becomes utterly meaningless, it is just one factor in the process.

But these tests have been done by using the same settings in each case. Only one setting was changed (VHQ). The point is: If you have some setting that gives you better compression at the same quality as another setting, the first setting would give better results at a fixed filesize than the second setting.

[ivanova]

Originally posted by Assault
I think MfA explained it much better than I'm able to but I'll try nevertheless. ;)
You can't infer the quality of an encode from the quanitzer used. Make one encode with the h.263 matrix and a constant quantizer of 2 and another one with the Andreas_87er Matrix and a constant quantizer of 2. You'll soon realize that the quality of the encodes is different.
Furthermore don't judge an encode by its PSNR but make you own tests and use your eyes instead. You'll be surprised about the results. :)

Assault

But we are not using the h.263 matrix and then the Andreas_87er Matrix. But I do understand your point. But by using the same settings, in the test, you minimise the effect of the different quantization factors, and can attribute the change in filesize to the setting you did change. I'm not saying it's a perfect test, but it gives some indication.

But the quality of the resulting clip must be nearly the same though and this must be tested. Visual comparison is best of coarse, but is much more difficult - so PSNR is used which I agree is not realy the best way of indicating that two clips are nearly the same. But again it gives a good estimation for quick testing.

[MfA]

Just because fixed quant testing sometimes corresponds to a usefull testing methodology such as fixed rate or fixed distortion testing cannot be used to justify it in it's entirety ... if the fixed quant testing only makes sense where it agrees with such methodologies the only conclusion can be that it is actually those methodologies that are valuable, and the fixed quant testing in itself is entirely inconsequential.

People who advocate fixed quant testing are putting the cart before the horse.

[sysKin]

Originally posted by ivanova
But we are not using the h.263 matrix and then the Andreas_87er Matrix. But I do understand your point. But by using the same settings, in the test, you minimise the effect of the different quantization factors, and can attribute the change in filesize to the setting you did change. I'm not saying it's a perfect test, but it gives some indication.OKay this test did show that VHQ4 is better than 3 and better than 2. PSNR was the same, filesize was smaller. However, it did not show anything about VHQ1, because it had better psnr but worse filesize.

I was rather referring to methodology, which was wrong. As MfA said, his is especially wrong when quantization changes (matrix/trellis/bframes/lumimasking) but *also* wrong for any other setting. Quant 2 is just one of many many factors which change filesize *and* quanity, and only keeping this single value constant doesn't mean anything. For example, VHQ can be changed to give you much smaller filesizes - just like first VHQ used to do.

[Kb_cruncher]

Originally posted by crusty
Really, artifacts? I thought that was fixed? Are you talking about RC1 or earlier builds?

What type of artifacts exactly?

No, i have not tested it with RC1.The last release i tested it with was Beta3.It tended to give definate ringing in some scenes(mainly static or low motion scenes).

If it was a bug and has been fixed in RC1 then i will definatly give it some more testing.

[Soulhunter]

Originally posted by MfA
Yes, if you are doing it to test the efficiency of mechanisms which actually change the quantization it is stupid. We might call it fixed quant, but in reality it is far from it. Adaptive-quantization/trellis-search/quantizer-matrices/b-frames all change quantization, there is nothing fixed about it...
No Adaptive-quantization !!!

No other quantizer-matrices than the 2 default ones... :rolleyes:

And also No b-frames in my test !!!

So you see, it was not a test about the efficiency of this mechanism's... ;)
Originally posted by MfA
I can change the code in the trellis search to give you any level of compressibility you want, using just quant2 !!!
Really ??? Wow... :eek:
Originally posted by ivanova
But the quality of the resulting clip must be nearly the same though and this must be tested. Visual comparison is best of coarse, but is much more difficult - so PSNR is used which I agree is not really the best way of indicating that two clips are nearly the same. But again it gives a good estimation for quick testing.
I thought the same way... ;)

Of course, eyes are alway the best quality identifier !!!

But telling what you "feel by seeing" is very difficult...

Also because ppl "feel & see" different ways... :rolleyes:

Should I write a short summary about every test encode ???

Say it this way...

I'm also not a big friend of this "quality metrics" !!!

Just done the PSNR test for completeness... ;)
Originally posted by sysKin
Quant 2 is just one of many many factors which change filesize *and* quantity, and only keeping this single value constant doesn't mean anything. For example, VHQ can be changed to give you much smaller filesizes - just like first VHQ used to do.
Ok, agreed... :rolleyes:

But it could be still useful for the ppl that telling you that their encodes are over or under-sized... :p

Because you can see what settings (Trellis, Qpel, MPEG/H.263 matrix) will raise or lower filesize !!!

Ok, you could also use smaller resolution and/or denoisers to lower the filesize...

Or you could use higher resolution and/or sharpening to raise the filesize !!!

But this test was not about filtering, It was only about the basic settings... :o



Hmm... I feel its nuff said about my "dumb" test now !!!

Back to the topic... ;)



Bye