Skip to content

Add YUV 4:4:0 stubs - #502

Open
qyot27 wants to merge 2 commits into
AviSynth:masterfrom
qyot27:440
Open

Add YUV 4:4:0 stubs#502
qyot27 wants to merge 2 commits into
AviSynth:masterfrom
qyot27:440

Conversation

@qyot27

@qyot27 qyot27 commented Jul 29, 2026

Copy link
Copy Markdown
Member

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

pinterf commented Aug 6, 2026

Copy link
Copy Markdown

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants