Need guidance using curve compression

[Brother Darrell]

While encoding Syriana, I noticed a big problem on the scene starting from frame 627 to frame 1059 (23.976). The problem? FOG. Specifically FOG against a DARK background. (Blue grey?) Not alot of detail, very slow pan. Horrible blocking unless I set the quant at 1-1.33. Blocks become noticeable past that.
I try to use as little filtering as possible. The exceptions are Undot,(because it was such a Gknot standard and never seemed to hurt anything), and Tweak(setting saturation to 1.25).
I use HVS-BEST matrix. Size is 720x308. To combat the blockiness, without applying more filtering. I decided to adjust the curve compression. I also fed it ALOT more bitrate.
Now it looks great during playback. But the file looks like a fat toad taking up harddrive space. I used WAY too much bitrate to acheive my goal.
My understanding of curve compression amounts to "Rob from the rich, give to the poor". So how does Xvid decide which scenes are bitrate poor? What does it use to determine the threshhold of low bitrate to high bitrate? I know, for example , %90+ this movie looks great using an average bitrate of 1450. This appears to be the effecient bitrate. But the fog scene requires much more. Xvid, on its own, doesn't see it that way. How do I make it see things my way?
Without getting too detailed (unless I have to..) I want to know, is there a way to define a minimum allowable bitrate? In effect, telling Xvid that if bitrate drops below this threshhold, consider it too low and add more. I know I can define a ceiling, but how to define a floor?
Which leads to the next question. MUST I set C-high & C-low proportionately (C-low=20 C-high=10). Or are they independant of each other? Mind you, I don't mind giving extra bitrate to the needy, but not at the expense of high rate scenes that really need it. Any suggestions?
I don't consider this as a movie specific problem. I think this is a good thing for me to have a grasp of for all future encodes.

[foxyshadis]

You're very unlikely to get curve compression to fix fog scenes. The problem is xvid's analysis decides fog isn't complex and isn't worth spending much bitrate on, when it's just the opposite. (And high-bitrate matrices will only make blocking worse, by their nature.) You'd be better off setting a zone for anything really mangled, because by the time you raise curve compression to the point where it makes a noticable difference, it'll be wasting tons on other non-complex scenes, and probably dragging the harder scenes down.

You can definitely set a maximum quantizer if you need a minimum bitrate/quality (more effective than a simple minimum bitrate floor).

[Brother Darrell]

Ahh. I was suspicious of the matrice, though, by my (current) reasoning, I also thought it would raise the bitrate by default. Because of the extra detail. But with fog, there AIN'T no detail. Just a defined haze. I also see the logic behind using zones instead of a bitrate floor,(though I think a bitrate floor could be used effeciently in many respects)
The negative side to it would be, truly low bitrate scenes becoming needlessly heavy.
And you are correct (obviously) about curve compression.
I used 20/10 as an example only. The actual percentage I used was 76/38..and a bit rate of 2000.
The only issue I have with zones, is that they are so scene(s) specific.
Something more general, such as a bitrate floor, would have an advantage in several instances (advantage #1 = less typing :D ). A bitrate floor would also allow curve compression to be used in a more effective manner, Meaning I would not have to define c-low & c-high with the ridiculious margins I needed. (That is.. providing of course, raising the floor does not mean I have to lower the ceiling to compensate). But all of that is,... wouldn't it be cool if...stuff. The practical approach is, I believe, what you described. Use zones. As far as a Matirce (Matrix?). What would you suggest? I want to preserve as much detail as practical.

[foxyshadis]

The more a matrix is inclined to spending bitrate on detail, the less it will on the lowest frequency elements along the borders, which manifests itself in blocking. Vice versa, you end up with less blocking and more ringing. With a lower-detail matrix you also automatically get more bits applied to areas with lower detail but higher quants, just because they're now closer to the average detail level of the video.

To be honest, I don't know what'd be the right tradeoff. If you can pull the qpel hack (encode just that segment with, say, V3ULR, and join them all together), that'd be one rather labor intensive option. If you really need the eye-popping detail from HVS-Best, it might be the only option other than a zone. =\ I guess you could compare that one scene at some bitrate with a few different matrices to see which is less objectionable while still detailed enough in the rest of the movie for you.

The feasibility of the other ideas, I guess only Syskin or the devs can chime in.

I'm all for hearing how other people deal with times when the codec falls over in fog and haze though. (Might help in x264 too, which often suffers the same problem, to a lesser degree.)

[Brother Darrell]

Uhhh, ARE C-high/C-low dependent or independent of each other?

[henryho_hk]

People said enabling Trellis would help.

Can you host a small clip somewhere for us to test? ^_^

[Didée]

You're very unlikely to get curve compression to fix fog scenes. The problem is xvid's analysis decides fog isn't complex and isn't worth spending much bitrate on, when it's just the opposite.
It's the other way round. If the fog scene is of low complexity, then during 1st pass, this scene's bitrate will be below average. And if it's bitrate is below average, then using cc-low will give this scene more bitrate during 2nd pass.


(And high-bitrate matrices will only make blocking worse, by their nature.)
Huh? I'm using 6of9 pretty much, and would say that low complexity scenes come out pretty fine in my encodes. (Given that the average bitrate basically isn't too low, of course.)


You'd be better off setting a zone for anything really mangled
Very true, though it's laborous work.

What'd be needed is some volunteers to explore the possibilities of XviD's HVS-plugin (http://xvid.ist-dein-freund.de/short.html) ... (i'm too busy.)

There's also a sort-of thread about it in this forum: >link (http://forum.doom9.org/showthread.php?t=114811)<


My rule of thumb for XviD's curve compression is rather easy. Given I roughly know the average quantizer that will be reached (which is, with 6of9, usually q4~q4.5 for me), I set minimum quant to average-2 (rounding down), maximum quantizer to average+2, and use curve compression in the range of cc-low 20~25, cc-high = 30~40. (Exact values come mostly from the guts ... 24/36 is a good allrounder.)

[Prettz]

I'm all for hearing how other people deal with times when the codec falls over in fog and haze though. (Might help in x264 too, which often suffers the same problem, to a lesser degree.)
Whenever I have a scene with extremely fine detail (especially when the scene is dark and all high-chroma), I use a weight zone with a very high (probably uselessly high) weight and an extremely low b-frame sensitivity to pretty much disable b-frames. This is for when, because of the bitrate, the scene was already coming out to all Q2 with all Q3 b-frames, but still looked terrible. Some of the times I've done this, part of the problem I was trying to solve was fog/smoke, but not always, so this may not be adequate to handle fog scenes in general.

For animation, eliminating b-frames from the zone always seems to be a good first step to preventing the worst-looking blocking in fog/smoke scenes, though.

I wish Xvid had a feature to use different quant matrices in zones. As I understand it, as long as you insert a new VOP (???) header with the new matrix in it, it's valid for ASP. And you could put a pop-up message box in the GUI warning the user, when they try to make the zone have a different matrix, that hardware decoders might not handle the video.

[Brother Darrell]

People said enabling Trellis would help.

Can you host a small clip somewhere for us to test? ^_^

Sure, But is that allowed? I mean uploading a clip from this movie, wouldn't be a problem. But I don't want to face a lawyers wrath because of it. Of course it would be original source. VERY small clip. I would just have to find someplace to host it.

[Brother Darrell]

My rule of thumb for XviD's curve compression is rather easy. Given I roughly know the average quantizer that will be reached (which is, with 6of9, usually q4~q4.5 for me), I set minimum quant to average-2 (rounding down), maximum quantizer to average+2, and use curve compression in the range of cc-low 20~25, cc-high = 30~40. (Exact values come mostly from the guts ... 24/36 is a good allrounder.)

So I gather that C-low & C-high are not independent of each other. But not as dependent as I was thinking? Or at least not as linearly dependent as I was thinking? Maybe I'm using the wrong values then. I derived my C-low setting from simply playing with it.. 76% came from the fact that it was this setting which gave me a noticeble result. My C-high setting came from thinking..okay if I set c-low to 76% , then I need to proportionately lower the c-high to compensate. Wrong approach?
BUT If they were truely independent of each other, then problem solved. This would in fact give me a bitrate floor without complex scenes suffering.
However, your approach suggests they, of course, are dependent on each other, but not linearly so?

I downloaded the HVS build of Xvid encraw & would be happy to test it, if I knew the relevent parts to test. I have to admit though, the expression LAMBDA just makes me think of stupid sheep.

[squid_80]

I wish Xvid had a feature to use different quant matrices in zones. As I understand it, as long as you insert a new VOP (???) header with the new matrix in it, it's valid for ASP.
The header is not allowed to change throughout the stream.

[Prettz]

The header is not allowed to change throughout the stream.
Alright. What all is allowed to change in the file?

Back in the days of Modulated Quant there were discussions about this, and it was mentioned that in ASP you could repeat one of the headers, holding a copy of the new custom matrix, to legally use different quant matrices in a single file. Was that all rubbish?

[foxyshadis]

In raw m4v, mp4, or mkv, the VOP header cannot be repeated - but you can store multiple streams in mkv, at least. The problem is support. Since this counts as a corner case, splitters and decoders simply don't support re-initializing at video stream boundaries. In fact you might need to reinitialize directshow to do it, because the codec itself can change in mkv. (I was just testing mpeg4 chained to mpeg1, crash city.) I wouldn't mind the delay just to have it working.

In avi, the VOP header repeats every GOP, and decoders (at least Divx and Xvid, maybe lavc) will reinitialize on VOP changes. That's how the qpel credits hack works, and who knows, it might work for matrices too.

More trivia, since I don't think it's a really good idea to do it.

I'm too tired to finish investigating some stuff, so I'll just drop it. Plus I don't have offhand a really good fog scene to test with.

[Prettz]

In avi, the VOP header repeats every GOP, and decoders (at least Divx and Xvid, maybe lavc) will reinitialize on VOP changes. That's how the qpel credits hack works, and who knows, it might work for matrices too.

Oh, that's interesting. That's obviously what I remember hearing. I've put together an Xvid encode (with no b-frames, as they were still sort of unsafe for quality when I did this) with a scrolling credits sequence that was encoded with GMC, put it into .ogm, and it worked like a charm with ffdshow. GMC made the compression on the credits incredible, way more than you'd ever get with 2 b-frames. Highly illegal for hardware decoders, of course.

[Brother Darrell]

Here is a link to the fog scene. I hope there is enough to it for proper testing.
http://www.sharebigfile.com/file/10647/Fog-scene.m2v.html

[henryho_hk]

I compressed the clip using Teegedeck's >90% preset at 1000kbps.

http://rapidshare.de/files/35052474/fog.avi.html

You can take a look at it's quality. This is a pretty compressible clip and I think the real challenge is not to let the codec allocating too much to other parts of the movie, leaving too little to this portion.

[Brother Darrell]

I compressed the clip using Teegedeck's >90% preset at 1000kbps.
You can take a look at it's quality. This is a pretty compressible clip and I think the real challenge is not to let the codec allocating too much to other parts of the movie, leaving too little to this portion.


It certainly looks better on the opening scene than what I was getting. But the 1st shot of the folks waiting on the bus appears blocky. (But still better than what I was getting at the same bitrate.) I know about the presets. Did not think to try any of those. Must they be used only with Megui or can Xvid Encraw use them direct?

[henryho_hk]

I wrote a win2k/xp batch script implementing Teegedeck's great presets as well as compressibility test, all using xvid_encraw. If AVI's size is > 2GB, it will use ffmpeg.exe to convert it into OpenDML AVI.

http://forum.doom9.org/showthread.php?p=882250#post882250

[squid_80]

I'm finishing off testing new avi writing code for encraw, it will write opendml avi's when necessary.