Avisynth+

[pinterf]

I'm having a lot of problems with this version on both vdub 1.10 and vdubFM, even with the simplest script, namely, "Version()" AVI: Opening file "E:\Data\Downloads\_test.avs"

[i] AVI: Avisynth detected. Extended error handling enabled.

Beginning dub operation.

[i] Dub: Input (decompression) format is: RGB888.

[i] Dub: Output (compression) format is: RGB888.

Ending operation.

[E] Error: Avisynth read error:
Avisynth: script open failed!

I loaded the Version script and selected File, Run video analysis pass to check framerate. I suspected a problem because another movie I had opened with both FFMpegSource and LibAVSource played verrry slowly and then crashed.[E] Error: Avisynth read error:
Could not allocate video frame. Out of memory. memory_max = 536870912,
memory_used = 3686451 Request=3686431
(E:\Data\Downloads\_misc.avs, line 1023)

I can see that memory consumption is growing frame by frame when serving vdub. Something leaks in outputting through VfW... Checking.

[yup]

Hi pinterf!
:thanks: for new release.
I am waiting Y16 support in Imagereader.
I am updating Avisynth, plugins64+ and Devil.dll.
Script simple
ImageSource("film7 1.png", start=1, end=1, use_DevIL=true, pixel_type ="Y16")
When open in VirtualDub (shekh mod) I see colour image. I am testing tif and png files.
Please advice.
When I added string ConverttoRGB64() I see grayscale image.
yup.

[pinterf]

Memory leak found, I'll release the fix soon.
@yup: For me, Y16 is read correctly, but needs to be converted to YUVxxx or RGB64

[pinterf]

Hotfix is out, thanks for the patience.

Avisynth Plus r2489-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2489-MT)

20170529 r2489
- fix: memory leak in CAVIStreamSynth (e.g. feeding vdub)
- fix: ConvertToY for RGB64 and RGB48

20170528 r2487
- Blur, Sharpen 10-16 bits planar and RGB64: SSE2/SSE4 (2x-4x speed)
- New script function: int GetProcessInfo([int type = 0])
Without parameter or type==0 the current bitness of Avisynth DLL is returned (32 or 64)
With type=1 the function can return a bit more detailed info:
-1: error, can't establish
0: 32 bit DLL on 32 bit OS
1: 32 bit DLL on 64 bit OS (WoW64 process)
2: 64 bit DLL
- Fix: Blur width=16 (YV12 width=32)
- Fix: Overlay Lighten: artifacts when base clip and overlay clip have different widths (regression since r2290)
- Fix: YUY2 HorizontalReduceBy2 did nothing if target width was not mod4
- ImageReader: 16 bit support; "pixel_type" parameter new formats "RGB48", "RGB64" and "Y16"
- ImageWriter: 16 bit support; save RGB48, RGB64, Y16, planar RGB(A) 8 and 16 bit formats
(note: greyscale through devIL can be corrupt with some formats, use png)
- ImageWriter: flip greyscale images vertically (except "raw" format)
- SubTitle: new parameter "font_filename" allows using non-installed fonts
- (project can be compiled using gcc)
- Allows opening unicode filenames through VfW interface (virtualdub, MPC-HC)
- Script function Import: new parameter bool "utf8" to treat the filenames as UTF8 encoded
(not the script text!)
- SubTitle: new parameter bool "utf8" for drawing strings encoded in UTF8.
Title="Cherry blossom "+CHR($E6)+CHR($A1)+CHR($9C)+CHR($E3)+CHR($81)+CHR($AE)+CHR($E8)+CHR($8A)+CHR($B1)
SubTitle(Title,utf8=true)
- New script functions: ScriptNameUtf8(), ScriptFileUtf8(), ScriptDirUtf8(),
they return variables $ScriptNameUtf8$, $ScriptFileUtf8$ and $ScriptDirUtf8$ respectively

[pinterf]

The way MT is implemented is a mess, and several things aren't working right now.

Any reason why it couldn't be using a simpler design with a thread pool similar to VapourSynth, instead of trying to predict the future with a magic ball and micro-managing the way there?
Probably the only reason that this is a project done in our free time.

[Groucho2004]

@pinterf
I have another suggestion in addition to the bitness function you added which is just as easy to implement.

When you use "LoadPlugin" on a 64 bit plugin from a 32 bit avisynth.dll (and vice versa), the error thrown is "There is no function named..." which can be misleading even for experienced users. Using the determined bitness of avisynth.dll, you could add this function to check the bitness of the plugin and throw the appropriate error if there is a mismatch:
BOOL Is64BitDLL(std::string sDLL, BOOL &bIs64BitDLL)
{
bIs64BitDLL = FALSE;
LOADED_IMAGE li;

if (!MapAndLoad((LPSTR)sDLL.c_str(), NULL, &li, TRUE, TRUE))
{
//error handling (check GetLastError())
return FALSE;
}

if (li.FileHeader->FileHeader.Machine != IMAGE_FILE_MACHINE_I386) //64 bit image
bIs64BitDLL = TRUE;

UnMapAndLoad(&li);

return TRUE;
}

[pinterf]

@pinterf
I have another suggestion in addition to the bitness function you added which is just as easy to implement.

When you use "LoadPlugin" on a 64 bit plugin from a 32 bit avisynth.dll (and vice versa), the error thrown is "There is no function named..." which can be misleading even for experienced users. Using the determined bitness of avisynth.dll, you could add this function to check the bitness of the plugin and throw the appropriate error if there is a mismatch:

LoadPlugin function is already throwing an exception.
Are you proposing that during plugin autoloading, if any mismatch is found, exception should be thrown immediately?

[LigH]

I believe the idea here is not just "throwing any exception", but "throwing a specific 'wrong bitness' exception which can be handled according to its type". Maybe.

[yup]

@yup: For me, Y16 is read correctly, but needs to be converted to YUVxxx or RGB64
Problem related with VirtualDub which do not show all available colorspace in Avisynth+.
ConvertToRGB64 in last string script help.
yup.

[Groucho2004]

LoadPlugin function is already throwing an exception.
If I use an implicit "LoadPlugin" in the script it does indeed throw "%1 is not a valid Win32 application".
If I put the 64 bit plugin in the auto-load directory and call one of its functions in the script it throws "there is no function named...".

I have not looked at the plugin manager code but I thought the auto-load enumeration at the start would call "LoadPlugin" on each plugin which does not appear to be the case.

Anyway, even the "%1 is not a valid Win32 application" message is a bit cryptic for many so I think it might be a good idea to have it throw a clear error message.

Are you proposing that during plugin autoloading, if any mismatch is found, exception should be thrown immediately?If the user doesn't call a function from the "wrong" DLL, everything will be fine. However, I would still check for any potential problems during the auto-load enumeration.

[pinterf]

Anyway, even the "%1 is not a valid Win32 application" message is a bit cryptic for many so I think it might be a good idea to have it throw a clear error message.


This is the source or error message:
// Load the dll into memory
plugin.Library = LoadLibraryEx(plugin.FilePath.c_str(), 0, LOAD_WITH_ALTERED_SEARCH_PATH);
if (plugin.Library == NULL)
{
if (throwOnError)
{
DWORD errCode = GetLastError();
Env->ThrowError("Cannot load file '%s'. Platform returned code %d:\n%s", plugin.FilePath.c_str(), errCode, GetLastErrorText(errCode).c_str());
}
else
return false;
}



If the user doesn't call a function from the "wrong" DLL, everything will be fine. However, I would still check for any potential problems during the auto-load enumeration.
Only the function name is known, but we don't know, which DLL should be loaded. After autoloading and the function is still not found, Avisynth+ can't tell which was the failing plugin exactly, maybe just in general: during autoload there were problems with some DLLs.

[pinterf]

Problem related with VirtualDub which do not show all available colorspace in Avisynth+.
ConvertToRGB64 in last string script help.
yup.
Most of the color spaces unavaliable on VfW interface are autoconverted, such as Planar RGB 10 bit autoconverted to 16 bit RGB64, 12 bit YUV is autoconverted to 16 bits.
10+bit greyscale is an exception, it is not autoconverted at all.

[Groucho2004]

This is the source or error message:
// Load the dll into memory
plugin.Library = LoadLibraryEx(plugin.FilePath.c_str(), 0, LOAD_WITH_ALTERED_SEARCH_PATH);
if (plugin.Library == NULL)
{
if (throwOnError)
{
DWORD errCode = GetLastError();
Env->ThrowError("Cannot load file '%s'. Platform returned code %d:\n%s", plugin.FilePath.c_str(), errCode, GetLastErrorText(errCode).c_str());
}
else
return false;
}
OK, I looked at the auto-load code and now I know why it doesn't throw the same error during enumeration:

void PluginManager::AutoloadPlugins()
{
...
// Try to load plugin
AVSValue dummy;
LoadPlugin(p, false, &dummy);
...
}

[tuanden0]

I got this error when use Imagewriter filter after update AVS+ 2489
System exception - Accsess Violation
(E:\Download\makeimagesequence.avs, line 6)

Here's my script:
LWLibavVideoSource("E:\Download\FF8.mkv")
AssumeFPS(24000, 1001)
Spline64ResizeMT(848, 480)
Trim(14583,14702)
ConvertToRGB()
ImageWriter("E:\Download\gif", type="png")

[Groucho2004]

I got this error when use Imagewriter filter after update AVS+ 2489

Try this:
ImageWriter("E:\Download\gif\%09d.png", type="png")

[pinterf]

I got this error when use Imagewriter filter after update AVS+ 2489

Bug. ImageWriter is searching a dot for getting the extension in the filename, and since the dot does not exist, the check fails with that nice AV error. I'll fix it. (The extension comes from another parameter. The extension check is new, because if 'raw' is found then it does not flip the image upside down)

And in the meanwhile with a magic '//' I have probably healed the infamous MT_SERIALIZABLE problem (which was intended to optimize the speed of the script a bit).

So there will be a new release in some days.

[tuanden0]

@Groucho2004: :thanks: IT's work now :D

@pinterf: luv you :D

[pinterf]

And what about raising the default max memory to 4Gbytes on x64? Of course with the already existing physical memory constraints. 4g but max 1/3? of phys. RAM? I'm from mobile, not sure in one third.

[Groucho2004]

And what about raising the default max memory to 4Gbytes on x64? Of course with the already existing physical memory constraints. 4g but max 1/3? of phys. RAM? I'm from mobile, not sure in one third.I'm wondering if we even need SetMemoryMax(). Can this not be done dynamically depending on script requirements, possibly with a warning if Avisynth tries to allocate more than a certain percentage of the available memory?

[pinterf]

OK, I looked at the auto-load code and now I know why it doesn't throw the same error during enumeration:

So the final question: should we force users to keep their autoload directories logical and clean, containing only 32 or 64 bit DLLs, and report a friendly exception immediately upon startup, or keep the existing behaviour?

For manual LoadPlugin I have applied the checking you have proposed to give a clean error message
avs [error]: Cannot load a 32 bit DLL in 64 bit Avisynth: 'c:/Test20160220/dll32mix64/etwas32.dll'

[Groucho2004]

For manual LoadPlugin I have applied the checking you have proposed to give a clean error message
avs [error]: Cannot load a 32 bit DLL in 64 bit Avisynth: 'c:/Test20160220/dll32mix64/etwas32.dll'
OK, but does Avisynth throw the same error when a user tries to use a function from a plugin that does not have the correct bitness?

So the final question: should we force users to keep their autoload directories logical and clean, containing only 32 or 64 bit DLLs, and report a friendly exception immediately upon startup, or keep the existing behaviour?
The answer to this is connected to my question above. If the bitness check is omitted during auto-load enumeration, the same cryptic message will be thrown ("no function named...") and the user is confused since he/she sees the DLL in the auto-load directory but it won't work.

[LigH]

So the final question: should we force users to keep their autoload directories logical and clean, containing only 32 or 64 bit DLLs, and report a friendly exception immediately upon startup, or keep the existing behaviour?

AviSynth+ supports separate autoload directories per bitness. But people sometimes make mistakes, thus a sensible, specific, and verbose error message will help debugging in case of mistakes.

[stax76]

should we force users to keep their autoload directories logical and clean

I vote for yes.

[amayra]

The way MT is implemented is a mess, and several things aren't working right now.

Any reason why it couldn't be using a simpler design with a thread pool similar to VapourSynth, instead of trying to predict the future with a magic ball and micro-managing the way there?

i already mentioned this problem in AvsFilterNet about MT after i tested in the first time
i think C++ not designed to deal with thread in in general leave alone Avisynth
new programming languages is different stores
PS: please correct me if i am wrong

[Groucho2004]

i think C++ not designed to deal with thread in in generalApart from the statement being nonsense, how did you come to that opinion?

new programming languages is different stores "New" programming languages are simply a different layer of abstraction of the underlying OS API and allow faster development which is important when you're working in a professional environment.

If you need fast code there is still nothing better than C/C++/ASM.

As a side note, since you mentioned AvsFilterNet, bringing the .NET monstrosity into Avisynth plugin development is just blasphemy. :sly:

[TheFluff]

i already mentioned this problem in AvsFilterNet about MT after i tested in the first time
i think C++ not designed to deal with thread in in general leave alone Avisynth
new programming languages is different stores
PS: please correct me if i am wrong

The fundamental reason Avisynth's multithreading is so broken is that people insisted on trying to shoehorn it into the existing API, which is highly unsuited for a multithreaded environment. It's not bad because it's written in C++, it's bad because there's a ton of complexity and hacked-up code piled up in an attempt to shove a square peg into a round hole.

In the Avisynth API every single function call is synchronous and blocking, and that's exactly what you don't want in a multithreaded environment (it makes scheduling and cooperating around shared resources really obnoxious and difficult). There are many different mechanisms for designing asynchronous API's, and while C++ doesn't have some of the fancier ones that some higher level languages do (for example promises/futures, the async/await keywords, etc) I always found that while simple callback-based interfaces tend to tempt lazy programmers into writing spaghetti code, they are simple, work in most languages and are easy to reason about and understand.

[mcjordan]

I've a problem. Dear pinterf, help me!
Last night I compiled a 2500 build, but today...
See screenshot below:
https://postimg.org/image/772vwju35/

[pinterf]

Try deleting CMakeCache.txt and do it again?

[mcjordan]

Yes. But cmake configured to generate project for VS2017 not working anymore (аs opposed to earlier). For VS2015 - working.

P.S. Hmmm... After updating Visual Studio to version 15.2 26430.12 all working again as before...
I'm confused. Sorry for disturbance.

[pinterf]

New build.

Download Avisynth+ r2502 (https://github.com/pinterf/AviSynthPlus/releases/tag/r2502-MT)

20170602 r2502
- fix: (Important!) MT_SERIALIZED mode did not always protect filters (regression since r2069)
Such filters sometimes were called in a reentrant way (like being MT_NICE_FILTER), which
possibly resulted in using their internal buffers parallel.
- Fix: ImageWriter crash when no '.' in provided filename
- Fix: Overlay: correct masked blend: keep exact clip1 or clip2 pixel values for mask extremes 255 or 0.
Previously 0 became 1 for zero mask, similarly 255 changed into 254 for full transparency (255) mask
- New: script functions: StrToUtf8, StrFromUtf8: Converting a 8 bit (Ansi) string to UTF8 and back.
- New: PluginManager always throws error on finding wrong bitness DLL in the autoload directories
- Modified: increased x64 default MemoryMax from 1GB to 4GB, but physicalRAM/4 is still limiting
- Modified: allow conversions between RGB24/32/48/64 (8<->16 bits) w/o ConvertBits
- Added VS2017 and v141_xp to CMakeList.txt


Please report if this build fixed any of your unexplainable problems, image corruptions, that happened only in MT mode.

[tuanden0]

@pinterf:
I got this error from avs+ 2502. The AVSP said some 64bit filters were 32bit and AVSmeter can't get info from the avsisynth.
Then, I getback to 2489 and everything works again.

avs+ 2502: http://i.imgur.com/QfyD2Ux.png

avs+ 2489: http://i.imgur.com/jmSX2Es.png

[real.finder]

last build (r2502) didn't work in xp, test done by using VirtualBox

[tuanden0]

last build (r2502) didn't work in xp, test done by using VirtualBox

I'm using windows 7 64bit, Sir :D

[sneaker_ger]

@pinterf:
I got this error from avs+ 2502. The AVSP said some 64bit filters were 32bit and AVSmeter can't get info from the avsisynth.
Then, I getback to 2489 and everything works again.

avs+ 2502: http://i.imgur.com/QfyD2Ux.png

avs+ 2489: http://i.imgur.com/jmSX2Es.png
Delete the two .dll files. In the past they just wouldn't be loaded even if there was no error message.

[Groucho2004]

@tuanden0
Could you please upload the VSFilter.dll from your second screen shot somewhere?

[Groucho2004]

last build (r2502) didn't work in xp, test done by using VirtualBoxThe 64 bit build does work (XP64) but there's something wrong with the 32 bit version, I'm getting random exceptions.

[real.finder]

I'm using windows 7 64bit, Sir :D

seems there are confuse, I report that to pinterf :)

[Groucho2004]

In the past they just wouldn't be loaded even if there was no error message.Yes, but AVSMeter would have thrown the error instead. Also, look at the second screen shot, there is only one plugin listed. Something's weird.

Edit: @tuanden0: The complete AVSMeter logs would help find the problem (AVSMeter -avsinfo -log).

[tuanden0]

@tuanden0
Could you please upload the VSFilter.dll from your second screen shot somewhere?

@Groucho2004:
Here is it :D I take it from test server of MeGUI :D
http://megui.tmebi.de/test/vsfilter.1.5.0.2827_x64.7z

If I use AVSmeter to write a log with avs+ 2502, the program said cannot load filter until I deleted all 32b and 64b filter folders?
Then, after deleted filter folder, i have a logs

[Groucho2004]

If I use AVSmeter to write a log with avs+ 2502, the program said cannot load filter until I deleted all 32b and 64b filter folders?I highly doubt that it says to delete folders. You're supposed to remove the 64 bit DLL(s) from the 32 bit plugin folder(s) and the 32 bit DLL(s) from the 64 bit plugin folder(s).

Also, post the logs somewhere else. It could take a long time before the attachment is approved.

[pinterf]

I'm on the XP problem, so far no success.
EDIT:
Arggh. It was a compiler setting problem: /Zc:threadSafeInit- was missing.

But now I see what happens.
During autoload, these DLLs called GetCPUFlags in their Init, after AddFunction and caused Avisynth+ to crash.

VerticalCleanerSSE2.dll
RepairSSE2.dll
RemoveGrainSSE2.dll
RemoveDirtSSE2.dll
SSE2Tools.dll


e.g. in old RemoveGrain source
extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env)
{
#ifdef MODIFYPLUGIN
env->AddFunction("Repair", "cc[mode]i[modeU]i[modeV]i[planar]b", CreateRemoveGrain, 0);
env->AddFunction("TemporalRepair", "cc[smooth]i[grey]b[planar]b", CreateTemporalRepair, 0);
#else // MODIFYPLUGIN
env->AddFunction("RemoveGrain", "c[mode]i[modeU]i[modeV]i[planar]b", CreateRemoveGrain, 0);
env->AddFunction("Clense", "c[grey]b[reduceflicker]b[planar]b[cache]i", CreateClense, 0);
env->AddFunction("MCClense", "ccc[grey]b[planar]b", CreateMCClense, 0);
env->AddFunction("BackwardClense", clenseargs, CreateBackwardClense, 0);
env->AddFunction("ForwardClense", clenseargs, CreateForwardClense, 0);
#endif // MODIFYPLUGIN
AVSenvironment = env;
if( (CPUFLAGS & env->GetCPUFlags()) != CPUFLAGS )
#if ISSE > 1
env->ThrowError("RemoveGrain needs an SSE2 capable cpu!\n");
#else
env->ThrowError("RemoveGrain needs an SSE capable cpu!\n");
#endif
#if 0
debug_printf(LOGO);
#endif
return "RemoveGrain: remove grain from film";
}

The GetCPUFlags gave access violation.

From the two debug lines in GetCPUFlags, only the first one was displayed, seems that calling CPUCheckForExtensions gave an instant crash.

In cpuid.cpp
static int CPUCheckForExtensions()
{
...
}

int GetCPUFlags() {
_RPT0(0, "GetCPUFlags() called\n");
static int lCPUExtensionsAvailable = CPUCheckForExtensions();
_RPT0(0, "GetCPUFlags() called 2\n");
return lCPUExtensionsAvailable;
}

This static initialization fails under XP w/o the /Zc:threadSafeInit- flag.

Rebuild later, it's already dark here, and I have get home w/o police affairs (forgot to put front lamp on my bike)

[pinterf]

Thank you for your patience, here come the fixed binaries

Download Avisynth+ r2504-MT (broken XP support hotfix) (https://github.com/pinterf/AviSynthPlus/releases/tag/r2504-MT)

[Groucho2004]

Thank you for your patiance, here come the fixed binariesThank you, this seems to work fine now.

[Groucho2004]

@Groucho2004:
Here is it :D I take it from test server of MeGUI :D
http://megui.tmebi.de/test/vsfilter.1.5.0.2827_x64.7z

If I use AVSmeter to write a log with avs+ 2502, the program said cannot load filter until I deleted all 32b and 64b filter folders?
Then, after deleted filter folder, i have a logs
According to your logs, there are no plugins in the listed auto-load directories which makes sense since you apparently deleted all auto-load directories. Judging by the auto-load entries in the registry it seems that you installed several Avisynth versions on top of each other without un-installing first.

You should clean this up and re-install:

- Delete "C:\Program Files (x86)\AviSynth+" and subdirs
- Delete these registry keys:
HKEY_CURRENT_USER\Software\Avisynth
HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Avisynth

[tuanden0]

You should clean this up and re-install:

- Delete "C:\Program Files (x86)\AviSynth+" and subdirs
- Delete these registry keys:
HKEY_CURRENT_USER\Software\Avisynth
HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Avisynth

How can I say "I love you" Groucho2004 :thanks:

[jpsdr]

@Pinterf : Are-you using VS2017 ? If i haven't try for now to update to VS2017, is that i don't know if XP is still supported. When your new version didn't work, i thought i was the case, i said to myself "No... He didn't forget the /Zc:threadSafeInit-, it's probably not so easy... ;)".
Another thing, i don't know if the it can be installed under a 32bits OS (bad surprise with last Intel Compiler which doesn't install under a 32bits OS... :().

[StainlessS]

Jpsdr, see here:- https://www.visualstudio.com/en-us/productinfo/vs2017-compatibility-vs

XP supported as target, but last VS to support compilation on XP was vs 2010.
(Not sure, I think XP tool set was not provided until quite recently on vs 2017, I guess that they
finally realized that not everyone was willing to drop support for some millions of the old OS users).

[qyot27]

Jpsdr, see here:- https://www.visualstudio.com/en-us/productinfo/vs2017-compatibility-vs

XP supported as target, but last VS to support compilation on XP was vs 2010.
(Not sure, I think XP tool set was not provided until quite recently on vs 2017, I guess that they
finally realized that not everyone was willing to drop support for some millions of the old OS users).
IIRC, when installing VS2017, you can also install VS2015's compilers/toolsets, so it could be configured to use v140_xp. The difference would be that there's also a v141_xp now (specifically for VS2017, apparently) too.

But I installed it a couple months ago and don't remember too well.

[pinterf]

@Pinterf : Are-you using VS2017 ? If i haven't try for now to update to VS2017, is that i don't know if XP is still supported. When your new version didn't work, i thought i was the case, i said to myself "No... He didn't forget the /Zc:threadSafeInit-, it's probably not so easy... ;)".
Another thing, i don't know if the it can be installed under a 32bits OS (bad surprise with last Intel Compiler which doesn't install under a 32bits OS... :().
I'm not using it for production releases yet. When I have edited the cmake list file for vs2017, the XP support switch was moved (and not copied) from the vs2015 section so vs2015 build missed that option.

[VS_Fan]

FFmpegSource2(source="MVI_2038.avi")

#ConvertToYV12()
c0 = last

Y8=ExtractY()
U8=ExtractU()
V8=ExtractV()

Y8= <luma Separate filter(s)>
U8= <chroma Separate filter(s)>
V8= <chroma Separate filter(s)>

CombinePlanes(Y8, U8, V8, planes="YUV", sample_clip=c0) #, pixel_type="YUV420P8" #, source_planes="YYY")

This will work if I convert to YV12 (YUV420P8), but my source is YV16 (YUV422P8), and I would of course prefer to keep it that way.

Am I doing anything wrong?

This is the error message I get when trying it with YUV422 material:

"CombinePlanes: source and target plane dimensions are different"