Log in

View Full Version : Green vertical line to the left, or right...


MrPiercer
24th October 2007, 07:26
I often see a vertical green line/bar to the far left, or far right when I resize a video with LanczosResize or Lanczos4Resize to a given value.

Most often they disappear if I change the resize width +/- 4pixels, to it's not really a big deal, however I'm curious about why they appear, and if there are other ways to avoid them?

IanB
24th October 2007, 09:27
Let me guess:- You are using YV12 and DivX is your external YV12 codec.

If you add a ConvertToRGB() to the end of your script does the green go away?

If yes, the internal YV12 to RGB code inside your DivX (and some Xvid) is bugged for non mod 16 widths.

If you are using VirtualDub make sure the internal YV12 codec is enabled. For other apps find a better YV12 codec.

Most causes are to do with YV12 width handling.

MrPiercer
24th October 2007, 09:57
Yep, it's YV12 and DivX.. ;)
Next time I run into it, I'll try convert to RGB.

Thanks!

MrPiercer
24th October 2007, 20:01
If you add a ConvertToRGB() to the end of your script does the green go away?
Worked perfectly fine in two cases I've done today. Tip was really appreciated! Thank you!:goodpost:

Sagekilla
25th October 2007, 00:13
I don't mean to hijack this thread, but I actually encounter a very similar problem depending on what media player I'm using.

I encode using x264 and when I play the .mkvs back in VLC, I usualyl get a green bar to the far right. But, in mpc I don't get this at all. Is this in any way related? I always make sure to encode at a mod 16 resolution also (848x480 for example)

IanB
25th October 2007, 03:45
Problem is generally slack MMX code. MMX likes to access things in 8 byte chunks. In YV12 format the chroma planes are 0.5 the height and 0.5 the width of the video frame. So in order to make the chroma planes a multiple of 8 you need to make the overall width a multiple of 16.

In avisynth routines generally the code to deal with the odd 0 to 7 bytes of unalighned data is often more than the main code that deals with 8 byte chunks.

Also SSE2 code has the ability to deal with 16 byte chunks. So you may eventually find something that chokes on non multiple of 32 widths.