XviD-1.1.-127-13102004...

[Koepi]

Hello mates,

since I had a few testers who did really hard work on testing the build I decided to put it online now for public download. Find it over at my XviD page at www.koepi.org !

I want to thank especially Sharktooth for his graphs and PSNR tests, as well as yaz and omni.

Enjoy (and don't forget it's unstable, for testing features...)!

Regards
Koepi

[Sharktooth]

B-VHQ increases quality of b-frames in almost every case (and slowes down the encode job).
VBV buffer "should" work (at least i tried with only 1 standalone...) and image quality impact is imperceptible.
Loose Curve Scaling is similar to Xvid 1.02 curve scaling, while Strict Curve Scaling (disable loose...) has a better overall PSNR and has less "spikes" (higher min PSNR, lower max PSNR).
My personal (that means i could be wrong!) suggestion is to use Srict CS with sources with "constant" motion and Loose CS with sources with mixed motion scenes.
Decoder AR is b0rked.

@koepi: few more tests are coming. However the bitstream AR should be working (mpeg4modifier reads it correctly).

[Koepi]

Sharktooth:

I mean the dshow decoder. Does it display with "corrected" AR if there's a AR set in the bitstream? :)

Regards
Koepi

[Sharktooth]

Ehrr... ok... my fault... however the encoder works... :)

New Excel sheet with graph and Min/Avg/Max PSNR values (you can find them in the "Data" sheet below the PSNR values): http://ebola.gamersrevolt.it/koepi/xvid.xls

[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 :)

Regards
Koepi

[pogo stick]

Thank you, guys, for your hard work and testing.
I didn't try encoder yet.
I tried decoder. It's very nice to have brightness and deringing back. :)
But there is something wrong with auto-resizing. It's not working for mp4 files with B-frames. It's OK for avi, but not for mp4. Deinterlacer is not working for both of them. :(
I played XviD 1.0.x encodes in MPC and BSPlayer using 3ivx splitter.

[Koepi]

Deinterlacer only gets used if you a) checked the option and b) have the interlaced flag set in the bitstream(!).

I wonder why the mp4 AR isn't working, I guess it's something odd with the 3ivx splitter - it works fine with avi, ogm and mkv (thus really from the bitstream, not the conatiner AR).

Maybe you can switch something in the 3ivx splitter to disable it's AR features and thus let xvid take over (or: use the "auto(external first)" option in xvid dshow decoder to use the AR set by the splitter)?

EDIT: I have a 243kb sample which is made with bframes + 4:3-ar (352x576 resolution->768x576 corrected). Works like charme?!

Regards
Koepi

[bond]

afaik the 3ivx splitter passes the ar info by simply passing the vol to the decoder, which than leads to the resizing (i hope i remembered it right)
in .mp4 the vol is seperately stored from the raw bitstream (thats how the mpeg-4 spec wants it to be handled), so no vol attached to every i-frame aso, like its the case with .ogm, .avi and not native mpeg-4 (as all tools place mpeg-4 in mkv today) in .mkv...

btw koepi when i try to reach your page (koepi.org) i always get a "wrong page" message which than redirects me to koepi.org again, with the error message again aso...

[Koepi]

bond:

that's bad, then your provider (or router) doesn't properly refresh the DNS entries - it's been on the new servers for over 2 weeks now (I think already for close to 4 weeks).

You might want to call your ISPs customer service and ask them if they could refresh their DNS entries (at least for koepi.org). It should point to 198.87.84.234 (it's a vhost there at www.vogon.hr _ Daniel was so nice to host the site :) ).

On the issue with the non-working auto-AR with mp4 files, xvid doesn't check for a vol attahced before the bitstream anymore, we rely on the bitstream itself now. So doesn't the 3ivx splitter pass the vol in the bitstream itself? It should be perfectly valid to have the vol there in userdata?

Regards
KOepi

[pogo stick]

Originally posted by Koepi
Deinterlacer only gets used if you a) checked the option and b) have the interlaced flag set in the bitstream(!).
Yes, I understand, but it's not working. I even tried changing field order with MPEG4Modifier.
Originally posted by Koepi
I wonder why the mp4 AR isn't working, I guess it's something odd with the 3ivx splitter - it works fine with avi, ogm and mkv (thus really from the bitstream, not the conatiner AR).
Maybe you can switch something in the 3ivx splitter to disable it's AR features and thus let xvid take over (or: use the "auto(external first)" option in xvid dshow decoder to use the AR set by the splitter)?
Well, maybe it's because of 3ivx splitter. I don't know. There are no AR settings in splitter. It works for FFDShow.
I also tried "auto(external first)". All the same.
And I forgot to mention that auto-AR is not working for avi files without packed bitstream too. It's the same as with Minolta's hack.

[bond]

Originally posted by Koepi
So doesn't the 3ivx splitter pass the vol in the bitstream itself? It should be perfectly valid to have the vol there in userdata?i cant really answer this, i only know that in .mp4 the video data and the vol are seperately stored
i will point shitowax to this thread

[SeeMoreDigital]

Hi Koepi,

The new DSdec filter does not seem to be able correctly auto AR B-VOP encodes without packed bitstream :(


Cheers

[RadicalEd]

What's the current status of VBV? The last news on that was awhile ago and I was under the impression that work on it had stalled. Also, any information on the new rate control options? I recall some alternative rate control work done a few months back by an irregular (can't remember the name) -- is this the new strict cs?

[Sharktooth]

VBV seems to work. It's a checkbox in the 2nd pass options.
Rate control options (curve scaling) is also in the 2nd pass tab, you can choose a Loose or a Strict curve scaling.
Strict curve scaling tends to "average" the encoding quality (new default) while loose curve scaling is similar to the old (xvid 1.0x) curve scaling behaviour.

[minolta]

same here as pogo with deinterlace. checkmarked the option, but still no difference. perhaps changes in xvidcore.dll are not updated yet? also, can "deinterlace = on" be the default setting since most users don't configure the decoder?
thanks,
-minolta

[Leak]

Originally posted by Sharktooth
VBV seems to work. It's a checkbox in the 2nd pass options.

I've just noticed that while VBV seems to work the Level tab still says "XviD's ratecontrol will not respect these values" - removing that before a final release might be a good idea to prevent unneccessary confusion... :)

np: Delarosa & Asora - Saigon (Lily of the Valley)

[LoKi128]

As far as I understand, VBV is only needed (useful) when targeting standalones or otherwise bitrate limited machines, such as slow computers. For newer computers where bitrate dosnt matter, it should not be used.

Am I correct, or is VBV good for most encodes?

[RadicalEd]

Quality may be better without VBV because it can fluctuate more in a VBR environment, but then the stream isn't necessarily guaranteed to be decoded by a strictly compatible MPEG-4 profile@levelx decoder.

[BoNz1]

Hi, I have a request. I realize this is that 1.1 is beta so there isn't everything there that might be there if it was a release. But, I think it might be cool if in future versions we could have the DivX profiles selectable in the Profile at level. This would be cool. Also, the levels tab could be moved to the 2pass tab and things like the max frame size, buffer size could be editable. Just a suggestion. Thanks.

[LigH]

"VHQ for B frames too (mode decision only)" - that means: No matter if I chose VHQ 1..4 for P frames, B frames will use VHQ=1 (and 0 = off for both)?

Or in C style: "if (VHQp >= 1) VHQb = 1" (not "if (VHQp == 1) VHQb = 1")?

[sysKin]

Originally posted by LigH
"VHQ for B frames too (mode decision only)" - that means: No matter if I chose VHQ 1..4 for P frames, B frames will use VHQ=1 (and 0 = off for both)? No, setting for p-frames and setting for b-frames are independent. The wording is confusing, I know.

[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?

[yaz]

here are some evidence that all options work (i mean they do sg :-)
source : 1000 frames, mode=2pass, target bitrate = 3000, compression ~ 85%

set
I : no B-VOP
II : 1 B-VOP
III : 1 B-VOP + VHQ/B

cc
0 : 'inner' curve scaling
1 : 'loose'
2 : "strict vbv'
3 : 2 + 3 (! yes, in my version it's allowed)

results : max framesize / average br

I
0 -> 92340 / 3137
1 -> 92340 / 3209
2 -> 133477 / 2734
3 -> 133477 / 2769

II
0 -> 133477 / 3122
1 -> 133477 / 3138
2 -> 162148 / 2810
3 -> 133477 / 2748

III
0 -> 133477 / 3123
1 -> 133477 / 3139
2 -> 162148 / 2813
3 -> 133477 / 2745

as it's seen, the bitrate variation is fairly high (i haven't got time to try a bigger clip, but it'd worth)
notes :
1) the difference betw II & III is(!) significant as the psnr is always higher for III respectively
2) 'loose' scaling is pushing the quantizers downward. i mean, it uses lower quants than 'inner'. I-VOPs gets q=1 preferentially while 'strict' doesn't seem to like it (much less q=1)
3) the increase in max.framesize is always on an I-VOP but at different places for 'loose' and 'strict' (???)
4) the speed drop is about 20-25% when switching vhq/b on. (it'd be higher when more than 1 B-VOP used)
5) 'strict' changes the q distribution (not seen here) very much. i found even 2->8 shifts in q.

i found it a bit confusing (but maybe i was just too tired:-) a short explanation of the new opts would be quite beneficial. (maybe a devel or ...)

as regards dsf. yes, if b-frames are used wout packed bitstream then no aAR. that's pity.

the bests
y

[SeeMoreDigital]

Originally posted by yaz
...as regards dsf. yes, if b-frames are used wout packed bitstream then no aAR. that's pity. Agreed.

Just to make things 100% clear Koepi. The auto AR signalling still works in the bitstream because other software players such as Nero's ShowTime and VideoLAN can detect it. It's just the XviD DSdec filter that can't make it work.... yet!


Cheers

[Koepi]

The thing about the packed vs unpacked bitstream / bframe -auto-ar issue is a small one, I think we had a bugfix for that already but somehow I messed up (again).

I'll try to correct things with sysKin if he's finished with his tests and exams and wnats to spend some time doing bugfixing ;)

Also note that GomGom strongly votes against strict scaling, in his tests it always gives lower PSNR. (Which can be right, since the fluctuation of quality gets minimized we don't have near-black quant2 frames in an average quant5-encode anymore which raises PSNR quite a bit. It's all a matter of taste, and I think it should be possible to check the difference with a wider user base.). And remember, GomGom's mostly always right :) [I hope not in this case though as I like strict scaling very much ;) ]

Regards
Koepi

[Sharktooth]

Just leave the option there on the 2nd pass tab.
Let the users decide which scaling is better for their encodes.
That perfectly fits in the "xvid way"...

EDIT: Fixed typos

[CruNcher]

@Koepi

Foxers RC was allways under GomGoms in my tests that i did and i came to the same conclusion then GomGom especialy with harder 2pass settings instead of the standard 5/5/5 but you know that allready ;)

[Sharktooth]

Is it a big problem to have more than one standard curve scaling?

[Koepi]

No, it's about choice ;)

(May I repeat that PSNR isn't everything that counts? I can't stress that TOO_SMALL_LIMIT example which _always_ gave higher PSNR with visible degraded quality...)

I had a few words with GomGom and he just happens to not like strict scaling, so it's a not too serious issue (it's not that I totally crippled xvid now to say it with other words). Test for yourself and see what you like more. Though recommended because proven stable is of course the old loose scaling.

Regards
Koepi

[olnima]

First of all and I have to say it again and again:

THANKS TO ALL OF YOU WHO CODED, COMPILED, TESTED, RELEASED AND DID ANY OTHER KIND OF WORK ON THIS FANTASTIC PEACE OF SOFTWARE !!!!!!

One question about the 1.1-tree: Are there any improvements for
the "single-pass-directly-into-xvid-capture-users" like me?
(maybe with that kind of use I'm the only one who use xvid in a totally legal way :)

My settings are default except:
BVOPs off or 1 (because of playing back on DVD-player)
adaptive Quant is on (don't know if it makes sense, wanna save some bytes)
chroma optimizer enabled
MSP=5 ; VHQ=0 (because of my too slow CPU: AthlonXP 2000+)
Turbo-Mode is on when using B-VOPs
Min I/P/B-Quant is 2

Olnima

[Sharktooth]

Originally posted by Koepi
Test for yourself and see what you like more. Though recommended because proven stable is of course the old loose scaling.
More options, more fun... :)
However here are some results from SSIM tests on a High motion souce:
Xvid 1.02: Average SSIM= 65.57
Xvid 1.1 No B-WHQ/strict: Average SSIM= 65.41
Xvid 1.1 No B-WHQ/loose: Average SSIM= 65.63
Xvid 1.1 B-WHQ/strict: Average SSIM= 65.60
Xvid 1.1 B-WHQ/loose: Average SSIM= 65.84

As you can see the Loose Curve Scaling produce better SSIM results but the source is high motion...

PSNR:
Xvid 1.02: Average PSNR = 40,69843226 Overall PSNR = 39.8640
Xvid 1.1 No B-WHQ/strict: Average PSNR = 40,46406713 Overall PSNR = 39.9273
Xvid 1.1 No B-WHQ/loose: Average PSNR = 40,63747488 Overall PSNR = 39.8871
Xvid 1.1 B-WHQ/strict: Average PSNR = 40,51540425 Overall PSNR = 39.9988
Xvid 1.1 B-WHQ/loose: Average PSNR = 40,68424018 Overall PSNR = 39.9650

Also, Strict CS produces a LOWER AVERAGE PSNR but a HIGHER OVERALL PSNR indicating a more constant quality thru the whole encode.
I will try a low motion source to see if things will change.

[Koepi]

Thank you for verifying my point, as I wrote earlier, I think the quality is more constant with strict CC.

(Which then again is a matter of taste - quality fluctuation can look better. [That's why we added quantiser fluctuation to Nandub, it was giving back some "life" to the scenes - dunno if this really helps with XviD though]).

Keep the results coming! :)

Regards
Koepi

[Sagittaire]

18/10/04 ... ;)

Originally posted by Sagittaire
To make peace with Koepi:

I prefer a little worse Average PSNR (-0.1 dB or -0.2dB) if Min PSNR is very higher (+ 1dB). Average PSNR isn't really good tool for testing Rate Control quality ... ;)

Sharktooth's test confirm that: Average PSNR must be very better with CBR than VBR. For example sample with very long/very "low motion" part and very short/very "high motion" part done very better Average PSNR for CBR.

Overall PSNR or Frame PSNR graph are very better tools for testing RC quality. For example a Frame PSNR test had been able to show a weakness with the RC in H264 beta test from Ateme.

[Sharktooth]

More info:
I tried to playback my 1.1 encodes with the latest Nero Showtime.
Both Packed-bitstream and unpacked-bitstream were played back with the correct AR.

[SeeMoreDigital]

With regard to the DSdec filter. Is there any real need to have all those "aspect ratio" options.

Surly it would be less confusing if it operated fully automatically!


Cheers

[pogo stick]

How should VHQ for B-frames influence on file size? I made a few tests with Quantizer=2 and size of B-frames is always a little bigger with "VHQ for B-frames". But just increasing VHQ mode (without "VHQ for B-frames") making total size smaller. Is it right behavior? Or am I missing the whole point and there shouldn't be connections between file size and VHQ mode?

[Sharktooth]

@koepi: Can the other VHQ modes be implemented for b-frames? Have xvid devs done some tests yet and choosen VHQ-1 coz an higher VHQ is not woth the time spent for the encoding?

[SeeMoreDigital]

Sadly, I still can't make XviD 1B-VOP encodes work with my Xcard.

As I can't use B-VOP, can anybody confirm whether the SP encoding feature have been improved?


Cheers

[Manao]

pogo stick : VHQ is mainly about finding the best compromise between size and quality. Sometime, it's possible for VHQ to improve both quality and filesize, but most of the time, it has to choose either one or the other. To make a fair comparison, you then either have to compare two files which have the same filesize ( and in that case, the VHQ one will have a better quality ), or two files that have the same quality ( the VHQ one will be the smaller ).

Anyway, you'll find clips where VHQ for b-frames will reduce the filesize, and other where filesize will increase.

Sharktooth : yes it can be done. But are you ready to halve ( roughly ) the encoding speed of the codec ?

[Sharktooth]

Yes, if it's worth the time... obviously a 0.01db gain in PSNR will be useless. But if there's a more consistent advantage, well, why not do it?:D

[Manao]

I strongly doubt overall psnr will raise by more than 0.1 dB. But who knows... Anyway, since VHQ1 is implemented, VHQ > 1 can easily be added ( it's almost 'just' a matter of changing the CheckCandidate function by another one, already written ).

[Sharktooth]

a 0.1db is 10 times 0.01... :)
However b-frames are roughly 30-40% of a movie frames.
Rising b-frames quality/decreasing b-frames size keeping the same quality, will give a sensible boost to the overall movie quality.

[loni_blues]

Oh, where´s the file?
I feel like an idiot but at www.koepi.org I can find no updates since September 7. No single reference to the 1.1 build.
Am I nuts?
Regards,
loni_blues

[Sharktooth]

Go to xvid binaries section and find the latest UNSTABLE binary.

[loni_blues]

Thanks Sharktooth.
But no, nothing's there. I've all the same managed to download it by using www.koepi.org/XviD-1.1.-127-13102004.exe . I think it may have to do with the problem bond had: that's bad, then your provider (or router) doesn't properly refresh the DNS entries - it's been on the new servers for over 2 weeks now (I think already for close to 4 weeks). Anybody else with a similar problem?
Regards,

[malkion]

Thanks for the release Koepi. This version could really mess up my encodes, I luv that. :D

Anyways, I haven't experienced dropped frames in quite some time using xvid until I tried the 1.1 release.

Has anyone else had this happen?

[helix]

All the encodes i've done so far with 1.1 are superb, with no dropped frames at all. I did some anime and it seems to look slightly better with B-VHQ enabled. I haven't tried any encodes with the loose curve options but I want to see if that has any affect on quality.

[Koepi]

loni:

Hm, did you use the page out of your proxy or cache or something?

When heading to www.koepi.org or www.koepi.org/xvid.shtml , hold down the shift key and hit reload (and then release the shift key).
This will tell your browser/proxy to fetch the site fresh from the web.

I think this might solve your problem - that is a general problem with most of the internet users today, they don't know about proxies, caches and how they affect the browsing experience (no big problem usually, but as you see sometimes it's annoying [because of "false accusitions" ;) ]).
So the problem is totally different from bond's problem as you're just "seeing" an outdated webpage but access the correct server (you got the binary), bond has much more trouble, www.koepi.org points to the wrong server on the net for him, thus he can't even get the build.

I hope this helps

Regards
Koepi

[Boulder]

Originally posted by Koepi

I think this might solve your problem - that is a general problem with most of the internet users today, they don't know about proxies, caches and how they affect the browsing experience

Not to mention the fact that IE6 probably defaults to 'Automatically' regarding the situation when it should check for a new version of the cached page. Sometimes it just doesn't check for a new version for a very long time which then brings up the problem. That's why it should always be set at least to 'Every time you start Internet Explorer'.

To keep from going totally OT, thanks for the new binary! VHQ for B-frames didn't slow the encoding process as much as I figured it would:)

[yaz]

i can't get it. can anyone explain me how's this implementation work ? as i see from my table ticking different combinations of cc i got different results but ...
- what cc do i use if i don't tick any of the new options ?
- what cc do i use if i tick both 'strict' and 'loose' ? is it the case of 'loosely strict' or what ? :-)
- what conditions do these ccs try to maintain ? i went on testing and i saw that the new ccs always tampered with the bitrate curve even if a went down to 600kbps. as a simpleton i thought it's in the range where no real vbv maintenance's needed. such small frames wouldn't harm anything. or would they ?

sure, i misunderstand sg ... but what ?

thx
y

[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

[Taurus]

Originally posted by 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?

Mediaplayer 6.4.09.1125 can't open the file. Error 80040216
Mediaplayer Classic 6.4.8.2 opens the file in 4:3 mode,
after one mouseclick in the screen (left or right)16.9 Widescreen Anamorphic resolution is shown. Very strange but funny:D .
Mediaplayer 9 opens the file in 16.9 Widescreen Anamorphic resolution,
but refuses to open via right click in explorer.
BS Player messed up too. In window mode 16.9, full screen mode 4:3.

Edit: Mediaplayer 6.4.09.1125 opens the file if in options menu avi support is enabled.

[SeeMoreDigital]

Well just to make things more consistant...

Here is a link to my PAL 4:3 720x576 - Test Card File (http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/PAL_4.3_720x576_-_Test_Card.zip).

So together with the already up-linked PAL 16:9 - Test Card File (http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/PAL_16.9_720x576_-_Test_Card.zip). That's good old PAL sorted.


And for all you NTSC guys... here are your encodes: -

NTSC 4:3 720x480 - Test Card File (http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/NTSC_4.3_720x480_-_Test_Card.zip).

NTSC 16:9 720x480 - Test Card File (http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/NTSC_16.9_720x480_-_Test_Card.zip).



Cheers

EDIT: PAL "Test Cards" updated, NTSC "Test Cards" added.

[Taurus]

Originally posted by SeeMoreDigital
Well just to make things more consistant...

Your testfile is shown in correct 4:3 aspect ratio in all mentioned
players (see above)

16:9 testfile is displayed only @4:3 in mediaplayer classic when overlay mixer is used.
In VMR9+7, while opening the file, most of the time it is drawn at 4:3 first. Maximizing the window, clicking into it, or switching to fullscreen mode restores the 16:9 setting.

[jaapaa]

This is not related to the discussion above, but this is related to XviD-1.1.-127-13102004 so I post it here..

After installing XviD-1.1.-127-13102004, I've got several occasions where the encoding job and virtualdubmod have just plain died and disappeared in the middle of the encode. No error message, no message box, zilch, nada, nothing..
Never had it with XViD 1.02. Of course I'd provide you with more info, if I'd know where to get it and or what you want to know...

XP, 1 gig, no SP2, vdubmod 1.5.10.1, amd 3200+

[Koepi]

That's usually an issue with bad memory. Or too hot CPU/memory.

You should open your computer and clean the fans, maybe there is too much dust collected and the cooling doesn't suffice anymore.

XviD stresses your CPU and memory more than usual programs like burn-in-tests and memory checkers (at least the ICL compiled builds).

Regards
Koepi

[loni_blues]

Hi,
Thanks kurt: Zoomplayer with vmr9 displays the PAR correctly!

Another issue: From what I've read I believe vbv compliancy is only useful for compatibility in standalones. Is this right?

Regards

[Sharro]

Originally posted by loni_blues
... From what I've read I believe vbv compliancy is only useful for compatibility in standalones. Is this right?

Regards

From what I've read YES you're right :)

The sudden bitrate spikes make many standalones choke....

From my experience with standalones (I encode always above 1.200Kbps averages) the Mediatek 1389EE copes much better with these than 1389DE did and I do hope this is something that will not be an issue in the future if we want to dream of HDTV resolutions Xvid playback on standalones....

All the best,

Sharro

[Sharktooth]

@Koepi: any news on the bughunting side?

[Koepi]

Nope. I've not too much time and can't imagine where this comes from. I'll ask sysKin if he remembers.

Regards
Koepi

[Sharktooth]

I meant... in the decoder.

[Koepi]

I know.

[loni_blues]

Oh, oh, this thing about resizing never ends. It is working fine in MPC and Zoomplayer (with VMR9) but it stops working if subtitles are auto-loaded with DirectVobSub. The right PAR is displayed as long as no vobsub subtitles are displayed.
Is anybody having the same problem? What can be happening with PAR displaying/detection?
Thanks in advance.

[Sharktooth]

It seems AR is working if Xvid is the last filter before the renderer.

[loni_blues]

Thanks!
Sorry for my ignorance, but is there any way to put the decoder after DirectVobSub, so that it's last before the renderer?

[LigH]

:confused: The decoder filter after an overlay filter?

On which surface shall an overlay filter (like DVobSub) render its content, before a decoder creates the video surface?

[Ark]

I've never seen this feature working.

I tried it on 2 PC's at work and on my home PC without luck...

I can change Pixel AR or Picture AR but it does absolutely (apparently) nothing. I tried MPC and WMP with all renderer, tried to maximize/minimize the player or pause/click on it (someone has reported that such things "activate" the correct AR), change the decoder AR (16:9, 2.35:1) but nothing happens.

My home machine was formatted not too long ago, I simply installed Windows XP, MB/VGA drivers, DirectX 9.0b, Xvid, MPC. That should be enough to play correctly!

Maybe I forgot something...

(I've an Athlon XP-M 3600+, 512 mb RAM, MB Abit NF7-S rev 2)

[Koepi]

Dumb question:

did you change the PAR/DAR in encoder and switched over to playback or did you encode with that setting and the resulting bitstream doesn't change the AR?

Regards
Koepi

[Sharktooth]

Originally posted by Ark
I've never seen this feature working.

I tried it on 2 PC's at work and on my home PC without luck...

I can change Pixel AR or Picture AR but it does absolutely (apparently) nothing. I tried MPC and WMP with all renderer, tried to maximize/minimize the player or pause/click on it (someone has reported that such things "activate" the correct AR), change the decoder AR (16:9, 2.35:1) but nothing happens.

My home machine was formatted not too long ago, I simply installed Windows XP, MB/VGA drivers, DirectX 9.0b, Xvid, MPC. That should be enough to play correctly!

Maybe I forgot something...

(I've an Athlon XP-M 3600+, 512 mb RAM, MB Abit NF7-S rev 2)
Make sure to have VMR9 enabled (AR seems to work only with VMR, at least for me...), use DirectX 9.0c (maybe it helps) and make sure you have no filters between Xvid decoder and Video renderer (use graphedit to check).

[Ark]

Originally posted by Koepi
Dumb question:

did you change the PAR/DAR in encoder and switched over to playback or did you encode with that setting and the resulting bitstream doesn't change the AR?

Regards
Koepi

I did a few short encodes with all possible PAR/DAR combinations and played them all with all decoder DAR settings. From the results it seems that the AR flag is ignored by player/decoder in every case i tried. (I don't think XviD doesn't write it though)

@Sharktooth

Yes, WMR9 is enabled (i tried all renderer from overlay to WMR9 renderless). I've still to check with Graphedit, thanks for the suggestion :)

[Ark]

I've a Matrox video converter filter (coming from a RTX100) after XviD, causing this issue. (see attachment)

Erasing this filter cause the video to play correctly (finally!!) if I play the graph from Graphedit, but it's only temporary.

I've to find a way to erase this filter for normal playback on Dshow players...

(Bella Shark, ottimo consiglio!! :))

(Thank Shark, good suggestion!! :))

EDIT: hey i've attached a .gif file, but it doesn't show... :confused:

[Sharktooth]

@Ark: the attachment should be approved by a mod then it will show up :)
comunque ... grazie :)

[Ark]

Thanks, i didn't know that

[SeeMoreDigital]

...or upload your images via ImageShack (http://www.imageshack.us/). It's free to use!


Cheers

[Leak]

Originally posted by Ark
I've a Matrox video converter filter (coming from a RTX100) after XviD, causing this issue. (see attachment)

Erasing this filter cause the video to play correctly (finally!!) if I play the graph from Graphedit, but it's only temporary.

Add this filter to MPC's block list: "Options/Filters/Overrides/Add Filter", browse for it and set it to "Block" - if you need the file name, the "Insert Filters" dialog in graphedit will show it if you expand that filter's node, then just make MPC block that file.

That should probably fix it; if you don't need the filter at all you could also just unregister the filter with regsvr32 or G-Spot...

np: März - The Pop Song (Wir Sind Hier)

[Bill_st]

I've been doing some testing with this build and I have a question about vbv support. I'm trying to make my encodes work with a cheap standalone that doesn't allow bitrate spikes above 3 Mbit before giving problems, I don't know if it is a chipset limitation (it is a ESS Vibrato II) or loader speed limit, but going above 3 Mbit/s leads to audio skipping and stutters.

With Divx, unchecking the Divx profiles and setting the max bitrate at 3 Mbit was enough to make it work (it changed the CL to -vbv 3000000,3145728,2359296) , and now with this Xvid build with vbv support and using the AS@L4 profile it still skips audio during complex scenes, though less than before. I don't know how to view avi bitrates, but checking with Virtualdub I measured 2.32 MB of video during a complex scene that was 123 frames long, so I guess the average bitrate in that interval was around 3.77 Mbit/s (it is a PAL video, 25 fps). Wouldn't this be impossible with vbv on and AS@L4 profile? One thing is true though, it was more than twice as much with the 1.0.2 build, so it is doing its job, even if I don't know why it isn't respecting the 3 Mbit limit. Perhaps this number (max bitrate) could be selectable in newer builds?

[celtic_druid]

Think VBV is probably just hard coded to the DivX Home Theatre settings. There were some older custom builds around with selectable VBV if I recall correctly.

[Bill_st]

Hmm, that would make a lot of sense, since I measured a bitrate very close to the max bitrate allowed by the Divx Home Theater Profile. If that is the case, I would please ask for this number to be selectable in future releases, thx :D

[Ark]

Originally posted by Leak
Add this filter to MPC's block list: "Options/Filters/Overrides/Add Filter", browse for it and set it to "Block" - if you need the file name, the "Insert Filters" dialog in graphedit will show it if you expand that filter's node, then just make MPC block that file.

That should probably fix it; if you don't need the filter at all you could also just unregister the filter with regsvr32 or G-Spot...

np: März - The Pop Song (Wir Sind Hier)

Strange, today i checked the yesterday videoclip in Graphedit, and the Matrox filter wasn't there! But the autoAR yet doesn't work...

There is a "Subtitle Mixer" filter between XviD decoder and video renderer, and if i erase it AR works.

So i tried your method and set to Block this filter in MPC.. but nothing changes, it still doesn't work, and i don't know how to do now, i can see correctly played movies only in Graphedit...

[Sharktooth]

The xvid decoder needs a fix coz most filters does not support AR signaling.
A possible workaround is to "pass" the AR corrected resolution instead of the full resolution or building a special resize DS filter that will be always placed before the video renderer.

[pogo stick]

Originally posted by celtic_druid
Think VBV is probably just hard coded to the DivX Home Theatre settings.
Is it? Koepi, can confirm it?
I thought it supposed work with levels of ASP and SP. :confused:

[Koepi]

VBV works with hardcoded values currently, no matter what you enter as profile. I / we should adopt that of course. Don't forget this is a test build. We were wondering if VBV compliancy works as expected at all - which it seems to do. So now it's time to extend that.

Regards
Koepi

[Sharktooth]

Good news.
There will be also an option to make custom profiles (or maybe a simple override where you can manually set max bitrate...)?

[PiXuS]

I am doing a ~24h encode with 1.1. My settings are:

mode: single pass
qm: 6of9
qpel
b-vops: 2/1.50/1.00
target quant=4.00
MSP: 6
VHQ: 4
b-vhq: enabled
chroma motion

My AVS script chain is: Telecide.Decimate.Crop.Undot.ConvYUY2.PixieDust.ConvYV12.LimitedSharpen.Undot

I lend 256MB to VDM 1.5.10.1/2439.

After about 11h in the encode, the memory consumption is up to 317 604kB (or around 310MB). Something is leaking at an avg. rate of 5MB per hour.

Could it be due to XviD 1.1 alpha? I'll try to find more evidence... I'll let the script run during the night.

thanks.

Edit:Well, the encoding is finished and the memory usage oscillated at around 310MB during the last minutes. I don't know why VDM didn't respect the 256MB limit (it used to). Anyway.. sorry for hijacking this thread (?).

[Didée]

Hmh, I don't think XviD is to blame. I suspect any plugin, or Avisynth itself, or even hole-y Windows (see PM with lots of off-topic Avisynth stuff).

[Jawor]

Originally posted by celtic_druid
There were some older custom builds around with selectable VBV if I recall correctly.
They are here (http://jawormat.republika.pl). Check out the builds from 25.06.2004.

[trbarry]

I guess I'm still a bit confused on VBV. The options are specified in the 2-pass section but it seems it might be very useful to help a nice constant bit rate in 1-pass CBR, say especially for things like streaming.

Is VBV intended to work in 1-pass CBR?

- Tom

[stegre]

I think this fixes all of the decoder's flaky AR behaviour:
HRESULT CXvidDecoder::SetMediaType(PIN_DIRECTION direction, const CMediaType *pmt)
{
if (*pmt->FormatType() == FORMAT_VideoInfo)
{
VIDEOINFOHEADER * vih = (VIDEOINFOHEADER *) pmt->Format();
BITMAPINFOHEADER * hdr = &vih->bmiHeader;
ar_x = vih->bmiHeader.biYPelsPerMeter * abs(hdr->biWidth);
ar_y = vih->bmiHeader.biXPelsPerMeter * abs(hdr->biHeight);
}
else if (*pmt->FormatType() == FORMAT_VideoInfo2)
{
VIDEOINFOHEADER2 * vih2 = (VIDEOINFOHEADER2 *) pmt->Format();
ar_x = vih2->dwPictAspectRatioX;
ar_y = vih2->dwPictAspectRatioY;
}
if (direction == PINDIR_OUTPUT)
{
return ChangeColorspace(*pmt->Subtype(), *pmt->FormatType(), pmt->Format());
}
return S_OK;
}

[celtic_druid]

Tried it and it still doesn't work without packed bitstream. Same files worked fine via ffdshow.

Ok here's something interesting, it isn't so much packed not packed, but the DivX999b000p flag. Add that and it works fine, however then you get the whole jerky playback thing.

[sysKin]

Originally posted by stegre
I think this fixes all of the decoder's flaky AR behaviour:
HRESULT CXvidDecoder::SetMediaType(PIN_DIRECTION direction, const CMediaType *pmt)
{
if (*pmt->FormatType() == FORMAT_VideoInfo)
{
VIDEOINFOHEADER * vih = (VIDEOINFOHEADER *) pmt->Format();
BITMAPINFOHEADER * hdr = &vih->bmiHeader;
ar_x = vih->bmiHeader.biYPelsPerMeter * abs(hdr->biWidth);
ar_y = vih->bmiHeader.biXPelsPerMeter * abs(hdr->biHeight);
}
else if (*pmt->FormatType() == FORMAT_VideoInfo2)
{
VIDEOINFOHEADER2 * vih2 = (VIDEOINFOHEADER2 *) pmt->Format();
ar_x = vih2->dwPictAspectRatioX;
ar_y = vih2->dwPictAspectRatioY;
}
if (direction == PINDIR_OUTPUT)
{
return ChangeColorspace(*pmt->Subtype(), *pmt->FormatType(), pmt->Format());
}
return S_OK;
}

Hmmmmm where did you get this code? It looks just like old v1.0.2 code that reads AR info from avi container (removed from 1.1) and from matroska splitter (still there). It doesn't have new AR logic at all, so it can't fix this logic ;)

Radek

[stegre]

Oh yeah, that is old source, I'll have to see if I can confirm whether it's the same problem - I got identical flaky behaviour with both, though I meant to debug the new one. What I did was create a "nullnull" filter with logging and determined that it was sending a mixture of the two AR's to the renderer as the negotiated the pin connection. I pasted a copy of a code snippet from CheckMediaType() into SetMediaType() which fixed the variable at that point and stabilized it. So it may be the same problem - in other words, it may be getting the right AR from the container or the stream or whatever, but just not getting it to the renderer properly.

[stegre]

here, this fixes the latest XviD version in my tests, including packed bitstream. I'd have to study more how those base classes work before I could "justify" it, though ;)HRESULT CXvidDecoder::SetMediaType(PIN_DIRECTION direction, const CMediaType *pmt)
{
DPRINTF("SetMediaType");

if (direction == PINDIR_OUTPUT)
{
if (*pmt->FormatType() == FORMAT_VideoInfo2)
{
BYTE* pFormat = pmt->Format();
VIDEOINFOHEADER2* pVideoInfoHeader = (VIDEOINFOHEADER2*)pFormat;
ar_x = pVideoInfoHeader->dwPictAspectRatioX;
ar_y = pVideoInfoHeader->dwPictAspectRatioY;
}
return ChangeColorspace(*pmt->Subtype(), *pmt->FormatType(), pmt->Format());
}
return S_OK;
}

[Koepi]

Using that code with my xvid-1.1-build completely disables AR correction :p

But then I decided to take a deeper look into the sources again and I fixed the forced aspect ratio stuff.

Find the new build as usual on my homepage www.koepi.org .

(there were some changes in the CVS on 30.10.2004 but I didn't notice which changes exactly. I think it was an altivec assembler code addition.

Regards
Koepi

[SeeMoreDigital]

Hi Koepi,

Has the DSdec filter been modified so it can correctly display the AR of PAR encodes with B-VOP but without packed bit-stream?

If so, I've just tried it myself and it's still not working correctly :(


Cheers

[Koepi]

I posted an entry concerning that on my homepage ;) it reads "I don't know yet if it also fixes the auto-resize-with-unpacked-bframes-issue, but forcing the aspect ratio to i.e. 4:3 or 16:9 works again."

I didn't find the problem with that yet, it seems to be in the core - the internal VOL-stats data gets overwritten before it can be read by the DSF.

Regards
Koepi

[SeeMoreDigital]

Your confirmation over here on Doom9 is most welcome all the same ;)

I just wish I knew how to help out :( But this sort of stuff is right out of my depth.


Cheers

[Koepi]

You could help me with PMing me your email address again so i can send you a testing-build ;)

EDIT: well, that doesn't help either (yet), I tried a small sample myself and the things I could do properly don't work. Sorry for the fuzz.

Regards
Koepi

[SeeMoreDigital]

Originally posted by Koepi
You could help me with PMing me your email address again so i can send you a testing-build ;) Job done!


Cheers

[Sharktooth]

Ok, i can confirm decoder AR options work (with PB).
However:
1 - brigthness is still not set to the default value after installation (you have to manually click the RESET button to do it as in the previous build).
2 - deinterlace doesnt work.

[stegre]

Originally posted by Koepi I posted an entry concerning that on my homepage ;) it reads "I don't know yet if it also fixes the auto-resize-with-unpacked-bframes-issue, but forcing the aspect ratio to i.e. 4:3 or 16:9 works again."

I didn't find the problem with that yet, it seems to be in the core - the internal VOL-stats data gets overwritten before it can be read by the DSF.
That's the problem I was looking at, but yeah, the patch doesn't work for the general case. Note, though, that the correct value is always available when the file is played - it's too late, though, as the renderer won't change AR "on the fly". See log (http://headbands.com/misc/0x1d0.htm)

[pogo stick]

Forcing AR is OK now. Auto-AR is not.
I am sure not the one who can give you good advice but auto-AR is connected with DivX999b000p flag and not with packed bitstream as Celtic Druid pointed. Because if user data have DivX999b000p auto-AR works even in mp4 file.
And have anyone looked at deinterlacing bug yet?

[BigDid]

Hello Koepi,

Originally posted by Koepi
Hello mates, ...
Find it over at my XviD page at www.koepi.org ! ...
Regards
Koepi

http://www.koepi.org/XviD-1.1.-127-13102004.exe
Is the above link down?
I can go to the xvid page, download the 1.02 exe but not the 1.1 ?

Thanks for the info and all the best for the terrific work.
Best regards.

Did

PS, second attempt to post this inquiry, seems first one may have gone to subspace ...:rolleyes:

[kurt]

hi,

this is the latest 1.1 test build from koepi: http://www.koepi.org/XviD-1.1.-127-06112004.exe

[SeeMoreDigital]

After navigate to the XviD Binaries section (http://www.koepi.org/xvid.shtml). Refresh you browser and you should now find XviD-1.1.-127-06112004.exe (631kb) (http://www.koepi.org/XviD-1.1.-127-06112004.exe). Which is the most up to date version...


Cheers

[BigDid]

Originally posted by SeeMoreDigital
After navigate to the XviD Binaries section (http://www.koepi.org/xvid.shtml). Refresh you browser and you should now find XviD-1.1.-127-06112004.exe (631kb) (http://www.koepi.org/XviD-1.1.-127-06112004.exe). Which is the most up to date version...


Cheers

Hello kurt & SeeMoreDigital

It works; 1 more victim of non-refreshing browser grmbl ... me :angry:

Thanks to the two masters ( five point palm-exploding heart technique

) and ( Sigma Xcard ) ;)

Did

[ChronoCross]

so I encoded a 25 min long anime last night and then went to see how it turned out this morning. Several things were strange

1)stats file said the first pass was 680MB. the vob is only 950MB. the latest stable build returns 320MB.

2) when the file is opened in MPC, WMP10, or winamp. it detects that the video clip is over 9 hours long. (this is fixed by wrapping it in either mkv or OGM)

3) horrible quality. by far the worse I've seen. I was able to duplicate it this afternoon.

Options Enabled
VHQ for Bframes
qpel
trellis
cartoons mode
VHQ 1
1 bframs

Edit almost forgot. Uses xvid 1 to decode.

[Aktan]

Originally posted by ChronoCross


Options Enabled
VHQ for Bframes
qpel
trellis
cartoons mode
VHQ 1
1 bframs



Qpel adds noise, while for anime u want smooth.
Cartoon mode, I read, is more suited for simpler shapes like Simpsons, while anime has more detail

What matrix did you use.

[Teegedeck]

Excuse that I disagree.

Nope, cartoon mode is good for anime.

And QPel is a matter of taste also in this case.

Use VHQ=4, and leave b-frame settings at defaults (2/1.5/1).

[iradic]

hi

with XviD-1.1.-127-13102004 when i click 'calc' button i get 'rundll32 error in kernel32 ...'
OS is WinME

bye

[Koepi]

Can you test with XviD-1.1.-127-06112004.exe?

It works flawless for me.

Regards
Koepi

[iradic]

tested - not working - same error msg

bye

[celtic_druid]

Some more builds to try: http://ebola.gamersrevolt.it/celticdruid/

[iradic]

@celtic_druid: your builds are ... ? i mean are the same as koepi's or different - source is not i believe - what about dshow decoder and installer deinstaller and other things... i can see they are smaller and dates are confusing me ... (in firefox they are all last mod 4. nov 2004, date stamped head build is older than koepis and ... )

some info if you can write

thanks bye

[celtic_druid]

Those files were kindly mirrored by Sharktooth. As such the dates shown are the dates that they were uploaded.

http://celticdruid.no-ip.com/xvid/

Dates shown there should be roughly just after they were compiled.

There haven't been any changes in the cvs since my last compile.

[iradic]

xvid.cvs.head.2004.10.25.7z - produces same error...

[Sharktooth]

Uhm... i tried koepi,celtic_druid and my compiles... and nothing went wrong.
Maybe you have some problem with your Windows ME (WinME IS EVIL!!! use win98 instead)...

[chilledoutuk]

personaly i amazed there are still people using os's based on the 9x kernel when os's using the superior nt kernel such as win 2000 and xp are so well supported.

[iradic]

i dont have time to do all that (backup - install - etc)...

encoding is working... playback also... decoder forcing 16:9 too...

i need some calculation ... if someone can do it for me :)
movie length - 02:43:37
audio size - 84860 kb
container - matroska

what video size i need for 1cd (700 mb)

thanks bye...

[kurt]

with the build_in xvid calculator i get 634257kb with your movie settings (mkv, 700MB=716800kb) ....i guess the size is correct...

[iradic]

that confirms my assumptions that gknot calculates wrong numbers...
it gives me 631873 kb

thanks again bye...

[Sharktooth]

Ok, some news from the FFDSHOW front...
Milan said he added mpeg PAR signaling support to FFDSHOW, so in the next builds the FFDSHOW raw video filter should not interfere with xvid AR anymore (at least i hope...).

[LigH]

About your battle between GKnot and XviD bitrate calculations:

GKnot usually calculated the pure video size, and additionally the multiplexing overhead if desired. Because it seems that XviD interprets the target size including some muxing overhead, I noticed that GKnot 0.32 disables overhead calculation when selecting the XviD codec...

[iradic]

HI

does someone know this magic xvid calc formula?

will this 'feature' be removed from xvid ? - i dont see the point for using it ...

thanks bye

[Sharktooth]

@Koepi: Any news? New builds?
There are some changes in the Xvid CVS...

[Tommy B.]

Originally posted by iradic
will this 'feature' be removed from xvid ? - i dont see the point for using it ...

This calculator quite good in predicting filesize. And also because
it is embed into the codec, it makes it easy to use (for beginners
for example).

[iradic]

@Tommy B: i was thinking about this 'embeded in the codec' feature...

Yes it's good today, but tomorow?

bye...

[Tommy B.]

As long as the codec is not overloaded by these embed functions it's
ok, I think.

It's pretty handy when you have to calculate the bitrate and you
don't have to look in the program tree for it (saves time).

What I mean is that it is quite usefull when you are encoding with
non automated programs like VirtualDub.

[[MA]Debito]

Are there any plans of implementing an h.264 version of xvid?

[Tommy B.]

Look here:

http://forum.doom9.org/showthread.php?s=&threadid=82927&highlight=h.264

[ChronoCross]

there any chance of seeing a 1.1 final anytime in the next month or two?

[sysKin]

Originally posted by ChronoCross
there any chance of seeing a 1.1 final anytime in the next month or two?
There is no plans to release 1.1 final for now. 1.1 is just the current development branch, pretty much like dev-api-3 was the developemt branch for a long time before.

[ChronoCross]

much thanks. I really do like the improvements 1.1 makes. Look forward to seeing a full release but until then I'll keep on testing the dev build.