Vapoursynth

[stax76]

yuv fourcc on apple dev page:

https://developer.apple.com/library/...4-CH1-SECTION3

d:\Temp>ffmpeg -codecs -hide_banner | findstr 4:4:4
 DEVI.. ayuv                 Uncompressed packed MS 4:4:4:4
 DEVI.. v308                 Uncompressed packed 4:4:4
 DEVI.. v408                 Uncompressed packed QT 4:4:4:4
 DEVI.S v410                 Uncompressed 4:4:4 10-bit

[Khanattila]

I don't think it's helpful.

x264/x265 accept i420, yv12, nv12, i422, yv16, nv16, i444, yv24:
- yv12, yv16 and yv24 are planar, good;
- i420, i422, i444 are identical except that the U and V plane order is reversed, good;
- nv12, nv16 are semi-planar.

Why add a packed format?

[Myrsloik]

My personal opinion is that you should just let vfw die. I know it's convenient and simple sometimes but it simply doesn't define enough things. Simply convert to RGB24 or yv24 at the end of all scripts you're only going to preview and be done with it.

If anything I thinkbthe future belongs to specialized editors/preview apps that have proper 10bit and up handling. There are monitors that truly support a higher depth but I don't think any open source solution is capable of properly doing that yet. Let vfw die, it's old and tired.

And you can easily pipe y4m at higher depths into x264 so that makes even less sense. I got that stuff added to y4m several years ago to work around this.

[stax76]

I don't give it up yet, I'm getting closer though.

[Myrsloik]

Originally Posted by stax76

I don't give it up yet, I'm getting closer though.

Why does staxrip need it at all when doing VS stuff?

[stax76]

It does not really need it, it just was always good enough.

[speedyrazor]

Does this all relate to this issue?
http://forum.doom9.org/showthread.ph...ng#post1766005

[stax76]

Originally Posted by speedyrazor

Does this all relate to this issue?
http://forum.doom9.org/showthread.ph...ng#post1766005

no, vspipe don't use VFW

[speedyrazor]

Originally Posted by HolyWu

The fault comes from the source filter you use. You'd better open an issue on https://github.com/VFR-maniac/L-SMASH-Works and provide a small sample file so the author can reproduce the problem.

Done, thanks for the suggestion.

[feisty2]

anyone ever thought about making a GUI based editor, something like Nuke for vs?
I mean vseditor is cool but it's based on script writing still... you're gonna have to write scripts even for some pretty simple tasks and that is not very user friendly..
would be nice if such GUI thing exists and you manipulate the filters and modules as "nodes" and it generates python scripts automatically for you..

[LigH]

You are probably thinking of something similar to "AVE AviSynth Visual Editor" (which was probably abandoned, IIRC).

[feisty2]

Originally Posted by LigH

You are probably thinking of something similar to "AVE AviSynth Visual Editor" (which was probably abandoned, IIRC).

shame, I always think it's good to "GUI whatever if possible and script manually only where it must"

[LigH]

That's the POV of the user.

The developer looks from the opposite angle and needs to have basic routines working first. A pretty GUI on a brittle core is like a penthouse floating above a basement still being built.

AviSynth was developed as (scriptable) frameserver; it was meant to be invisible. VapourSynth is a video filtering framework, not the same as a frameserver, but still meant to be the invisible engine covered by any kind of casing. Because the VapourSynth engine itself is partially made of a common programming language (Python), it is even more probable than for AviSynth that a user interface could be made which may change the video processing script as a part of itself. But this is just a very elaborate challenge...

[Are_]

Originally Posted by feisty2

anyone ever thought about making a GUI based editor, something like Nuke for vs?
I mean vseditor is cool but it's based on script writing still... you're gonna have to write scripts even for some pretty simple tasks and that is not very user friendly..
would be nice if such GUI thing exists and you manipulate the filters and modules as "nodes" and it generates python scripts automatically for you..

Not sure if it is exactly what you meant, but somebody did think about it and wrote pyhenkan.

I don't know if it works out of the box in Windows, it's not mentioned anywhere, and has some bugs here and there, looks a little unfinished yet.

I don't really know what's Nuke, but is not Staxrip similar to what you are asking for (I have not used it, so I don't really know what it is)?

[feisty2]

Originally Posted by LigH

The developer looks from the opposite angle and needs to have basic routines working first. A pretty GUI on a brittle core is like a penthouse floating above a basement still being built.

been years since the first vs release, I actually think the vs core should be pretty stable by now, trivial changes and improvements and bug fixes will always be going but nothing drastic, the basement is done imho

[feisty2]

Originally Posted by Are_

I don't really know what's Nuke

Nuke is a node based commercial NLE software, it's a pretty popular thing in movie industry, see https://www.thefoundry.co.uk/products/nuke/

and it's different from transcoding toolkits like Staxrip or MeGUI, it's designed specifically for video manipulating not transcoding

[Mystery Keeper]

Originally Posted by feisty2

anyone ever thought about making a GUI based editor, something like Nuke for vs?
I mean vseditor is cool but it's based on script writing still... you're gonna have to write scripts even for some pretty simple tasks and that is not very user friendly..
would be nice if such GUI thing exists and you manipulate the filters and modules as "nodes" and it generates python scripts automatically for you..

Like Cycles in Blender? Doable. But how usable it would be? Writing scripts is simply faster. It lets you copy/paste and comment out lines. A complex script might use tens of nodes.

[feisty2]

Originally Posted by Mystery Keeper

Like Cycles in Blender? Doable. But how usable it would be? Writing scripts is simply faster. It lets you copy/paste and comment out lines. A complex script might use tens of nodes.

It's extremely useful on complex restoration projects like VideoFred's stuff, you got a clearer view of the entire process chain instead of figuring it out by hours of script reading and organizing, and it helps the function calling also, some fat plugins, mvtools kind of thing, might contain 20+ parameters or so, and you got them all on a gui panel, no more staring at the extra long function calling and tryna locate the parameter you set before and wanna modify now...

[feisty2]

And scripts tend to be messy and confusing and likely to go wrong when things get big and complex, cuz we humans make mistakes...GUI nodes help with that too

[dipje]

Utvideo codec has now RGB 10-bit and RGB-with-alpha 10-bit versions, with quicktime support and working (import/export) in Adobe After Effects for Windows at least.

Virtualdub FilterMod has added b64a support and tested the codecs and they seem to work.
But there is no way yet to go from Vapoursynth (with RGB30 / RGB48) into Virtualdub FilterMod since Vapoursynth doesn't support those colorspaces in the VfW module. May I request this? There is a legit use now for it .

(Vpy RGB30 into Utvideo 'UQRG' seems to be close to 50% of the same RGB30 as a DPX sequence in disksize so it helps a lot with disk i/o in After Effects)


An alternative would be an updated ffmpeg with the 10-bit utvideo versions in _encoding_ mode, but since there doesn't seem to be support for the (now a fear years old) YUV422-10bit mode (UQR2) I have little hope for that happening.