Add YUV 4:4:0 stubs

[qyot27]

See: https://forum.doom9.org/showthread.php?p=2033250#post2033250

Consider this a WIP pull request until a couple of things happen:

• Add API mechanisms for generating new pixel format configurations on-the-fly that aren't present in avisynth(_c).h?
• Sub-note of the above: expose that functionality through the scripting interface so end users can play with it?
• Add Y+alpha formats? These were missed during the broader alpha group.

For all of the above, we'd need to be able to do so now so they can be integrated into the changes before the interface version bump (which is going to be required if we're adding any new pixel formats, so might as well get any new API stuff or additional formats in here too so we don't end up bumping again right away).

Here's the thing about both of the first two points: clients have to match the pixfmt with the identifier that AviSynth+ hands them along with the video frame. Which means on-the-fly generated formats either need to somehow magically generate compliant names that could be easily added to the client, a new finding mechanism needs to be done for clients that could automatch, or - as I mentioned on Doom9 - we leave it as a huge user warning because on-the-fly generation is intended for plugins or scripts to work internally in a custom format but not necessarily export that format from the script. An olive branch at that point would be to have the user be able to set an output pixel format name to match with the on-the-fly generated frames, so that a client might be massaged into understanding what it's being given.

And that's not even touching any of the plumbing that needs/would need to be done for getting Convert working with them.

[pinterf]

If we'd touch this section (w/o considering the introductions of some freely definiable format creation option), I would add 4:1:1 for all bit-depths, it was always a pain to me to treat it as an exception e.g. in format conversions. VideoInfo class will need then a bit-depth agnostic Is411 and avs_is_411 (yes I know all these extra functions are for convenience but still).

Similarly, such supporting functions can be added to this new format: Is440 and avs_is_440.

Y+alpha: don't know. IsYA and is_ya, a new two-plane format.

Then: 16 bit float support (still not convinced about it; but VapourSynth got a huge facelift for that feature recently - internal filters are treating the format natively), but then we need an VideoInfo::IsInteger or IsFloat to be able to separate the 16 bit integer and 16 bit float option.

[Asd-g]

Another vote for 4:1:1 all bit-depths. Once I had to make patch for this. It would be nice if it's officially supported.

[radpopl]

I vote for YUV440. Camera photos happen in this format.

[qyot27]

Rebased and force-pushed.

• YV411 in all bit depths (the higher depths using the proper YUV411 naming)
• Alpha-bearing YUV411 formats
• Y plus alpha in all bit depths

AviSynth 2.6 actually added another pixel format constant that was never implemented: YUV9. As it turns out, this is actually 4:1:0, which was not immediately obvious given the strange naming. So as a bonus, I added constants for it too, in all bit depths and with alpha. Whether we want to enable the old IsYUV9 API function (which seems to actually be merely a stub, as compared to the Is410 that was newly added) is an open question, considering nobody would have been using it these past 17 years (the references to it show up in a commit from August 14th, 2009).

[qyot27]

Fixed a couple of issues, rebased and force-pushed.

YA32 is now YAS, and YS has been introduced as an alias for Y32. This makes the 4:0:0 float formats consistent with the others.

[pinterf]

Till which point will you implement the details? I'm already working on the consumer side of these new formats, checked the relevant places to change and ready to start the implementation. Large changes are expected, propose how to arrange that, should I work into your repo, or do different PRs by topic (and I'm sure there will be small fixes and forgotten parts later, individually)

0.) check general support in functions where the formats are assembled, displayed or exported (Info, PixelType builder, CombinePlanes, VfW interfaces (e.g. downgrade to YV411 if 411 format is larger than 8 bits), etc...
1.) 411 for all bit depth, many places are just assuming 411 is always 8 bits, lucky places can fallback to any-bits-411 subsample cases, once the Is411 instead of IsYV411 checking is freeing up the path automatically, but these are to be checked individually.
2.) supporting the new subsampled formats (harder one, +at many places all former three - 411, 420, 444 - are optimized)
but this is also mostly mechanic refactoring.
3.) Y+A support
4.) (probably not in this release) When touching the source here and there, make the float-case check a bit smarter, other than simply checking bits=32, thus preparing the easier adoptation of 16 bit float)

[qyot27]

Open them against the 440 branch on my repo. That way I can still move the interface bump commit if I have to.

[pinterf]

Thanks. This project then started. First phase (4:1:1 extensions) is done. But I need to clarify things again, I cloned your repo rather than forking. Still I have already a fork of the original repo, so I have to fork it under a different name, and make PRs from there, correct? (I'm mostly a solo developer, so I totally forgot the PR workflow :) ) I will make the commits and until you accept the PR it they will appear one after another for you? And if I want for revert one or two thing, revert, redo and force-push?
EDIT: I already have an AvisynthPlus fork from our main repo, and it is not allowed to fork from your one, since name collision.

[qyot27]

You can [locally] attach my fork as a remote so you can grab just the 440 branch:

git remote add qyot27 https://github.com/qyot27/AviSynthPlus.git
git fetch qyot27
git checkout -b 440 qyot27/440
# work on the 440 branch or split off a new branch to keep that one clean, just in case
# push the new branch(es) to your personal fork as normal

And then in Github's pull request interface, you can actually select a different fork to submit the changes to. If you add any commits after opening the PR, they will show up in the PR as long as they were committed to the branch that the PR was opened from.