H263 vs Mpeg quantization and a couple of questions [Archive]

philippas

19th February 2002, 22:38

I just two passes with xvid the first one with H263 and the other one with mpeg quantization. I used the stats reader by Koepi and the size of the first pass was the same with both settings. Is this normal? Does the quantization method affects only the second pass ?

1. Can someone explain a bit those two algorithms ?

2. Also i noticed that during the first pass i could see (with debugView) both intra and inter frames. Is this also normal?

3. Where can i get a DRF analyzer for xvid to check for quality comparisons.

4. I used divx fourCC and for the decoding divx 4.12 is used. Is that decreases the quality of Xvid, or Xvid and divx4 are fully compatible ?

An impressive thing is that the filesize is very accurate. I aimed at 632mb and guess what i got 632mb! The quality is very good. I'll do now the encoding in nandub for comparison and i'll post my full results and settings used.

-h

19th February 2002, 23:38

I just two passes with xvid the first one with H263 and the other one with mpeg quantization. I used the stats reader by Koepi and the size of the first pass was the same with both settings. Is this normal? Does the quantization method affects only the second pass ?

It isn't normal.. the output from MPEG quantization should normally be smaller than H.263.

1. Can someone explain a bit those two algorithms ?

They are different ways of "quantizing" the DCT coefficients. Quantizing just means "divide these numbers by some other number to make them smaller". H.263 divides everything by the same number, whereas MPEG is biased towards low-frequency quality.

2. Also i noticed that during the first pass i could see (with debugView) both intra and inter frames. Is this also normal?

Intra frames (I-frames) are the equivalent of key frames. Inter frames (P-frames) are.. not key frames.

3. Where can i get a DRF analyzer for xvid to check for quality comparisons.

Don't even know what a DRF analyzer is.

4. I used divx fourCC and for the decoding divx 4.12 is used. Is that decreases the quality of Xvid, or Xvid and divx4 are fully compatible ?

They are fully compatible in theory (both are MPEG4 codecs), but DivX 4.x has a bug when dealing with MPEG quantiztion. If you're not using MPEG quantization, using the DivX filter will give you the added benefit of post-processing, which XviD currently lacks. If you are using MPEG quantization, you'll notice weird colours showing up every now and then if you use DivX to decode.

-h

An impressive thing is that the filesize is very accurate. I aimed at 632mb and guess what i got 632mb! The quality is very good. I'll do now the encoding in nandub for comparison and i'll post my full results and settings used. [/B][/QUOTE]

movmasty

20th February 2002, 07:00

Teegedeck says that h.263 quantizers are for lower size
and that h.263 quantizer 2 is like the mpeg 3

-h says: output from MPEG quantization should normally be smaller than H.263

then ??

-h

20th February 2002, 10:14

I should do more tests on this.. but typically, MPEG quantization will result in smaller frame sizes for equal quantizers than H.263.

The reason for using H.263 in 1-CD rips is that it looks smoother when typically-high 1-CD quantizers are used. In this case, MPEG looks harsher.

-h

movmasty

20th February 2002, 10:26

if i understand:
-h.263 quantizers gives larger size(in fact it is an older codec)
-then some "smooth engine" make the size of high h.263 quantizers smaller...........

....then.....
if you use the mpg quantizer but applying before some smooth filter,
you should get both, an higer quality form a newer codec, and same high compression from the smooth filter used??

in fact also the wmv8 codec works this way,
at low quantizer it almost the same as divx/mpegV3
then,at high quantizers,it applies some kind of smoothing....

-h

20th February 2002, 10:34

Not really.

Applying H.263 and MPEG quantization to the same frame, with an equal quantizer, will normally result in the MPEG frame being smaller.

However, the different matrix used by MPEG quantization makes the decompressed image appear "sharper", whereas H.263 appears "smoother". There is no filtering involved, just different DCT coefficients receiving bias. Sometimes the softness of H.263 is favourable, since it means you won't see the block artifacts as easily. MPEG quantization, with higher quantizers, normally means very visible block boundaries.

in fact also the wmv8 codec works this way,
at low quantizer it almost the same as divx/mpeg3
then,at high quantizers,it applies some kind of smoothing....

WMV8 always applies a smoothing prefilter, so does DivX 3.11 (though this can be turned off).

You could apply a smoothing filter prior to MPEG quantization.. but your eyes would be the final judge of what looks better.

-h

movmasty

20th February 2002, 10:41

ok :)

philippas

20th February 2002, 14:56

Then if H263 and mpeg quantization produce different 1st pass sizes it should be a problem with virtualdub. I chained in the job file two encodings one with H263 and the second with mpeg quantization and both gave me a stats file which when i opened it in koepi's stats reader,Gnot, gave me the same size/quality(for Gnot). So i guess the codec settings are not saved correctly in the jobs file in virtualdub ?
I'll do some tests and i'll post again.

2. About question 2, it was strange for me because Nandub used only delta frames in the first pass but Xvid uses delta and keyframes(inter and intra) that's why i didn't know if that was normal or not.

movmasty

21st February 2002, 07:45

Nandub used only delta frames in the first pass

really?

Acaila

21st February 2002, 09:16

So i guess the codec settings are not saved correctly in the jobs file in virtualdub ?

I have noticed exactly the same thing. Yesterday I qued two jobs. Both were the credits section of a movie (about 5 mins). Just as I always do with DivX4 I set mQ=MQ=31 for XviD. The first file turned out as about 10MB (as it should), the second as 50MB!!

My conclusion, XivD settings aren't save properly in VDub jobs. So, is this VDub's fault or XviD's?

rui

21st February 2002, 09:48

I must do some experiments with this too.
All my XviD encodings are done by using the job control feature.
If it's messed up, i'm in trouble. :scared:

Franko30

21st February 2002, 09:57

Originally posted by rui
I must do some experiments with this too.
All my XviD encodings are done by using the job control feature.
If it's messed up, i'm in trouble. :scared:

Well, if it is, I'm in trouble, too - but:

Why do the encodings still look that damn good and keep the filesizes exactly to the given size, even if s.th. might be wrong?

Frank

P.S.: @movmasty

I didn't know you could do XVID in Nandub? Or do you just use it for creating the *.stats files? But why do the encoding first pass with Nandub and the second pass with VirtualDub (as you can't choose the XVID codec in nandub)?

Ripe73

21st February 2002, 10:27

Well i encoded two movies over the night qued in V-dub 1.4.8 and when i wake up and checked the last encodings settings L.Masking was enabled and im 100% sure i did not enabled it.
The first movies endcredits was(5min) 14mb with 25%endcredits
The second movies endcredits was(5min) 37mb with 25%endcredits so there must be something wrong,i guess i have to do the second movie again;)

EDIT:I think i have smaller size on the endcredits when the there was a constant DRF setting insteed %

Acaila

21st February 2002, 10:55

@Ripe63:

Did you check how the credits look? Do they look like they are encoded with 25%?

I'm asking, because the weird thing is, my credits which came out at 50MB actually look like they are encoded with quantizers 31 even though the filesize is way too big, it was far too crappy quality to justify the size...

I'm at work atm, so I can't re-check the movie or settings.

Ripe73

21st February 2002, 11:03

Did you check how the credits look? Do they look like they are encoded with 25%?

I checked the Debugview and it show me every frame with DRF and size and the DRF was 6-8 on the first movie and 8-10 on the second movie but its two different movies but 37mb is to much i think.

-h

21st February 2002, 11:10

Teegedeck

21st February 2002, 11:16

...just because Nandub gets mentioned some times here, and this might be confusing for some people, I want to make clear that NANDUB CAN'T ENCODE XVID, it always encodes DivX3.11.

This is for visitors reading this topic who didn't know yet

[EDIT:] One more thing: You CAN'T use the .stats files from a first pass with Nandub to do the second pass with XviD, either, for the same reason as above.

Franko30

21st February 2002, 11:27

Originally posted by Ripe73

its two different movies but 37mb is to much i think.

Well, I guess it is possible - just check whether the credits of the second movie have moving background or whether it's REALLY black etc. And why use a Quant lower than 10 for end credits, where's the point? My end credits of Boiler Room 576x308 (ca. 5 min.) are 28.4 MB using Quant 14, 50 % Bitrate of ca. 732 and look great. I guess I could compress even more, as 5 min. from the actual movie amount to 39 MB.

BTW, I did some tests concerning filesizes (predicted and actual) but without end credits:

Koepi's Feb17th binaries.

Test-01-576x432:

XVID 2 pass, Global Quant settings 1-14, I-Quant settings 1-6, Quant smoothing enabled, search precision 5, luma masking disabled (and it stays that way, no "automatic switching") - desired filesize 13535.

Quantization Type: H.263

Last line of Debugview 1st pass shows:
(...) sum: 21104 (...)

Resulting filesize of the 576x432 H.263 Quant file: 13542

Quantization Type: MPEG

Last line of Debugview 1st pass shows:
(...) sum: 21104 (...)

Resulting Filesize of the 576x432 MPEG Quant file: 13544

Quantization Type: Modulated (H.263 during first pass)

Last line of Debugview 1st pass shows:
(...) sum: 21104 (...)

Resulting filesize of the 576x432 Modulated Quant file: 13544

So, what might this tell us? I think this means:

On my system the Job settings of VDub are saved correctly and that everything seems to be fine... :)

Frank

@ Teegedeck:
I knew that using Nandub isn't possible, just wanted to know whether movmasty really tried to do it.

Ripe73

21st February 2002, 11:59

And why use a Quant lower than 10 for end credits, where's the point?

You never know what DRF there will be on the endcredits with this %
the Average bitrate on the movie was 920 and 25% of that is 230,so i thought it should be around 12DRF as use when i encode with Divx3.11
in GKnot.
So again this % is not good ,i vote for constant Q.

Acaila

21st February 2002, 12:14

I just want to say that I don't "like" the credits rate system - encoding credits with a fixed quantizer is much neater imho. Not to mention faster.

But if you must.. you should expect the odd weird result

I DID use constant quantizer settings (1 pass quantizer), but still something went wrong.

And why use a Quant lower than 10 for end credits, where's the point?

To get filesize down of course! Why else?
I always use constant 31 on end credits and it gives me a range of 5-15MB depending on framecount. What's the use in using 10 if you can compress much more with 31 I tell you? If you want good quality, then don't even bother to encode them seperately.

And even with 31 the credits are perfectly readable.

rui

21st February 2002, 12:19

Well, i just did some tests using a movie trailer.
I qued a lot of jobs in Vdud and the results are:

First, i qued two jobs, with the exact same settings (CBR-900), to see if the filesize was the same in both. Both files came out with 16602, so no problems here.

Then i qued another two jobs, one using quality 50 and the other using quality 85. This last one should have much bigger filesize than the first. It went ok, the first had a filesize of 6160 and the second one 20126.

Then, i qued another two jobs, one with quantizer 25 and the other with quantizer 5. The first job should have a filesize smaller than the second one. It went ok again, the first filesize was 4248 and the second had 22628.

So, i didn't find out any errors. But i didn't test with the encoding credits.

Franko30

21st February 2002, 12:24

Originally posted by Acaila

And even with 31 the credits are perfectly readable.

Can't confirm that - as I use MPEG2 files from an analogue source, credits with small letters really suck starting from Quant 16.

Frank

BTW: "lower than 10" from my previuos post is 1 to 9. You might want to check the logic of your reply.

Acaila

21st February 2002, 16:24

Can't confirm that - as I use MPEG2 files from an analogue source, credits with small letters really suck starting from Quant 16.

Don't know about analogue, but with DVD's it's still very readable for me. And that's not even all I do to it to get the filesize down... But I guess it's all a matter of perspective, what might look good for me could look like shit to you.

BTW: "lower than 10" from my previuos post is 1 to 9. You might want to check the logic of your reply.

Sorry, my mistake. I was thinking on a quality scale instead of a numerical scale. So lower quality than 10 would be 11-31.

Ripe73

21st February 2002, 19:29

HI Again!!!

I encoded a movie(as usually;) )the movie is "the watcher" not so good but worth a cdr.
My settings

Koepis build(afraid to change)
2pass int. H:263
M.Search:5
Main DRF Min:1 Max:10
Iframe Min:2 Max:5
SmoothQ. secondpass
No L.masking
endcredits%10 (ca5min)
Average bitrate:920
moviesize calculated with GKnot 640392KB
moviesize after encoding 653608KB:scared:

Everything look okay until the endcredits start,overflow +257 the frame before endcredits.
But then every frame was encoded with DRF:10 and the overflow grow like hell:devil: and the overflow on the last frame was -13486867 so it seems that mainDRF lock the endcredits too.But i encoded the endcredits with 1pass quantizer 16 and got the exact size i wanted and then append the files in AVIut.
I think it was -h i asked if the endcredits locks with the main DRF but it shouldnt.
Is something wrong?

philippas

21st February 2002, 22:03

I mentioned Nandub in an early post meaning that while doing a first pass with nandud+divx3.11 you have only one keyframe at the begining the rest are delta frames. In the contrast while doing a 1st pass in virtualdub with Xvid(17-02-02 by koepi)i noticed (with debugView) that there were inter and intra frames(keyframes and delta frames).
You can't use xvid with nandub !!!

The only combination that seems that is not saved correctly in the jobs files of virtualdub is when you chain a 1st pass with h263 quantization and a first pass with mpeg quantization. I did some further tests and the same thing is happening.

I compared also the quality of an automatic 2-pass encoding with nandub and an 2-pass encoding with Xvid and xvid seemed better. I think xvid has a better motion detection algorithm(i used ultra-6) and with H263 quantization it appeared less blockier in fast motion scenes.
The bitRate was for one cd target of 632mb which both xvid and nadub hit excatly.

-h

21st February 2002, 23:10

I think it was -h i asked if the endcredits locks with the main DRF but it shouldnt.

Ohhh you're using credits % rate mode! If you use credits % rate or size modes (not credits quant), the credits get restricted by the min/max quant settings. I should probably change this.

-h

Foo

22nd February 2002, 02:13

Originally posted by -h
Ohhh you're using credits % rate mode! If you use credits % rate or size modes (not credits quant), the credits get restricted by the min/max quant settings. I should probably change this.

-h

Yes, you should ;) . A BIG thanks for adding the const quant credits back in -h. I only had to beg once, I love OSS development <g>.

cheers,

foo

philippas

23rd February 2002, 01:29

Quantization Type: H.263

Last line of Debugview 1st pass shows:
(...) sum: 21104 (...)

Resulting filesize of the 576x432 H.263 Quant file: 13542

Quantization Type: MPEG

Last line of Debugview 1st pass shows:
(...) sum: 21104 (...)

Resulting Filesize of the 576x432 MPEG Quant file: 13544

Sorry i thought the two quantization methods would have some Mb difference and not bytes that's why i thought the size was the same for the two methods. I didn't checked it with debug view but with koepi's stats reader which gives you the size in Mb.

An odd problem now, i finished a 2-pass encoding which i had trimmed the credits. Then i tried to join the credits, which were encoded seperately, but virtualdub gives an error saying the video streams have different format :confused:
Any ideas what's wrong ? The movie and the credits have the same FourCC (divx)

Foo

23rd February 2002, 02:17

The joining issue is a known problem (although I haven't seen a detailed reason for it yet). Vdub/Ndub report different formats, even if they are both the same. Aviutl (.96i) will join them just fine though.

cheers,

foo

philippas

23rd February 2002, 02:52

Thanks i'll try Aviutl

philippas

23rd February 2002, 03:10

I tried Aviutl 0.97a and it gives me the error "unsupported format" for the movie. I tried also to change the FourCC of the movie with the FourCC changer but it can't open the file.
The movie though plays fine and can be opened with virtualdub. It's starting to get very irritating!
Any other ideas???

Foo

23rd February 2002, 04:14

Well this is another known problem :D . The newer versions of Aviutl also have problems with them. I'm not sure exactly which is the LAST version to work, but I know .96i works on this box. Not sure if older versions are up anywhere though, but I assume they are available.

cheers,

foo

philippas

23rd February 2002, 04:26

Thanks
Is it posible to zip and upload in this thread, a version of Aviutil that is working ?

Ripe73

23rd February 2002, 09:21

Download Doom's version and execute the *.exe with the latest Aviut *.exe and you can append XviD's and you dont need to understand Japanese:D

Acaila

23rd February 2002, 09:31

I had that problem with not being able to join the credits also. It seems that the different XviD builds (which appear about every day :) ) play a part in that. Once I had that problem with a movie, re-encoding the credits with the same build as the main movie solved it completely.
After doing that you can just use Vdub/Nandub again.