green bar and color ghosting with non-mod16 heights

[mjl5007]

I'm hoping someone here can help me fix a problem I'm having. I've searched here and Google endlessly and haven't been able to find anything.

I have an x264-encoded clip in a Matroska container and the resolution is 1280x580, so the height is not mod16 (off by 4 pixels). When I play the .mkv file directly through mpc-hc (x86), it plays just fine. However, when I write an Avisynth script:

DirectShowSource("C:\Videos\theFile.mkv")

and load the .avs into mpc-hc (or Windows Media Player, or whatever), there's a wide horizontal green bar across the entire bottom of the clip, and the entire image has colored vertically-shifted ghosts, almost as if the image was separated into it's individual color channels, and some of the channels were shifted vertically while others were left in place.

I've run into this problem before, and I'm 99% certain it was with another clip with a non-mod16 resolution.

I'm on Windows 7 64-bit, have AviSynth 2.5 installed, and have the MPCVideoDec.ax filter from mpc-hc installed and set as the default H.264/AVC/x264 decoder for both 64- and 32-bit. Also using Haali Media Splitter if that makes any difference.

Any ideas on what's causing this, and/or how to fix it? I can post a screenshot of the issue if necessary.

[IanB]

Your direct show decoder is not correctly aligning the pixel data into memory. Try decoding to YUY2 format, add Pixel_Type="YUY2" to your DirectShowSource() call.

Also there is an updated DirectShowSource.dll, version 2.5.8.8 on SourceForge (http://sourceforge.net/projects/avisynth2/files/AviSynth%202.5/AviSynth%202.5.8/DirectShowSource_2588.zip/download) which has some special code to try and detect/correct for some of the more common misalignment bugs, maybe this will help.

[amfilica]

add boarder (08,70,08,70)
resize to (1280,720)

sorry not at home at the moment cannot help much

[mjl5007]

Adding pixel_type="YUY2" gives me an error message, "I don't know what YUY2 means", and adding borders/resizing doesn't help either.

One curious thing is that MediaInfo says the resolution is 1280x580, but adding Info() to the end of my script shows a resolution of 1280x592.

Here's a screencap just so we're clear what the issue is:

http://i45.tinypic.com/x25caw.png

Also, Version() shows AviSynth version 2.58.

[IanB]

DirectShowSource("C:\Videos\theFile.mkv", Pixel_Type="YUY2")

Also http://sourceforge.net/projects/avisynth2/files/AviSynth%202.5/AviSynth%202.5.8/DirectShowSource_2588.zip/download is a replacement DirectShowSource.dll plugin. Try it.

[mjl5007]

DirectShowSource("C:\Videos\theFile.mkv", Pixel_Type="YUY2")


Alright, now I'm confused. I tried exactly that before my last reply, and all I got was an error message video saying "I don't know what YUY2 means". Double-checked for typos/syntax, tried variations in casing, quotes and no quotes around YUY2, and kept getting the same message. I just tried it now, and it worked perfectly :rolleyes:. I still have the thinner solid lime green bar across the bottom, but I'm assuming that's the extra 12 pixels being added to the 580 height to make it mod16 (592)? I'm just cropping it off.

Anyway, thanks for the tip. If someone's got time, care to explain why changing pixel type from YV12 to YUY2 helped the problem?

[IanB]

For YV12 planar format the pixel data for the frame consist of all the Y channel data Width by Height pixels, followed by the V channel data Width/2 by Height/2, finally followed by the U channel data Width/2 by Height/2. The Direct Show API only has provision for specifying Width, Height and total bytes for the image. Typical fault with badly written decoders is to decode from their internal format which requires mod 2**N height and width and then specify the true width and height but then fail to repack the buffer accordingly. Thus where we expect to find V channel data we actually get the tail end of the mod 2**N Y channel data.

For YUY2 interleaved format the data for the frame consists of a Y channel value, a U channel value, next Y channel value, and then the V channel value. A total unit of 32 bits representing 2 pixels, this is repeated Width/2 by Height times to give a full frame. Given the interleaved data arrangement it in not possible to screw up the arithmetic in the active part of the picture, but of course you can still stuff the end of the frame.

It is possible to try and guess the alignment being used from the total bytes value if it is not equal to Width * Height * 1.5 as it should be for a YV12 image. The 2.5.8.8 DSS update tries for width being 32bit aligned, this is a quite common bug. Obviously I could try mod 8 and mod 16 alignments as possible other guesses for bad frame layout.

[XMEN3]

fixed with Matroska header editor, tool that can be found on mkvmerge...

in my example :
video pixel width :1024
video pixel height :464 (mod16)
display pixel width :1024
display pixel height : 426 (mod2)

Video is anamorphic encoded at 1024x464 but muxed as 1024x426 to keep aspect ratio.
Green bar appears usin' video pixel height, same as display height, 426 (non mod16)
Mkvmerge, when filling display width/height it wrongly put the same information on video width/height istead of the real one.
So i must edit the video resolution to 1024x464 as the video original resolution mod16 that has wrong aspect 2,20.
With display resolution of 1024x426 the video is displayed correctly with DAR 2,40.

before editor:
Codec ID V_MPEG4/ISO/AVC
Risoluzione 1024 x 426
Frame aspect ratio 512:213 = 2.403756
Pixel aspect ratio 1:1 = 1
Display aspect ratio 512:213 = 2.403756
Framerate 23.976025 fps
after editor:
Codec ID V_MPEG4/ISO/AVC
Risoluzione 1024 x 464
Display resolution 1024 x 426 (pixels)
Frame aspect ratio 64:29 = 2.206897
Pixel aspect ratio 232:213 = 1.089202
Display aspect ratio 512:213 = 2.403756
Framerate 23.976025 fps