Recursive use of AviSource -- AviSource("file.avs") in 2.53

[jggimi]

I find that when I have a script that uses another script as the source ... for example, using an .avs script as input to Gknot ... there seems to be something that looks colorspace-wrong with the resulting video.

Eg: If I have a script that joins two .d2v projects
mpeg2source("part1.d2v")++mpeg2source("part2.d2v")and I use this as input to Gknot, the automated script produces what should be a legalavisource("both.avi").If I replace the AviSource() with my mpeg2source aligned splice line, the problem goes away. The problem also appears to occur when DirectShowSource() is used in the base script, also. It was reported by snowcrash in the GK forum: http://forum.doom9.org/showthread.php?s=&threadid=67958.

Info() says the AviSource is YV12, but I'm flummuxed as to what it is. If I force a different colorspace, or play with all the various SwapUV() variants, I cannot correct it. Nor can I make a good video stream appear like the stream in error using SwapUV() either.

I don't see this in the buglist at sourceforge, nor in the Q&A or FAQ at avisynth.org. I haven't found it mentioned in the AviSynth Usage forum, either. Granted, I'm not in AviSynth Usage daily, and my forum searches may have missed it.

Is it known? If so, I apologize for not being able to find mention of it.

If it has not been reported here before, can a brighter bulb than I am determine what filter set might correct it? That way I can report what the problem actually is to the sourceforge project bug list. Low priority, of course, since there's a simple circumvention to include the script rather than AviSource-ing it, but a bug nonetheless.

[Mug Funky]

please to post a screenshot?

i can't tell from your description what the problem actually is (the description doesn't make much sense to me, so i can't tell what the problem is).

[edit]

just thought some more aboot it, and it could be a problem of whatever VFW codec your machine is using to decompress YV12. a lot of codecs have probs with this.

paste the following text into a new text file and call it "yv12.reg", then run it.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
"vidc.YV12"="xvid.dll"

this will make xvid (or you could change it to something else) do the yv12 decompression.

[jggimi]

I'm sorry it's taken me so long to reply. I'm travelling, and have only limited access to the Internet (or to test sources).

I do have two clarifications. The image I was seeing appears now to have been a video adapter overlay problem; running the recursive script through an encoder produced solid green frames.

I've been able to create scripts that reproduce the problem, and it is colorspace related. RGB32 works fine, YV12 does not.a.avs:
colorbars(640,480)

b.avs:
avisource("a.avs")

c.avs:
colorbars(640,480).converttoyv12()

d.avs:
avisource("c.avs")Opening b.avs and then d.avs in Vdub(mod) will show that the b script in RGB works, whereas the d script in YV12 does not. If you add an Info() filter to d.avs, it shows the green screen in YV12.

[jggimi]

Well, after a couple of days with no further response, I'll open a bug report at sf.net. I did also test this with ConvertToYUY2(), and it is definitely YV12 specific.