CQ killers?

[Maury Markowitz]

This is from the Best Settings, but it seemed a little off topic there...

* Selecting 'Constant Quality' for quality;
* Setting the factor to 0.66 (the slider only accepts even numbers);

I've been experimenting with use CQ with a couple of action titles. With PAR the output is identical in size to DVD Player so it's easy to pause on key frames and look for problems. This wasn't so easy in the past, when the encoded movie was physically smaller -- is that jaggy due to the encode or QT scaling it up on-screen?

When I was looking through the best settings thread it struck me that there were a lot of "this looks good" cases, but there weren't that many mentions of whether or not it was compared back to the original DVD. So I encoded a variety of sources for sampling, and then sat down and automated a test run of four encodes on two titles. I encoded Transformers and Animatrix in full at 50%, 56, 60, and 66, and 2001 at 60 and 66, and then compared them all against each other and the original DVD. I was going to do the same with 2001, but ended up using only 60 and 66 in this case.

I can't find a single case where 60% wasn't completely indistinguisable from the original DVD (ignoring the QT gamma problem anyway). The breakpoint was 60; the encodes at 50 and 56 were definitely lower quality, while 66 was identical to 60. My copy of 2001 is obviously a crap transfer, so it wasn't a very good test case.

So I have a couple questions:

1) am I looking in the right places? I looked for examples with text overlayed on a moving background, oversaturated areas around window frames, and in the case of Transformers, explosions during the night-time scene near the opening.

2) maybe I'm just using the wrong examples? I chose the two specifically for the action in one case, and the sharp edges of the animation in the other. But maybe these two just encode well. Does anyone have a favorite title that kills QC?

3) Also, an I right in reading between the lines that a CQ encode that ends up producing some bitrate xxx would be basically identical to selecting that bitrate as the average and using two-pass? IE, is there something the test pass finds that the single-encode CQ doesn't?

Maury

[Bear Hunter]

CQ or CRF?

[jbrjake]

is that jaggy due to the encode or QT scaling it up on-screen?

Probably QT. Its scaler is [Censored] beyond reason and explanation. It's using all sorts of fancy Core technology stuff but still somehow looks like ass.

When I was looking through the best settings thread it struck me that there were a lot of "this looks good" cases, but there weren't that many mentions of whether or not it was compared back to the original DVD.

One of many reasons that thread is almost entirely useless. Quality is so subjective, especially without controls for video metrics, displays, playback software, etc.

2) maybe I'm just using the wrong examples? I chose the two specifically for the action in one case, and the sharp edges of the animation in the other. But maybe these two just encode well.

Yep. Animation is extremely easy to encode, as are shiny new action movies that are basically computer-animated films to begin with.

If you want difficult content, go for something with a lot of film grain, like Dazed and Confused, or that has to use lots of reference frames to handle strobing lights, like a concert video.

I, personally, don't find 60% to be good enough, or even 64%. I'm happier at 69% or 70%.

3) Also, an I right in reading between the lines that a CQ encode that ends up producing some bitrate xxx would be basically identical to selecting that bitrate as the average and using two-pass? IE, is there something the test pass finds that the single-encode CQ doesn't?

A 2-pass at the same average bitrate as a CRF encode will be slightly higher in quality, but probably not to the extent you'd notice it. It'll show up in metrics, but just barely, and not in a statistically significant way.

[Honeyko]

Get ahold of "Superman Doomsday", and encode the first couple chapters (which contains the "fireburst" opening credits). Certain cartoon films, with long "limited" animated sequences (in which the tiniest of artifacts stands out like a raisin on a china plate) sandwiched inbetween intense action scenes, can really break encoding tools. Blocking will really stand out, as will "halos" over people's heads.

(FWIW, I couldn't get reasonable 264 output on that particular movie at any decent time/space savings combination, and in the end just encoded it at 3000 avg bps MPEG4. The output was large, but it was 60% of original with original AC3 audio, and looked gorgeous...and rendered insanely fast compared to the newer codecs. It's bigger than I'd like, but at least I won't regret it a few years down the road when I play it again on a new, huge display.)

[SteveB]

I've got may Mac back together, music backed up et al, and returned my mind to the CQ offering. I've encoded a chapter or two of two comedies - BlackBooks and Red Dwarf using a number of different encodings. (in the following Cav means his preferences specified in the 'My Favourite Settings' thread, for TV shows:

• * Apple TV preset
  * Cavalicious preference - CQ 66 ('Cav 66')
  * Cavalicious preference with lower quality - CQ 60 (Cav 60)
  * Cav 56
  * Cav 50
  * An ABR 2000, two pass, with a bunch of stuff added to slow down / improve quality

For BlackBooks (UK sitcom circa 2003 - 16/9 native aspect), file sizes for a 15.2 minute chapter were:

• * AppleTV preset : 300.4 Mb
  * Cav 66 : 369.9 Mb
  * Cav 60 : 209.0 Mb
  * Cav 56 : 145.0 Mb
  * Cav 50 : 93.0 Mb
  * ABR2000+ : 240.0 Mb

For Red Dwarf (UK sitcom circa 1990 - 4:3 aspect ratio) file sizes were:

• * Apple TV : 167.8 Mb
  * Cav 66 : 216.0 Mb
  * ABR2000+ : 134.3 Mb

The two pass ABR 2000 failed a couple of times before it worked - which is why I don't usually use two pass encoding.

The interesting thing to me is the change in file size from 370Mb to 93 Mb moving from 50% to 66%. This suggests a pretty large variation. Interestingly, on my 81 cm (32 inch) TV I didn't really detect much difference in the quality on a quick watch.

I suspect from this that CQ in this case set at 65 would coincide with Apple TV preset, whereas at 66 it is 30% higher! Very sensitive in this case.

I wonder if a more linear measure for CQ could be developed. I remember seeing a description of the CQ measure, just can't recall where.

[jbrjake]

The interesting thing to me is the change in file size from 370Mb to 93 Mb moving from 50% to 66%. This suggests a pretty large variation.

I suspect from this that CQ in this case set at 65 would coincide with Apple TV preset, whereas at 66 it is 30% higher! Very sensitive in this case.

I wonder if a more linear measure for CQ could be developed. I remember seeing a description of the CQ measure, just can't recall where.

It's *not linear*...compression rates follow a logarithmic scale. It's represented with a slider because OS X doesn't have curved widgets, and sliders require things to be linear percentages.

[Maury Markowitz]

The two pass ABR 2000 failed a couple of times before it worked - which is why I don't usually use two pass encoding.

Based on other comments here, I'm skipping it in favor of CQ as a matter of course.

I suspect from this that CQ in this case set at 65 would coincide with Apple TV preset, whereas at 66 it is 30% higher! Very sensitive in this case.

Yeah, there's absolutely a breakpoint in terms of quantity/size right around there.

Maury

[Maury Markowitz]

Get ahold of "Superman Doomsday", and encode the first couple chapters

Ok, I'll give that a try. I looked at some screen snaps on the 'net and it seems this will be a tough encode no matter what -- lots of fine detail black lines bordering very different color swatches on either side.

Blocking will really stand out, as will "halos" over people's heads.

Ok, but here's my question: have you noticed any difference when you use a two-pass constant rate set to the same rate as the CQ encode ended up with?

and in the end just encoded it at 3000 avg bps MPEG4.

Interesting! So you were willing to take a quality hit in this case because 264 wasn't up to it either? Or are you saying the MP4 was better able to deal with this particular source?

Maury