PDA

View Full Version : Current status and usable options in XviD?


Bulletproof
16th November 2002, 10:24
Hey I've been using the current Koepi build and was wondering currently what works and what doesn't work. I would be greatful if someone could answer these questions please (All pertain to Koepi builds):

Is Q-Pel and B-frames currently working with no problem?

When B-frames are used (Alone), must you use the DX50 FourCC? When I used the XviD one it seems to playback very choppy with dropped frames, like the one of the first betas did when you had Packed Bitstream on.

Does the current XviD decoder support GMC or must the DX50 FourCC be used?

Is GMC working together with Q-Pel, is a FourCC change needed?

Is GMC working together with Q-Pel and B-Frames, is a FourCC change needed?

Does using a custom quantizer matrix (Known working in stable builds) mess up any of the new options? Do the custom quantizer matrix's even get used with the new options?

I did a test today with all the new options enabled, B-Frames, Q-Pel and GMC and it did not seem to decode with the XviD decoder, I used a 720x480 resolution but the video was just playing back corrupted. When I changed the FourCC to DX50 then it seemed to show a good picture, except there are like jumping blocks in the picture when heavy motion happens. I would really appreciate it if someone could answer those questions above, I'm sure it would help alot of other people also and save them from writing another thread about the issues.

glenn
16th November 2002, 11:04
If you SEARCHed the forum first, most of these questions have already been answered in previous threads...

At least one answer: You need to use a b-frame-enabled directshow filter to show b-frame encodes, that's why your encodes look choppy when viewed with the normal xvid filter. Use Nic's dshow filter (personal favourite), ffdshow or set the fourcc to DX50 and use DivX's filter.

iago
16th November 2002, 12:04
Well, I can say that GMC only (without b-frames) works great. I have just finished a 2CD encode, keeping the ac3 audio, of a 121 min. movie, 1stPass size/2ndPass size: ~2.2, with the below script:
-------------------------------------------
LoadPlugin("C:\FILTERS-YV12\mpeg2dec3.dll")
LoadPlugin("C:\FILTERS-YV12\UnDot.dll")
mpeg2source("C:\MOVIE\MOVIE.d2v")
crop(6,12,706,552)
UnDot()
a=Trim(0,3356).BilinearResize(640,352)
b=Trim(3357,175969).LanczosResize(640,352)
c=Trim(175970,0).BilinearResize(640,352)
return a + b + c
-------------------------------------------
(Koepi's 14112002-1 build / 1stPass:MPEG / 2ndPass:NewModulatedHQ)

The result is just outstanding, with no decoding problems using ffdshow 13/11, "use xvid" checked.

regards,
iago

edit: ffdshow 13/11 "use xvid" unchecked seems to display some artifacts at certain scenes with GMC encodes.

sysKin
17th November 2002, 13:01
OK, let me summarize what we got:

B-frames have been working without any problems for a longer time now. They are OK.

GMC is still in early development stage, I don't think it improves anything. However some people say it helps - OK, I don't encode movies so I don't know for sure.
I personally saw some artifacts (in color) when other filters decoded XviD's GMC - or when XviD decoded Divx5's GMC. I'm not sure if our GMC is really correct :/

GMC + Bframes should work correctly as far as encoding is concerned. However, I don't think that a needed fix has been applied to decoder - I don't know if decoder decodes them. Use ffdshow or change fourcc to dx50.

Qpel works, even if very slow. I'd call it 'safe'.
Qpel+GMC should work, but I think GMC is even less efficient then.

And most importantly: qpel doesn't work with b-frames. If you set max bframes to >= 0, qpel is automatically off.
But don't worry, this should be fixed in the next few days :D I already have a 90%-working XviD with bframes and qpel together ^__^

As for mpeg/custom matrices, I wish I knew myself. I looked in the code and didn't see anything wrong, but it seems that always h263 matrix is used. I'm not sure about this :/

Radek

Teegedeck
17th November 2002, 13:29
Thanks a whole lot, sysKin! You work as if you were getting paid for it. :cool: Without people like you, Koepi and all the rest of the team, of course, where would our sweet little open-source community be?

Has anyone else tried to encode with B-frames and no DX5-B-VOP-compatibility? I was wondering, I got the impression that letting B-frames refer to I-frames like this yielded slightly better visual quality but I might be imagining things.

iago
17th November 2002, 15:01
@sysKin

Thanks for clearing everything up! ;)

regards,
iago

sysKin
17th November 2002, 15:26
Originally posted by me
And most importantly: qpel doesn't work with b-frames. If you set max bframes to >= 0, qpel is automatically off.
But don't worry, this should be fixed in the next few days :D I already have a 90%-working XviD with bframes and qpel together ^__^
OK, good news: 90% changes to 100% when a bug is found :D.
If you want bframes+qpel(+gmc if you want), get my build from http://noa.sm.pl/~syskin/xvid.zip . It's a dll only, repace the old one. Warning: completely untested.

Have fun,
Radek

wotef
17th November 2002, 19:37
fwiw, with koepi's 14/11 build, b-frames off, 2-pass H623 run with qpel + chroma motion + gmc, i get what i can only describe as "motion shiznit-trails" on slow pans - i only detected this on a clip with a dark background, and didn't catch this at all on a lighter clip

anyone got any similar material to verify this?

the trails don't occur when i encode with gmc unchecked

http://www.zenadsl5618.zen.co.uk/misc%20pix/2hqpelgmcchroma.avi

drebel
17th November 2002, 21:47
@Teegedeck
I've been using b-frames since the early release of the special api,even though my DURON 1GHZ kept crashing in the middle of every encoding.Then i discovered that without checking the option "DX5-B-VOP-compatibility" everything was fine.So, i have more than 5 b-frame encodings WITHOUT the option and about as many WITH it checked(latest xvid builds-no crashes).Quality of b-frames seems to be the same (very pleased with the final result),no decoding problems(except that xvid.dll seems too heavy for my machine ,so i'm using ffdshow).
The funny(?) thing is that in ffdshow's OSD using libavcodec I/P/B frames are showed correctly,but when using xvid.dll in it,OSD recognises EACH frame as I-frame.
regards,
george

Rrrough
17th November 2002, 22:27
@sysKin

thanx for your build.

As for mpeg/custom matrices, I wish I knew myself. I looked in the code and didn't see anything wrong, but it seems that always h263 matrix is used. I'm not sure about this :/ that's only in combination with b-frames (I don't know if you were referring to that).
Marc hacked in some support for mpeg/custom matrices in combination with b-frames (seen on the mailing-list). maybe he can tell you, and you'll get this into CVS !?
Thank you very much for your fabulous work !

cheers

marnum
18th November 2002, 11:20
Hi! Back again to Xvid - seems as you've made much progress since I last checked out your forum. I'll try the (more or less) new b-frames on Gladiator in the next days.

@ iago:

>> LoadPlugin("C:\FILTERS-YV12\mpeg2dec3.dll")
LoadPlugin("C:\FILTERS-YV12\UnDot.dll")
mpeg2source("C:\MOVIE\MOVIE.d2v")
crop(6,12,706,552)
UnDot()
a=Trim(0,3356).BilinearResize(640,352)
b=Trim(3357,175969).LanczosResize(640,352)
c=Trim(175970,0).BilinearResize(640,352)
return a + b + c

Silly question, but: What does this using 3 different resize filters do? Does it give you 3 different results for comparison?
And UnDot - never heard before. Could someone explain to me what it is for?

sysKin
18th November 2002, 11:31
Hi.
Just dropped in to tell you to forget about this build above. It has many errors, one of them being that you can't turn on qpel at all, anyway.

Qpel+bframes is still not ready.

Radek

Sirber
18th November 2002, 13:14
Does someone has been able to encode with this settings in 2 pass?

5 b-frames @150%
GMC

No Hinted MV
No DIVX5 comp.

Thanks

bond
29th November 2002, 14:59
Ok the current status of b-frames, qpel and gmc has been discussed in the above threads, to complete this issue i have 2 more questions:

1) Lumi masking:
I found various threads about the use of this feature some say that lm should only be checked in the second pass, some say in both passes.
As a rule of thumb is it right to say that lm should be used in the 2nd-pass only for 2cd-rips, and in both passes for 1cd-rips (or will that be too much of lumimasking?)

2) Quantization Type (1st-pass -> 2nd-pass):
Is it right to say that for 1cd-rips the combination h.263->modulated should be used (as h.263 smooths the images) and for 2cd-rips mpeg->new modulated hq (as mpeg sharpens)?

kastro68
30th November 2002, 02:38
Don't use lumi masking at all

Koepi
30th November 2002, 03:05
Use lumi masking :P

And since some months we agreed to use it on both passes. Use it only if you can't achieve the low bitrate otherwise (e.g. high action movies on 1CD).

As for modulated quant type, I don't recommend it - it's most likely not standard compliant, even if every player supports it (yes, _every_ player).

Regards
Koepi

Bulletproof
30th November 2002, 03:33
The new lumi masking seems to have a bug, it seems to put white dots in areas that are black. I think there is a bug somewhere with the custom quantizer matrix also, last night I tried to encode a video but I kept getting "green leaks", a part of the video would get a green spot then progressively turn the whole frame green until the next key frame, I've seen this in nandub too. I tried alot of combinations, even with B-frames and Q-pel, gmc etc. all turned off and only default settings used except custom quantizer. When I set the quantizer back to H.263 the green leak went away.

Koepi
30th November 2002, 08:55
I can't reproduce a green-leak bug here, sorry.

Check your setup (mod16/32 resolution?): cust. quant. matrices may need such an resolution.

Regards
Koepi

Bulletproof
30th November 2002, 10:03
It seems to happen only if you use DX50 decoder, I can't use the regular resolutions like 704x480, 720x480 or 352x240 with the current xvid decoder, so I change to the DX50 decoder. I changed the size this time to 512x384 so that the XviD decoder would show it, and there is no green leak then, and Q-pel and B-frames work together, adding GMC in though causes glitching. So I guess if you use a custom quant in the current build and make DX50 decode it, it will then do the green leak. If you need a video with the problem let me know.

Bulletproof
2nd December 2002, 02:42
Can anyone else say if they are getting the same problems, so I know it's not just me. Here are the current problems I'm having:

1. Current supplied xvid.ax decoder is not working with 720x480 or 704x480, and alot of other common resolutions. I did however test 512x384 and that is working.

2. Q-Pel works with the XviD decoder, but not with the DivX decoder, if you try to use the DivX decoder there are many bad blocks.

3. Custom quantizer Matrix is not working if you use the DivX decoder, but it does work with the XviD decoder. When I use a Custom quantizer matrix (Any one besides H.263) it causes frames to turn green until the next key frame. However if H.263 is used there will be no problem.

sysKin
2nd December 2002, 11:53
Originally posted by Bulletproof
2. Q-Pel works with the XviD decoder, but not with the DivX decoder, if you try to use the DivX decoder there are many bad blocks.
This is a limitation/bug of DivX decoder. You can work it around by using motion precision 4 - XviD will not use the motion mode which DivX5 cannot decode.3. Custom quantizer Matrix is not working if you use the DivX decoder, but it does work with the XviD decoder. When I use a Custom quantizer matrix (Any one besides H.263) it causes frames to turn green until the next key frame. However if H.263 is used there will be no problem.Another DivX5's problem. By the way, H.263 is not custom. There are two matrices - H.263 and MPEG. MPEG might be custom, while H.263 is not editable.

Radek