B-Frame Setup too restrictive?

[Clock]

Yep, first Post (never registered, 'cause the 5 days frightend me :) ), so Hi everybody!

I really like to encode and play around with different settings, that's why i really like Xvid (besides it's quality, which I don't have to mention). But maybe I don't know enough about the way it works, because I just don't understand:

1) Why do I have to tell the codec which quants to use vor B-Frames? It desides by himself which one to use for I and P, but for B we have to tell it an equation? It know whether to use 1, 2, ... consecutive B-Frames (if I allowed them), but not how to compress them? Are there any plannings to change this? An option, that let's me choose to tell him, or let him decide?

2) 2Pass mode is a great thing. Basically. I just think it doesn't use all it's oportunities. As much as I know, only the quants are changed from the 1st pass (which is all quant2) in order to achieve the desired size. But why does the codec have to decide during the first pass, where to put I, P, B Frames? It has to in 1Pass-Mode, but why now tell him to make that decision during 2nd-pass? Like "oh, that guy want's a really small filesize. I'm going to use more B-frames instead of higher quants" for example.

Sorry to admit that I don't have the slightest clue about how to do that, but hey, you are the geniuses! I couldn't make any of that great stuff you already did.

So, bye, Clock

[Teegedeck]

Originally posted by Clock
Why do I have to tell the codec which quants to use vor B-Frames? [...]Are there any plannings to change this? An option, that let's me choose to tell him, or let him decide?
[...]
But why does the codec have to decide during the first pass, where to put I, P, B Frames?
Welcome, clock!

Well, perhaps it would be time to hard-code the b-frame ratio; then you wouldn't see it and everything would seem 'automatic' and 'smart'... ;)

If frame-types aren't the same as in the first pass, the whole scaling of the bitrate-curve for 2nd pass won't be correct, anymore. What would seem interesting is a smarter quantizer decision, and I believe sysKin once had such plans. But don't expect miraculous improvements would come from it.

[Manao]

Originally posted by Clock
1) Why do I have to tell the codec which quants to use vor B-Frames? It desides by himself which one to use for I and P, but for B we have to tell it an equation?Well, in fact, the codec doesn't choose all by himself concerning I and P frames, since you can add an I-Frame boost, which allows you to ponderate I over P-frames ( or the contrary ). It's the same thing with b-frames. With the settings, you can make b-frames having a lot less weight than p-frames ( with a high ratio / high offset ), or you may want them to be at almost the same quality than b-frames ( ratio around 1, no offset ). That way, you can tweak the settings in order to please your eyes, not the eyes of the developpers.
Are there any plannings to change this? An option, that let's me choose to tell him, or let him decide?Well, in that case, just use the default settings. I think I know what you want : you want b-frames quant to be chosen as p-quants are in second pass, quality wise. But it's exactly how works the ratio / offset settings : they allow b-frames' quality to be totally correlated to p-frames surrouding it. What you have to choose is how much you allow the codec to lower quality of the b-frames, asserting that you won't see the difference because of the motionBut why does the codec have to decide during the first pass, where to put I, P, B Frames? It has to in 1Pass-Mode, but why now tell him to make that decision during 2nd-pass?How would you do your file size prediction that way ? You can't predict the size of a B-frame with the size of the corresponding P-frame.Like "oh, that guy want's a really small filesize. I'm going to use more B-frames instead of higher quants" for example.Yeah, but the guy wants firsly a constant quality and a precise file size. And too much b-frames won't give you much improvments. Of course, if the user didn't choose the right parameters for b-frames for his first pass, the codec won't output something optimal, but it can do nothing about it, since it would need another different first pass. You would say : then, precise the second pass size already for the first one. But that is not useless, because the codec won't know until the end of the first pass how hard the video is to compress. So we end up with three passes algorithms, the first one analysing the complexity of the movie, and the two others being the true first and second pass. But it would take more time, and the choice of b-frames would still be totally as valid ( theorically speaking ) as it is now, since you still don't know relation between p and b frames size.

[sysKin]

Believe me, every single time someone says that software is "smart", he means that parameters are hard-coded and programmer thinks they are correct. In other words, assume that defaults make XviD smart ;)

"Hey, I use defaults and XviD was smart enough to disable VHQ, because XviD knows it doesn't help that much and I'm in a hurry". You know, this sort of stuff - works with all smart software in the world.

And no, I'm not making fun, it's usually pretty correct.

Radek