One question, one idea

[Vanos_b]

I recently found out that the great benefit of B-frames in DivX5 wasn't that great (as the size reduction came from lower quantizers for B-frames, not the frames themselves) and so I ran some (short) tests myself (60 seconds scene from Wild Wild West):
1. no B-frames - file size 100%
2. B-frames with Bidir Quant Multiplier 2 (2000 in hexa in the registry)- file size ~75%
3. B-frames with Bidir Quant Multiplier 1 (1000 in hexa, I hope I'm right as I'm only guessing here) - file size ~101.5%
So if I'm right the B-frames actually gave a 1.5% overhead, and the only thing that does the job is the Quant Multiplier.
Now, is this because of the poor implementation of B-frames in DivX5 (I know there are some restrictions due to the AVI file format)? I hope so, because I really wanted to see B-frames implemented in XviD and I would be very dissapointed to see they are useless.
But the thing is that the picture actually looks very good (IMO) with B-frames. So my idea is: couldn't this be implemented in XviD too? I mean not for the B-frames, but it would be a nice thing to have something like "Every second frame quant multiplier", at least for the "1pass-quantizer" mode.
Regards.

P.S.
DISCLAIMER: Everything in here is only a suggestion and it's not intended to offend anyone.

[Koepi]

@Vanos_b:
Your observation is indeed correct.

And that the filesizes are so small shows that DivX5 has a real good b-frame implementation.
I'm still not myself on the xvid-internal devel mailinglist but i heard from the first results of the first tests. They correlate with your experiences.

@All:
Since XviD shouldn't suffer the same as many other projects were people were urging the developers to release snapshots, especially that bitching "your codec sucks as it can't compete" even though the people know it's alpha, that code isn't public yet(it doesn't even work correctly AFAIK, but what do I know? ).

I guess noone wants to see XviD die like nandub.

So give it some time until isibaar's, suxen_drol's, gruel's, -h's and everyone else's code is working correctly. Don't urge them to release unstable, crappy sources.

All the above paragraphs are just meant as prevention from people start shouting for working b-frame code again as it usually happens in such threads.

I hope this helps getting some insights.

Best regards,
Koepi

[-h]

Now, is this because of the poor implementation of B-frames in DivX5 (I know there are some restrictions due to the AVI file format)?

Not really, it's just how B-frames work. It seems DivX5's motion estimation is letting it down here - B-frame streams should be around 2% smaller, not larger, though it is possible for the overhead to increase file size.

XviD will have quantization controls for B-frames, so you can play with it without resorting to registry editing.

-h

[MoonWalker]

I guess noone wants to see XviD die like nandub

A "little" irelevant but why nandub has died? What happened? ( I know that it has died but why?? )

MoonWalker

[Teegedeck]

Koepi has more insights into that than I, I guess, but let me just say that Nando got frustrated because he really cared about the users of Nandub. He tried very hard to give them every feature they wanted and smoother out the bugs in his brilliant proggie but people kept complaining and complaining about quite unimportant stuff. I really don't see how Nando got the time for programming or even leading a life. So let's not repeat the same mistakes and just let the developers do their job.

[Teegedeck]

So my idea is: couldn't this be implemented in XviD too? I mean not for the B-frames, but it would be a nice thing to have something like "Every second frame quant multiplier", at least for the "1pass-quantizer" mode.


No, no, B-frames actually IS the right way to implement something like this. Look also in the 'Quantizer Jitter'-thread.

[MoonWalker]

@Teegedeck
Thanks for the your answer

You are right. We must not complain. The only thing tha we could achieve is frustrating the developers and dumbing the whole project.We shouldn't forget the this is a FREE PROECT made by people the they love this kind of stuff. If anyone should complain, this is the developers itself. Afterall anyone is welcomed to join the developing team...

Just a little thoughts

MoonWalker..

[Teegedeck]

I hope I didn't let it sound like we'd have to kneel and be humble and treat developers like gods... They dig good user input, it's just a matter of the qualityl (and also quantity) of the input. I.e. no good to complain about the same stuff again and again... :)

[Gabriel_Bouvigne]

Does this means that usually b frames don't save bitrate because of bidirectionnal prediction?
According to your posts, it seems that they only save bitrate because they could be allowed to be quantized more (because quality of a b frame has obviously no repercussion on other frames)

[LotionBoy]

I think that Bi-direc prediction allows them to be quantized more. They are drawing data from more sources, so they can contain less data themselves. So you can compress them more without quality loss = smaller file size. At least that is how I think it works. I'm probably wrong ;-)

LotionBoy

[-h]

According to your posts, it seems that they only save bitrate because they could be allowed to be quantized more (because quality of a b frame has obviously no repercussion on other frames)

Yep. Errors are not propogated, thus it is "safer" to quantize them heavily.

-h

[Gabriel_Bouvigne]

So the 1-2-5 ratio for i-p-b frames is just a dream? In fact it is 1-2-2?

It seems to me that at least if I have i-p-b-i and there is a frame change on b, this b could save space compared to a p.

But this make me think about on thing (here is the real question of this message): in mpeg4, are you able to insert an i frame on scene change, or do you have to wait until next theorical i frame position?
I'm asking because in mpeg1-2 the gop sequence is fixed for the whole stream, but I'm not sure about mpeg4

[-h]

But this make me think about on thing (here is the real question of this message): in mpeg4, are you able to insert an i frame on scene change, or do you have to wait until next theorical i frame position?

I-frames can be inserted anywhere, as can P- and B-frames from memory (though I will check this). Coded sequences like IIBB (decoded as IBBI) are possible, and correct decoding is facilitated through VOP timecodes.

-h

[TripleA]

Originally posted by -h
According to your posts, it seems that they only save bitrate because they could be allowed to be quantized more (because quality of a b frame has obviously no repercussion on other frames)

Yep. Errors are not propogated, thus it is "safer" to quantize them heavily.

-h

So using B frames is a case of sticking potentially not so good-looking frames where they probably wouldn't be noticed? Interesting...

And I think XviD is the best thing since the wheel, for the record ;-)