MPEG2 bad decoding?

[jkwarras]

Hi,

I don't really know if this is a question that concern avisynth, but i try anyway. When i encode DVD to DivX or XviD, the encoded file I have horizontal artifacts around edges that are very noticable in diagonal lines, it's more like an interlaced source look, but i deinterlace (using separate fields, select even).

So my question ot there is: the problem is caused by

- Graphic card or player (just updated drivers and use bsplayer or zoomplayer)

- The deinterlace method;

- The mpeg2dec3 filter for avysithn 2.5

Or it's just that we can get rid of those strange lines? :)

Thatks

IVan

[TelemachusMH]

What is the resolution that the output video is in? It is recommended that the video be a multiple of 16 for divx, and probably the same for xvid. I am not sure if this is entirely correct for xvid, but the reason for this is the way it is stored. Divx uses 16x16 pixel block areas and if you don't have a full 16 pixels the data isn't stored the same way, and does produce artifacts like what you are discribing.

TelemachusMH

[jkwarras]

Th resolution is multiple of 16, because i do the resize with Gordian Knot. For sometime i was thinking that the problem was the resize (simpleresize), so i try with bicubic, and lanczos, but still there, so i don't know what to think really :(

It's like the lines and the edges of images are not really well defined, like a little pixelated; It's really very noticable with text, maybe it's normal, i don't know, i will post a snapshot tomorrow see if you see what i'm talking about;

Thanks

Ivan

[frodoontop]

Are you sure the source is interlaced, because DVD2AVI says this all the time, while this isn't correct most of the time. You should try without interlacing to check if your file looks any better.

[trbarry]

When i encode DVD to DivX or XviD, the encoded file I have horizontal artifacts around edges that are very noticable in diagonal lines, it's more like an interlaced source look, but i deinterlace (using separate fields, select even).

Dunno if it will help but if you are using YV12 Avisynth 2.5 you might drop the separatefields/selecteven and just try YV12InterlacedSelectTopFields() that I recently wrote for this purposed. At the least it will be faster and it does adjust for a small YV12 chroma delay in what you are doing. That function is included in the YV12InterlacedReduceBy2.dll at:

www.trbarry.com/YV12InterlacedReduceBy2.zip (source and dll, test status)

- Tom

[sh0dan]

Post some screenshots, or perhaps a short AVI. Also include you script, and which versions you're using. We're kindda shooting in the dark here.

[jkwarras]

Froddontop:
>Are you sure the source is interlaced, because DVD2AVI says this all >the time, while this isn't correct most of the time. You should try >without interlacing to check if your file looks any better.

That was one thign i really didn't know!! I always do encodes from Pal DVD; so I guess most of the time they are not interlaced, that's it?

Tom:

>Dunno if it will help but if you are using YV12 Avisynth 2.5 you >might drop the separatefields/selecteven and just try >YV12InterlacedSelectTopFields() that I recently wrote for this >purposed. At the least it will be faster and it does adjust for a >small YV12 chroma delay in what you are doing. That function is >included in the YV12InterlacedReduceBy2.dll at:

Thaks, i will try as soon as i can :)

ShODan:

>Post some screenshots, or perhaps a short AVI. Also include you >script, and which versions you're using. We're kindda shooting in >the dark here.

Sorry, I will post some screenshots or maybe an avi as soon as i can, maybe tomorrow; I know is really shooting in the dark :p
Thanks all!!

Ivan

[jkwarras]

Ok, there's an avi: It's taken from Paris, Texas; Watch out the edges in the car's window and the cigarrete, you can really see the problem that i mentioned; IS around 2 MB.

http://www.arkania.org/jkwarras/vid/prueba.avi

The AVS script i used: don't have it right now, but

- MPEG2dec3.dll from MArcDF without any postprocessing
- separatefields; select even for deinterlace
- Fastbilinearresize from bicublinresize.dll (trying normal methods like simpleresize or bicubicresize or bilinearresize, and even lanczos resize don't resolve anything to me)
- Crop is even and multiple of 2.
- Resize is multiple of 4.
- YV12 and Avisynth 2.5

Thanks people

Ivan

[jkwarras]

Sorry, you have to do "save link as" to download, else you will get an error from the server :)

[sh0dan]

OK - I watched it 5 times before I re-read your post, to see what was wrong with it.

There is actually nothing wrong with it, except separatefield is a very tough way of deinterlacing - as in this example it leaves aliasing because you remove the information lying inbetween.

I you only resize horizontally, the resizer will not have much influence on the result.

Do a full-frame deinterlace: Use field-deinterlace, or something similiar to restore progressive frames, and resize after this. This will remove most aliasing, especially if blend=true, or using a soft resizer.

Otherwise do a verticalreduceby2() instead of separate/selecteven. Will result in a blurrier image, but will probably reomve the aliasing.

[manono]

Hi-

If it just has the shifted fields problem common with PAL DVDs, then Telecide(Guide=2) by itself (no Decimate) will take care of it. It's worth a shot, before ruining it by just deinterlacing.

And as frodoontop mentioned, if you decided it was interlaced based on what DVD2AVI told you, then it lies a lot about such things.

[jkwarras]

Very thanks to you all :)

[jkwarras]

Originally posted by trbarry
Dunno if it will help but if you are using YV12 Avisynth 2.5 you might drop the separatefields/selecteven and just try YV12InterlacedSelectTopFields() that I recently wrote for this purposed. At the least it will be faster and it does adjust for a small YV12 chroma delay in what you are doing. That function is included in the YV12InterlacedReduceBy2.dll at:

www.trbarry.com/YV12InterlacedReduceBy2.zip (source and dll, test status)

- Tom

I've just tried it. Works good, as fast as separatefields().select even and really less deinterlace artifacts.

Only one issue, it seems to work badly with certain resolutions, just after doing the crop; I'll post soon the avs script, but i think this was with a resolution of 696*xxx (after croping and before resize); It produce a big vertical green line at the left of the video with YV12IntrlacedSeectTopFields(); when using just reducedby2 with the filter it produced not green line, but an strange vertical at the same place.

To avoid that i have to put YV12IntelacedSeectTopFields() before the crop; It solve the green line problem. BUt at surprise it produces a realy smaller filesize for the same clip with same parameters; Before crop: 1,7 MB, after crop:3 MB; for a 30 seconds video;

[trbarry]

jkwarras -

I am cursed by green lines at the right in many of my filters since most of my MMX code processes at least 8 pixels per instruction and I always add the boundary condition stuff after everything else is done. So I may have forgotten it again, and will fix it.

But to save time please post your script first.

- Tom

[jkwarras]

Originally posted by trbarry
jkwarras -

I am cursed by green lines at the right in many of my filters since most of my MMX code processes at least 8 pixels per instruction and I always add the boundary condition stuff after everything else is done. So I may have forgotten it again, and will fix it.

But to save time please post your script first.

- Tom

Ok, that was at the right of the video; sorry for the mistake, and definetly it was with 696*xxx resolution after resize, but the strange thing, with one video it have produce putting YV12IntelacedSelectTopFields() after the crop abd before the resize, and on another just the inverse, putting the instruction before the crop and the resize, anyway, moving it solve the problem;


-------------------
-------------------
Crop(-10,-4,696,*)
YV12IntelacedSelectTopFields()
FastBilinearResize(512,*)
Undot()
Limiter()
-------------------
-------------------
Sorry, when *; i mean i don't remember the exact number;

[sh0dan]

@trbarry:

The problem is, that you crop off the rowsize, by bitshifting.

You could fix YV12InterlacedReduceBy2 by simply requesting an aligned rowsize, since you process max 8 pixels in parallel.

YV12SelectTopFields is a bit more tricky, since you process 16 pixels per loop.

You could either change it to do 8 pixels per loop (which I believe will only have minimal influence, since the algorithm seems largely memory limited.

The other solution is to simply let it process too far. As the pixels are overwritten by the next row being processed, no harm is really done. On the other hand the last line could write 8 bytes out-of-bounds. You could either ignore this, or make a special loop for that case.

On another issue: I noticed you use movntq in your ISSE routines, I also did this in the conversion routines I made lately, but I found out that they perform horribly. When I replaced them with movq's I got a significant (measurable) speedup of several percent.
It seems movntq is only suited for direct memory copies - otherwise the penalty is simply too big.

[trbarry]

Sh0dan -

Thanks. That should be enough for me to go fix it. I often shift to get the count to make a tight loop but I have a "spare change" test to decide whether to handle any excess at the end separately. In this case that was busted (test eax,3). It'll be a 1 instruction change.

I'm surprised at your movntq results. For me on both P3's and P4's it has always seemed faster as long as things were aligned to at least 8 bytes and I wasn't subsequently reading it back in soon. But maybe it is machine dependent. What hardware were you testing this on?

- Tom

[sh0dan]

A followup in the dev. section (http://forum.doom9.org/showthread.php?s=&threadid=48413).