Regarding Turbo and Trellis Settings

[kalorx]

Hi all. Question: if I turn on Turbo speed and Trellis quantization, what sort of quality hit can I expect? I've heard that activating them can greatly decrease encoding time, but also that quality might (might?) be affected. However, no source I've yet looked at tell me just _how much_ quality will lower. I'm a bit of a quality freak, so I'm wary about using the settings.

Thanks,

Robert Aronson

[sysKin]

Hi all. Question: if I turn on Turbo speed and Trellis quantization, what sort of quality hit can I expect? I've heard that activating them can greatly decrease encoding time, but also that quality might (might?) be affected. However, no source I've yet looked at tell me just _how much_ quality will lower.

It's difficult to tell "how much", right? :)
Turbo, when active, makes encoding faster (especially if you use qpel) and the quality drop should not be noticeable.

Trellis... keep trellis on. Speed gain from removing it is measurable but small, while it's doing a really good job.

I'm a bit of a quality freak, so I'm wary about using the settings.
Well then, turbo off, trellis on for you. It's the default anyway.

[kalorx]

So wait, Trellis actually _decreases_ speed but can also decrease quality? Now I'm rather confused. I always heard that Trellis makes things faster, and might negatively affect quality in some cases...

As for being a quality freak, I'm not so sure I'm enough of a quality freak that I want to cripple my PC for 40+ hours. I don't have a separate PC for encoding. Ever since I started encoding videos at the proper DVD display resolutions of 852x480 (16:9) and 860x366 (2.35:1) (rather than 640x360/272), and at much higher bitrates (2500-3000+), XviD has been taking far longer than a single overnight period to encode on 2-Pass.

If I activated Turbo, how much of that 40+ hour encoding could I kill, and what would I really be doing to my poor video? :scared:

Thanks,

Robert Aronson

[unskinnyboy]

To Trellis or not to Trellis? and To Turbo or not to Turbo? are age old questions which have been hashed out here and the discussions died down about 2 years ago at least. There used to be a time where every other day you would see a thread on one or other of the XviD features, mostly asking what are the advantages or disadvantages of using them. Use search and you will get your reading material going into detail about the pros and cons of these 2 options.

My quick & summarized answer is:


Trellis is good. Always good. No idea where you heard that it will decrease quality. Probably some age-old thread during the time when Trellis RD implementation was still rudimentary or you mixed it up with what Turbo does.



Turbo isn't good for quality. When using Turbo, there is a speedup in encoding and a drop in quality. Period. Whether you perceive that quality loss or not, whether you consider the time saved as considerable or not, are both subjective matters. Now how much time will you save from an expected 40+ encoding time cannot be said for sure because there are too many variables there to know for sure other than actually testing it and see. 10%, 20%..who knows, try it and see.

Basically whatever sysKin said.

[Teegedeck]

Well-said.

[foxyshadis]

If I activated Turbo, how much of that 40+ hour encoding could I kill, and what would I really be doing to my poor video? :scared:
Unless you have a P3 or something, it's not xvid's fault. For the sake of testing I turned everything up near maximum and turned it on a dvd: with no filtering, xvid's thread runs faster than the decoding thread and spends a lot of time idle. Of course with any filtering, even just ivtc/deint, xvid will only run that much faster than the script.

What I'm trying to get at is that if avisynth is taking 35 hours and xvid 5, all the fiddling in the world with xvid's options can never make it take less than 36 or so, and you should concentrate on speeding up your script or accepting the slowdown.

[kalorx]

Alright guys, thanks for the info! I apologize for not using the search function... I usually do. I guess I was just impatient this time.

Thanks,

Robert Aronson

[iNFO-DVD]

Doing my own tests today I must say I've been pleasantly surprised by the trellis option. First off, doing my own tests with both turbo ON and OFF didin't really make any real different in quality that I could see, just a slight change in speed.

I did some tests on trellis and at first the results appeared the same, slight difference in speed, nothing noticed quality wise.

So I lowered the bitrate as I wanted to get to a stage where I could see some deteriation/break-ups/blocks e.t.c. So I converted a VOB clip to:

640x272
XVID (XVID0041)
AC3
b/p (QF) 0.17
754 bitrate (2-pass)

During the playing of this clip quality was fine, but on closer inspection I was able to grab a frame that was showing signs I was after (for test). I then did the same encode, everything as before, except for choosing the TRELLIS option.

At these lower bitrates for this picture size is where trellis actually seemed to show it's worth.

The picture on the left is WITHOUT trellis, the picture on the right, WITH. Look at the white section, near bottom left, you'll notice the blocks, where as with the trellis they're gone, or close to it. Much better, and very pleased with this result.

http://www.dvduk.pwp.blueyonder.co.uk/__img/_forum/Sample.png

Hope the picture helps in your question concerning trellis.

A final though, you may not actually be able to see what I'm refering too with a CRT monitor, the good thing about LCD monitors is you can see the problem areas far easier and obviously with my saving of the screenshots e.t.c. has also had an impact on the differences.

[kalorx]

Interestingly, I have a CRT monitor and was still able to readily see the displayed differences. I _did_ mention I was a quality freak. :)

Anyway, what I'm really surprised about is the image clarity you got with a bitrate of only 754. Back when I was encoding at 640x272/360 I virtually always used a bitrate between 1100 and 1500, and the image clarity was seemed quite that nice (who knows, maybe it was?). I had enabled 2-Pass, QPel, GMC, adaptive MPEG quantization, max VHQ, VHQ for bframes, max motion search, all the chroma optimizations, and every other quality setting imaginable (except Trellis...).

You must have been working with a low-motion video or something. Either that, or you're using some sort of advanced quantization and/or weighted bitrate method that I never bother using because it hurts my brain to do so. :) Or I'm just missing something really obvious and I'm too tired to think of it...

The thing I once noticed was that with all those aforementioned options enabled, a moderate-motion 640x272 23.976fps video looked pretty great at a 2-pass bitrate of 1500. I did a quick calculation on how many bits that was per pixel in a frame, and came out with 116.0533 repeating. To this day, that's how I judge the intended bitrate of my videos: find out how many pixels they have in a single frame and divide by 116.0533. There's probably something very wrong with that approach, but it hasn't failed me yet. :)

Thanks,

Robert Aronson

[henryho_hk]

640x480/116 ~= 2650 ... kbps !

That's a quite a high bitrate~~

[iNFO-DVD]

what I'm really surprised about is the image clarity you got with a bitrate of only 754.I just used avi.NET.

or you're using some sort of advanced quantization and/or weighted bitrate method that I never bother using because it hurts my brain to do so.No advanced anything, no qpel, gmc or mpeg quant.

a moderate-motion 640x272 23.976fps video looked pretty great at a 2-pass bitrate of 1500. I did a quick calculation on how many bits that was per pixel in a frame, and came out with 116.0533 repeating.I don't understand how you got that, a bitrate of 1500 on a 640x272 23.976 is 0.36 (0.359).

Anyway, glad the piccy was of some help.

[kalorx]

I don't understand how you got that, a bitrate of 1500 on a 640x272 23.976 is 0.36 (0.359).

It's simple: multiply 640x272 (for example). You get 174,080. Then divide 174,080 by 116.0533. You end up with approximately 1500. I use that method to determine the bitrate for whatever I encode.

For an actual 2.35:1 video, I use a resolution of 860x366 (the actual DVD display resolution with black bars cut out). The amount of pixels in a single frame is 314,760, and dividing that by 116.0533 gives me the number 2712. A 2-hour 23.976 film comes out at about 1.5-1.6GB with normalized stereo Vorbis sound at q4. 16:9 videos will obviously come out the largest, given the amount of pixels in a single frame.

I basically just reached the point where I said, "I have a DVD burner. Why am I trying to fit all my videos onto CDs?" That's when I decided that as long as a video didn't get larger than 2.35GB (half a 4.7GB DVD) I didn't care how large it got.

It's actually a pretty good method; combined with ColorMatrix.dll when necessary, there's virtually no discernable loss of quality in the transfer so long as the detelecining or deinterlacing is done right and you're not looking at it frame for frame.

Actually, I don't know what you're talking about with the "0.359" thing. Are you talking about the quality setting?

Thanks,

Robert Aronson

[Teegedeck]

I'm sure the '0.359' figure is the GKnot bitrate-pixels-fps thingy. In the end it is rather comparable to your idea of 'normalizing' bitrate in order to make it comparable.

(BTW, both values mean next to nothing.)

[iNFO-DVD]

You get 174,080. Then divide 174,080 by 116.0533. You end up with approximately 1500.I see, well I only mentioned it because you said bits per pixel, that's not bits per pixel. It all gets to the same thing though, it gives us a value we can start with. The value I mentioned was bits/pixel, look at GSpot in the QF box.
I basically just reached the point where I said, "I have a DVD burner. Why am I trying to fit all my videos onto CDs?" That's when I decided that as long as a video didn't get larger than 2.35GB (half a 4.7GB DVD) I didn't care how large it got.I know exactly what you mean.
I'm sure the '0.359' figure is the GKnot bitrate-pixels-fps thingyI've never used GK, it wasn't supposed to mean anything as such, it was just a statement of what it was, bits/pixel.