DivX4 CQ

[Taric25]

I'm getting better with DivX, but I'm not really good at comparing DivX quality under any circumstance.:(
I wanted to use Nandub because I heard it was faster and higher quality. I've now switched to DivX 4, but there's one thing I don't like in general about encoding.

I can't understand why anyone would want to do ABR encoding. I once had this explained to me:
CBR in video = CBR in audio.
ABR in video doesn't exist and has no equivilent in audio.
VBR in video = ABR in audio.
CQ in video = VBR in audio.
CQ in audio doesn't exist and has no equivilent in video.

I hate encoding in CBR. How can one decide what quality to use on a general basis? A scene where two people are sitting doesn't take as many bits to encode as a scene where two people are running. Why should the whole video suffer from a general bitrate?

Many people complain that their calculated bitrate doesn't give them their projected filesize for 1 CD rips. This is understandable, but I don't like this idea as well. I also don't like the idea of x-pass VBR. It yields higher quality than CBR, but not as good as CQ.

So let me explain my solution. This is what I do when I want to encode an MP3 at "128 kbs": I encode it at 128 kbs CBR, then I encode it at 100% VBR, I compare the file sizes and determine what percent of VBR I should use to get the same file size. For example: If a VBR MP3 at 100% is 100K and at 128 kbs is 28K, then I set my VBR quality at 28% to obtain the same file size.

So, what's the point? Better quality. When the music is very quiet, not so many bits are used, but when the artists are screaming their lungs out and all the insturments are being played, lots of bits are used.

What does this have to do with video? Well if the same meathod used that I use with audio could be used with video, then a new "2-pass CQ" could be made for DivX. The first pass would be made with 100% CQ video, the file size would be determined, then, depending on what filesize one needs, a percentage of CQ video could be calculated to give one that filesize.

Any ideas?

[Taric25]

I have many of views on this post, but not any responses. Do you understand what I'm writing or am I confusing?

CBR = Constant Bitrate.
ABR = Automatic Bitrate. (I think)
VBR = Variale Bitrate.
CQ = Constant Quality

[Steady]

CBR in video = CBR in audio.
ABR in video doesn't exist and has no equivilent in audio.
VBR in video = ABR in audio.
CQ in video = VBR in audio.
CQ in audio doesn't exist and has no equivilent in video.

It would probably be more accurate to say:

CBR in audio = doesn't exist in video
ABR in audio = CBR in video
CQ in audio = CQ in video = VBR in video

In either CBR or VBR the size of the individual frames will vary greatly.

[ChristianHJW]

CBR audio : constant bitrate for every frame/sample

CBR video ( 1 Pass ) : real constant bitrate is only used for elder video codecs. New codecs like DivX3/MPEG4V3 or DivX4 try to achieve the bitrate that was set as the predefined bitrate, but it is only allowed to work within the min. and max Quantizers ( mQ, MQ ) that were set and the reaction time to change quantizers is defined by the other Rate Control Setttings ( RCA, RCR, RCDUR ) . In DivX4 these setttings are accessible, for DivX3 Fast/Low motion they are fixed and were defined by GEJ ( low motion is said to be original MPEG4V3 without any changes ). Nandub is the only tool that will allow us to influence them.
As a result, if the delta information between two frames is really big ( action ) and MQ already applied on the frames it may happen that actual bitrate is much higher than the predefined bitrate, so this is by no means a real 'constant bitrate' . Vice versa, in low motion/still picture bitrate will fall under the predefined bitrate if mQ is alrey applied or Rate control settings are such that reaction is very slow so mQ will not be reached. To ensure the bitrate that was set will be met in average, the codec will always trace the average bitrate it was using so far and then use a factor on the quantizers. As an extreme example if you try to encode a 720 * 480 full DSVD res action movie at a bitrate of 400 kbps you will very likely end up with an encoding where only MQ was applied on every frame. The smaller the range between mQ/MQ is the bigger the changes in bitrate depending on action/low motion scenes and the worse the file size predictability.

CQ Audio : not aware of any audio codec doing this

CQ video : DivX4 only ( i very much like the expression ; it was originally called '1 pass VBR quality based', but CQ is much better ) : In this mode the same quantizer is applied on every frame. 100% quality is Q = 2 , 85% was Q = 4, 60% used to be something like Q = 6, but they recently changed the scale ( DivX4.02 ). The bitrate is highly variable and fully depending on the source movie. In action scenes it may be factor 40 to 50 higher than for low motion scenes, according to the real delta information between the source frames. File size is completely unpredictable. In fact its a big waste of bits as there is really no need to store action scenes with teh same picture quality as low motion and if you go for lower quality values your low motion scenes are compromised too much. I use it only for AVI masters where space is not an issue, i use 100% with full DVD res ( cropped, but not resized ) then.

ABR audio ( 1 Pass ) : Average Bitrate . Lame uses this and it was recommended to me by several members of the R3MIX forums to use preferably for DivX movies if you're aiming for audio bitrates < 140 kbps, compared to Lame VBR being better for > 140 kbps . ABR will use different bitrates on every MP3 audio sample, depending on complexity of the sound. Again it will remember during encoding how many bits it had already spent on audio and thus change its internal way of bits distribution for different complexity levels.

VBR audio ( 1 Pass ) : Similar to ABR audio, but this time the codec will not respect the bitrate it had already spent but always use the same bitrate for certain sound complexitiey, so the outcome is again unpredictable and very much depending on the source material.

VBR video ( 2 Pass !!! ) : In 1st pass video will be analyzed and a complexity value be found for every frame, average complexity will be used to determine how many bits can be spent on each frame in order to meet the prefeined bitrate ( total file size ). In 2nd pass the video is then finally encoded, using information from 1st pass log/stats.


Comparison between the modes :

CBR audio : no equivalent video anymore for modern codecs

CBR video ( 1 Pass ) : similar to ABR audio ( Lame ) ; bitrate changes, codec will try to meet the defined bitrate by changing its encoding algorithm during encoding

CQ video ( 1 Pass ) : similar to VBR audio ( Lame ) ; a fixed compression ration will be applied on every frame/sample depnding on its complexity/delta information

CQ audio : not existing

VBR video ( 2 pass ) : no equivalent audio 2 Pass encoding so far ( would be interesting though )

[undercut]

In DivX4 these setttings are accessible, for DivX3 Fast/Low motion they are fixed and were defined by GEJ

This is done by Microsoft, and Gej has nothing to do with it. DivX 3.11 Fast is MS-MPEG4 V3 3917, Low Mo is 3920. Resulting files are identical except for FourCC codes.

[jrmillerUT]

I totally agree with Taric on his distaste of 4.02 filesizes. I encode a fair amount of anime along with movies. I switched to 4.02 and have done both vfapi with filters and the gknot avisynth as well as writing my own avs scripts. At first I thought it looked great and indeed it does but only if your res is small and you don't care if your filezise predictability is off by give or take 10%. Now when i'm trying to compress 4-5 25 min episodes on a 700mb cd with 128kbs mp3 abr divx4.02 just doesn't cut it. If the codec's log files could be controlled as precisely as gknot's stats file editor and end credits options and sooo forth it would be a great tool. 2pass vbr no editing for the newer rippers as well as people in a rush. And the SBC type ripping with the codec for the experienced. I really do like the better color saturation of the new codec. Everything looks kinda more alive but i also think that the codecs bitrate does not respond well no matter what settings you encode with on 1st pass. And believe me i've tried diff q settings along with diff motion sensing params. I just feel that nandub is still the way to go due to the ability to control the bitrate manually to make the perfect encode. While 4.02 looks great its not refined enough for me so i made the switch back to a dvd2avi gknot nandub setup and i'm not regretting it at all.

Hopefully when 4.5 (is that right?) comes out we will get the control over the codec the way we have control over 3.11

SORRY FOR MARATHON POST!
James

[ChristianHJW]

Originally posted by undercut This is done by Microsoft, and Gej has nothing to do with it. DivX 3.11 Fast is MS-MPEG4 V3 3917, Low Mo is 3920. Resulting files are identical except for FourCC codes.

I know 3.11 Low motion behaves very same way as 'normal' MPEG 4 V3 , so i assumed it was the same. But i was not at all aware of a 'special' MPEG 4 V3 version that is identical to 3.11 fast Motion ? Are you sure about that ? Where did you get this information including the specific version numbers ? So did GEJ do nothing else but just hack the codec and its DirectShowFilter ? How can Nando accesss the quantizers then in nandub if he didnt learn from GEJ how to do it ??

[undercut]

Originally posted by ChristianHJW

Where did you get this information including the specific version numbers ? So did GEJ do nothing else but just hack the codec and its DirectShowFilter ? How can Nando accesss the quantizers then in nandub if he didnt learn from GEJ how to do it ??

http://anipeg.yks.ne.jp/mpeg4.html#divx

It's in Japanese, but check the table. How do you even know Gej did anything beside applying DivX fourCC code to already existing cracks? There were many who were already aware of the crack before DivX. Have you seen the Micro$oft codec floating around?

[fu2k]

undercut is right, but no file size checking is required. From the release readme:

> Files in archive:
>
> engine:
>
> DivXc32.dll Video Codec Version 4.1.00.3920 (Low-Motion codec)
> DivXc32f.dll Video Codec Version 4.1.00.3917 (Fast-Motion codec)
> DivX_c32.ax Direct Show Decoder Version 4.1.00.3917 (Hi Quality decoder)

[Taric25]

Okay,

I understand what we're talking about here, so let me explain what I want out of this discussion.

MusicMatch Jukebox (yes, I know this isn't the same as lame) does MP3 CBR and MP3 VBR. When you want to encode to CBR, the slider bar (right is worst quality, smallest filesize, left is best quality, largest filesize) is shown and allows you to pick your bitrate. When you want to encode to VBR, the slider bar (right is worst quality, smallest filesize, left is best quality, largest filesize) is shown and allows you to pick a percentage of quality.

I would like to intergrate this into DivX4 and make a new type of DivX4 CQ, where the first pass would be at 100%, the filesize would be determined, and a new percentge of CQ could be calculated to suit one's filisize needs. For example, if a video's 100% CQ filesize was 3500MB, a 20% CQ would be set to provide a 700MB filesize.

Would there be an actual way to do this or is this talk simply theoretical?

[jrmillerUT]

yes but we need specificity over the bitrate... like end credits encoded at minimum and the ability to boost complex scenes the codec might have given less bits...

[Taric25]

Originally posted by jrmillerUT

yes but we need specificity over the bitrate... like end credits encoded at minimum and the ability to boost complex scenes the codec might have given less bits...

You totally didn't understand what I said. The bitrate is dependant on quality, not bits. The quality of the video stays constant, but the bitrate changes throughout the entire movie.

Am I being unclear?

[jrmillerUT]

whoah dude calm down... didn't mean to offend anyone... i understand what you're saying... but if we had more of a control over the curve... and no off to dmitry or blacksun... then we wouldn't have to deal with just the CQ's... we need more control than just CQ's

[Taric25]

Okay, I understand what you mean now, and I'm sorry for blowing up on you, and I hope you accept my apology.

So what other kind of control would you want, specifically?
Also, I hope this isn't just theoretical discussion and not related to any actual tool that can be made.

Any ideas?

657 views and only 12 responses?
Hey you. Yes you, the one reading this post and not contributing. If you have any ideas that are good for discussion or something else, please post them.

[ChristianHJW]

Taric25, where would you way of encoding differ from DivX 4 1 Pass quality based encoding with quality settings ??

[Taric25]

The quality settings don't allow us to get an estimated filesize. My way is like a 2 pass CQ.

[-h]

The current DivX4 2-pass code already does this - it performs the first pass at "100% quality" (quantisers fixed at 2), then chooses a "lower quality" (average calculated quantiser) for the entire movie to reach the desired bitrate, say 4.24 for example, though it does include some under/overflow compensation to reach the target bitrate.

The quality slider just allows you to specify an average quantiser for the whole movie - 90% sets it to 3.4 for example. Doing multiple quality-based passes is functionally no different to the 2-pass mode, and will just require more of your time to get the right bitrate. The differences introduced by the under/overflow compensation are quite minor.

-h

[ChristianHJW]

Originally posted by -h The current DivX4 2-pass code already does this - it performs the first pass at "100% quality" (quantisers fixed at 2)

Nandub/DivX3 does it this way, DivX4 will do a very normal '1 Pass' ( in former times being called '1 Pass CBR' ) encoding during 1st pass, using different quantizers depending on rate control settings. This is only done to measure 'complexity' for each frame, to be calculated from frame size and quantizers that was used on it.

Frame information, average complexity and average quantizer, as well as the calculated file size from this 1st pass ( although there is no file being created ) are stored in the log file and used for 2nd pass then....

[dragonlz]

Taric25,

You are saying divx4 doesn't give you the exact size that you specify? I've done a lot of rips in divx4 and using the bitrate calculated in GKnot, the size always comes up to be the desired size(give or take 3MB)
Maybe I'm missing your point, but why bother with quality parameters when the bitrates are distributed according to the curve that's built in the first pass?

[ProfDrMorph]

657 views and only 12 responses?
Hey you. Yes you, the one reading this post and not contributing. If you have any ideas that are good for discussion or something else, please post them.
Have you ever thought of the possibility that others that are new to DivX read this to learn and can't give you new ideas or that ones that want to help see that others already posted what they would've said? I think it's not so nice to "shout" at people like that.

[sh03z]

I don't know how I found this post, but it seems interesting...

anyways, your whole "concept" of DivX is wrong.

First off, NEVER EVER use divx 4, except for watching (decoding) movies on your computer. Why? Because it's crap, DivX 3.11 is the best for encoding...not speaking about divx 5.01 or any higher than 4, because I have never bothered with those.

Second, you don't want to encode a movie twice with a constant biterate, then a variable bite rate. Why? Because the biterate HAS TO CHANGE in the movie...why does it have to change??? It changes to higher biterates when an action scene occurs...programs such as nandub know this, and sense the motion and add extra biterates...

Like if they were sitting and having coffee, maybe the biterate would be 650, but...if they were fisting it out, it would be about 950-1000 I would think...

If this thread was on video tape, the beginning would be in 700 kbps, and the rest would be going up to like 1000+ kbps...

Your comparing apples with oranges, audio is totally different than video...

[jonny]

The last post is dated 12th December 2001
Now is 19th December 2003
:rolleyes:

[sh03z]

haha!!!

I was looking for a date, just couldn't find it.

LMAO