XviD-1.1.-127-13102004...

[Koepi]

I have the options:

[ ] loose curve scaling and
[ ] respect vbv buffer

here. What options are you talking about, where to find those?

if you check loose curve scaling, "old" loose scaling gets used, else if it is unchecked then the new, strict scaling of foxer is in effect.

Unchecked "respect vbv buffer" means _no_ vbv compliance, checking the box means VBV buffer constraints should get respected. This works with both CC algorithms.

Regards
Koepi

[yaz]

@koepi
thx, man! it seems i messed up everything. i made a lot of tests while i didn't know what was i doing exactly (my usual way :-)

would u (or anybody else) detail what does 'vbv compliancy' means here exactly ?

another (very very small) thing. wouldn't it be better to change the ticking logic on cc ? i mean, if 'loose' was the old cc why not ticking when i want the new one. this way, if i don't tick anything i get the old way. ticking anything would call the new implementations. more straightforward for me. i just mention it, because that's been my logic so far. not a big deal, anyway.

thx again
y

[kurt]

Originally posted by LigH
I was just confused if VHQ>1 is working with, and applied to B-frames too, although it sounded like "VHQ works in mode 1 only for B-frames, if used".

If I select VHQ = 4, mode 4 is applied to P-frames; but does it apply mode 1 or 4 to B-frames, if "VHQ for B frames" is enabled?

that would interest me too... ;)

[Sharktooth]

If VHQ is enabled and you select VHQ for b-frames it will use VHQ x (your setting) for P frames and VHQ 1 for B frames.

@Koepi: could you please make a build with selectable VHQ mode (1-4) for B-frames too (only if it is not too complex...)? Or maybe just one more checkbox which will enable VHQ 4 for B-frames...

[Koepi]

sysKin implemented VHQ mode 1 (mode decision) for bframes _only_. There's no such thing as VHQ > 1 for bframes yet.
IIRC sysKin did mention that there'll be no benefit other than a speed loss when applying other additional search for bframes.
(Unofotunately I forgot the arguments sysKin used, they were very convincing though.)

Regards
Koepi

[Sharktooth]

Ok, so a research was already made. :)

[loni_blues]

@Koepi
Well, your suggestion seemed to work fine. But I was using no proxy and no cache.
Thanks a lot.:)

[Sharktooth]

Some ISPs use transparent proxies...

[Prettz]

Thanks so much for this new build, xvid devs! And thank you for putting in all the hard work and patience it must have taken to implement b-frame VHQ.

[ChronoCross]

I finally got it to compile myself. after some major fricken editing I was able to compile it in MS visual studio .net 2003. I tested out some of the new features and all I can say is WOW. it's pretty nuts the increase in quality. The new strict scaling is having a huge effect. Keep up the great work xvid.

[kxy]

Originally posted by yaz
@
would u (or anybody else) detail what does 'vbv compliancy' means here exactly ?
thx again
y

VBV is short for Video Buffer Verifier, VBV is a MPEG standard that helps ensure MPEG data stream never exceeds the buffer on the MPEG decoder.

There, the major purpose of the Video Buffering Verifier mechanism was to set some restrictions on the maximum variability of the number of bits per picture, especially in the case of constant bit rate operation, and thus on the complexity of the encoded video streams.

This model is used to verify if the bitstream memory required at the decoder does not exceed the values specified for the corresponding profile and level definition. The model is defined in terms of the VBV buffer size which is the maximum amount of bits that the decoder can store in the bitstream memory. The encoded bits for each VOP enter the VBV at constant or variable bit rate, and are instantaneous removed from this buffer at the VOP decoding time.

Generally speaking, operation of the VBV is tied to two transmitted values, vbv_buffer_size_value, the maximum buffer fullness, and vbv_delay, the delay between storing a picture start code in the buffer and starting the decoding of that picture. vbv_buffer_size is transmitted in every sequence header. vbv_delay is transmitted in every picture header.

[yaz]

@kxy
thx very much but ... i know the theory of vbv :-) what i asked how does this certain implementation works. just asked because i found significant effect of switching on/off 'vbv' even at low bitrates (800kbps or lower) where i wouldn't expect any vbv harming. maybe i'm wrong here (again:-), but what i see is a kinda 'smoothing effect', maybe, for preventing sharp spikes in the bitrate. dunno. so, what i'm interested in is the 'mechanism' of this algo.

thx again
y

[Mug Funky]

hmm... q3 encodes seem a little bigger under this version (with b-frame VHQ on). they're certainly prettier though :)

[edit]

oh, and the decoder seems to decode in the TV range... black in the last version becomes dark grey in this one.

[ChronoCross]

Possible glitch? 1 out of 4 times xvid fails to create a stats file any ideas?

[Tommy B.]

I did some test on a high motion clip. "Call on Me" (you know, the
one where the chicks are in ;))

Bitrate: 700kbit/s (128kbit/s for sound)

Adaptive Quant on
BVOPs: 3
Closed GOV
Chroma Optimizer Enabled
MSP: Ultra High
VHQ: 4
Use Chroma Motion
All Quants: 2-31
Trellis

Everything else on default.


Tests:
h263 with B-VHQ on (Avg. Quant: 11.606)
h263 with B-VHQ off (11.535)
jawor's 1cd matrix with B-VHQ on (11.378)
jawor's 1cd matrix with B-VHQ off (11.261)

This was somewhat like a stress test for the codec. Look at the
results.


Frame 307
h263 B-VHQ off
http://v129101.dd6718.kasserver.com/370_h263_off.png

h263 B-VHQ on
http://v129101.dd6718.kasserver.com/370_h263_on.png

jawor B-VHQ off
http://v129101.dd6718.kasserver.com/370_jawor_off.png

jawor B-VHQ on
http://v129101.dd6718.kasserver.com/370_jawor_on.png

There is a lot of blocking in h263 compared to jawor. Still, if you
look at the left arm of the black dancer you'll see that VHQ on
creates less blocks here. Also look at the lip of the dancer in
front. jawor creates less blocks with B-VHQ on. The right hand of
the dancer in front is also less blocky.


Frame 1323
h263 B-VHQ off
http://v129101.dd6718.kasserver.com/1323_h263_off.png

h263 B-VHQ on
http://v129101.dd6718.kasserver.com/1323_h263_on.png

jawor B-VHQ off
http://v129101.dd6718.kasserver.com/1323_jawor_off.png

jawor B-VHQ on
http://v129101.dd6718.kasserver.com/1323_jawor_on.png

Seems like B-VHQ off gives more detail in h263. Download the pictures
and compare it yourself with irfanview (switch between the images).
Look at the lip of the woman and the hair. Jawor on and off is nearly
the same. On smooths the image a bit, while off gives a little bit
more blocks (hardly noticeable).


Frame 1406
h263 B-VHQ off
http://v129101.dd6718.kasserver.com/1406_h263_off.png

h263 B-VHQ on
http://v129101.dd6718.kasserver.com/1406_h263_on.png

jawor B-VHQ off
http://v129101.dd6718.kasserver.com/1406_jawor_off.png

jawor B-VHQ on
http://v129101.dd6718.kasserver.com/1406_jawor_on.png

B-VHQ on in h263 results in a lot of less blocking. Look at the
raised arm. jawor with B-VHQ on creates less artifacts (look at
the other arm). jawor off looks a little more sharper to me.


Frame 2645
h263 B-VHQ off
http://v129101.dd6718.kasserver.com/2645_h263_off.png

h263 B-VHQ on
http://v129101.dd6718.kasserver.com/2645_h263_on.png

jawor B-VHQ off
http://v129101.dd6718.kasserver.com/2645_jawor_off.png

jawor B-VHQ on
http://v129101.dd6718.kasserver.com/2645_jawor_on.png

h263 looks pretty bad here. B-VHQ on results in less blocking again.
Jawor with B-VHQ on gives a better image than off. If you look at the
neck, there are some ugly blocks which are not present in off mode.
Seems like some sort of smart bitrate redistribution to me?


Conclusion
Looks like VHQ for B-Frames smooths out the picture a bit, while
creating usually less artifacts that in off mode. Using the matrix
by jawor gives the best results so far.

Let's see how these clips perform on my Kiss DP-450.

Btw: These frames are all B-Frames.

[Sharktooth]

B-VHQ improve B-Frames quality in a considerable way.
My tests have shown a global PSNR/SSIM rising when B-VHQ is enabled.
BTW that improvement depends also on what quantization type/matrix is used.
In my tests (high motion source, 2 pass encoding at 900kbps - xvid default settings except trellis and b-whq) EQM V3ULR was the best ("numerically speaking") performer.

[stegre]

Originally posted by Koepi
Sorry to bump into my own thread again, but I just checked a sample - encoding anamorph with this build (thus writing the AR info into the bitstream) works like charme with the included dshow decoder.

So only forcing different AR during playback in dshow doesn't work, else everything seems quite alright :)
I don't think it's using exactly the right values, though. When encoding 720x480 to 16:9 it should use the 32/27 as par_width and par_height respectively. You can get that by taking 7680/6480 (which is 16/9 * 480/720) and reducing it using the GCD of 240. It looks like the required code to perform that calculation is there, but instead it comes up with "255/215". If I run it under a debugger it appears that it gets that as an integer approximation of "5333/4500", but I didn't trace it back any further than that.

[SeeMoreDigital]

Originally posted by stegre
I don't think it's using exactly the right values, though. When encoding 720x480 to 16:9 it should use the 32/27 as par_width and par_height respectively. You can get that by taking 7680/6480 (which is 16/9 * 480/720) and reducing it using the GCD of 240... I'm glad you mentioned this... I've been saying for many months that all the standard PAR values are wrong but keep getting shouted down by people quoting ITU standards

XviD, 3ivx and MPEG4 Modifier use the following 'presets' to calculate an anamorphic frame with PAR signalling: -


Default PAR Setting | Codec Calculation | As stated in player info
For 4:3 PAL 12:11 625lines 15:11
For 4:3 NTSC 10:11 525lines 15:11
For 16:9 PAL 16:11 625lines 20:11
For 16:9 NTSC 40:33 525lines 20:11Personally I prefer to use these PAR settings: -


Required PAR Setting | Custom Codec Calculation | As stated in player info
For 4:3 PAL 64:60 (16:15) 4:3 or 768x576
For 4:3 NTSC 64:72 (32:36 / 16:18 / 8:9) 4:3 or 640x480
For 16:9 PAL 64:45 16:9 or 1024x576
For 16:9 NTSC 64:54 (32:27) 16:9 or 853x480

Some people may be interested to know that I'm currently in the process of generating some "pixel perfect" test cards. Which I hope will finally prove this matter.


Cheers

[RadicalEd]

He's talking about the picture aspect ratio calculations, not the pixel AR presets. And mine are still better. :p

[SeeMoreDigital]

Originally posted by RadicalEd
He's talking about the picture aspect ratio calculations, not the pixel AR presets. And mine are still better. :p So am I...

http://img98.exs.cx/img98/4033/SMDPARInfo.png

If the presets are wrong, the files will be "encoded" and consequently "decoded" and analysed wrong!

Have a look at these 720x576 PAL examples (http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/PAL_720x576_16.9_Anamorphic_PAR_Tests.zip). And tell me which one plays back correctly?

One has been encoded using the default XviD (3ivx and MPEG4 Modifier) "16:9 PAL" setting, the other has been encoded using a "Custom 64:45" setting. And there's a 720x576 1:1 encode for you to play with!


Cheers

EDIT: Added an 1024x576 "True 16:9 Frame" encode to the above mentioned samples.

[stegre]

I should add that, technically, "255/215" is illegal under ISO/IEC 14496-2, as the two numbers are not "relatively prime" (though I doubt any player or other software would really care). The value is quite close, though, as can be seen below on the next version (not released yet) of GSpot 2.5x beta where I've just added support for AR info from MPEG-4 streams inside an AVI container.

http://gspot.headbands.com/images/par.png

edit: I should mention that I obtained the second screenshot from a second file I encoded, where I manually entered the 32/27 instead of selecting 16:9 - that worked fine.

[SeeMoreDigital]

Hi stegre,

I've found a tool that will allow the user to generate video from still images. While this is not "earth shattering", it does allow you to generate encodes to the nearest "even" pixel.

I've just used it to generate an 854x480 Mpeg4.avi, which is about as close as you can get to a "true 16:9 frame" NTSC image!

If the tool could be of use to you, please let me know?


Cheers

[loni_blues]

@Koepi,

Sorry to bump into my own thread again, but I just checked a sample - encoding anamorph with this build (thus writing the AR info into the bitstream) works like charme with the included dshow decoder.

I can´t get PAR (Pixel-Aspect-Ratio) to be displayed correctly by any program except VLC (which does not use the Xvid decoder). I have unregistered the Intervideo decoder. GSpot shows xvid.ax is being used for decoding.
But when I use Bsplayer or Zoomplayer the AR is wrong. What software do you use for playback? Is something inherently wrong with what I'm saying?
Thanks in advance.

[Koepi]

loni_blues:

that is weird. Do you have DirectX9 installed? It works fine for me on WinXP / DX9c and Win2k /DX9b+c with every dshow based player (mplayer2, media player classic,...).

Also note that you have to uncheck "compatibility renderer" - the old compatibility renderer isn't capable of resizing!

I need to know a little about your system I fear.

Regards
Koepi

[SeeMoreDigital]

Koepi,

Quite often, I've noticed, that if you play an anamorphic encode and then a square pixelled encode and then an anamorphic encode. The "Aspect Ratio" box goes completely blank....

http://img96.exs.cx/img96/5010/SMD_XviD_AR_setting_box.png

Has anybody else noticed this?


Cheers

[Sharktooth]

No, but i have the same problem as loni_blues.
DirectX 9.0c installed and the compatibility render is uncecked...
Nero Showtime displays the correct AR, while WMP, MPC and Winamp 5 (just for trying...) dont.
I have the latest FFDshow (from sourceforge) installed but xvid decoding is disabled (Raw video: all enabled).

[loni_blues]

Koepi,

My OS is Windows XP. I have recently installed DirectX9.0c (had 9.0b before) and compatibility renderer is unchecked. The only programs that display the Pixel-aspect-ratio correctly are VLC and now "MPlayer for Windows". None else (Bsplayer, ZoomPlayer, MPC, Nero Showtime).
Thanks for any help or suggestion,
Regards.

[SeeMoreDigital]

Originally posted by loni_blues
... The only programs that display the Pixel-aspect-ratio correctly are VLC and now WinMPlayer. None else (Bsplayer, ZoomPlayer, MPC, Nero Showtime). This is not right!

If WinMedia player is working correctly, it must be using a suitable DSdec filter from somewhere, which you can identify from the players properties.

Also, if you're not getting any "auto" AR switching in ShowTime, you must have an old version installed.


Cheers

[Leak]

Originally posted by SeeMoreDigital
This is not right!

If WinMedia player is working correctly, it must be using a suitable DSdec filter from somewhere, which you can identify from the players properties.

I'd hazard a guess that WinMPlayer was meant to mean "MPlayer for Windows", which of course doesn't rely on DirectShow at all...

np: Mouse On Mars - Blood Comes (Radical Connector)

[loni_blues]

Leak,
You're right. I meant "MPlayer for Windows". I'll correct that in the previous message.

SeeMoreDigital,
My Showtime version is 1.5.0.22 while the latest seems to be 1.5.0.41. My version doesn't seem old at all.

I use matroska as container but did a test with avi as well. The only program that displays both formats right is still VLC. MPlayer for Windows only seems to display well the avi and the other programs tested can't display well neither of them. The Xvid decoder seems to not be working at all.
Regards.

[Koepi]

Do a search for "xvid.ax" on your system partition and post the date/time, filesize here.

I get the feeling the xvid decoder doesn't get used at all and your system is messed up (you quite obviously have plenty of softare installed which can interfere wit that for proper operation).

In that case we can't do anything for you except for giving the hint to properly install a fresh sytem, start with vga drivers, then platform(chipset) drivers - then xvid. In that state it should work. Then install all the stuff you want - and after each installation check whether xvid still works or not until you tracked down the guilty program.

At this stage I want to emphase again that codec packs are evil and if you installed one (it doesn't matter if it seemed to have been uninstalled correctly) you better should mention that, then the only solution is a fresh installation anyways.

Koepi

[HalfHuman]

Originally posted by Koepi
Do a search for "xvid.ax" on your system partition and post the date/time, filesize here.

I get the feeling the xvid decoder doesn't get used at all and your system is messed up (you quite obviously have plenty of softare installed which can interfere wit that for proper operation).

In that case we can't do anything for you except for giving the hint to properly install a fresh sytem, start with vga drivers, then platform(chipset) drivers - then xvid. In that state it should work. Then install all the stuff you want - and after each installation check whether xvid still works or not until you tracked down the guilty program.

At this stage I want to emphase again that codec packs are evil and if you installed one (it doesn't matter if it seemed to have been uninstalled correctly) you better should mention that, then the only solution is a fresh installation anyways.

Koepi

if koepi doesn't mind i have a sugestion of my own
if u want to kill all the codecs on u'r system just install the evil acemegacodecs pack 5.93 or 6+ using the agressive remover and the full install mode. then just remove the thing and manually install all codecs. i think that after uninstalling ace meg pck u won't be able to play mp3s. groovie :))
in my opinon as mr koepi said codec packs are evil... but only if u don't know how to install them. even if u know things could get screwed up.
be well
@koepi: nice work with da codec. i see it's been very appreciated. nice to see that!!!

[LigH]

Unfortunately, many people don't know how to use them - enabling everything will mess your system quite surely. Some codec packs even contain registry hacks which change the preference of some codecs or filters, and this can be very dangerous (e.g. not playing MPEG1 any more).
__

A similar approach of removing any codec is the "BigFix" tool (version 1.6, AFAIR). But it might kill Windows' default codecs as well, and I would definitely not recommend this.

[Sharktooth]

I can confirm the decoder version is the one included in xvid 1.1beta but still AR doesnt work at all.
I triple-checked the filter chain and Xvid is used to decode but after xvid there's ffdshow raw video.
If i disable FFDSHOW Raw video support then AR works (with the reported bugs).

[loni_blues]

Unfortunately xvid.ax version seems to be OK: 10/13/04 64kb.
What's more: the xvid decoder seems to be working: flip video and brightness work perfectly. But still no good PAR.
Koepi: Should I follow your suggestion in this case, as well? Or does the problem seem to be something else?
Sharktooth: GSpot shows only Xvid decoder and VFW:Xvid codec are being used. Ffdshow raw video filter is disabled in codecs section in ffdshow.
How did you triple-check?

Many thanks to you guys for all your help. I really want to get this solved.
Regards.

[Koepi]

That's really strange - it works soooo good for me.

Can you explain a bit closer what is going wrong exactly? _How_ is the AR wrong? Doesn't it resize at all? (If yes, did you uncheck packed bitstream?) All that kind of information is helpful.

Regards
Koepi

[SeeMoreDigital]

Please use this PAL 720x576 - 16.9 Widescreen Anamorphic - Test File (http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/PAL_720x576_16.9_Widescreen_Anamorphic_Test_File.zip).

It works perfectly in all the players I've tried - using the current XviD-1.1.-127-13102004 XviD.ax and Minolta's test XviD.ax


Cheers

[sysKin]

I also remember ythe whole thing not working fo me. Later, it miraculesly started to work.

I don't expect this function to work for everyone and always, unfortunately :(

Radek

[Sharktooth]

Originally posted by loni_blues
Sharktooth: GSpot shows only Xvid decoder and VFW:Xvid codec are being used. Ffdshow raw video filter is disabled in codecs section in ffdshow.
How did you triple-check?
I checked with GSpot, Graphedit and MPC.

@SMD: Your sample is a 16:9 anamorphic like my test encode. So it works (disabling FFDSHOW Raw video support).

[chilledoutuk]

ok i ran a few test encodes and it seems that when packed bitstream is used the aspect is resized but if it isnt used the video aspects is not resized.

I assume that semoredigitals test encode is also packed bitstream

[SeeMoreDigital]

Originally posted by chilledoutuk
I assume that semoredigitals test encode is also packed bitstream Nope... it does not!

I tend to generate everything in "simple Profile" because my Xcard does not like any of XviD's B-VOP implementations!

As far as we know, only B-VOP encodes "without" packed bit-stream b0rk, when used with any of the available versions of the "anamorphic" XviD.ax file!


Cheers

[ChronoCross]

Interesting enough I tried loading several encoded files using the new 1.1 into mpeg4modifier and it came out correct, xvid, all the stats were right, wtc. but when I loaded it into gspot it came up as divx. not sure what's going on there. the fourcc is set correctly. not sure if this was xvid or gspots problem. oh well just thought I'd give that input.

Additionally the aspect ratio in my experience works perfectly no matter the container. I have the latest FDDshow (just came out like 2 weeks ago) and that's about it in terms of codecs(the latest FDDshow pretty much plays all audio and video. It opens perfectly in MPC, BSplayer, WMP10.

Is it possible to make a tool that can detect all dshow codecs installed on your system?

[SeeMoreDigital]

As far as I'm aware ChronoCross, MPEG4 Modifier (http://www.moitah.net/) is up to version 1.2.0.

With regard to detecting your "direct-show codecs, you could try Gspot Beta 2.5x, GraphEdit, Radlight's Filter Manager (v1.4) etc...


Cheers

[loni_blues]

Woooow! Listen to this:

I have tested SeeMoreDigital's clip and it works with MPC, BUT... Occasionally! ... Sometimes MPC begins displaying the pixel AR correctly but most of the time it requires that the clip be PAUSED and then, and only then, the right PAR is displayed. Weird! Any ideas about this behaviour?
One more thing, MPC only works (in these conditions) if packed bitstream is on (in my own clips).
Regards.

[SeeMoreDigital]

Sometimes MPC can't lock on to the AR properly. This can usually be overcome by "Maximizing" and "Restoring" the size of the player window.

The latest 6.4.8.3 version of the player seems to cope a little better!


Cheers

[stegre]

No, I've seen this before, I don't think it's MPC or even renderer related. I'd love to know more about why it happens, but here, take a look: I just made these GraphEdit screenshots using XviD decoder in question. The only extra "parts" required were a file reader, the AVI splitter, and a null renderer:

http://gspot.headbands.com/notes/misc/xvid_aspect.html

[SeeMoreDigital]

Hi stegre,

So when it comes to playing anamorphic encodes in MPC with XviD's DSdec filter, where do you think the problem lies?

The filter seems to function fine in WMP9/10....


Cheers

[kurt]

I have no problems to decode (XviD-Decoder) SMD's video in the right PAR with zoomplayer by using vmr9 ... with mpc it doesn't work ...

[stegre]

Originally posted by SeeMoreDigital
Hi stegre,
So when it comes to playing anamorphic encodes in MPC with XviD's DSdec filter, where do you think the problem lies?

I've reproduced the problem and seen it come and go depending on any number of things - minimizing, which player is used, whether packed bitstream is used, etc. - it's totally flaky and sensitive the the specifics of the situation. So to find the "cause" you want to get rid of all the extraneous variables. I've succeeded in seeing both the correct and incorrect aspect ratio displayed - on the same input file - on GraphEdit generic playback window using only a file reader, avi splitter and renderer, and furthermore I still "see" the problem if a null renderer is used.

It doesn't seem likely the bug is in the file reader or AVI splitter, or in GraphEdit itself, so that leaves the decoder. As an aside, I've looked at the carefully at the encodes that can exhibit this problem and the AR bits & values seem totally fine.

[SeeMoreDigital]

Has anybody here checked how well the old Windows Media Player 6.4.09.1125 (mplayer2.exe) or Media Player 5.1 (mplay32.exe) cope with XviD.ax?


Cheers