Much change in rate in DivX 5 ??

[mitch1966]

Is there a DivX5bitrate available ??

If not, will DivX4bitrate still give an accurate result if you use the suggested bitrate and encide using DivX 5 ?

[aleksander]

I don't know of any divx5 bitrate calculators. The bitrate you will get when using any of the divx 4 bitrate calculators, should be quite accurate. You can use Gknot for that.

aleksander

[dragoman]

Hi,

The bitrate you will get when using any of the divx 4 bitrate calculators, should be quite accurate.

This isn't necessarily true.....for example, I am currently encoding the X-files, Season 4 episodes.

Each is 45min long, and when loaded into Gknot the typical bitrate for a 300MB video file size (adds to 350mb per ep when muxed with audio), it gives me a bitrate of 740kb/sec.

However, when experimenting, a bitrate of 950kb/sec gives me close to 300MB with DivX 5 Pro, GMC and b-frames enabled, psycho-visual to light, no processing.

Now that is a big difference between 740kb/sec and 950kb/sec....

I've said it before...DivX 4 bitrate calculators cannot be accurately relied upon to predict DivX 5 filesize, especially DivX 5 Pro.

dragoman

[aleksander]

Originally posted by dragoman
I've said it before...DivX 4 bitrate calculators cannot be accurately relied upon to predict DivX 5 filesize, especially DivX 5 Pro.
I agree with the Pro - it's a little bit unpredictable. But my test encodings with divx 5 (not Pro) proved that divx4 bitrate calculators are quite accurate (difference in predicted size only +/- 20-30 MB)...

aleksander

p.s. And I'm talking about 2cds rips here...

[theReal]

All the divx5 files I have made up to now had been 2MB off at most. I'm always using b-frames and sometimes pre-processing filters.

I have just finished "Hanibal", it came out 699MB using exactly the bitrate Gordian Knot had given me for 700MB Divx4.

Maybe the gmc, q-pel and psy stuff make it unpredictable, but I don't use that stuff anyways.

[dragoman]

Hi,

With regards to DivX 5 basic, no argument. DivX 5 Pro with b-frames turned off also is similar to DivX4 filesize.

But what we need is a b-frame compatible bitrate calculator....

dragoman

[mitch1966]

Sorry to bring a newbies perspective to this conversation guys, but what are the main differences between DivX 5 standard and pro ?

And are they useful ?

[theReal]

what I just said was
I'm always using b-frames and sometimes pre-processing filters. I have just finished "Hanibal", it came out 699MB
so I don't need any "b-frame compatible" bitrate calculator. When I can't reach the desired filesize with b-frames (which might have been the case had I aimed for 2 cd's), then I just turn b-frames off.

[sierrafoxtrot]

bitrate is bitrate

the number of bytes per unit time, ie kb/s, is invariant for any movie of the same length. like if you're trying to fit several movies of 100min onto a 700mb with cbr mp3 at 128kb/s, then the bitrate will always be the same.

the funky thing with divx5pro is that once you turn on q-pel and gmc, the codec compressess more efficiently and may not be able to fulfill your specified bitrate. b-frames alone have never given me problems, normally i get to within 2mb.

try it and see; encode 2 movies of the same length with the same bitrate, and q-pel and gmc and b-frames, you'll see a different final size depending on how compressible the movie is. or if you prefer, encode the same movie with different resolutions. the smller resolutions will give smaller files, which doesn't happen with divx3 or XviD.

one to overcome this has been discussed in the divx5 forum (can't remember the thread but search for comp check) where you use an avs script to do the 1st pass in VDub, and then edit the resulting log file to be opened with GKnot. this doesn't actually help with bitrate calculations, that stays the same for the movie, but it allows you to choose your resolution so the codec is taxed more, and hence is able to produce a file closer to the size you want. ie, for a particular bitrate, you can increase the resolution by a couple of notches.

hope this helps ;)

[dragoman]

@theReal

When I can't reach the desired filesize with b-frames (which might have been the case had I aimed for 2 cd's), then I just turn b-frames off.

How is this any different from what I have been saying? If you can't get the right filesize using b-frames (and I am not saying you never will, just not 100% of the time), you turn them off!!

Of course! B-frames are quantized differently than other frames, therefore you cannot predict them with existing bitrate calculators!

I said this, you know....

With regards to DivX 5 basic, no argument. DivX 5 Pro with b-frames turned off also is similar to DivX4 filesize.

@sierra foxtrot

Yes, bitrate is bitrate with respect to cbr files, and vbr files with b-frames turned off. DivX5 uses the same filesize structure as divx4 and therefore, is remarkably similar in filesize when you are not using b-frames!

You say:
the number of bytes per unit time, ie kb/s, is invariant for any movie of the same length. like if you're trying to fit several movies of 100min onto a 700mb with cbr mp3 at 128kb/s, then the bitrate will always be the same

Since you are talking about cbr here, yes you are correct.

VBR methods are different. Yes, the traditional methods used by DivX4, Nandub, and Xvid all use a set bitrate as a guideline when encoding a movie...the result is a movie with an average bitrate of whatever you set, making the movie's filesize very predictable.

The reason this is predictable is that during the first pass, the quantizer for each frame is set with regards to the final bitrate. Each frame is quantized using the same method.

However, with b-frames, these frames are quantized differently than other frames, and thus have varying degrees of difference with regards to frame size.

It has been said that DivX 5 Pro merely doubles the quanitzer for a b-frame, but I have not seen this proved anywhere in the documentation. If so, there should be a way to provide an accurate bitrate calculator for b-frame encoding.

If, however, b-frames are encoded using variable quantizers (using some criteria or formula known only to the DivX5 creators) then RIGHT NOW you cannot predict accurately the effect b-frames will have on filesize.

If we knew how b-frames were encoded with respect to the other frames, filesize prediction is merely a mathematical problem.

dragoman

[sierrafoxtrot]

@dragoman

i think i see your point about b-frames being quantized differently through some mystical algo, and how this would affect bitrate, but at the same time, (i don't know this for a fact so pls bear with me) wouldn't any bit-savings from b-frames be used on other p- or i-frames to bring the average bitrate up (ie improving quality)?

and i thought that although we enter an average bitrate for codecs like divx3, divx4 and XviD (well, final filesize for XviD) we are in effect telling the codec how much space we are allowing for the compressed video data, and the codec decides how to allocate that bitrate in a VBR fashion.

the 10+ movies i've done with divx5pro with only b-frames turned on has always given me pretty accurate final filesize. i frameserve using avisynth (generated by GKnot) and encode using VDub. credits first at constant quant, then i use GKnot to calculate bitrate after the addition of audio and credits section, and i make sure that the number of frames is entered correctly (ie, _minus the number of frames of credits_). i stick that final bitrate into GKnot and do 2 passes, mux everything with nandub, and i've always gotten pretty close to 700Mb. (i'm encoding La Reine Margot on 2CDs overnight so i might have something to say about 2CD rips tomorrow)

so i guess from what empirical evidence i have, i can say i've not had problems hitting the right filesize. if you recommend a couple of DVDs which you've done that have come out undersized i'd like to confirm the bahaviour of the codec.

not dissing you or anything but the first couple of encodes with divx5pro i didn't take into account that i had to subtract the number of frames of credits from the total and i got what appeared to be undersized files because i was entering a miscalculated bitrate (too many frames for a particular target filesize) ;)

could this be the cause of ppl's woes out there?

[dragoman]

@sierrafoxtrot

but at the same time, (i don't know this for a fact so pls bear with me) wouldn't any bit-savings from b-frames be used on other p- or i-frames to bring the average bitrate up (ie improving quality)?

Yes, but there is a limit to this because the codec does not reference the entire movie (what I mean is, a frame at the end of the movie will not be referenced to a frame in the beginning). It only references the frames to the previous keyframe. Any bit savings from that b-frame will only be applied to the frames in that particular scene (the frames that are referenced to that particular keyframe).

Now, this will bring the average bitrate up of the entire movie, but only to a certain degree, and it cannot be predicted. The reason is each b-frame is apparently encoded with a different quanitzer, which is determined by the codec in an as-yet-unknown way. That means that the bitrate "savings" for each bitrate are not predictable, and are therefore unreliable to count on to bring the bitrate up. Furthermore, if the surrounding frames of a b-frame are already quantized at 2, then the excess bits saved from that b-frame are discarded, instead of being applied to another scene in the movie.

In order for these extra bits to be applied to other scenes (again, scenes are my way of saying "bundle of frames referenced to X keyframe) in the movie, it would take a second "1st pass". The 1st pass would assign applicable quantizers to frames. Then the second pass would take any leftover bits and redistribute them to bring the avg bitrate up to the desired level. Then the "2nd pass" would create the movie along these guidelines.

Unfortuneatly this does not happen. The quantizers assigned to each frame are relevant to the previous keyframe, not the entire movie. This is why an extremely compressible movie will sometimes come out with a lower filesize than anticipated, no matter how high the bitrate. If the max quantizer is applied to every frame, then max quality possible for the codec has been reached, and no bitrate setting however high can increase the quality any more.

B-frames are a part of this problem because:

1) We don't know how the codec determines the quantizer for a b-frame, so we can't predict the size of the frame in advance

2) Since b-frames are still only referenced to the frame before it and the frame after it, DivX5Pro is still encoding on the "scene-based" system, and doesn't reference the entire movie in the first pass.

This is why b-frames are making such a big impact on filesize prediction....they introduce an unknown, unpredictable element into the encoding process. Sometimes prediction works out, sometimes it doesn't.

dragoman

[sierrafoxtrot]

@dragoman

phew! well that explains some things. thanks for making it a bit clearer, filesize prediction is a bit off. actually, my 2CD rip of La Reine Margot came out about 20mb undersized, something i haven't seen before, so i guess i gots to concede to you there.

i had quite a high % after comp check, so i'm re-encoding it again at a higher resolution to see if i can hit the right filesize ;)

[theReal]

It's just that all the files I have encoded up to now (not too many, but quite a few different things, tv-captures, DV, DVD) were so exactly hitting the desired size, I couldn't wish for any better.
I have been using b-frames on all these files.

So, I'd say that as long as maximum quality is not reached, b-frames don't make filesize totally unpredictable.
Isn't this the same as with Divx4 and even Divx3? When maximum quality is reached, the resulting file will be too small. The only difference is that with b-frames the maximum quality is reached at a smaller filesize and so it happens more often. I don't think it will happen that often on 1-CD rips with a high resolution.

[dragoman]

@sierrafoxtrot

Yes, you are correct. This issue does not (usually) apply when max quality for a movie has not been reached. Then usually the bitrate savings of b-frames are applied to surrounding frames in each scene, and the filesize is generally correct.

However, most often times you don't even notice this problem unless you are encoding a movie where max filesize is reached (memorable ones: Unbreakable, the Matrix, Species, Xmen). All of these movies will be undersized if you try to encode as a two-cd rip....try it!

So, in reality, this problem is not really a problem for people who want to get a 1-cd rip of every movie they come across....but for quality freaks (I admit I am one, now I am encoding using 100% quality DivX5Pro to see how it does) it becomes an issue more often.

@theReal - Yes, this can crop up using DivX 3.11 and DivX 4.xx also. I tried to encode Soldier as a two-cd rip....highest filesize I would get is 900MB or so....and that was with Nandub!

dragoman