Bad news for interlacing

[-h]

Though I had hoped that "bad" interlaced XviD streams could be converted to "correct" ones (CVS is finally patched, woohoo), it seems that MPEG decided to change the edging behaviour from the way it's described in the vm18 document.

So while it is possible to fix the bitstreams, there will be some muddy or smeared areas at the top and bottom of the corrected file, which will last until the next I-frame.

My advice? If you have interlaced files that you can't re-create, I'd consider re-encoding them to either the corrected XviD (you'll need a FourCC trick for this) or to MPEG-2. If you don't want to do that, I could build a "bad" version of XviD with a different FourCC, especially for playback of these buggy files. Of course trying to play them on newer builds or other MPEG-4 codecs won't work.

Sorry guys. Such is alpha software :(

-h

[ma.hoff]

>My advice? If you have interlaced files that you can't re-create, I'd consider re-encoding them to either the corrected XviD (you'll need a FourCC trick for this) or to MPEG-2. If you don't want to do that, I could build a "bad" version of XviD with a different FourCC, especially for playback of these buggy files. Of course trying to play them on newer builds or other MPEG-4 codecs won't work.
:eek:
Can't you change XViD to enable backward compatibility ?
I have encoded around ~25 CDs with 2 Episodes StarTrek DS9 on each and several movies on 10 or more CDs and several music videos from MTV... I don't like losing them by upgrading to current cvs :(
Other MPEG4 Codecs do not work of course ! (not so nice, but acceptable :) )
But can't xvid be backward compatible to old builds ?
Please ?? :confused:

>Sorry guys. Such is alpha software
:(

Martin

[-h]

Can't you change XViD to enable backward compatibility ?

Nope.

I have encoded around ~25 CDs with 2 Episodes StarTrek DS9 on each and several movies on 10 or more CDs and several music videos from MTV... I don't like losing them by upgrading to current cvs :(

Ouch :( Sorry about that.

But can't xvid be backward compatible to old builds ?

Nope, there's no way to "detect" whether a given stream is good or bad, you just have to watch it and see what happens.

Hrm. You'll need two copies of XviD on your system - one which uses the traditional xvid/XVID FourCCs and has the bug, so you can play back all your CDs without reading them, changing the FourCCs of every file, then burning them back again. However that means you can't use xvid/XVID for the good builds that will be distributed from now on. So, any new builds you get will need a different, MPEG-4 compatible FourCC (rmp4/RMP4 is a good candidate) so that when you create files with it, the old buggy version doesn't jump in and try to decode them.

I can help you with all this of course, if you decide what you'd like to do.

-h

[ma.hoff]

So, i guess the AVIs do not contain any kind of version number of xvid, to tell how to decode the video data !?? :(

Okay, then it seems i have to do it :-((((

So here's some useful information:
I have used "XVID" as Fourcc for all my encoded AVis and i do use linux as OS (no windows installed anymore)

But i guess it won't be too hard to use mencoder (from mplayer) to reencode those avis (beside changing CDs, burning again - but that's only a logistically problem ... :( )
Maybe i can create some script to do that for me - i'll test that !

Do you think rmp4 is generally a good idea ? Or should i use xvid or divx ? Whats the best buy ?

Can i compile a "mixture" of both cvs versions so that decoding is done with the old algorithm and encoding is done by the new ?
I cannot think of any other method at the moment with mencoder !

Thanks in advance for any help !

Martin.

PS: Todays cvs is the correct interlaced version ? i mean mpeg4 compliant ?

[-h]

I have used "XVID" as Fourcc for all my encoded AVis and i do use linux as OS (no windows installed anymore)

Well then. You need a codec which accepts "XVID" as the FourCC, and has the interlacing decompression bug. I can do that.

But i guess it won't be too hard to use mencoder (from mplayer) to reencode those avis (beside changing CDs, burning again - but that's only a logistically problem ... :( )

That sounds like a colossal pain. It would be easier to use two different builds of XviD and keep your old stuff as it is.

Do you think rmp4 is generally a good idea ? Or should i use xvid or divx ? Whats the best buy ?

DivX (any version) doesn't seem to support interlacing, so using it as your FourCC wouldn't be too good. I guess you could even use "MPG4" or "MP41" which are Microsoft's "ISO MPEG-4" FourCCs from memory, at least I know ffmpeg plays them.

Can i compile a "mixture" of both cvs versions so that decoding is done with the old algorithm and encoding is done by the new ?

Yes, however such a build would not be able to decode anything that it encoded itself, as decoding would be buggy, but encoding bug-free.

PS: Todays cvs is the correct interlaced version ? i mean mpeg4 compliant ?

Yep, I patched it 10 hours ago.

-h

[ma.hoff]

That sounds like a colossal pain. It would be easier to use two different builds of XviD and keep your old stuff as it is.

But how can i have two build at the same time ?
mplayer/mencoder only uses one - i cannote see how to force him to use two different builds :confused:
That's why i asked about the mixture of both ...


DivX (any version) doesn't seem to support interlacing, so using it as your FourCC wouldn't be too good. I guess you could even use "MPG4" or "MP41" which are Microsoft's "ISO MPEG-4" FourCCs from memory, at least I know ffmpeg plays them.


Does ffmpeg play "new" xvid interlaced correctly ? Buggy ones were refused -> cannot decode interlaced / frame broken ...
Generally i like xvid as fourcc !

However i would really appreciate a solution with two versions since i can re-encode all my files (yes) - but this will take quite some time and i need a working xvid encoder (new one) for everyday use (recording series) - so basically one version which decodes buggy and encodes correctly would do the job - major drawback is that this version does not allow for viewing the new encoded material - so i cannot check if it's all right !

So, either i need a solution which allows for a second xvid installation that decodes correctly or ffmpeg does the job !? (this would be really fine)

You see my problem ? :confused:

IDEA: :sly: Would it be possible to compile "binary compatible" libxvidcore.so ? Then i would compile two versions (buggy dec+new enc) and (new dec+new enc) and could simply exchange the two libxvidcore.so files (or rename them) to change the behaviour ... Would this work with one version of mencoder ? Or are there two versions needed aswell ? :sly:

Martin

[-h]

But how can i have two build at the same time ?
mplayer/mencoder only uses one - i cannote see how to force him to use two different builds :confused:
That's why i asked about the mixture of both ...

Oh mencoder huh.. no idea how, I've never used it. I'm sure that somewhere inside mencoder there is a list of what FourCC corresponds to what .so file, so you should be able to copy/paste the existing XviD mencoder code to use two different .so files - one for decoding bad content (xvid/XVID) and another for encoding/decoding good content (rmp4/RMP4).

Does ffmpeg play "new" xvid interlaced correctly ? Buggy ones were refused -> cannot decode interlaced / frame broken ...

No idea. I hate compiling ffmpeg, I wish they'd given thought to non-*nix support. I believe it should work.

-h

[ma.hoff]

Okay, i checked out current cvs - how do i create the mixed version ?

I have tried to use an old version (from june) of decoder.c - but it won't compile anymore :-(
I guess this one was too old ...

So i took former version of decoder.c (just the one before your interlacing fixes) - but it won't compile then :-(

What do i have to change ?

Could you please send me a patch/diff ?

Martin

[-h]

To create a "bad" decoder, you just open decoder.c and find:

if (cbp || intra) {
mb->field_dct = BitstreamGetBit(bs);
DEBUG1("decp: field_dct: ", mb->field_dct);
}

Once you've found it, just comment out the if statement surrounding it, so it always reads the field_dct bit:

//if (cbp || intra) {
mb->field_dct = BitstreamGetBit(bs);
DEBUG1("decp: field_dct: ", mb->field_dct);
//}

Now you'll be able to play your old buggy content, but encode new bug-free content.

-h

[ma.hoff]

Okay, thank you !

Compiles just fine !

I'll try it with my files and try to exchange two libxvidcore.so versions ... I will report these days :)

Thanks for your support !

Martin

[ma.hoff]

Are you sure that i only have to comment out those few lines ?

Basically it works as expected - however the "buggy" decoder gives me some artefacts on some videos that the old version (xvid cvs from early june this year) did not have !

These artefacts remain over several frames - so they "smear" my video :(

If i switch back to my old libxvidcore.so i do not have these artefacts !

Any idea ?

Maybe its not interlacing specific - i cannot test this :(

Martin

[-h]

Basically it works as expected - however the "buggy" decoder gives me some artefacts on some videos that the old version (xvid cvs from early june this year) did not have !

You know what.. you're right! I forgot about the old interlaced edging behaviour, which expands frames (incorrectly) on a per-field basis instead of per-frame.

Here's what you have to do - the fix is in image.c. If you search for "interlacing", you'll find a function image_setedges() that has two identical sections of code commented out that concern interlacing. They look like this:

/* // if interlacing, edges contain top-most data from each field
if (interlacing && (i & 1)) {
memset(dst, *(src + edged_width), EDGE_SIZE);
memcpy(dst + EDGE_SIZE, src + edged_width, width);
memset(dst + edged_width - EDGE_SIZE,
*(src + edged_width + width - 1), EDGE_SIZE);
} else {*/
memset(dst, *src, EDGE_SIZE);
memcpy(dst + EDGE_SIZE, src, width);
memset(dst + edged_width - EDGE_SIZE, *(src + width - 1),
EDGE_SIZE);
/*}*/

Basically you want to remove the /* */ comments to re-enable the interlacing test and process. The code appears again only 20 or so lines down, and you need to uncomment it as well.

I completely forgot about this - sorry! That is all that I've altered in decoder behaviour to fix the bug.

-h

[ma.hoff]

Ahhh ! :)

Looks much better now ! :D

Thanks for your fast answer !

Martin

[ma.hoff]

Just another question comes up...

Is it intended that xvid crashes if i try to play old (buggy) interlaced content with the new iso decoder ?
At least mplayer crashes - sometimes at the first frame - sometimes there is at least 1 second video with totally scrambled colored blocks. Then mplayer crashes! Using NEW decoder (no changes to mplayer) works fine - so it seems to happen in the xvid code !?

Is this the way it's meant to be ? Shouldnt xvid simply refuse to decode the "buggy" stream and deliver black/green or pink picture - as most other decoders do ?
Couldn't this also happen if the stream is broken (e.g. scratched CD) ???

Martin

[-h]

Is it intended that xvid crashes if i try to play old (buggy) interlaced content with the new iso decoder ?
At least mplayer crashes - sometimes at the first frame - sometimes there is at least 1 second video with totally scrambled colored blocks. Then mplayer crashes! Using NEW decoder (no changes to mplayer) works fine - so it seems to happen in the xvid code !?

Unfortunately, while XviD has a fair bit of internal error checking for such cases, there isn't enough to catch a stream that's hopelessly flawed (like an invalid interlacing one is).

I might try to see where exactly it crashes (access violation I presume) and add a check for it.

Having the new version crash for old content will certainly notify people that there is a problem :)

-h

[ma.hoff]

Yeah,

however i would like if xvid itself would check for every kind of stream error and just display nothing (or black or whatever), but would not crash under these circumstances :)
I know that this isn't an easy task since all this is very complex!

So this was just an idea to improve xvid !


I might try to see where exactly it crashes (access violation I presume) and add a check for it.

If i can provide any help, please tell me !
However at the moment i have plenty of encoding to do (as you might know :D) so i have not much spare time right now ! But if you need any help to reproduce such crash, tell me !

Martin

[-h]

However at the moment i have plenty of encoding to do (as you might know :D) so i have not much spare time right now ! But if you need any help to reproduce such crash, tell me !

Oh I've created the crash plenty of times at my end :)

Also, have you tested your new XviD clips with ffmpeg? I would be interested in whether it likes the new code, or spits it out just because it has XviD's stream signature.

-h

[InfoCynic]

I just started using interlacing in XViD after reading about it for about 2 days straight on these and getting a massive headache. :) I have some source material (VOB) that's ugly as sin to try to deinterlace (heavily mixed Telecined FILM and Interlaced NSTC, hybrid deinterlacing with Decomb has produced bad results), so I encoded it in XViD using Interlaced mode after outputting a 29.970 fps .d2v.

Works great on my TV (I have a Radeon 8500, using S-Video out, ZoomPlayer 2.8). Obviously, it's not supposed to work right on a montior, but COULD it be done? I tried using an AVISynth script to run SeparateFields and then change the AR with Zoom, but it didn't look right, it stuttered in parts (CPU load wasn't an issue, I'm on an XP 1800+). I don't really care about the CPU cost involved, if my friends borrow the CD from me I'll warn them to use TV out or have a really fast CPU, but it would be awful nice to be able to use the monitor (because sometimes I need to put a clip on while I type up my algorithms homework :)).

Thanks.

[-h]

Works great on my TV (I have a Radeon 8500, using S-Video out, ZoomPlayer 2.8). Obviously, it's not supposed to work right on a montior, but COULD it be done?

Sounds like you want DScaler (http://deinterlace.sourceforge.net/).

-h

[Owen]

-h,

I did not know that Dscaler could play back .avi files through its deinterlace engine.

Can it do it now, or is this planned for the future?

Regards,

Owen.

[trbarry]

What is the status of the incompatible interlace fix?

I've been using Xvid with interlace and my own strange checkered interlace format to post some HDTV Samples on the AV Science Forum (see this thread over there (http://www.avsforum.com/avs-vb/showthread.php?threadid=161166).

But to do this I have to make sure people download a current version of Xvid to play them. Is the fix just in CVS, or in the various downloads available these days? (Nic's, Koepi's, Umanicac, ffdwhow?)

These are just samples and I don't care if they are long term compatible with anything but I'd like to encode them with whatever out there is most likely to play them now. And it seems that using Xvid with interlace gives me about a 10% compression edge due to some quirks of what I'm up to.

Re: DScaler - I don't think it's file playback or dshow deinterlace filters are quite ready yet. But I'm also working with Milan to put TomsMoComp deinterlacing into ffdshow. This might help some for VGA playback of XVID interlaced files, though it will not do IVTC.

- Tom

[-h]

What is the status of the incompatible interlace fix?

It's fixed in both branches of CVS, but I'm not aware of who has compiled it recently enough. Unfortunately it crashes when decoding old buggy content, I'll look into having it display a black screen of death when my new keyboard arrives. I'm not really aware of a way to detect if it's the interlacing bit that's crashing XviD though, since they're all just bits in a bitstream..

Re: DScaler - I don't think it's file playback or dshow deinterlace filters are quite ready yet. But I'm also working with Milan to put TomsMoComp deinterlacing into ffdshow. This might help some for VGA playback of XVID interlaced files, though it will not do IVTC.

Whoops, I was thinking it was something else. Doesn't sound like me at all :)

-h

[milan]

ffdshow now supports (thanks to libavcodec and especialy Michael Niedermayer) both XviD interlaced 'modes'. On misc. page in cfg dialog is new option "workaround bugs", where you can set if next played movie should be treated as old xvid interlaced video.
This changed was commited to CVS few minutes ago so no binaries yet.

[trbarry]

On misc. page in cfg dialog is new option "workaround bugs", where you can set if next played movie should be treated as old xvid interlaced video.

Milan, -h -

The Xvid forum seems to have disappeared and I have no idea how to get on the mailing list so let me try to sell you an idea here..

Xvid usually uses the fourcc pair xvid/XVID. But if ffdshow is going to keep some old compat code around for awhile maybe we could convince anyone who had old buggy interlaced Xvid clips to use the AVIC Fourcc changer utility and set them as something like xvid/XVIX or something agreeable.

The ffdshow could be set to use the old compatibility mode when encountering these. It would be a quick one time change to any clips like this, without reencoding. Other decoders could either honor this, or choose to refuse to play them, or (less desireable) choose to crash. ;)

Would this work?

- Tom

[MfA]

The xvid-devel mailing list website is at http://list.xvid.org/mailman/listinfo/xvid-devel

[milan]

@trbarry

I'm not sure if the "xvid/XVIX" idea can be implemented, because ffdshow obtains only one FOURCC and I'm not sure which one. Need to test it.
Much better would be autodetection. libavcodec is initialized only after first frame is available. So if there would be a way to detect xvid type depending on first frame, I could try to add automatic selection of proper bugs workaround option.

[-h]

Much better would be autodetection. libavcodec is initialized only after first frame is available. So if there would be a way to detect xvid type depending on first frame, I could try to add automatic selection of proper bugs workaround option.

Sadly not - interlaced intra blocks were encoded fine with the old core of XviD, it was inter blocks that had the problem, so you need at least 2 input frames to determine whether or not it's a good stream.

I assume libavcodec will throw an error when receiving a bad stream (as opposed to XviD going into meltdown), could the user be presented with an alert suggesting that they toggle the workaround bugs option?

-h

[milan]

I agree, some warning should be displayed (using OSD functions). More detailed description should be in the documentation (when it will be written :) ).

[trbarry]

Well, how about just a convention of renaming the fourcc's in the old ones "xbad" or something. I think some of the point is to stop them from crashing unaware players using the newer Xvid decoders, but ffdshow could maybe still recognize and process them and maybe some other players might also.

It's not like they have to be standard. We already know they are not. They are broken. But it would allow some folks to keep around clips that are otherwise going to do annoying things for years to come. And they would be easily identifiable just by looking at their attributes.

Anything that is put only into ffdshow doesn't help the other players so I was looking for a more general solution, though I'm not sure this is it.

- Tom

[ma.hoff]

@ -h

Also, have you tested your new XviD clips with ffmpeg? I would be interested in whether it likes the new code, or spits it out just because it has XviD's stream signature.


Now i could finally find the time to test - the result is very promising ... As far as i can test any interlaced mpeg4 created with the NEW xvid is just played back by ffmpeg (libavcodec) in linux mplayer without any problems or glitches ... :D

Time to change the topic of this thread to "good news for interlacing" :);)

Again may thanks to you ...

Martin

[milan]

Xvid usually uses the fourcc pair xvid/XVID. But if ffdshow is going to keep some old compat code around for awhile maybe we could convince anyone who had old buggy interlaced Xvid clips to use the AVIC Fourcc changer utility and set them as something like xvid/XVIX or something agreeable.


Now in ffdshow CVS.

[trbarry]

Hey, good news. :)

So, which fourcc invokes the old compat mode then?

- Tom

[milan]

XVIX, as was your first suggestion.

[trbarry]

Milan -

Okay, thanks. I've been posting some interlaced HDTV samples over in the AV Science forums and was anticipating when the folks there eventually upgraded to a new ffdshow or other Xvid decoder.

Now I've got something more useful to tell them, for anyone wanting to keep the samples around to compare. :)

- Tom

[ma.hoff]

Sorry to dig up this thread again :-)
But now i found the time to test ffmpegs implementation for the "buggy" xvid interlace files !
And guess what !?
The same problem i had with the xvid decoder (commenting out some lines to achieve old behaviour) occurs with ffmpeg !

Just read the 1st page opf this thread or my quote:



Basically it works as expected - however the "buggy" decoder gives me some artefacts on some videos that the old version (xvid cvs from early june this year) did not have !

You know what.. you're right! I forgot about the old interlaced edging behaviour, which expands frames (incorrectly) on a per-field basis instead of per-frame.

Here's what you have to do - the fix is in image.c. If you search for "interlacing", you'll find a function image_setedges() that has two identical sections of code commented out that concern interlacing. They look like this:

code:

/*// if interlacing, edges contain top-most data from each field
if (interlacing && (i & 1)) {
memset(dst, *(src + edged_width), EDGE_SIZE);
memcpy(dst + EDGE_SIZE, src + edged_width, width);
memset(dst + edged_width - EDGE_SIZE,
*(src + edged_width + width - 1), EDGE_SIZE);
} else {*/
memset(dst, *src, EDGE_SIZE);
memcpy(dst + EDGE_SIZE, src, width);
memset(dst + edged_width - EDGE_SIZE, *(src + width - 1),
EDGE_SIZE);
/*}*/

Basically you want to remove the /* */ comments to re-enable the interlacing test and process. The code appears again only 20 or so lines down, and you need to uncomment it as well.

I completely forgot about this - sorry! That is all that I've altered in decoder behaviour to fix the bug.

-h


Would be nice if one of the ffmpeg developers could adapt this to ffmpeg's decoder ...

Martin

[-h]

The same problem i had with the xvid decoder (commenting out some lines to achieve old behaviour) occurs with ffmpeg !

So ffmpeg isn't being buggy enough for the buggy streams :)

You could drop a note to the ffmpeg-devel mailing list if you'd like, but I'm not sure whether Michael will want to add even more workaround code for this.

-h

[ma.hoff]

You're right, but i think if it's implemented it should be implemented properly ;)

Martin

[milan]

Could you send me a sample? I would like to test it and if Michael won't modify libavcodec, maybe I could try to do it.

[-h]

Could you send me a sample? I would like to test it and if Michael won't modify libavcodec, maybe I could try to do it.

I just checked mpegvideo.c -> draw_edges_c() in latest ffmpeg cvs, and there is no field-based edging which the old buggy xvid clips require.

I would send code but I am looking for the libavcodec mpeg dequant bug I think exists (see cg matrix ffdshow bug thread).

-h

[-h]

Well since there's nothing more I can do about the matrix issue, here's some code for mpegvideo.c. I didn't add the if (workaroundbugs) code as I don't know the variables.

new code:

static void draw_edges_c(UINT8 *buf, int wrap, int width, int height, int w)
{
UINT8 *ptr, *last_line;
int i;

last_line = buf + (height - 1) * wrap;
for(i=0;i<w;i++) {
/* top and bottom */
if (i&1 || !workaroundxvidbug) {
memcpy(buf - (i + 1) * wrap, buf, width);
memcpy(last_line + (i + 1) * wrap, last_line, width);
} else {
memcpy(buf - (i + 1) * wrap, buf + wrap, width);
memcpy(last_line + (i + 1) * wrap, last_line - wrap, width);
}
}
/* left and right */
ptr = buf;
for(i=0;i<height;i++) {
memset(ptr - w, ptr[0], w);
memset(ptr + width, ptr[width-1], w);
ptr += wrap;
}
/* corners */
for(i=0;i<w;i++) {
if (i&1 || !workaroundxvidbug) {
memset(buf - (i + 1) * wrap - w, buf[0], w); /* top left */
memset(buf - (i + 1) * wrap + width, buf[width-1], w); /* top right */
memset(last_line + (i + 1) * wrap - w, last_line[0], w); /* top left */
memset(last_line + (i + 1) * wrap + width, last_line[width-1], w); /* top right */
} else {
memset(buf - (i + 1) * wrap - w, buf[wrap], w); /* top left */
memset(buf - (i + 1) * wrap + width, buf[wrap+width-1], w); /* top right */
memset(last_line + (i + 1) * wrap - w, *(last_line-wrap), w); /* top left */
memset(last_line + (i + 1) * wrap + width, last_line[width-wrap-1], w); /* top right */
}
}
}
There are cleaner (and faster) ways of doing it, but this is a quick show of how the code used to work. I haven't looked at the edging mmx, but can if you'd like.

-h