idea about zones

[Blue_MiSfit]

Hey all, I just had an idea.

What if XviD were able to run 3 passes? I know people have talked about this before, but think about approaching it this way:

The first and third passes would be the same as our conventional first and second passes, but the new second pass would be different.

This pass would look at the video and decide how much weight to give every scene. That is, it would break the video into a large number of scenes (a scene would probably be defined as the space between I frames), analyze the complexity of that scene, and then assign it a certain weight zone - thus maximizing quality consistency and thus bitrate effeciency.

Maybe XviD already does something similar with 2 passes and I'm just talkig out of my ass, but AFAIK something like this doesnt happen already.

Slap me if I'm talking stupid here, but I think I may be on to something.

Comments please!
~MiSfit

[frodoontop]

Use divx if you want to waste encoding time. Xvid only needs 2 passes to get optimal quality. Can you tell why you want many different zones to have worse quality than the rest? For I don't see the point of that. In first pass the complexity is already analyzed.

[Didée]

That idea has something in it.

Me also has had some thoughts about what senseful modifications could be done to XviD's 2-pass system.

First of all, I still believe in good old curve compression. If a complete movie comes out at an avg. quant of, say, ~q3, I don't like the idea too much that the ultra-action scenes are also coded with quant 3, and eat bits like Godzilla eats fish. Curve compression still has its pro's - and even more in conjunction with bitrate restrictions due to hardware profiles.

But, IF curve compression, then it should be as intelligent as possible. And this is one of my concerns about the current CC: it is a black box, and there never has been any useful explanation how it actually works. Yeah, we all know what "high BR degradation" and "low BR improvement" do - that's self explaining. But HOW is it done?

How are the quants scaled? Is a frame 10 bytes bigger than average already "high BR", or is a frame @ 66% of average still considered average? What IS average? The average of P+B-frame sizes, or only of P-frames? What is the number in "Degradation" mean? (It cannot be %-of-size, since you cannot give 100% less bits...).
I could go on with questions, but I'm not looking for answers here and now, so I'll stop that. But still, the old & now vanished "alternative CC" had at least one strong point: There I *knew* what I was doing ;)

However. More important would be to get more "intelligence" into the system: It seems like ages since koepi mentioned that something like a "scene complexity reckognition" is perhaps on the way. After all, it makes a big difference if a scene is high BR because of very strong motion, or because of very detailed textures etc, together with little motion.

Currently, perhaps there is something going on in CC, or perhaps it is not. We simply don't know. CC is a black box.
(Yeah, it's all in the sources, I know. I will laugh later.)

The good thing is: obviously, there still is room to further improve XviD, to kick the others even more ;)


But back to Blue_MiSfit's idea:

Something that I had in mind, goes as follows (possible in normal 2-pass):

In relation to curve compression:

Don't take the clip's overall-average. Instead, [somehow] break the clip down into scenes. Figure the average bitrate for each 'scene'. Then, do the curve compression according to those local averages.

Sidenote: similar idea could be done to B-frame sensitivity: an adaptive modulation "the higher the local bitrate, the higher the local B-frame sensitivity" perhaps should be tried out.


- Didée

[Blue_MiSfit]

exactly. I really like that sidenote about bframe sensitivity. Say for example the scene is low complexity, then you might want to increase sensitivity as well as other bvop settings.

I read somewhere on the forum about in the future having zones able to change not only sensitivity but also the max consecutive setting, the ratio, etc... This would be very nice for those low motion scenes, and also for reducing bvop settings for high complexity scenes.

I have yet to explore curve compression. Since Didee is praising it so much I think I'm going to have to explore it - a lot.

In relation to curve compression:
Don't take the clip's overall-average. Instead, [somehow] break the clip down into scenes. Figure the average bitrate for each 'scene'. Then, do the curve compression according to those local averages.

This is a very good point. Perhaps much of what I speak of can still be accomplished in 2 passes.

And to frodoontop, you're missing the point buddy. I'm not talking about doing a worthless third pass like DivX does, I'm talking about actually letting XviD do another pass in order to set up zones which (when used properly) can actually improve the overall quality of a movie by taking bits from scenes that compress well and giving them to scenes that dont. This makes the average quality much smoother which is much more important IMHO than the quality of a certain scene.

[Teegedeck]

I extensively messed with curve-compression in the good old Nandub days and found it never gave me a good trade for the cost. I set my compression to almost none or none and was glad when there came up a different way of scaling with Gordian Knot. Curve compresson had its heydays in XviD too; first there was Nandub-style cc-code (yuck), then Foxer had a go at it (and again, his 'conservative mode' which gave an almost constant quant undisputedly worked best), and in the end everyone agreed that the as of now current system is much nicer.

Let's wait what sysKin eventually does with his planned hvs-plugin for scaling in 1.1 before we open that box again.

As for hi-motion scenes: Some time ago, long forgotten, I believe -h explained that removing coefficients would work much nicer than simply quantizing stronger in such scenes, something like a motion-blurr would be OK (but we have that anyway in most movie-DVDs).

[Manao]

exactly. I really like that sidenote about bframe sensitivity. Say for example the scene is low complexity, then you might want to increase sensitivity as well as other bvop settings.Not me : if you want more b-frames in low complexity scenes, just increase the sensitivity / max number of b-frames. The codec won't put more b-frames in high motion scenes, because in such scenes, it costs more to put b-frames.

[Teegedeck]

In any case I'd prefer something like 'motion masking' (stronger quantization or perhaps just softening of fast-moving parts of the picture only) over a crude two-pass algo that removes bits from scenes with lots of motion. It's easy to see where this will go terribly wrong - i.e. in scenes where only part of the picture moves; for example shots of drivers in a car.

[frodoontop]

Originally posted by Blue_MiSfit
And to frodoontop, you're missing the point buddy. I'm not talking about doing a worthless third pass like DivX does, I'm talking about actually letting XviD do another pass in order to set up zones which (when used properly) can actually improve the overall quality of a movie by taking bits from scenes that compress well and giving them to scenes that dont. This makes the average quality much smoother which is much more important IMHO than the quality of a certain scene.

The whole idea of two pass is already to get all scenes the same average quant more or less. In other words: constant quality. Didee made actually a good point by saying that bits can be saved from scenes that are really hard to compress, because with a lot of movement, artifacts tend to be less visible.

You're suggesting the opposite. Easy to compress scenes will already have low bitrate, if they would be compressed even more, artifacts will likely be very visible.

[Prettz]

I have a few ideas for some changes to the zones GUI (not the codec's internal behavior itself).

1) It would be really nice if the zones listbox also displayed the b-frame sensitivity, because sometimes this is the only settings that distinguishes two consecutive zones. Right now the zones display can be so confusing (with all these zones that appear to have the same settings according to the display) that it can approach being unusable.


2) I'm right now facing a situation where I have to create a whole hell of a lot of tiny zones in a movie in order to adjust the weight/quant setting and the b-frames sensitivity, to prevent b-frames from being used in a scene or make them only used extremely sparingly (because the effects of the higher quantization are too visible.)

It would be really awesome if you could create "styles" or "profiles" to hold commonly-used combinations of zones settings. These styles would be stored alongside the rest of the codec settings in the registry. I'm not familiar with how zones are stored there, but hopefully this extension wouldn't conflict with the existing format.

Basically, you could still enter in zones as you do now, and when you enter zone settings like that, in the main listbox you would see the info for that zone as you do now (showing the weight/quant and chroma optimizer, greyscale, etc.) You could call this kind a 'unique' or 'custom' zone.

However, in the zones settings dialog, there would be a drop down listbox where you could select from a list of zone styles that you have created; when you select a named style, the rest of the dialog controls are filled in with that style's settings. If you make any changes to the settings, the drop down selector would revert to saying "Unique". If you set a zone to a style, then in the main GUI listbox, rather than displaying the zone's quant/weight and other settings, it would display the name of the style (i.e. "Style: Still scenes 2"). This would make it very easy to keep track of (and modify) projects with lots of zones.

[lordadmira]

What ur talking about is doing a complexity analysis on the video and then applying psychovisual effects or rate reductions on certain scenes. This wouldn't really need 3 passes, it could be done as part of the first pass. If u ask me this is just another form of chinsing on quality (comeing from an ultra quality freak >:). I don't know of any development going on in this area, maybe Koepi knows of somebody pursuing it. I know it's something I wouldn't use. Now making the rate control algorithm psychovisually aware might be something worth pursuing. That way each frame would have the same human perceptible quality rather than the mathematical approach used now.

LA

Prettz: u can use Divx's EKG app to play with the quality for individual scenes.

[Prettz]

Originally posted by lordadmira
Prettz: u can use Divx's EKG app to play with the quality for individual scenes.
I have no idea what this means or how it relates to what I said.

[lordadmira]

With respect to "all ur tiny zones".

[Didée]

Some more elaboration on my above posted thoughts.


Curve Compression

Blue_MiSfit:

If I were "praising" XviD's curve compression, I wouldn't have so much questions about its inner workings. It's a tool I still like to use, not a dogma, nor the way to salvation. Just a tool ;)


Teegedeck:

When saying CC, of course I'm not talking about "quant 2 for low BR scenes, quant 12 for high BR scenes". You don't suppose me to do such a thing, no? :eek:

Consider a case, again, where your encoding turns out with an avg. quant of 3.5. Without curve compression, this will give (in theory, & only for the P's):
For low bitrate scenes: q3-q4-q3-q4-up-down-up-down-up-down ...
For high bitrate scenes: q3-q4-q3-q4-up-down-up-down-up-down ...

And that is exactly what I don't like so much: The permanent quant fluctuations in itself, and the fact that the low-BR parts could easily be given more bits, whereas the high-BR parts would be *much* cheaper without so much q3-frames.

What I'm heading for is more like
low bitrate scenes: q3-q3-q3-q3-q3-q3 ...
high bitrate scenes: q3-q4-q4-q3-q4-q4-q3-q4 ...

and the way to get that is - curve compression.

[edit] An alternative, super-kludgy ;) approach to get such a distribution I described here (http://forum.doom9.org/showthread.php?s=&postid=473069#post473069).

We don't need to discuss the fact that it would be better to dedicately treat high motion, instead of simply pushing quantization on "big-sized-for-whatever-reason--frames". That's what I meant with "more intelligence" for the CC algorithms ;)



Adaptive B-Frame-Sensitivity


For calm scenes, I consider B-frame-sensitivity = 0 just ideal. Perhaps even -1 or -2. Anything more than sens=1 is simply pressing too much B-frames into the calm parts (for my taste, that is).

For (high) motion scenes, sens=0 gets pretty "expensive". Depending on circumstances, a good compromise bitrate~~quality is somwhere in the range of sensitivity = 5 ~ 15~20.

So, what always is needed, is lots of manual work with zones, zones, zones - just to distribute the B-frame-sensitivities all over the clip.
Well, I'm a lazy man, and don't like too much breaking my encoding into 5 single parts, and to manually apply 64 zones to each of them ... by the time I'm finally done with setting up all those zones, the encoding could already have finished ;)

Now, instead of offering only one base value for B-frame sensitivity, XviD could offer something like a "lower B-frame sensitivity" and an "upper B-frame sensitivity". Then, as bitrate changes with the clip going on, XviD would automagically use not too much B-frames for the low-BR scenes, but still enough B-frames for the high-BR scenes.

Got the idea?


- Didée


edit: accidentially adressed malkion instead of Blue_MiSfit. Corrected. Sorry, malkion!

[malkion]

malkion:

If I were "praising" XviD's curve compression, I wouldn't have so much questions about its inner workings. It's a tool I still like to use, not a dogma, nor the way to salvation. Just a tool

@ Didee

Erm, ok. If I have more praises or questions I'll be sure to write a post first in this thread next time. :rolleyes:

(Wondering what questions I had about XviD's CC)

[Teegedeck]

Originally posted by Didée
When saying CC, of course I'm not talking about "quant 2 for low BR scenes, quant 12 for high BR scenes". You don't suppose me to do such a thing, no? :eek:

Consider a case, again, where your encoding turns out with an avg. quant of 3.5. Without curve compression, this will give (in theory, & only for the P's):
For low bitrate scenes: q3-q4-q3-q4-up-down-up-down-up-down ...
For high bitrate scenes: q3-q4-q3-q4-up-down-up-down-up-down ...

And that is exactly what I don't like so much: The permanent quant fluctuations in itself, and the fact that the low-BR parts could easily be given more bits, whereas the high-BR parts would be *much* cheaper without so much q3-frames.

What I'm heading for is more like
low bitrate scenes: q3-q3-q3-q3-q3-q3 ...
high bitrate scenes: q3-q4-q4-q3-q4-q4-q3-q4 ...
Now that makes perfect sense. But difficult to reach, especially if you use a matrix that doesn't have so many fine quantization steps i.e. more standard matrices. Any ideas on how to get framesizes that predictable without multiple passes? Because personally I wouldn't accept a quadrupled encoding time for a minor gain in quality - and that even though I'm pretty fanatical about quality.

Also the problem remains that you don't know whether just part of a frame is in motion. Fast motion can mean just an actor talking in front of a moving background or it can mean fast camera-rotation. So, unless you only compress GMC+fast-motion-frames stronger there would have to go some work and thought into this. I'd rather compress only the moving part of an individual frame stronger. That would be a redistricute-within-one-frame solution (adaptive quantization) and wouldn't need to touch curve-compression. Probably easier to do correctly, at least there would be fewer pitfalls.

BTW, thanks to adaptive quantization I don't get q3-q4-q3-q4; I get something more like q3.42-q4.01-q3.67-q4.45. I wonder whether this makes things better or worse. ;)

[lordadmira]

Originally posted by Didée
Consider a case, again, where your encoding turns out with an avg. quant of 3.5. Without curve compression, this will give (in theory, & only for the P's):
For low bitrate scenes: q3-q4-q3-q4-up-down-up-down-up-down ...
For high bitrate scenes: q3-q4-q3-q4-up-down-up-down-up-down ... I don't think this kind of scenario can happen unless u set a fixed quantizer of 3.5. In two pass encoding the quantizers follow the *necessary frame sizes* to achieve the desired file size. The codec figures out how large frame x needs to be according to the scaling from the stats file and then picks a quantizer that results in the best match for that size. This should result in a narrow distribution (bell curve) of quants in the output file (e.g. 4-7).

What I'm heading for is more like
low bitrate scenes: q3-q3-q3-q3-q3-q3 ...
high bitrate scenes: q3-q4-q4-q3-q4-q4-q3-q4 ...
and the way to get that is - curve compression. I don't this this kind of "psuedo-psychovisual compression" is something for quantizer manipulation to try to achieve. It would be far better to do the psychovisual stuff in preprocessing. Like a Virtual Dub filter or something.

We don't need to discuss the fact that it would be better to dedicately treat high motion, instead of simply pushing quantization on "big-sized-for-whatever-reason--frames". That's what I meant with "more intelligence" for the CC algorithms ;) I think this kind of thing is beyond the scope of the codec.

For calm scenes, I consider B-frame-sensitivity = 0 just ideal. Perhaps even -1 or -2. Anything more than sens=1 is simply pressing too much B-frames into the calm parts (for my taste, that is).

For (high) motion scenes, sens=0 gets pretty "expensive". Depending on circumstances, a good compromise bitrate~~quality is somwhere in the range of sensitivity = 5 ~ 15~20. Eh? Ur second guessing the B frame algorithm in the codec. It has quite good (not that they couldn't be better) routines for deciding where P and B frames should be. Why are u prejudiced against B frames? ;) /1/0 B frames don't degrade quality no matter how many there are of them. The codec's not going to force B frames into a place where there just shouldn't be any because the sensitivity is "too high". Trust the codec. :)


LA

[Prettz]

Originally posted by lordadmira
With respect to "all ur tiny zones".
I don't understand how that addresses the fact that the zones display in the vfw interface becomes extremely confusing and difficult to use with lots of zones that appear similar or identical in the display, but which in fact are not.

edit: maybe I should clarify that my suggestion only consisted of a cosmetic change to the vfw GUI (albeit a rather extreme change), that would possibly streamline its use in a few rare situation, and that you could completely ignore and not use in the rest of them.

[Didée]

lordadmira:

Veto. Big Veto.


* this post will be edited **


edit: Relocated this post to next page, to stay in the thread's flow.

[Teegedeck]

Originally posted by lordadmira
I don't think this kind of scenario can happen unless u set a fixed quantizer of 3.5. In two pass encoding the quantizers follow the *necessary frame sizes* to achieve the desired file size. The codec figures out how large frame x needs to be according to the scaling from the stats file and then picks a quantizer that results in the best match for that size. This should result in a narrow distribution (bell curve) of quants in the output file (e.g. 4-7)
Lordadmira, I'm afraid XviD is not quite as intelligent as you think. :) There's no reason to 'trust the codec'. What the 2-pass algo does is trying to reach a certain filesize for the 2nd pass, it does not attain the 'needed' bitrate to each individual frame but takes a good guess and has to compensate for its worse guesses (resulting frame too big) by compressing other frames more strongly than it would do otherwise. That's the reason why you seldomly get a really constant quantizer in 2-pass but more of a fluctuation between two or three quants. Room for improvement is there, though I wouldn't know how it could be improved (as I don't think the fluctuation is important enough to deem multiple passes necessary).

As the idea is to have a more intelligent fluctuation instead of a merely arbitrary one, Didée's idea would yield very good results indeed; there's nothing that's negatively 'pseudo-psychovisual' about it. The only problem is the above-mentioned: How to get it to work?

[nanga parbat]

hello,

reading this thread, i think it's time to let loose that question which 'haunts' me since quite some time...

consider a sequence of q3-q4-q3-q4... just like Didée posted, we all know such ones.
now i perfectly understand the desire to make low bitrates all q3 and high bitrates all q4 (however, there are some high scenes which should better get a 3 or 2 even).
but back to the initial fluctuation - taking PAL as an example - one sequence of q3-q4 would amount for 80 ms of display time. so guys, what are your opininons? would we notice such a fast fluctiation as a fluctuation in quality or would we percieve it more like something constant (you know, just like we 'think' those images are actually moving)?
i mean looking at the frames in close examination is one thing, but actually 'watching' the movie is another (i too do examine frames, but very often i am quite astonished when noticing how it actually looks in, lets say, 'safe' distance).
basically what i mean is, is it really that bad? i daresay we wouldn't even notice if there were some considerably bad frames every now and then.

yeah well, i think i just had to let that out. i know it doesn't really help the discussion.
personally i think it wouldn't be that bad if xvid contained something like what Didée mentioned, but such a thing would need a considerable amount of user interaction.

nanga

[lordadmira]

Originally posted by Prettz
I don't understand how that addresses the fact that the zones display in the vfw interface becomes extremely confusing and ... I was just trying to offer another way of manipulating individual scenes.

[lordadmira]

Originally posted by Teegedeck
That's the reason why you seldomly get a really constant quantizer in 2-pass but more of a fluctuation between two or three quants. Room for improvement is there, ...
As the idea is to have a more intelligent fluctuation instead of a merely arbitrary one, Didée's idea would yield very good results indeed; there's nothing that's negatively 'pseudo-psychovisual' about it. The only problem is the above-mentioned: How to get it to work? There's no reason to expect every frame getting the same quantizer even in the ideal case. Because u can't have fractional quantizers. Ur necessarily going to get the bell curve. I don't see why u think this is something wrong. Scaling the stats file might call for a quantizer of 3.64, but that's impossible, so u need mostly 4's, a lot of 3's and probably some 2's and 5's to finagle the output size to what u want. It all depends on how compressible each frame is, and how much motion compensation there is. P and B frames take their quantizer *after* the motion compensation.

I totally agree the algorithm can be improved. But I think what Didee's talking about is just curve compression revisited. That's why I say "pseudo-psychovisual".

LA

[Didée]

(Relocated this post from last page, to stay in the thread's flow)

lordadmira,

You have taken my little examples about quantizer distribution too literally. In practice, the distribution will hardly ever look so synthetic like I wrote. But it will *basically* look like that. Since (without curve compression), XviD's 2-pass system will *try* to achive exactly that: reach the desired filesize with as little quant fluctuations as possible. In an 100% ideal case, it would turn out exactly like a constant-quant encode, using the right (fractional) constant quant that is needed to reach that filesize. All quant fluctuations greater than +/- 1 derive from bad guessing [q2 framesize]-->[qX framesize].
A bell-curve like quant distribution will appear through user-specified curve compression, not with linear compression (0/0).

I don't this this kind of "psuedo-psychovisual compression" is something for quantizer manipulation to try to achieve.

There's not much psychovisual about this, and for sure it's not "pseudo-psychovisual".
First of all, you must be aware of the fact that quant fluctuations like q3-q4-q3-q4 actually are wasting bits: a q3 frame codes a certain amount of information. a q4 frame codes less information.
Thus, on a 3-4-3-4... sequence, there is always information thrown away by the q4, has to be restored by the following q3, is again thrown away by the q4, has again to be restored by the q3, ... and so on. If you minimize the fluctuations, you can spare those bits that are additionally needed for detail restoration, and can them use elsewhere for a better purpose.
BTW: One more argument for high-BR matrices with smaller quantization steps ;)

It would be far better to do the psychovisual stuff in preprocessing. Like a Virtual Dub filter or something.
Oh, are you still filtering your encodes in VirtualDub? You should have taken the other pill from Morpheus :D

Moreover, there is not the slightest chance to get goal-directd control over quantizer distribution by frame filtering the source before it flows into the codec.

[We don't need to discuss the fact that it would be better to dedicately treat high motion, instead of simply pushing quantization on "big-sized-for-whatever-reason--frames".]
I think this kind of thing is beyond the scope of the codec.
So you would also say that curve compression is beyond the codec's scope? And so is Adaptive Quantization? Hell, even B-frames are beyond its scope, then!

Basically, this is only about making decisions which frames can get away with higher quantization, and which frames need a lower one. And of course this is NOT beyond the scope of the codec.
I'm only proposing some thoughts on how the codec could make better suited decisions.

Eh? Ur second guessing the B frame algorithm in the codec. It has quite good ... routines for deciding where P and B frames should be. Why are u prejudiced against B frames? ;)/1/0 B frames don't degrade quality no matter how many there are of them. The codec's not going to force B frames into a place where there just shouldn't be any because the sensitivity is "too high". Trust the codec.

I do trust the codec - to certain limits. The codec is only a binary system. In the end, I trust man's brain and intuition much more than any binary system, anytime. And no, I'm not prejudiced against B-frames. Not at all .
It would get too lengthy to describe this here to the last details. But ... of course and for sure, you can force the codec to put too many B-frames. What do you think why DivX allows only 1 B-frame in a row? (Perhaps 'cause the guy's weren't smart enough to hack more than 1 into AVI? Could be.) Because it has no adaptive decisions for them, it just puts them. And two in a row are way too much in many cases. And that's just what you'll get with XviD also, if you set the sensitivity too high.

XviD's decision about putting B-frames is based on R-D and PSNR, AFAIK. But on quite some instances of complex scenes with strong motion, I found that for a tiny little bit less perceived quality, I can get a very noticeable drop in needed bitrate by forcing more B's for those scenes. And again, these spared bits can be spend elsewhere much better. Free bits always come handy in video compression ;)
For some certain scenes, I have seen bitrate drops in the range of 800~1000 kbit/s by just pushing sensitivity from 0 to 20, while the quality drop was hardly noticeable.
But I won't like my calm scenes to be coded with a B-sensitivity of around 20, really.

For your example of ;)/1/0 B-frame settings:
Well, set ;) = 8, and sensitivity to 1000. Then go ahead and encode Saving Private Ryan, Gladiator, or something like that. I wish you much fun with the result you'll get :)


- Didée

[lordadmira]

Originally posted by Didée
There's not much psychovisual about this, and for sure it's not pseudo-psychovisual". Of course it's psychovisual. Applying extra compression to "fast motion high bitrate" scenes where it is believed that human perception is less than other scenes. But all I think a curve compression approach will lead to is blockiness in those scenes. Adaptive Quantization is a primitive form of psychovisual tweaking.

Thus, on a 3-4-3-4... sequence, there is always information thrown away by the q4, has to be restored by the following q3, is again thrown away by the q4, has again to be restored by the q3, ... and so on. If you minimize the fluctuations, Not necessarily. The quantizer is assigned after the motion compensation. i.e. diff(frame1, frame2) So any caught macroblocks from the initial Q3 frame will be carried through the entire 3-4-3-4 sequence. The same with macroblocks from the 2nd Q4 frame and so on. It's a building, cumulative process. So u see the motion compensation potential, since it is source dependant, vastly complicates ur proposal.

Moreover, there is not the slightest chance to get goal-directd control over quantizer distribution by frame filtering the source before it flows into the codec. Sure there is. Here's why. In preprocessing u can have arbitrarily complex modular algorithms for smoothing out desired "high bitrate" scenes. I think this is the much more promising path. Since the otherwise high bitrate scenes have been smoothed out already, the codec can apply it's normal good old decision algorithms and naturally give the "fast" scenes fewer bits. But to the codec it's giving them the normal amount of bitage.

But on quite some instances of complex scenes with strong motion, I found that for a tiny little bit less perceived quality, I can get a very noticeable drop in needed bitrate by forcing more B's for those scenes. And again, Yep, that's because the B frames are doing what they were designed to. P frames anchor the endpoints of the motion and the B frames compensate everything in between. This is why B frames are ur friend.

For your example of ;)/1/0 B-frame settings: Well, set ;) = 8, and sensitivity to 1000. Then go ahead and encode Saving Private Ryan, Gladiator, or something like that. I wish you much fun with the result you'll get :) Why, those are almost my standard settings for all encodes! ;) Although setting Bsens to anything over about 50 doesn't make any difference anymore. I'm quite sure the encode would look spectacular.

I totally agree the algorithms can be improved. Right now I think improving the B frame routines hold the greatest promise. I've been advocating this in other threads. Anything that can increase the amount of motion compensation will give u the most bang for the buck.


LA

[Blue_MiSfit]

look at what I started... hah.

All I really was thinking was to automate the following process

So, what always is needed, is lots of manual work with zones, zones, zones - just to distribute the B-frame-sensitivities all over the clip.

good stuff though

[Didée]

@ lordadmira

I consider these my closing words on the 'topic'. The discussion won't lead us to new insights, and moreover I simply don't have the time for playing the "arguing for the argument's sake" game.


Of course it's psychovisual
I was more concerned about your beloved usage of the pseudo-psychovisual term. But I see it already starts getting better. :D

Not necessarily. The quantizer is assigned after the motion compensation.
... etc etc ...
Oh, c'mon. You don't need to explain to me how mpeg compression actually works. Spare your time.

No matter how much you stress the benefits of motion compensation: the interesting things in relation to quantizer fluctuations happen *after* it. After motion compensation, there is still information to quantize & code. And each P is referring to the former P-frame on en/de/coding. So, since it is still true that a q4 will quantize more information to Nirvana than a q3, the q4's are a less good reference than the q3's are. Therefore, a q3 that follows a q4 will require more texture bits to recreate the actual content from the q4 reference, than it would need if it had a q3 as predecessor.
This can relatively easy be proven through synthetical tests. I'm not just wildly guessing here, lordadmira ;)

Sure there is.
There is, in your sense. There is not, in my initial sense. We're talking a little apple & oranges here.
You may call content-adaptive filtering "controlling" the final quantizer usage. But in the context we started this discussion with, that's lame. You might filter the content differently for motion and calm scenes, and you will influence the final quantizer distribution by that. There is no doubt about that: I do that every day in my encodings ;)
But you can NOT filter the content so as to avoid the mentioned *quantizer fluctuations*. That is totally impossible to do on the filtering side, since by that time you have zero information about what will be going on when encoding.
Sorry if I'm splitting hairs here. But you placed your comment in my context of quantizer fluctuations, so I took your comments in relation to that.


Why, those are almost my standard settings for all encodes! Although setting Bsens to anything over about 50 doesn't make any difference anymore. I'm quite sure the encode would look spectacular

Do you know what you are talking.

You formerly said
>> xyz/1/0 B frames don't degrade quality no matter how many there are of them.
>> The codec's not going to force B frames into a place where there just
>> shouldn't be any because the sensitivity is "too high".

That's why I told you to try 8 B-frames with a sensitivity of 1000.
You said "no matter how many there are", so according to you, 8-in-a-row would be okay. But, if you allow as many as 8 consecutive B-frames, then sensitivity=50 versus sensitivity=1000 will make a *HUGE* difference. Just try out what I told you, you'll see then. Because with such a high sensitivity, the codec *will* put too many B-frames, even in the most unsuited places. In fact, with sens=1000 you will pretty much force the usage of 8 B's throughout the whole encoding.

Know your tools.

I totally agree the algorithms can be improved. Right now I think improving the B frame routines hold the greatest promise. I've been advocating this in other threads. Anything that can increase the amount of motion compensation will give u the most bang for the buck.

Glad we have a point to agree :)

I suppose that VHQ for the B-frames will help their quality considerably.

But the penalty in encoding speed will raise just as considerably ... :|


I back off to more constuctive work now.


- Didée

[lordadmira]

I only have one more point before we can let this die. ;)

Originally posted by Didée
I was more concerned about your beloved usage of the pseudo-psychovisual term. But I see it already starts getting better. :D I was only calling curve compression pseudo-psychovisual.


Therefore, a q3 that follows a q4 will require more texture bits to recreate the actual content from the q4 reference, than it would need if it had a q3 as predecessor. That's why it should always be the lowest quant that kicks off the motion compensation chain.

You said "no matter how many there are", so according to you, 8-in-a-row would be okay. But, if you allow as many as 8 consecutive B-frames, then sensitivity=50 versus sensitivity=1000 will make a *HUGE* difference. Just try out what I told you, you'll see then. Because with such a high sensitivity, the codec *will* put too many B-frames, even in the most unsuited places. In fact, with sens=1000 you will pretty much force the usage of 8 B's throughout the whole encoding. Heheh, they have to be put in appropriate places. Arbitrarily putting x number of B frames into a sequence like Mpeg1/2 does is stupid. I guess I should have used different phraseology. My default B frame settings for all encodes are 28/1/0 sens 80. I do watch the status window to make sure Xvid isn't doing anything stupid with respect to B frames and amazingly it does a darn good job. There are rarely 8 B frames in a row, only on essentially static scenes does it approach Bmax. The frame sizes confirm that it is putting P frames at the proper anchor points and the intervening B frames are usually 25-60% of the size of P frames. Once in a while a few B frames will actually be larger than the proximal P frames. A lot of times B frames are totally compensated away and take up less than 1/2 k. Massive B frame usage is the direction H264 is taking and I think it's something that Xvid should embrace also.

Ok, so it was three points, so sue me. ;)

LA

PS: I just encoded an Inuyasha ep with the above settings, I can get u a copy if u want to look over how great it turned out. ^^

[Didée]

"an Inuyasha ep" seems to be animee, yes? Animee always is a different story ... and hardly ever touches any of my rigs. I'm doing natural movies exclusively.


[edit]

Grrrrrr! :devil:

It seems it was a little too long since I tested such 'extreme' B-frame settings myself.

Actually I'm running a XviD HEAD compile from June 12, and indeed ... even with a sensitivity of 1000 or 10000, XviD keeps the placement of B-frames within somewhat reasonable boundaries.
Just tried max. 8 Bframes @ 10000 on a scene with only camera panning - fast,slow,medium,very slow & very fast. Got an overall P/B ratio of 1/4.

I stand corrected on that aspect.


- Didée

[Teegedeck]

To get back onto more practical aspects, I think a more constant quantizer of the all-decisive p-frames could be reached if XviD tried to controll the bitrate rather by relying on b-frame quantization in cases where a p-frame comes out too big. Could perhaps work, but we'd perhaps have to sacrifice some compressiblity by lowering b-frame offset or ratio at the same time. Humm. Possible? Desirable?

BTW, what's your stance on adaptive quantization, Didée?

[Didée]

My impression is that XviD is doing this already, Teegedeck!

Looking at some 2nd-pass quant distributions, it seems that XviD tries to compensate for deviations from the calulated bitrate firstly by adjusting B-frame quantization. Only when the deviation gets too big to be compensated by B-frames with reasonable effort (quantizer +/- 1, I suppose), then it will start to actually change the quants for P-frames.

I assume it is like that. No guarantee though.


About AQ - well, I use it, and have no big complaints so far.

I just have too little time for testing these days. Therefore, I really can't tell much about AQ. I just take it as it is ...
(E.g. I promised crusty to do some certain tests, concerning overflow control ... he is waiting now since two months or so :( )

And, to be honest: due to the lack of time, I currently choose most of my filtering setup and XviD settings from the guts, and make a quick prayer that I'm right with it. Astonishingly, most times the prayer is heared ;)


- Didée

[movmasty]

coming back to the 3 passes question, i already do,or would like to if i had the time,3 passes, because after the second i am not satisfied with i-p-b distr and relative quantizers,
and this because the first pass in divx doesnt use the final quantizers but fixed 2, or 3 for b frames.

When i was using nandub i already modified the default.1st.pass.vcf to use quant 3 in the first pass, thus having a more realistic approssimation to the second pass, still better would be having the 1st pass at the bitrate you presumibily are going to encode the movie.

In the first pass xvid gains infos about the movie, but you dont get any to guess what the final bitrate should be,this could make sense in the age of CDs, when size was constrained to 700 mb(but still you could burn on a 800mb cd), but now you are free to choose any size from 400 to 4000 mb.

so the first pass is for the codec infos and the 2nd for yourself, then the 3rd...

I think that would be better to do the 1st pass not at fixed quant but at a given bitrate, that could then also be modified,
xvid will still have its info, but you too.

to guess what, approssimately, the bitrate should be , would be useful a "0" pass where the codec tests 20 random parts of 10 seconds at quant 2.