Alt CC suggestions for Tron

[Ned]

I'm doing Tron on 2cd's at 640x288 with neutral bicubic and the h.263 quantizer.

I tried the alternate curve compression using "low" curve aggression and 100% for high and low distances (everything else default).

The results were fairly good although the output was about 100mb undersized, I said 1102531kb and got 1016453kb.

Tron is probably an unusual type of movie to encode, as it has many very dark areas with very strong contrasted colored lines and large areas of somewhat noisy color. I've tried doing it with Nandub+3.11a but the large colored areas are plagued by 3.11's problem with gradients. Temporal smoother 2,1 smooths out the noise but the overall effect is not desirable.

Any suggestions for high/low and should I go with low/medium/high?

[Teegedeck]

100% for low/high is something I'd give a second thought... That's really extreme. Imagine, this means that high and highest quantizers are used starting at a fairly low bitrate - twice the average bitrate that is. And that for a 2-CD encoding! [As I'm ignorant about how Foxer's algo actually scales the curve, I'm not sure whether I should talk about the original average bitrate of the movie, here, or about the resultant (scaled) average bitrate... :( I always wanted to ask Foxer but I forgot. So the values I had mentioned - I deleted them now - probably were nonsensical. If we're talking about the original movie's bitrate, one might get away with 100% if the curve isn't too dynamic.] If you left 'strength' enabled, I'd imagine it will prevent too nasty side-effects, but I'm not sure.

Try it with the default settings... Always try the default settings first.

[sierrafoxtrot]

try Hi 250 Lo 80 Med strength auto strength at 60% ...

;)

[Foxer]

@Ned
You say you left everything else at their defaults..
Tell me, what was the minimum relative quality set to by the automatic mode with 50% strength for that encode?

I'd like to know because, for me, the alt curve has always hit the desired size mark as long as it's at or less than the 1st pass's size.

@Teegedeck
It doesn't really matter whether you talk in terms of unscaled or scaled as long as you don't use one with the other.

And yea, 100/100 is rather aggressive.
I just took a gander at the stats file for my tron encode.
It's not too smooth heh so, without examining the quantizer thresholds of your encode Ned, I'd guess low aggression with low/high 100/200 would be ok.
With low aggression, you might even want to raise the low threshold a little by reducing the low distance to around 90% or so since the bitrate doesn't often drop that low.

@sierrafoxtrot, @Teegedeck and everyone else who's using alt curve
How have your encodes with alt curve done so far? :)

[Teegedeck]

@Foxer: I haven't encoded enough with alt. curve to really have a solid experience with it. After my first experiments with distances I decided to leave them at 300%. I haven't seen any indication EVER that beneath-average frames would need to receive quant=2 and I don't want to risk crippling big frames, so... If I want more variation in quantizers, I simply set a higher value for strength. But I'm quite content with a more levelled quant-distribution, say max quant for biggest frames=5.

As for curve-types, with a 'dynamic' bitrate curve (i.e. a movie with lotsa dimm and static scenes but also lotsa bright and detailed scenes), 'medium' (=linear) seemed to work best, it seemed to me that the other types tended to take away too much on the high or the low end. But that's really speculating, need to do more tests.

BTW, another thing that I always wanted to ask you; how is it possible to have a low distance of -300% of the average bitrate? Wouldn't that be negative value? 8)

Oh, have I mentioned that I believe to see an improvement in quality over my encodes with 'regular' CC?

[Foxer]

@Teegedeck
Whatever suites you best :)
I made it so one can have a fair amt of control

Originally posted by Teegedeck
As for curve-types, with a 'dynamic' bitrate curve (i.e. a movie with lotsa dimm and static scenes but also lotsa bright and detailed scenes), 'medium' (=linear) seemed to work best, it seemed to me that the other types tended to take away too much on the high or the low end. But that's really speculating, need to do more tests.
That's odd.. Low aggression should hold off the longest on adjusting the encoding quality 'till the framesize is very close to a threshold.

Originally posted by Teegedeck
BTW, another thing that I always wanted to ask you; how is it possible to have a low distance of -300% of the average bitrate? Wouldn't that be negative value? 8)

lol Yep :) That'd be average framesize * -2
It's just to shape the curve.

Originally posted by Teegedeck
Oh, have I mentioned that I believe to see an improvement in quality over my encodes with 'regular' CC?

Glad to hear it :)

[wing1]

@foxer

alt. C.C. is an excellent tool. I like it very much. Can't encode without it :D

So far low aggression L<=100 and 150<H<200 with 30<Strength<50 works wonder for me.

[Ned]

Foxer-

in auto mode it says 88 for min relative quality. I tried 100low/200high, 25% strength, high curve aggression and it came out somewhat better. But should I use low aggression instead?

I'm still kind of fuzzy on the effects of the alt cc parameters. The graphs are certainly nice to look at but I think many of us can't make a conclusion as to what they mean. Could you discuss relative to actual types of movie encoding situations as to how the parameters work?

e.g
when a movie is mainly slow and dark scenes, we should ........
fast and dark scenes
fast and bright scenes
noisy vs clean source
etc, etc

The info in the graphs is probably more meaningful to those here who know programming but it's harder to interpret by those of us who don't have any programming knowledge.

[Foxer]

This produced filesize problem is strange..

I've tested the rate control code in the vfw pretty thoroughly and it's almost perfect. It's accurate to 1 byte (except with credits)

I dunno exactly what is going on..

Originally posted by wing1
alt. C.C. is an excellent tool. I like it very much. Can't encode without it :D

So far low aggression L<=100 and 150<H<200 with 30<Strength<50 works wonder for me.
lol! That's fantastic lol
Best of luck with your future encodes :)

[Foxer]

Oops.. :(

I made a rather large mistake and really must apologize..

I had previously said it was accurate to within 1 byte or up to 3 bytes with credits.. The credits part was wrong.

I erroneously assumed that the credits code was as precise as the rest and didn't test with it because the credits setup code looked ok. ugh..

Sorry :(

[Ned]

Foxer-

Maybe I'm confusing 1000 with 1024 as a kb. I setup Tron in Gordian Knot and in the video size box it says "1102531" kb. So in the Xvid 2pass - 2nd pass Int that's the size i put. The resulting file was
1,016,453,000 bytes (my target size was 695mb x 2 parts). So after that I added 100mb (1202531) in the Xvid config and was much closer.

Is the GK size in kb just wrong for Xvid?

The AC3 file is 307mb with interleave overhead calc'd as 1 frame (42ms).

[Foxer]

@Ned
desired size KB = 1024 bytes.

If you aren't using any of the credits options, I have no idea why it's not hitting the desired size mark dead on :(

Every large encode I've done has reached the filesize I specify +- a few k as long as it's <= the 1st pass size and I haven't used credits.

The KB size GK gives you should be ok.


@anyone else
Has anyone else run into such undersizing problems with or without using credits (other than the previous inability to do a 2GB+ encode)?

[Ned]

I am using credits at end from 128875-137766 using I-frame quantizer 20.

But I also used the credits option when doing Atlantis and the sizing was within a few mb's. Not using lumi-mask at all. The undersize is consistenly the same as I've encoded the full movie 4 times with vastly different alt CC settings. The first 2 using the value GK said, the last 2 using the extra 99mb added which got me much closer (689mb + 687mb muxed with ac3).