View Full Version : XviD 1.0.1 sample which shows problems with a bunch of MPEG-4 decoders
i recently noticed that a sample i encoded with XviD 1.0.1 (by using h263, VHQ4, ChromaMotion, QPel, GMC, Trellis, B-frames (1, other settings default) and AQ) showed problems with a bunch of mpeg-4 decoders:
divx5.1.1 (dshow): shows artifacts in some parts of the picture and than crashes
divx5.1.1 (vfw): shows the same artifacts, but doesnt crash
3ivx: shows similar artifacts, but not as much as divx5
enviviotv: shows similar artifacts, but much more than 3ivx and divx5
nero digital: simply doesnt display the parts where the others show artifacts (playback freezes and continues with the next keyframe)
xvid (vfw and dshow) and ffdshow dont show these problems
any ideas which can cause this? i didnt find a similar report by using search
for testing it yourself, grap the sample here (http://8ung.at/bond/xvid-sample.zip)
edit: it seems i get similar results with an old encode i did with RC4 (using the same settings, but 2 B-frames and no AQ)
Originally posted by bond
any ideas which can cause this? i didnt find a similar report by using search
Well, I'd hazard a guess that all this is caused by using GMC, as XviD (correct me if I'm wrong) is probably the only MPEG-4 codec that uses 3 warppoint GMC, all others either don't support it or only use 1 or 2 warppoints, which makes GMC not very useful compression-wise; I wouldn't be surprised if other decoders barf on that (almost all standalone MPEG-4 decoder appliances certainly do)...
QPel might also be a problem, but not that much anymore, and the B-frames setting should work almost everywhere by now.
h263, VHQ4, ChromaMotion, Trellis and AQ should be safe, though.
np: Amorphous Androgynous - Slo-Mo (The Otherness)
SeeMoreDigital
4th July 2004, 13:36
When I posted this obsevation I was informed that DivX's DSdec show filter does not like XviD's 3warp point GMC. Maybe it's the same for 3ivX.
Cheers
Teegedeck
4th July 2004, 13:44
Plays back fine with ffdshow (May 14th 2004), mplayer (March 2003) and VLC ("quite darn old").
SeeMoreDigital
4th July 2004, 13:49
Just tried changing the encodes 4CC (to NDIG) and forced it to play using Nero's DSdec filter.... seems to work OK!
Cheers
Sharktooth
4th July 2004, 14:38
The main problem seems to be GMC.
I've re-encoded your sample without it and i had no problems (except nero's DS)
SeeMoreDigital
4th July 2004, 14:43
Originally posted by Sharktooth
The main problem seems to be GMC.
I've re-encoded your sample without it and i had no problems (except nero's DS) What problems did you experience when using Nero's DSdec filter?
Cheers
Sharktooth
4th July 2004, 14:48
Stuttering/skipped frames. Hovever with NDIG as FourCC it plays fine.
Originally posted by Teegedeck
Plays back fine with ffdshow (May 14th 2004), mplayer (March 2003) and VLC ("quite darn old"). yeah as i said ffdshow (meaning libav) decodes it without a problem (i assume mplayer and vlc both use libav too)
Originally posted by SeeMoreDigital
Just tried changing the encodes 4CC (to NDIG) and forced it to play using Nero's DSdec filter.... seems to work OK!hm strange in my chase it simply didnt display anything where the others displayed the artifacts (meaning the playback stopped/picture freezed for some seconds) and after the next keyframe/scene change was reached playback continued in a normal way
Originally posted by Sharktooth
The main problem seems to be GMC.
I've re-encoded your sample without it and i had no problems (except nero's DS)reencoded with the same settings, but only without gmc? if yes, than i assume that this is the reason
i analysed the stream and also before the artifacts appear gmc has been used (dunno about the warppoints) and the artifacts also appear in frames where no gmc is used
Sharktooth
4th July 2004, 15:08
Originally posted by bond
reencoded with the same settings, but only without gmc? if yes, than i assume that this is the reason
i analysed the stream and also before the artifacts appear gmc has been used (dunno about the warppoints) and the artifacts also appear in frames where no gmc is used
Yep. Same settings (qpel included) but without GMC.
ok i now also encoded the scene again (from dvd source) with the same settings, but without gmc in xvid and i got the same results as Sharktooth -> no decoding problems with divx5 and 3ivx
BUT
i now also encoded the same scene with nerodigital, with gmc enabled (they also use 3warppoints), but divx5 and 3ivx dont show a problem there with the decoding (tough ffdshow reports that ND only used on maybe 4 frames GMC, in contrary to xvid, which used it on every third frame or so)
Teegedeck
4th July 2004, 18:47
Hm, I guess nerodigital can't get much out of GMC.
SeeMoreDigital
4th July 2004, 19:00
Originally posted by Teegedeck
Hm, I guess nerodigital can't get much out of GMC. Eeh gods!
I hope we're not going to have the same kinda compatibility problems with GMC that we have now with b-frames.
Surely one manufacturers version of 3warp-point GMC should be compatible with another manufacturers version of 3warp-point GMC...
What's next? Different types of Qpel.
Cheers
Originally posted by Teegedeck
Hm, I guess nerodigital can't get much out of GMC.yeah well, still its strange that divx5 and 3ivx can decode the nd stream with 3wp gmc without a problem, but not the xvid one...
Originally posted by SeeMoreDigital
I hope we're not going to have the same kinda compatibility problems with GMC that we have now with b-frames.well i dont know where such incompatibilites should come from
assuming that i am not that dumb to f* up the encode somehow, i assume there is a bug in xvid's GMC OR in the divx5/3ivx/envivio... decoder :D
Originally posted by SeeMoreDigital
What's next? Different types of Qpel.
We already have different types of qpel :(
Andrey
5th July 2004, 11:17
yeah well, still its strange that divx5 and 3ivx can decode the nd stream with 3wp gmc without a problem, but not the xvid one...
Just a guess - nd did not use GMC or did not use more than 1 wp in that sample. (for whatever reason)
We already have different types of qpel
Huh ?
SeeMoreDigital
5th July 2004, 12:38
Originally posted by Andrey
Just a guess - nd did not use GMC or did not use more than 1 wp in that sample. (for whatever reason) I've generated some Nero GMC tests of my own and they definitely use 3warp-points.
For me Nero GMC encodes play perfectly using XviD's DSdec filter. So do Nero GMC encodes with B-VOP.
Originally posted by Andrey
Huh ? I know... depressing isn't it :(
Cheers
Originally posted by Stux
We already have different types of qpel :( hm if you mean the potential idct mismatch, than this is only a "theoretical" problem as all "on doom9 present codecs" use the same idct afaik
Originally posted by SeeMoreDigital
I've generated some Nero GMC tests of my own and they definitely use 3warp-points.exactly, afaik its not possible to have mixed warppoints in a clip, so a 3wp gmc codec (like nd) will always use 3wp
SeeMoreDigital
5th July 2004, 20:00
Originally posted by bond
exactly, afaik its not possible to have mixed warppoints in a clip, so a 3wp gmc codec (like nd) will always use 3wp And the Recode2 encodes are looking a lot better too now!
Plus, if you force anamorphic 3ivx and XviD .AVI streams to use Nero's DSdec in say, WMP9 or MPC etc they will be displayed correctly automaticly... I've never been able to do this using any other decoder with AVI's.
Also... calling all XviD developers. Can you provide answers/suggestions to this question please (http://forum.doom9.org/showthread.php?s=&postid=520320#post520320)?
Cheers
Andrey
5th July 2004, 20:17
exactly, afaik its not possible to have mixed warppoints in a clip, so a 3wp gmc codec (like nd) will always use 3wp
Hmm ? Really ?
I thought, encoder simply place all 3 base points in one place...
So, seems that I was totaly wrong... :)
Then I can not imagine, how DivX decoder can play that clip
well i am not 100% sure (as always ;) ) but afaik its not like an encoder can use on frame #12 1wp, on frame #20 3wp, on frame #34 2wp aso...
SeeMoreDigital
5th July 2004, 20:28
Originally posted by Andrey
Then I can not imagine, how DivX decoder can play that clip I guess in much the same way the DivX decoder can play XviD GMC... very badly ;)
Cheers
EDIT: I would also be interested to know how successfully stand-alone players get on with encodes generated using 3WP GMC. Do you see an image at all or does the player crash?
Originally posted by bond
hm if you mean the potential idct mismatch, than this is only a "theoretical" problem as all "on doom9 present codecs" use the same idct afaik
No, the idct problem as it relates to qpel is just the final nail in the coffin
the problem I refer to is there are 3 different wrong ways that I can think of in relatively common use (think about codecs starting with "D"), and 2 different specified ways of handling qpel (the new and the old way)
My point is there are already multiple ways of handling qpel... and only 1 of them is actually right :(
My point is there are already multiple ways of handling qpel... and only 1 of them is actually right
An historical note, here: between v1 and v2 versions of the
ISO, the qpel specifications changed (i learnt it the hard way:
all this ASM code in xvid to throw away ... geee...).
The best is the reason for this change: MS's implementation
of qpel was wrong, so instead of correcting it, it was decided
to change the norm.
makes me laugh, now :)
bye!
Skal
Stux
10th July 2004, 06:22
Originally posted by skal
An historical note, here: between v1 and v2 versions of the
ISO, the qpel specifications changed (i learnt it the hard way:
all this ASM code in xvid to throw away ... geee...).
The best is the reason for this change: MS's implementation
of qpel was wrong, so instead of correcting it, it was decided
to change the norm.
makes me laugh, now :)
Yes :)
That was what I was referring to by "and 2 different specified ways of handling qpel (the new and the old way)"
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.