Jambo! (XviD-1.0-RC2-07022004)

[sysKin]

Originally posted by Koepi
Standalone players had no issues there. Only the software DivX decoder that ships to you in any form of the DivX package from DivX.com. Actually we can't be so sure. Maybe it also checks for divx version and gets confused with 0.00 ?

I wouldn't mind if someone tried.

[mikeX]

@ hulkenstrong:
you should find this thread (http://forum.doom9.org/showthread.php?s=&threadid=70084) interesting

I've only encoded a small 10000 frame clip with rc2 so far, i have to say it's nice to see quants 1 are not being used carelessly, quality seems to be slightly worse than rc1 though (have encoded the whole movie with rc1)... gonna do the whole movie to make sure...

[sPunkt]

Originally posted by Stereodude
Maybe not quite there yet... This is what I get when I encode a 956x536 clip. The chroma and luma don't line up. 960x540 and 960 x 536 work fine at though. Do I need to be able to divide the horizontal res by 8?

I also ran into the same problem encoding with rc1. (At resolutions that worked flawless with DivX, so I'm not sure it really is a problem with the chain.) Switching to mod16 solutions was very inconvenient in this special case, but did the trick for me, though.

[kadajawi]

I'm only using mod 4 resolutions, but I don't have any problem at all (or anyway not seen any). My source is YV12. Resolutions are 720x576 or lower (cropped to remove black bars, which sometimes differ a lot (music vids)).

[MTskull]

xvid since rc1 has been giving me really choppy panning.... all of my settings are the same with the addition to cartoon and turbo modes. now i have tryed to encode without those modes and i still get the same results .... and files that i did with previous builds re-doing them with the RC series i get the same choppy results... its as if the motion estimation isnt working period. i had no problems with the beta's, what am i doing wrong

[Koepi]

MTsKull:

you're not by _any chance_ using ffdshow or divx to decode xvid content? Please report back.

Koepi

[erdie]

Originally posted by jamest
Both RC1 and RC2 decoder stutter on playback of xvid and divx encoded clips, I tried zp, mpc with vmr9, overlaymixer with similar result.


don't know if it's the same problem, but with RC1 & RC2 I do too have stuttering playback:

* only RC1/RC2 encodes are affected
* RC1/RC2 decoder used, no ffdshow/standalone decoder
* Mplayer2 (WMP 6.4), DX 9.0, some ASUS MX 440 card
* options used for encodes: all defaults except 2 b-frames, 20 i-frame boost, all min quants set to 2

these encoded clips play fine with XviD-Dec-1.0-Beta3.exe and ffdshow using XviD-24062003-1 for decoding

postprocessing is off, CPU usage at 25-30% (Duron 1600)
clip res is 576x432, datarate about 1000kbit, no sound

[Taurus]

Just as small bug in encoder's bitrate calculator:
Changing the values of target size from 650 to 700 MB, the corresponding values at size and average bitrate are set in the wrong order. At 700MB the lower settings are displayed and vice versa.
Check it and you will see.
Doesn't matter much to me but for a newby this could cause a lot of hazzle.

Cheers
Taurus

###Xvid goes on and on and on................

[crusty]

erdie:
Is it a small clip or a big file? Check for fragmentation.
EDIT: sorry wasn't clear enough I guess...I meant file fragmentation on your harddisk. Defrag your drive.
Outpinged:
Is there a way to make RC1 encodes also DivX compatible? A small utility maybe?
Doubt it's worth the effort...RC1 has been around for only a couple of weeks, the issue is minor, and it was quite obvious that the next release would be rather soon. But that's just my opinion. :)

[erdie]

Originally posted by crusty
erdie:
Is it a small clip or a big file? Check for fragmentation.


~30mins ~300MB

what's "fragmentation"?

[NoX1911]

I used to playback xvid with ZoomPlayer(@StandardRenderer) to avoid OverlayMixer. But since RC1 it doesnt work anymore (always OverlayMixer). Any plans to put a switch in config to disable this?

[kadajawi]

erdie: defrag your hard disc. (accessories/system programs/defrag (or something like that) if you're using XP...)

[ARDA]

quote:
--------------------------------------------------------------------------------
Originally posted by sh0dan

Since there are also several places in the decode part that needs this,you can download
codec.c. The code is tested with both input and output YV12,and it works perfectly with
material that is only mod4.(You can see my changes by the missing tabs ;-)
--------------------------------------------------------------------------------

quote:
--------------------------------------------------------------------------------
Originally posted by Koepi

@sh0dan.
thanks a million for the fix, I sent it further to xvid-devel
--------------------------------------------------------------------------------

I've just cvs update, used codec.c modified by sh0dan and compiled.Can confirm mod4 YV12
(decoder) is fixed when open a d2v with avisynth and virtuldubmod.Just tested with avisynth.

Thanks all for the great work.

Regards
ARDA

[MTskull]

yes i am using ffdshow to decode, its what i have to decode divx because i dont want to deal with gain spyware junk.

[ChronoReverse]

And yet, the normal version of DivX5, which decodes ALL DivX5 content, contains no spyware at all to speak of.

[mikeX]

@ MTscull

ffdshow has a known bug which causes stuttering when playing xvid content with B-VOPS > 1 and packed bitstream, it has been mentioned many many times, you should use the search first!

to work around this, you can:
1) disable xvid in the codec configuration in ffdshow (so that the xvid decoder will get used for xvid clips and ffdshow for all others) or
2) not use 'packed bitstream' with more than one consecutive B-VOPs or
3) completely uninstall ffdshow and use only the xvid decoder (it can decode divx as well)

@ erdie

simply put, 'file fragmentation' is when parts of a file are written in different areas of your hard disk, thus slowing down the process of accessing that file
i don't think that this is a likely scenario for your problem though...

[sapient]

Whatever got fixed to allow b-frame playback with the divx decoder seems to have helped x-card playback with the latest drivers too. I haven't checked thoroughly, but things are definetely better.

sapient

[mikeX]

well, finished encoding the whole movie:

source DVD PAL 16:9 progressive anime 1h 44min

avs script: nic's mpeg2dec3-1.10, crop(0,8,0,-8)

xvid, 1st pass:
defaults -packed_bitstream +adapt_quant +PAR=16:9 +cartoon_mode +BVOP_sens=2
+zone of 6746 frames with weight=0.1,start_w_keyframe, greyscale, BVOP_sens=5 (for end credits)

xvid, 2nd pass:
target_size=670720, defaults+1st pass settings

the movie came out 682092 KB, ~10MB oversized

i got the same oversize (~10MB) for that movie with rc1, it must be the weight zone for the credits that's causing this, since i tried using overflow improvement/degradation and control strength of 60 and 80 (with rc1) and the movie still came out ~10MB oversized

the credits also appear to leave a trail of white dots behind them as they scroll upwards

[Danzel]

@mikeX
Did you set your credits to be really small?
I had a problem where I set the credits to use a real small bitrate with many BFrames and used trellis quantization the credits left a mess as they went up the screen, I disabled trellis and everything worked fine.
However this is a totally different setup to you, as I was using Dev-Api-3 (with trellis backported, the last api3 release by keopi IIRC) and encoding my credits seperately from the main movie.

in short: try disable trellis and see if your credits are better.
(Of course I may be completely wrong)
And I'll test low bitrate trellis on scrolling credits when I get home later....

Danzel.

(I did report this trellis thing quite a while ago but no one responded)

[sysKin]

Originally posted by mikeX
i got the same oversize (~10MB) for that movie with rc1, it must be the weight zone for the credits that's causing thisThat is true, very low values (below 0.2) cause something like this. I recommend using 0.2, it still gives quantizers below 20 in most cases.

Some time ago I thought that 0.01 would also work but I was wrong.

Radek

[sagill]

I'd like to know why in recent releases (RC1/RC2) packed bitstream is enabled by default. ;)

The Xvid FAQ states "It is safer to have it turned off."
One of the guides says "2 pass encoding does not work correctly when this is set" (I guess this advice is outdated)
And also ffdshow has problem with it if b-frame is set higher than 1.

I read through the posts in the "packed bitstream question" thread. Nobody seems to be able to give an advantage of using packed bitstream (other than better cutting in VirtualDub). So actually what is it good for? :confused:

[sysKin]

Originally posted by sagill
I read through the posts in the "packed bitstream question" thread. Nobody seems to be able to give an advantage of using packed bitstream (other than better cutting in VirtualDub). So actually what is it good for? :confused: The advantage is in cutting and generally using vdub. The disadvantage is not in xvid but in ffdshow.

As a result, much less people complain (to us) about ffdshow problems than would otherwise complain about "b-frame decoder lag" problems.

Radek

[sagill]

Originally posted by sysKin
The advantage is in cutting and generally using vdub. The disadvantage is not in xvid but in ffdshow.

As a result, much less people complain (to us) about ffdshow problems than would otherwise complain about "b-frame decoder lag" problems.

Radek

I see. :D
Thanks for the explanation.

Just have another question come up. Does quarterpel in RC2 still cause (possibly) artifacts when decoded in DivX5?

[free666]

There is an archive with several matrices included in the Xvid instalation...i wonder if it is possible to get further info or specification of them...thanx

[TripleA]

First: excellent work! I never dreamt, pre v1.0, I'd be able to fit Armageddon on one 90 minute CD and still have it watchable. I should try to locate "Bring it On" again, I guess.

Second: there seems to be a small, rather cosmetic, bug with the code that calculates the "Total" values in the status window. Or a totally new use of the word "average" I wasn't aware of before: it's telling me here that while the minimum quantizer is 4 and the maximum 5, the average is 1.97.

The actual minimum is 2, btw.

And it's not an undersized-target "bug" (what is that, btw, a bug in the user? :))

[nanga parbat]

hullo

it's telling me here that while the minimum quantizer is 4 and the maximum 5, the average is 1.97.

i guess you didn't use b-frames in that case. i have noticed this thing with niltze, too. there seems to be a slight calculation problem for avg quants as well as avg framesize when b-frames are not in use. i haven't done it, but i guess when you calculate it it for yourself you will find that the values '0' get somehow taken into account, thus giving an avg quant of less than 2 if only quants of 2 and higher got actually used.
the avg values will be correct if b-frames are used.

apart from that, great work! very clean installer, koepi.
i also like the new bitcalc.

guidance, nanga

[Heini011]

hi,

i have the same playback problem as with xvid rc 1 here. after playing few seconds fine, xvid drops occasional a single frame, blayback gets jerky. this is most obvious at the credits, when font is scrolling.

playback is fine with xvid beta 3 as decoder, but with rc 1 or rc 2 it gets jerky. :-(

i use no postprocessing. rc 2 results are the same with the following players: Windows Media Player 6.4.0.7.1112, 7.00.00 and with Media Player Classic 6.4.6.9

CPU-Load @ credits: 25% (with Windows Media Player 6.4)

video encoded with xvid rc 1:

resolution: 720 x 448

Profile @ Level: AS @ L5
Quantization type: H.263
BVOPs: 3 / 1.50 / 0.7
Closed GOV: yes, Packed bitstream: yes
Motion search precision: 6 - ultra high, VHQ mode: 4 - wide search
Use chroma motion: yes, Maximum I-frame interval: 250
Quantizations: all 2-31
trellis quantization: yes

credits: seperatly encoded with single pass @ q10.

container: avi
audio part: vbr mp3 (the problem remains without audio too)

system: win me
athlon xp @ 1900 MHz, nForce 2, Radeon 9100, 256 MB RAM
system is prime95 and 3dmark01 stable.

note:
- disabling b-frames did not help with rc 1.
- xvid manual uninstalled before new install
- defaut options always loaded at first time

i hoping very much that this gets fixed soon or that the beta 3 decoder is coming back...

greetings, Heini011.

[erdie]

Originally posted by kadajawi
erdie: defrag your hard disc. (accessories/system programs/defrag (or something like that) if you're using XP...)

that's not the problem.

[4N]

Hi,

in xvid there are a lot of profiles, and I think that it should be written when a profile corresponds to a certified divx profile,
eg: AS@L?/Home theater

[Olleman]

Hey!

I've found what I at least think is a bug in the latest XViD release (RC2 Jambo!). I've encoded an episode of ducktales from a DVB source with all XViD settings to their default except the "cartoon mode" wich I have turned on.

And I get those weird color problems in many frames. They are not particular to only Keyframes etc, they seems to appear more or less random.

Here is one frame that's messed up:

http://apollo13.mine.nu/ducktales_bad.jpg

and here's the one right after this one and this doesn't have the color problems:

http://apollo13.mine.nu/ducktales_good.jpg


The resolution is 512*384 and I've used GordianKnot with Lanzoz resize filter and TomsMoComp. Exactley the same settings as with RC1 wich I had no problems with.

Just thought that needed sharing :)

Regards, Olle

[Koepi]

The image has 1023x768 resolution here, not 512x384.

If that'd be the case, the uneven resolution will be responsible. The YV12 stride fix is for the next release, but maybe you could try gamr's instabuil to see if it gets fixed by that. Alo check your avisynth script - scroll with vdub to the same location and check if the source has _not_ this problem.

This can also be a temporal filter if i look at it again. (That would mean: no xvid bug, but filter effect).

Check that please and report back. :)

Regards
Koepi

[Olleman]

Hello Koepi!

Thanks for your fast reply.

Firstly, let me comment on the resolution of the pictures, I did a real lazy thing and just did a print screen and then cropped it with PhotoShop, thus the strange resolution :)

And secondly I can only apologize, this problem has in fact nothing to do with XViD. The problem is TomsMoComp (yes, the resolution was dividible by 4) that makes these artifacts...allthough I have no clue about WHY since it has worked before with the exact same crop values...

Nevertheless, it wasn't XViD in any way. Let me also just say that you're all doing a great Job and the latest builds of XViD has been phenomenal!

Best Regards, Olle

[sh0dan]

Originally posted by Olleman
Hey!
I've found what I at least think is a bug in the latest XViD release (RC2 Jambo!). I've encoded an episode of ducktales from a DVB source with all XViD settings to their default except the "cartoon mode" wich I have turned on.

Are you sure this isn't present in the source? It doesn't look like a typical stride error. Try finding the same frame in vdub (using the avs script), and compare.

[chilledoutuk]

use mod16 and see if you get the same colour distortions.

tomsmocomp is good deinterlacer but on DVB sometimes you need to blend.

[fccHandler]

I'm late coming into this thread, but I just wanted to say that the new RC2 seems to have finally cured my "packed bitstream" problems with the DivX decoder. (I knew it would be better to nag you guys! :p)

The quality is absolutely stunning. I also like the new installer (very professional looking). Thanks so much for your excellent work!

[Koepi]

chilledoutuk, sh0dan:

is it just me or didn't you read the second post on this page? It wasn't a xvid problem, it's a temporal smoothing artefact from the filter chain which Ollemann just verified. :)

fcchandler:

I'm glad your problems are solved and that you like the installer :)

Regards
Koepi

EDIT: corrected wrong Nick in my response, sorry %)

[mikeX]

back at 1800+ with northbridge cooler, right on...

@sysKin

yeah i remember you saying 0.01 could be nice for credits (aslo hinting to try out 0.00), that's what i had as a guideline when making those tests (my original weight zone config was at 0.00, same oversize problem, then went to 0.01) :rolleyes:
quant 31 zones have worked fine for me before rc1 (beta versions), do you know by any chance if they have problems now? (well i'm actually working on such an encode right now, will know in ~6 hours...)

--: edit

@ Danzel

oops, i totally missed your post somehow...
well i never really use trellis, so that's not it
Offcourse i give credits very little bitrate, and the 'artifacts' could easily fit into the description of b-frames artifacts, but as i mentioned earlier i've had (much) better credits, even @ quant 31 with 2 consecutive b-vops (only difference in settings could be Q-Pel (<-- that's probably it) and chroma-optimizer (unlikely))

[aaar9800]

I think I found a bug in the "XviD Status" dialog

http://rube.741.com/xvid_status.PNG

As you can see the total min quantizer is wrong. It should say 2 instead of 4.

[sdsalsero]

I have a collection of videos recorded with both Beta3 and RC1 which are in 480x480 size. I play them back in Zoom Player 2.9 and 3.0 with the aspect-ratio set to 4:3. This has always worked fine (and with other codecs, too). Now, with RC1 and RC2, I'm unable to adjust the aspect-ratio during playback. If I revert to Beta3, everything works correctly again.

Any idea what's going on? Do you want me to try anything else?

[TruckChase!]

No probs here sofar, thanks for keeping development going on this guys.

[ChristianHJW]

Just allow me to add that Tim Jansen has recently sent me an updated build of his XviD DirectShow encoder filter, compiled against beta3. Nibor didnt have time to make a nice installer around it, so the release was delayed for this reason. I am trying to get Tim to compile a new version against Jambo now, so that we can use q=1 for high quality real time analog capturing. More news hopefully soon ....

[Leak]

Originally posted by sdsalsero
I have a collection of videos recorded with both Beta3 and RC1 which are in 480x480 size. I play them back in Zoom Player 2.9 and 3.0 with the aspect-ratio set to 4:3. This has always worked fine (and with other codecs, too). Now, with RC1 and RC2, I'm unable to adjust the aspect-ratio during playback. If I revert to Beta3, everything works correctly again.

Any idea what's going on? Do you want me to try anything else?

I'd guess somehow ZoomPlayer is honoring the aspect ratio settings in the video file - try going to the "Aspect Ratio" tab in the "Level @ Profile" dialog (hit "more..." right next to it's combo box) and choose a 4:3 picture aspect ratio there (which is what you want anyway) and see what happens.

np: K-Taro Takanami - Portrait Of Tenderness (Chobits OST 1)

[mikeX]

quant zone @ 31 worked like a charm, the file is 670668 KB (670720 KB desired) plus the credits at the end don't have that nasty effect they had before with the weight zone (that's weird though, do they get less bitrate with a weight zone of 0.01 compared to a quantizer zone @ 31?)

[Matthaeus]

Hi there!
I have a very strange problem with the bitrate calc. When I select an audio file to get its size, the size entered in the Subtitles field not in the Audio/Size field!

[Koepi]

Matthaeus:

the problem is known and already fixed for the next release.

Regards
Koepi

[alky]

vdub crashes when opening a xvid rc2 2 pass encoding:

An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...
...while decompressing video frame 0 with "XviD MPEG-4 Codec" [biCompression=44495658] (VideoSource.cpp:1823).

it was done from an interlaced mpg2 capture using this avscript:

mpeg2source("D:\Capture\Tuner_0-4-20040208-0215\Enterprise.S01E02.d2v", 6, 2)
ColorYUV(Levels="PC->TV",gamma_y=40)
Crop(14,72,-8,-72)
BilinearResize(640,390)

xvid settings:
turbo mode
using chroma motion
wide search vhq
adaptive quantisation
interlaced encoding
quarter pixel
global motion compensation
no packed bitstream
everything else default

the video plays fine with ffdshow but not with xvid as decoder (but need xvid for muxing with sound)
any idea what went wrong?

[sysKin]

Originally posted by alky
An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...This is scary, and it's quite important for us that you cut a piece of this movie (beginning - a keyframe and some frames) and send it to syskinATihug.com.au or otherwise upload somewhere.

Thanks,
Radek

[alky]

i now tried it with "start with keyframe" but doesnt help... here is a sample and the full crashreport:

http://web00020.ipax.tk/xvid

[m0rtal]

strange thing, it doesn't crash on my side...

edit: oops, sorry, it really crashes!...

An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...
...while decompressing video frame 0 with "XviD MPEG-4 Codec" [biCompression=44495658] (VideoSource.cpp:1823).

but playback is OK

[celtic_druid]

Same here, well almost.

An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...
...while decompressing video frame 0 with "XviD MPEG-4 Codec" (VideoSource.cpp:[b]1772).

Could have something to do with the height being 390, try using 384 instead.