Strange Bug With XviD 1.0.1

[Sagittaire]

With same settings and same stat file in two pass: HVS-Better, GMC, Qpel, VHQ4, Ultra High, Trelli, AQ, Bframe 2/1.50/1.00

2 pass 1500 Kbps
http://jfl1974.free.fr/Test/NoBug-1500.avi

2 pass 2000 Kbps
http://jfl1974.free.fr/Test/Bug-2000.avi

frame 7: it's SFrame in stat files and 1500 Kbps encoding but bframe in 2000 Kbps encoding -> strong bug

[communist]

With ffdshow there is nothing wrong. Only XviD decoder spits out that blocky image.

So it looks like there is no problem on the encoder side :)

[Sharktooth]

Same here.

[Soulhunter]

Can't get a blocky image...

Not with ffdshow, either with the XviD decoder !!!


Bye

[CruNcher]

@Sagittaire no problem in the 2000 kbps encode it's also a Sprite Frame for me. Looks like you looked @ frame 6 in the 2000 kbps encode accidentialy ;) just be carefull with vdubmod and seeking with b-frames if you seek and go back their will be a 1 frame delay if you didn't used packed bitstream. Better use ffdshow and it's OSD or -1 for vdubmod.

[SeeMoreDigital]

This is an interesting one!

I changed the 4CC of the 2000kbps encode to DIVX and it crashed MPC after a while. But before it did you could clearly see a problem.

Same thing happened when I changed the encodes 4CC to 3IV2 (3ivX)!

I then changed the encodes 4CC to NDIG (Nero) and MPC played it OK. However, when using the 'step frame' button in MPC, the slider bounces backwards and forwards like a tennis ball.


Cheers

[CruNcher]

@SeeMoreDigital
and wich decoders where used with the diferent 4CC's ?
if for example the DivX Decoder was used with DIVX the crash is absolutely normal as the DivX Decoder doesn't support 3 Warppoints GMC and will crash when it comes to decode it, same for 3IVXs Decoder only Atemes Decoder supports it :) jep and seeking with Atemes Decoder is also a known problem so nothing wrong @ all

*requests thread close poor doom9s database space ;)*

[SeeMoreDigital]

Yes, of course CruNcher. I forgot about the GMC DSdec situation!

Using XviD's decoder in MPC the picture break-up is awful: -

http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/Bug-2000.jpg

Has anybody noticed that you don't see this when using XviD's decoder in WMP9.


Cheers

[Sharktooth]

Argh... another MPC glitch.

[CruNcher]

Using XviD's decoder in MPC the picture break-up is awful: -


no wait this is really strange huh GMC QPEL 2.77 and 2.78 and the 2.77 shows problems hmm strange very strange and only with the XviD Dshow Decoder hmm really strange Syskin ?

[Soulhunter]

Same here...

MPlayer2 + XviD decoder = OK

Zoom Player + XviD decoder = OK

Media Player Classic + XviD decoder = Blocks


Bye

[Koepi]

Disble MPCs builtin avi splitter and see if this still happens with mpc ;)

Regards
Koepi

[SeeMoreDigital]

Originally posted by Koepi
Disble MPCs builtin avi splitter and see if this still happens with mpc ;) That fixes the problem Koepi!

http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/Bug-2000_Fix.jpg

What does this tell us then?


Cheers

[Koepi]

Thank you for verifying that!

That tells us that MPC's built-in avi-splitter doesn't split that avi-frame correctly. (Thus - no xvid error around as expected.)

Too bad gabest isn't around anymore :(

Regards
Koepi

[Moitah]

I can get the same broken picture for this clip by stepping backwards in VirtualDub.

EDIT: Also, removing packed bitstream fixes the problem in MPC/VirtualDub.

[guada]

koepi in his work. :) :)
Very beautiful demonstration of the codec Xvid

Xvid forever ;)

[sysKin]

I get a *little bit* of this problem with Zoomplayer and mpc, but not with vdub.

I have some random buggy 1.1-tree build installed right now.

It's funny.

[Sharktooth]

So also the avi splitter in MPC is buggy...
Damn it, its my favourite player.

[unmei]

well Sharktooth, then you got to love the modularity of MPC - you just disable the built-in splitter and everything is fine with MPC.

..which other player would offer you to disble its broken parts (and use external replacements instead, automatically) :)

[Moitah]

I found another video (http://www.moitah.net/p.avi) with a frame that decodes incorrectly or crashes with XviD's decoder. I believe my clip (http://www.moitah.net/p.avi), Bug-2000.avi (http://jfl1974.free.fr/Test/Bug-2000.avi), and for-test.avi (http://www.sharemation.com/aketon/for-test.avi) all share the same problem because they all share the following behavior: when in an AVI container, only happens in MPC
when in a Matroska container, happens with any DirectShow player (MatroskaSplitter)
happens when stepping backwards in VirtualDub
decodes fine with ffdshow
is fixed by removing packed bitstream
I encoded my clip with XviD 1.0.0, the other two appear to be encoded with 1.0.1.

EDIT: The crash or bad looking frame is only when decoded with 1.0.1. When decoded with 1.0.0 there is still a problem, but the frame is a duplicate of the previous (so the video appears to stutter in this spot during playback).

[SeeMoreDigital]

Originally posted by Moitah

* is fixed by removing packed bitstream Damn that packed bit-stream... "Damn it all to hell!"

Seriously though, if the problem can be cured by removing it. Could this mean that we can wave good-bye to PBS, now that our PC's, software and hardware players have improved?


Cheers

[Koepi]

Originally posted by SeeMoreDigital
Damn that packed bit-stream... "Damn it all to hell!"

Seriously though, if the problem can be cured by removing it. Could this mean that we can wave good-bye to PBS, now that our PC's, software and hardware players have improved?
Cheers

No. Just because MPCs avisplitter has a bug this doesn't mean that we want all the new users (thousands of them) to believe XviD has an error which is called "bframe decoder lag".

[bond]

Originally posted by Koepi
Just because MPCs avisplitter has a bug this doesn't mean that we want all the new users (thousands of them) to believe XviD has an error which is called "bframe decoder lag".simply dont display the decoder lag message, but another frame twice ;)

but anyways xvid always gave the user the freedom of choice, so if there is a bug in packed bitstream its not a real solution for fixing the bug (it happens not only with gabests splitter) with simply not using it :)

[Koepi]

Well, the error is amplified by the bug in mpc's avisplitter. It could be that it's the issue that xvid doesn't know about s-vops for 2nd pass - it's too much optimized to fast first pass.

If xvid would respect that s-vop and make that frame at least a p-vop on 2nd pass the problem would be gone already.

(Thanks foxer for mentioning that xvid doesn't know s-vop on 2nd pass / stats reading.)

It's no real packed bitstream error, that bug would've gone unnoticed if PB wasn't there ;)

Regards
Koepi

[SeeMoreDigital]

Far be it from me to turn this thread into another PBS debate ;)

But like I mentioned before, have our PC's, software and hardware players improved to such a point where this implementation is not really necessary anymore?

I'll be honest I don't really know enough about BPS to work this out for myself....

But I have to ask. Are we using PBS, simply because it's there. Or because it's necessary?

And if it is necessary. How necessary is it?

More or less necessary than it was 18 months ago, 12 months ago or 6 months ago?

If I'm talking out of my arse (again) please tell me to shut up!


Cheers

[sysKin]

Originally posted by SeeMoreDigital
But I have to ask. Are we using PBS, simply because it's there. Or because it's necessary? We're using PBS to stop people asking about "b-frame decoder lag bug". Just take a look, not a single question about that for many many weeks.
Plus, it makes all avi operations easier. I like PBS and I'm using it, just for that reason - of course that's just my choice, but making it default helps all n00bs.

Radek

[unmei]

O/T i'm a member of a n00bs community but still don't like PBS :p

Anyway i agree, default or not, it's a matter of clicking on a checkbox once per xvid install. In that respect, it probably is better if this click is left to the people who fiddle around with the settings anyway.

[SeeMoreDigital]

Radek,

Does b-frame decoder lag get progressively worse in relation to the number of b-frames used?

If so, have all the previous reported problems been associated with encodes generated with more than 1B-VOP?

In XviD the default B-VOP implementation is 2 (with optional) PBS. But DivX's default implementation is 1 (without optional) PBS.

I don't know, but is b-frame decoder lag a big problem with DivX today. And if so, does DivX cope better or worse than XviD with 1B-VOP.

I'm just interested. As the two implementations appear to work/respond very differently!


Cheers