avs2pipe

[doobry]

avs2pipe is a tool to output y4m video, wav audio, dump some info about the
input avs clip or suggest x264 blu-ray encoding settings.

Usage: avs2pipe [audio|video|info|x264] input.avs
audio - output wav extensible format audio to stdout.
video - output yuv4mpeg2 format video to stdout.
info - output information about aviscript clip.
x264bd - suggest x264 arguments for blu-ray disc encoding.


Download:

http://doobrymedia.com/avs2pipe-0.0.3.zip


It simply takes a path to an avs script that returns a clip with audio and/or
video and outputs it as a y4m (--video) or wav (--audio) stream to stdout. It
can also generate information about the clip (--info) in an easily parsable
format for gui's.

The advantage of avs2pipe over other solutions, other than it doing multiple
things in one and supporting more colorspaces is that it links directly with
avisynth.dll via the C interface, so it compiles with both Visual Studio and
MinGW and when used with wine in linux simply requires that the avisynth dll's
are in PATH, so no need to have vfw configured correctly. Also as it uses
WAVE_FORMAT_EXTENSIBLE for wav output and directly takes data from avisynth
it will output exactly the same data as avisynth uses internally.


Source is provided in the src folder and is released under the GPL-3.0.
In addition to the source is:

src\avisynth25 - header and link lib from AviSynth 2.5.8
src\avisynth26 - header from http://git.videolan.org/?p=x264.git;a=blob;f=extras/avisynth_c.h;hb=HEAD
link lib from AviSynth AVS 2.6.0 Alpha 2 [090927]


Projects and scripts to build the source are located in:

vs2010 - Project for Visual Studio 2010 Express
mingw - Batch file MinGW on Windows, sh script for MinGW under Linux


The YUV4MPEG2 output is inspired by Avs2YUV by Loren Merritt, it is basically
the same method, converted from C++ to C. The changes are:

Interlaced Support - Picks up the flags for interlaced content from
AssumeFieldBased(), AssumeTFF() etc. and will pass this
on to programs such as x264 eliminating the need to add
flags to the encoder command.

Extended Color Spaces - Thanks to Chikuzen when compiled against AviSynth 2.6
there is support for a whole host of extra colorspaces.


The WAV output is coded from scratch using specs from "the internet" and so
could be full of problems, altho I have not found any in testing yet.



Examples:

avs2pipe info input.avs
avs2pipe info input.avs > info.txt

avs2pipe video input.avs | x264 --stdin y4m - --output video.h264
avs2pipe audio input.avs | neroAacEnc -q 0.25 -if - -of audio.aac

avs2pipe audio input.avs > output.wav


Included Binaries:

avs2pipe_gcc.exe - compiled with MinGW gcc 4.5.2 on Windows
avs2pipe_vs.exe - compiled with Visual Studio 2010 Express cl 16.00.30319.01

avs2pipe26_gcc.exe - gcc compiled for AviSynth 2.6 Alpha 2
avs2pipe26_vs.exe - VS2010 compiled for AviSynth 2.6 Alpha 2


Changes:

Version 0.0.3 - Added Blu-Ray x264 command generator based on specs from
http://sites.google.com/site/x264bluray/
Added Support for new Colorspaces in AviSynth 2.6 with code
written by Chikuzen
Version 0.0.2 - Added Support for Interlaced Output, AssumeFieldBased etc.
Version 0.0.1 - Removed Progress Output for "Speed"
Pre-Alpha - Initial Release on doom10.org


Forum Links:

Original - http://doom10.org/index.php?topic=759
Doom9 Continuation - http://forum.doom9.org/showthread.php?t=160383

---

Hi,

Last year I wrote a little program called avs2pipe which combines avs2yuv and wav output into a single program.

The main advantage over the current solutions, and the reason I wrote it, is that it is in C and so can be compiled with gcc (mingw) under linux, or visual studio, and when used in a "wine" environment just requires the avisynth dlls to operate.

However I abandoned it as it worked for my task and no one really seemed that interested, but I just found people refering to it on google, so...

Is there anyone who would be interested in a newer build with the logging removed / optional to increase speed?

[Chikuzen]

Is there anyone who would be interested in a newer build with the logging removed / optional to increase speed?

Yes, of course :)

Because you did not reply to Underground78 (http://doom10.org/index.php?topic=759.msg5030#msg5030) for a long time, I thought that you had stopped that work.

[b66pak]

i am interested too..
_

[space1999]

I am interested too (+1) :)

BTW, does it already support channel-mapping AND "100%-compliant" Wave-Format-Extensible info? Because sometimes I have to use sox.exe for correcting the outputs from wavi.exe...

[smok3]

would be interested in ubuntu and especially OSX version.

[doobry]

ok i'll pull out the sources from my dead projects and get it checked and uploaded tomorrow.

as for the channel mapping, at the moment it doesn't remap any channels, but i wrote the wav output from scratch using the specs I found on the internet, so it should be "100%-compliant Wave-Format-Extensible", the urls for the specs should be in comments in the source, so if i can work out channel mapping it will not be hard to add it, the main challenge would be parsing the command line options, as the current method simply matches the first argument.

as for ubuntu and mac os x, assuming you have a working wine install, it should just work... you would only need mingw if you wanted to compile it yourself.

[tebasuna51]

A program like this don't need make channel mapping.
The channel mapping is a encoder/decoder job. There are enough AviSinth audio decoders than work fine.

@space1999
wavi works fine, maybe is a decoder problem, can you put some sample.

[space1999]

@tebasuna51

This is really weird, but I swear, some weeks ago, Media Player Classic refused to play a 3.0 WAV file written by wavi, but today, the same file is accepted fine,
:confused: :confused: :confused:

Anyway, here goes an example of the difference between the WAVs outputted by wavi and the WAVs rewritten by sox:

from wavi:

52 49 46 46 3C 61 52 01 57 41 56 45 66 6D 74 20
28 00 00 00 FE FF 03 00 80 BB 00 00 00 65 04 00
06 00 10 00 16 00 10 00 07 00 00 00 01 00 00 00
00 00 10 00 00 80 AA 00 00 38 71 9B 64 61 74 61
00 61 52 01 00 00 00 00 00 00 00 00 00 00 00 00

from sox:

52 49 46 46 3C 61 52 01 57 41 56 45 66 6D 74 20
28 00 00 00 FE FF 03 00 80 BB 00 00 00 65 04 00
06 00 10 00 16 00 10 00 00 00 00 00 01 00 00 00
00 00 10 00 80 00 00 AA 00 38 9B 71 66 61 63 74
04 00 00 00 80 65 38 00 64 61 74 61 00 61 52 01

[doobry]

@tebasuna51

the initial problem that I had was that all the audio 2 pipe type programs for avisynth did not "work fine", all the ones I could find were just vfw programs, or are written in .NET etc, which for me under wine was causing problems.

avs2pipe directly links with the avisynth.dll which solved me a lot of problems under linux and gives direct access to any avisynth stuff. As far as I can tell wavi etc just use vfw and so have no real idea about avisynth at all.

as for the channel mask, the support is "already" in there, it just sets the mask to 0 at the moment, so i could add wavi style support of just specifying the mask as an int at the command line, but that seems a little user unfriendly. a suggestion for how it should work from a users point of view is welcome. i could for example let people specify a variable in the avs script and pull it out.


@space1999

one of them programs is using a different endianness to the other for the subformat waveex field, which means one of them probably has a mistake in it.

next post should be the same thing as was on doom10, but without progress reporting...

[doobry]

Here is the zip file with the source, updated visual studio project files, a batch script to build it on windows using mingw and two pre built binaries...

http://doobrymedia.com/avs2pipe-0.0.1.zip

Comments and suggestions are more than welcome.

@tebasuna51

if you could have a look at the source for anything stupid I'd be grateful, the wav handling is mostly in wave.c and wave.h and is pretty heavily commented as I was trying to work it all out from the specs.

[doobry]

from wavi:

52 49 46 46 3C 61 52 01 57 41 56 45 66 6D 74 20
28 00 00 00 FE FF 03 00 80 BB 00 00 00 65 04 00
06 00 10 00 16 00 10 00 07 00 00 00 01 00 00 00
00 00 10 00 00 80 AA 00 00 38 71 9B 64 61 74 61
00 61 52 01 00 00 00 00 00 00 00 00 00 00 00 00

from sox:

52 49 46 46 3C 61 52 01 57 41 56 45 66 6D 74 20
28 00 00 00 FE FF 03 00 80 BB 00 00 00 65 04 00
06 00 10 00 16 00 10 00 00 00 00 00 01 00 00 00
00 00 10 00 80 00 00 AA 00 38 9B 71 66 61 63 74
04 00 00 00 80 65 38 00 64 61 74 61 00 61 52 01

Had a little look into this, and avs2pipe matches the endianess of sox, (80 00 00 AA...) so i'm guessing that there is a problem with wavi (00 80 AA 00...), or that myself and sox got it wrong.

Grabbed a sample from http://www-mmsp.ece.mcgill.ca/documents/audioformats/WAVE/Samples.html and it matches sox and myself, the endianess I think can be architecture specific, but as everything is running on x86/x64 I believe they should match.

[Chikuzen]

It seems that ver 0.0.1 is only support YUV420 on video.
Do you have any schedule for supporting other colorspaces (YUV422/YUV444) and latest YUV4MPEG2 format?

[doobry]

@Chikuzen

I have no schedule for supporting other colourspaces, as I have nothing to test against, i.e. samples, encoders, players, and have not seen the YUV4MPEG2 specs. However I'm more than willing to have a go at adding it if someone comes up with a way for me to test it, and some specs.

At the moment it simply adds a ConvertToYV12 filter to anything that is not YV12.

FYI, a quick google turned up http://wiki.multimedia.cx/index.php?title=YUV4MPEG2 is that what you mean by the new format?

Update: I've had a play and avisynth 2.58 doesn't support YUV422/YUV444 so I assume you are using 2.6, and if so where did you get it, and can you give me a link to the sources.

[Chikuzen]

FYI, a quick google turned up http://wiki.multimedia.cx/index.php?title=YUV4MPEG2 is that what you mean by the new format?

I think that latest format is this (http://linux.die.net/man/5/yuv4mpeg).
and you will be able to test about YUV422 by using rawsource.dll .
http://forum.doom9.org/showthread.php?p=1470266#post1470266

[doobry]

@Chikuzen

What version of avisynth are you using? and if its 2.6 can you point me to the source code.

[Chikuzen]

I'm using 2.6.0alpha2(x86) now. http://forum.doom9.org/showthread.php?t=149113
but that RawSource.dll is for 2.5.
2.6.0alpha is completely compatible with 2.5.6 or later.

If you want to develop for 2.6 or later, then see manao's code.
http://forum.doom9.org/showpost.php?p=1411605&postcount=473
it includes 2.6 header file.

[doobry]

From what I can tell avisynth 2.5 does not support YUV422/YUV444 colourspaces, so if i add support for them it will have to be for 2.6 only.

Had a look at the rawsource source code, and it seems to "mangle" for want of a better word the input into one of the 2.5 supported formats.

I'm not sure exactly what your requirement is, I assume you want to be able to output YUV422 video from avisynth and have avs2pipe provide it as YUV4MPEG2 output without any conversion? If that is the case could you provide me with a small sample of your input YUV4MPEG2 and avs script so I can have a play with it.

Thanks for the header link, but I need the c header avisynth_c.h and the .lib to link with, really I'd like to track down the cvs people are using, but the sourceforge one seems stale, and it seems 2.6 is mostly passed about via forum links to random hosts, which is not good if i'm trying to develop against it.

[Chikuzen]

ah, i understood what you say.
I must study how to write the code that convert YUY2 to Planar YUV422.

[doobry]

I'm pretty much willing to add any support that people want, provided I can do it, all I really need is a test case and samples so I can make sure it works.

Personally I don't have any current use for anything other than 420 as I've only got DVD / BluRay sources, but I can see how it could be useful, so I'm willing to stick it on the todo list and add some macro's to enable 2.5 & 2.6 builds. Altho in this case I'm kinda stuck without an updated C interface that has support for the colourspaces.

However this has all caused me to add interlaced video support to the YUV4MPEG2 header, which I'm testing now, means I can convert interlaced mpeg2 to interlaced h264 without specifing extra options to x264.

PS. When you learn how to "convert YUY2 to Planar YUV422" please share the info with me, I'm clueless on these formats.

[Gavino]

Thanks for the header link, but I need the c header avisynth_c.h and the .lib to link with, really I'd like to track down the cvs people are using, but the sourceforge one seems stale
Do you mean this? It looks active to me.
http://avisynth2.cvs.sourceforge.net/viewvc/avisynth2/avisynth/

and it seems 2.6 is mostly passed about via forum links to random hosts, which is not good if i'm trying to develop against it.
I don't know what forum links you are referring to.
Chikuzen posted the link to the current 2.6 release (see above).
Perhaps you are thinking about the various unofficial MT builds floating around.

[ganymede]

Is it possible to combine audio and video output ? If I could pass audio and video at the same time to mencoder or ffmpeg, it would be a big step forward for me, compared to avs2yuv.

[doobry]

@ganymede

There is no reason not to be able to combine the outputs provided there is a simple container format that can wrap the video and audio unmangled, that the target tool can accept via stdin, any suggestions?

[doobry]

@Gavino

What I mean by stale is that the latest release is from 2009, and I cannot find an updated avisynth_c.h header in the cvs that supports the new colourspaces I think 2.6 has.

And yes I am thinking of the unofficial builds, I'm new to all this, and I don't want to write something just to find out that everyone is actually using something different or that the work had already been done.

[Chikuzen]

oh doobry, did you think that I'm using 2.6.0MT :eek:
Then, it is a misunderstanding.
IMO, official 2.6.0alpha is more stable and faster than 2.5.8(not MT).
(I can't understand why IanB doesn't change alpha to latest stable :p)

[doobry]

doesn't really matter what version you are using at this stage, I cannot find an updated avisynth_c.h that contains support for the new colourspaces, so I'm going to leave it until I can find an "official" source.

[Gavino]

What I mean by stale is that the latest release is from 2009, and I cannot find an updated avisynth_c.h header in the cvs that supports the new colourspaces I think 2.6 has.
I think this has something to do with developments regarding 'baked code' - see this post.
Perhaps IanB can shed more light on the subject.

[doobry]

@Gavino

Thats exactly what I'm talking about, thank you!!! been unable to find that info myself, will give it a good read when I get some time.

[doobry]

I've uploaded version 0.0.2 which has added interlaced support, and adds a dump of avisynth's internal pixel_type field to the --info option, as I thought it might be of use to be able to see / post the value avisynth is presenting to the program.

http://doobrymedia.com/avs2pipe-0.0.2.zip

[Chikuzen]

thanks for updating.

BWT, there is a typo in line 37 of readme.txt
s/aac/mp4/g

[tebasuna51]

About Wavi.

Please read the pending bug http://sourceforge.net/tracker/?func=detail&aid=2957741&group_id=196137&atid=956250
From this page you can download the wavi.exe fixed.

[doobry]

@tebasuna51, that looks correct, i found that link to samples I posted earlier great for testing if things were working correctly by piping them though my code and checking they came out the same.

fyi can you confirm that wavi handles channel mapping my parsing an int from the command line and directly writing it into the header? From a brief look at the code that seems to be what it does, but I just wanted to make sure.

[kemuri-_9]

you can find the modified avisynth_c.h that x264cli uses here (http://git.videolan.org/?p=x264.git;a=blob;f=extras/avisynth_c.h;hb=HEAD)

which is good enough to support recognizing the newer 2.6 csps if that's all you need.
it's not complete enough to write a filter with to support the new csps however.

[ganymede]

There is no reason not to be able to combine the outputs provided there is a simple container format that can wrap the video and audio unmangled, that the target tool can accept via stdin, any suggestions?Good news. But are you sure that a container is needed, and that both audio and video cannot be output together as a raw data stream ?
It seems that ffmpeg and mplayer/mencoder can work with a raw data stream where audio and video are "mixed" (I don't know if it's the right word). For instance, I tested the following commands on my linux system :cat file | ffplay -
cat file | mplayer -
"file" was either in .avi, .mp4 or .flv container, and in all cases ffplay or mplayer were able to read it, with both audio and video (so I guess ffmpeg and mencoder would be able to process it).

[doobry]

.avi, .mp4 or .flv container

what you are doing works because the avi etc files are sent directly to ffplay etc, they are already containers... something is needed to tell the receiving application what is video, what is audio, and how they are encoded. The current version provides YV12 video in a YUV4MPEG2 "container" and PCM / FLOAT audio in WAV container. In theory it should be possible to say use an AVI container to send both, but that assumes that you can send raw YV12 data in an avi file stream written on the fly, ideally one frame at a time.

Basically I've not looked into it, but I can easily make it output both streams, the issue is doing it in a way that other programs can understand.

[ganymede]

what you are doing works because the avi etc files are sent directly to ffplay etc, they are already containers...Oops, you're right :rolleyes:
If it's not too complicated to embed YV12 video and PCM audio streams in an avi container, I guess it would do the trick.

[doobry]

I really should be in bed, but I've had a quick google and YV12 is a supported microsoft / apple FOURCC, so it should be possible, the only problems I see is the receiving program being willing to play the avi without random access, which should be ok if you can cat then in, and it ignoring the 4GB limit that avi's 32bit headers impose. The same limit applies to WAV files but the encoders I use ignore the header so work fine.

Will have a go next week.

[space1999]

@ tebasuna51:

thanks for the unb0rked :) build of wavi.exe

@ doobry:

if a container is really desirable/required, would be a big problem to use Matroska ? AFAIK MP4 does not support uncompressed audio (not "natively" anyway), and even though AVI currently has no filesize limit, one can never be "100%-sure" of which applications fully respect the OpenDML specs.

[ganymede]

@doobry : thank you very much.

[tebasuna51]

@tebasuna51,...
fyi can you confirm that wavi handles channel mapping my parsing an int from the command line and directly writing it into the header? From a brief look at the code that seems to be what it does, but I just wanted to make sure.

I'm not sure what ask you.

If is a wavi test, yes I make many test (because part of the code is from me) and I think work fine.

If is about your soft seems also work (gcc build tested), but:

- A minor info problem, the code seems ok:
avs2pipe [info]: writing 20 seconds of 0 Hz, 48000 channel audio.

- The Chunk 'fact' is not needed with WAVE_FORMAT_PCM/WAVE_FORMAT_IEEE_FLOAT.
The 'samples' data is always 'data_length'/'BlockAlign'

- The WAVE_FORMAT_EXTENSIBLE_HEADER is useless without a correct MaskChannel value.
AviSynth don't have a MaskChannel audio property, then decoders like NicAudio, than know the proper MaskChannel value, can't pass it to AviSynth.
And AviSynth can't pass the value to wavi/avs2pipe.
Wavi put a default value for each numchannels and accept a parameter to change the default.

[doobry]

A minor info problem, the code seems ok:

Thanks will try to work that out, clearly something is not right.


The Chunk 'fact' is not needed with WAVE_FORMAT_PCM/WAVE_FORMAT_IEEE_FLOAT.

I saw that it was not required with WAVE_FORMAT_PCM but the info i had was a little unclear on WAVE_FORMAT_IEEE_FLOAT, i.e. info said it was "needed when the samples are not WAVE_FORMAT_PCM", so I figured as it is allowed, Its best to include it just incase... altho it should never be needed.


The WAVE_FORMAT_EXTENSIBLE_HEADER is useless without a correct MaskChannel value.

It was my understanding that the spec included an "all zero" option for the mask that means the channels are mapped in order, ie first channel -> first output etc. As you said I cannot get a channel mask from avisynth, so I figured using this "blank" mask was the best option until I add a way to specify a mapping.

[Chikuzen]

ok, It seems that I succeeded in modifying avs2pipe for support other csps (require avisynth2.6.0α2) :D

avs2pipe260-0.0.2 (http://www.mediafire.com/download.php?glbg875ch4hx81q)
*Added support YUV444(YV24) / YUV422(YUY2/YV16) / YUV411 / Y8 colorspace Y4M output.

thanks to doobry and kemuri-_9 !

[ganymede]

(require avisynth2.6.0α2)It works for me (using wine on linux) with avisynth2.6.0α2, but not SEt's 2.6 MT. With 2.6 MT, output is empty (no data). Nice step forward, though.

[doobry]

ok, It seems that I succeeded in modifying avs2pipe for support other csps (require avisynth2.6.0α2) :D

avs2pipe260-0.0.2 (http://www.mediafire.com/download.php?glbg875ch4hx81q)
*Added support YUV444(YV24) / YUV422(YUY2/YV16) / YUV411 / Y8 colorspace Y4M output.

thanks to doobry and kemuri-_9 !

Yey that is fan fricking tastic, I totally missed the link from kemuri-_9 to that darned header I couldn't find, and now the work is basically done for me :D

Will try to roll the changes into my "master" version, can hopefully stick in a macro to enable support if requested, and slap your name in the comments.

@Chikuzen, where did you get the avisynth.lib link library? is it the one that i included in the original zip (2.5.8) or one from avisynth2.6.0α2? as I think SEt's 2.6 MT build did not include the link library, and I cannot find his source release for it...

[Chikuzen]

@Chikuzen, where did you get the avisynth.lib link library? is it the one that i included in the original zip (2.5.8) or one from avisynth2.6.0α2? as I think SEt's 2.6 MT build did not include the link library, and I cannot find his source release for it...

I got it from official 2.6.0α2 binary(extracted installer with 7zip).

I don't know where 2.6MT source code is because I lost the interest in MT after SEt disappears .

[doobry]

Well my version now in theory supports the new colorspaces, thanks to the header from kemuri-_9, so there are now 4 binaries, gcc and vs compiled against 2.5.8 and 2.6a2, just need something to test them with.

As for 2.6MT support, I am not going to bother, the latest source link I could find was just above a post detailing a bunch of bugs, so it seems I cannot get a link library for the MT version, and as something weird is clearly happening with it I'm not going to waste my time without the proper sources and libs.

Also coming in version 0.0.3, Blu-Ray encoding suggestions for x264, it looks at your avs script and picks the correct settings from http://sites.google.com/site/x264bluray/ to pass to x264... kinda pointless for most people but it lets me define everything in the avs file as I use batch files to encode.

[doobry]

New Version 0.0.3

http://doobrymedia.com/avs2pipe-0.0.3.zip

Changed the command line usage to remove "--" from the command arguments, as there can be only one command and if I add "options" later this will keep things neater.

Usage: avs2pipe [audio|video|info|x264] input.avs
audio - output wav extensible format audio to stdout.
video - output yuv4mpeg2 format video to stdout.
info - output information about aviscript clip.
x264bd - suggest x264 arguments for blu-ray disc encoding.

Added Blu-Ray x264 command generator based on specs from http://sites.google.com/site/x264bluray/

Added Support for new Colorspaces in AviSynth 2.6 with code written by Chikuzen

I messed around a little with how the colorspaces are handled to make it a bit neater for the macro to switch between 2.5 / 2.6 support, so their could be bugs as its not tested fully.

I do know that the 2.6 versions will prob hang under 2.5 and the 2.5 versions will hang under 2.6 if you try to use new features, but thats expected.

[ganymede]

I just tested avs2pipe26_gcc.exe with SEt's 2.6 MT under linux/wine... and it works ! Don't ask me why it does :p , but it's a good news for me.
Thank you guys for your work :thanks:

[doobry]

Speaking of weirdness... why does outputting both an I420 and YV12 colorspace result in exactly the same data... shouldn't AVS_CS_I420 be y-u-v planar, while AVS_CS_YV12 is y-v-u planar? As I'd coppied the method from avs2yuv I hadn't really spent too much time looking colorspace details, but thanks to Chikuzen I had to fire up google and look, and from what I found in theory the code should not have worked from day one as the u and v planes should have been swapped (its called YUV4MPEG2 and not YVU4MPEG2 afterall).

The avs2pipe code takes each plane and writes then out in the order that avisynth presents them... litterally a planes 1-3 for loop (well 0-2), given this shouldn't streams marked as AVS_CS_I420 give different output to AVS_CS_YV12? It would not be hard to swap the planes if needed, and it should be, but it seems that it "just works (tm)" when it really shouldn't.

So anyone with a bit more AviSynth knowledge know whats going on? Does AviSynth store all planar colorspaces in the same order in memory (y-u-v) and just set the pixel_type for reference of where its reordered data came from?

PS. The current download version (0.0.3) automatically adds a ConvertToYV12 filter to anything it doesn't understand, which includes AVS_CS_I420, obviously I've turned that off for AVS_CS_I420 on my current test version and told it to handle it exactly the same as AVS_CS_YV12.

[Gavino]

The avs2pipe code takes each plane and writes then out in the order that avisynth presents them... litterally a planes 1-3 for loop (well 0-2), given this shouldn't streams marked as AVS_CS_I420 give different output to AVS_CS_YV12? It would not be hard to swap the planes if needed, and it should be, but it seems that it "just works (tm)" when it really shouldn't.

So anyone with a bit more AviSynth knowledge know whats going on? Does AviSynth store all planar colorspaces in the same order in memory (y-u-v) and just set the pixel_type for reference of where its reordered data came from?
The planes (Y, U, V) are always numbered the same, independently of the order they are stored in memory, so if you always ask for them (via GetReadPtr()) in a given order, that's the order you will get.

However, I'm confused by your saying planes 0-2, since Y, U, V are numbered 1, 2 and 4.
enum {
PLANAR_Y=1<<0,
PLANAR_U=1<<1,
PLANAR_V=1<<2,
...

[doobry]

I'm a giant idiot... ofc they are requested by name (or at least a named constant), ffs, I have an array at the top to map the 0-2 from the for loop to the constants AVS_PLANAR_Y, AVS_PLANAR_U, AVS_PLANAR_V... so that the loop is simpler.

So basically AviSynth isn't braindead, and if you request AVS_PLANAR_U it gives you U no matter what the formats storage order may be...

This is what happens when you convert someone else's method, to ms's ancient c that requires all variables declared at the beginning of the functions body, then don't look at it for 6 months.

@Gavino thanks for the well aimed cluebat. PS GScript and GRunT look pretty fantastic, would you have any issues with me adding auto loading of scripts via GImport? I can see two easy ways, a) Just load all scripts via GImport if the function / dll is present, or b) trying to load it if the passed file is *.gscript (or similar). Do you have a preference?

I.E. You would be able to do avs2pipe video myscript.gscript and have it autoload the plugin and GImport the script...