Problem with XviD and Archos AV400

[XTCrefugee]

I've been using XviD with my Archos AV400 for quite a while now, and I'm very happy with the quality (quite a bit better than DivX usually). However, I think I must have changed something (although I can't imagine what) because now I'm having problems.

I'm getting a kind of 'smearing' effect, where static parts of one frame seem to carry over on to the next few, until a keyframe. It kind of looks like areas (usually at the bottom of the frame) have been 'smudged'. I would stress that this is only happening on the Archos - not when playing it with either the DivX or XviD decoders.

Here is my AVISynth script (pretty normal) -

LoadPlugin("C:\Program Files\DVB-MPEG2\DGDecode.dll")
LoadPlugin("C:\Program Files\DVB-MPEG2\Decomb521.dll")
Mpeg2Source("Z:\The Mummy Returns\The Mummy Returns.d2v")
Telecide(order=1,guide=2,post=2,blend=false)
Levels(0,1.2,255,0,255)
BicubicResize(480,270,0,0.75,88,74,544,434)

At first I thought it was a problem with XviD 1.0.3 (which I only installed recently), but after going back to 1.0.2 It's still there.


I can only find one thing different about these files. In GSpot under 'User Data / Metadata', the ones I'm doing now have this:

[USER] XviD0037
[USER] XviD0037
[USER] XviD0037

Or XviD0036, since I've gone back to 1.0.2, wheras the ones that I've been doing until now, which have worked fine, have this:

[USER] DivX999b000p
[USER] XviD0037
[USER] DivX999b000p


I have no idea why this is different in the new files, although presumably it means DivX played some part in the encoding of the files that worked fine.

I was thinking perhaps that DivX was decoding the video and XviD was encoding? To try and change this I've tried enabling 'support generic mpeg-4' in the DivX decoder, putting a ConvertToYUY2() at the end of the script, even unregistering the XviD decoder. But the files still have the three XviD0037 lines, and still have the same problem with my Archos. Files encoded with DivX (which have three DivX999b000p lines) play fine - but I want to use XviD!!!

At it's my only clue at the moment, does anyone know what these 'User Data' lines mean, and what I can do to get the DivX999b000p / XviD0037 / DivX999b000p back?

[XTCrefugee]

OK, getting closer to the problem now, and it DOES seem to be an XviD bug.

DivX999b000p apparently means packed bitstream. However, the files without this also claim to have N-VOPS in GSpot.

I think the Archos is getting confused, either thinking it's a packed bitstream when it isn't or vice versa. I found a file without DivX999b000p and also without N-VOPS, and that plays fine too. I've encoded some files with B-Frames (which the Archos doesn't like, but will play) both with and without packed bitstream, and these do not have the 'smearing' problem as the 'DivX999b000p' marker is present with N-VOPS and isn't there without them.

The problem is, without enabling B-Frames, I have no control over whether or not a packed bitstream is used. Enabling B-Frames, enabling/disabling packed bitstream, then disabling B-Frames does not work.

So I either need to find a way to disable N-VOPS without enabling B-Frames, or I need to get XviD to include the DivX999b000p marker. I've tried to use MPEG4 Modifier, but it doesn't seem to work with Windows XP. Any ideas? Does XviD store any of these settings in the registry?


{edit] I'm using Koepi's XviD binaries, by the way.

I've got MPEG4 Modifier working now (needed .net 1.1), but it says N-VOPS are present but it ISN'T a packed bitstream, so won't let me unpack it. So I still need a fix for the XviD encode itself - how do I get it to stop using N-VOPS?

[ChronoCross]

this still sounds like a bug that I posted in the XVID 1.1 beta thread. or it may be an additional to that one. the smearing...or frame blockiness or whatever.

[XTCrefugee]

Well, it looks like I've sorted it out, in a way.

Using MPEG4 Modifier (big thanks to Moitah!) I just added DivX999b000p to the User Data and saved the file. Now it works fine, no smearing from static areas or smudging at the bottom of the frame.

In GSpot, the User Data now shows XviD0037, DivX999b000p, XviD0037.

I first attempted to delete the existing XviD0037 and add DivX999b000p, then XviD0037, so the file would show the same in GSpot as the previously working files. However, strangely this didn't solve the problem wheras just simply adding DivX999b000p did :rolleyes:

Anyway, it certainly does look like this is a bug in Koepi's XviD. According to GSpot, the files have N-VOPS and use packed bitstream. According to MPEG4 Modifier they also have N-VOPS, but do not use packed bitstream. So there's obviously some confusion over how to identify if a file uses packed bitstream or not.

Also, in the case of the Archos (and therefore possibly other MPEG4 decoders based on the same hardware) clearly having DivX999b000p in the user data is important for playback of files with N-VOPS. The extra step of using MPEG4 Modifier isn't much of an inconvenience, but nevertheless hopefully Koepi or someone can have a look at fixing this.

I'm very glad I don't have to stop using XviD - I had a look at the new DivX Fusion beta, and even at 'Insane' quality it still looked horrid in darker scenes compared to XviD :p

[edit] Just to add a bit more info, I took one of these clips (both before and after I added the DivX999b000p, to make sure it wasn't caused by that) and used AviC to change both 4CCs to DIVX so it would play with DivX Fusion instead - and the clip then showed the exact same problems as on my archos! So clearly current XviD content is not properly decodable by DivX, and the above 'fix' that worked for the Archos does not work for the DivX decoder.