Vapoursynth

[Reel.Deel]

(warning, completely untested but should work and if it doesn't just tell me and I'll actually try it myself)
Expr expression works as expected, the only only thing is that mt_lut by default only processes the luma. So I read the Expr documentation and added the following and now the results look identical.
avs = core.avs.mt_lut(c1=src, expr="x 128 - 1.49 * x 128 - 2 ^ x 128 - 2 ^ 9 + / * 128 +", Y=3, U=1, V=1)
vs = core.std.Expr(clips=[src], expr=["x 128 - 1.49 * x 128 - dup * dup 9 + / * 128 +", "", ""])

Thanks for the bonus material. Much easier to understand. :)

[wOxxOm]

Well... theoretically I could add the ^ operator but it would do you no good since it's very slow just for squaring things. In this case x*x is much faster. So I give you this equivalent that doesn't even need ^ and removes some duplicate evaluation
What about "something 1.05 ^"?
What about "something something ^"?
Also the calculation is done only once while building lut table, so the overhead may safely be neglected.

I also think it would be a good idea for existing mt_lut/x/y/z expressions to be compatible with Expr with no additional gimmicks.
Absolutely.
There are lots of useful scripts with very complex expressions.

[pie]

What about "something 1.05 ^"?
What about "something something ^"?

I'm not too sure with RPN, but something like this?
something log 1.05 * exp

For a^b
a log b * exp

--> e^(ln(a)*b)

[Myrsloik]

what about "something 1.05 ^"?


Absolutely.
There are lots of useful scripts using very complex expressions.

Then you have to remember from school that a^x = e^(x*ln(a))

so you rewrite it to:
a log x * exp (or something log 1.05 * exp)

And I have to reiterate that just copying and pasting expressions is kind of a bad idea for performance reasons. Just take the one I changed around above as an example.

[wOxxOm]

just copying and pasting expressions is kind of a bad idea for performance reasons.
What performance?

the calculation is done only once while building lut table, so the overhead may safely be neglected.
This is not something one learns at school, I guess, but still it's obvious.

[Chikuzen]

lutxyz requires at least about 16MiB(256*256*256*1byte).
Since a huge table is not settled in CPU cache, it may need very very slow memory access each time.
Therefore, runtime calcuration is often faster than LUT.

[wOxxOm]

Chikuzen, is this somehow related to my remarks about the majority of lut scripts, taking in account that lutxyz should be avoided at all costs and thankfully not commonly used anyway? Also, don't forget that memory access penalty during building of that 16MB table is *nothing* compared with memory penalty during processing of lots of actual video frames.

[StainlessS]

It is lut access during processing of video frames that will have a heavy cache miss penalty.

[wOxxOm]

StainlessS, I wrote about the same earlier, and to reiterate my point I'll rephrase: having a cpu-heavy instructions in expressions (like "^" - power) takes only an insignificant amount of overall processing time (it's calculated only one time, not each frame) so there's no need to exclude those in favour of non-practical 'performance gains' while degrading substantially ease of porting for existing lut-scripts.

[TheFluff]

Also the calculation is done only once while building lut table, so the overhead may safely be neglected.
expr() in Vapoursynth doesn't use a LUT, it re-evaluates the expression for each pixel, hence Myrsloik's comments about how you should be careful with your RPN expressions. It's done that way because building LUT's for high bitdepth video is a really stupid idea.

People who like faith-based optimizations may note that expr() isn't really any significantly slower than mt_lutxy[z] in many cases; for simple expressions it can even be faster than mt_lutxy.

[wOxxOm]

expr() in Vapoursynth doesn't use a LUT, it re-evaluates the expression for each pixelEven for 8-bit videos? Oh, quite unexpected... and seems errr... inefficient in this particular case.

And what about expr with complex expression for 1 video comparing with mt_lut (not xy) ?

[Myrsloik]

Even for 8-bit videos? Oh, quite unexpected... and seems errr... inefficient.

1. It's not inefficient, ironically x y + is about the same speed at mt_lutxy since memory reads for a lookup isn't magic
2. You can have 3 inputs (or more) without being inefficient
3. You can have mixed bitdepth inputs
4. There's a reason why the Lut and Lut2 filters exist
5. Get a clue, faith based criticism just annoys me and all other competent people reading this forum

[TheFluff]

And what about expr with complex expression for 1 video comparing with mt_lut (not xy) ?
If you want a LUT, you can have a LUT, see the standard library functions Lut() and Lut2(). Of course, they may or may not actually be faster depending on what you're doing and they have some restrictions that expr() doesn't have.

[wOxxOm]

Peace. I thought we were discussing technical issues not meant to be taken personally. Thank you for your answers and patience anyway.

[mastrboy]

# ret will contain frames 6 to 9 (unlike trim the end value of python slicing is not inclusive)
ret = clip[6:10]

Now that is just illogical, why is it not inclusive?

[Myrsloik]

# ret will contain frames 6 to 9 (unlike trim the end value of python slicing is not inclusive)
ret = clip[6:10]

Now that is just illogical, why is it not inclusive?

1. No, it's actually very common. Just see vdub and its timeline.
2. It's how the slicing operator works for every other sanely implemented python type so doing it differently would be even more "illogical".
3. This: a[:3]+b[3:10]+c[10:] (the point being that you can mindlessly set the end frame of the previous to the start of the first.

[kolak]

Very well known "problem" with different NLEs, transcoders, etc
Not including last frame is the most common approach as far as I can tell.

[gpower2]

In case you haven't noticed, latest VirtualDub (1.10.3) added support for .vpy extension!

[Adub]

Quick update on my end:

Fixed CFLAGS issues when comiling with Waf for CUDA support. I've added a bit more functionality to the Waf script to make everything work cleanly, although it might need some touch ups here and there. Currently, I've begun work porting some example filters, so that I can determine the best way to approach some of the algorithmic ports to the massively multithreaded CUDA architecture.

I'll be working with my professor to get remote access to some more "special" CUDA machines that we have available, which should vastly improve my productivity as I can then work remotely.

[Adub]

https://gist.github.com/4513971

Add dependency check for libavcodec, as vsresize.c requires the avcodec.h header.

[Myrsloik]

https://gist.github.com/4513971

Add dependency check for libavcodec, as vsresize.c requires the avcodec.h header.

Applied.

I'm a bit curious about your CUDA project. Did you get anything working yet?

[sl1pkn07]

fall build

NameError: global name 'AVCODEC' is not defined

http://paste.ubuntu.com/1522187

greetings

edit: missing ' ' in line 298

[Are_]

--- ../src/vapoursynth-read-only/wscript 2013-01-12 04:15:58.963414147 +0100
+++ wscript 2013-01-12 04:16:42.673431040 +0100
@@ -295,7 +295,7 @@

bld(features = 'c qxx asm',
includes = 'include',
- use = ['QTCORE', 'SWSCALE', 'AVUTIL', AVCODEC],
+ use = ['QTCORE', 'SWSCALE', 'AVUTIL', 'AVCODEC'],
source = bld.path.ant_glob(sources),
target = 'objs')

@@ -307,7 +307,7 @@

if bld.env.STATIC == 'true':
bld(features = 'c qxx asm cxxstlib',
- use = ['objs', 'QTCORE', 'SWSCALE', 'AVUTIL'],
+ use = ['objs', 'QTCORE', 'SWSCALE', 'AVUTIL', 'AVCODEC'],
target = 'vapoursynth',
install_path = '${LIBDIR}')

[sl1pkn07]

zankius for the patch.

[Adub]

Hmm, that's odd. My patch had proper quoting on the AVCODEC. Don't know why it got lost in translation.

I did miss the static line though.


As for my CUDA work, I'm still pre-alpha at this point. I have finished integrating the cuda 'nvcc' compiler into the Waf build system, which took a little while to get right.

I'm working on doing an initial test port of the invert filter, just to begin testing. I'm currently in the design phase, as I want to get the kernel "intelligent" enough before I start expanding the scope of the cuda port process.

The biggest difference is how the CUDA threading architecture is designed, so I'm figuring out the best way to port over the processing of a multitude of planes.

At the same time I'm learning the internal architecute of the Vapoursynth API, and Core. I don't want to have to implement anything that's been done already that I just didn't know about.

But I have finally received remote access to a Tesla-based machine, so I can work from anywhere now.

Unfortunately, I can only work on this project a few hours a day, as school has resumed.

[Myrsloik]

New version. Big bugfix release this time. As usual the changelog is in the first post and you can find a blog post about it here: R18 – Beta Quality (http://www.vapoursynth.com/2013/01/r18-beta-quality/)

[06_taro]

Great job for those fixes on memory leaks!

btw, version() still says r17 in r18: VapourSynth Video Processing Library
Copyright (c) 2012 Fredrik Mellbin
Core r17
API r3

[sl1pkn07]

and update files in TAG svn :P

[Myrsloik]

and update files in TAG svn :P

Yawn. I'm just going to let this single issue be. I think I got everything else right.

[gpower2]

Finally managed to run a comparison test myself.
I used 1500 frames of a 720p mp4 video downloaded from youtube (http://www.youtube.com/watch?v=y-9DVU6Kux8)

Software used:
VapourSynth R18
VirtualDub 1.10.3
XviD 1.3.2 vfw (koepi build)
AviSynth 2.5.8 (official vanilla version from http://www.avisynth.org)
Avisynth Core Filters (from http://www.vapoursynth.com)
GenericFilters 0.4.0 (from http://forum.doom9.org/showthread.php?t=166842)
HAvsFunc r3 (from http://forum.doom9.org/showthread.php?t=166582)
FFMS2 r739 (from http://forum.doom9.org/showthread.php?p=1607732#post1607732)

Scripts tested:
AviSynth
FFVideoSource(source = "C:\Garslan\Videos\Videoclips\1990-2000\Babybird - Atomic Soda ( HD ).mp4",
track = -1, cache = true, cachefile = "C:\Garslan\Videos\Videoclips\1990-2000\Babybird - Atomic Soda ( HD ).mp4.ffindex",
fpsnum = -1, fpsden = 1, pp="", threads = -1,
timecodes = "C:\Garslan\Videos\Videoclips\1990-2000\Babybird - Atomic Soda ( HD ).mp4.tcodes.txt", seekmode = 1)
trim(0,1500)
lsfmod()

VapourSynth - SingleThread
import vapoursynth as vs
import sys
import havsfunc as hf
core = vs.Core(threads=1)
haf = hf.HAvsFunc(core)

core.std.LoadPlugin(path=r'D:\Downloads\ffms2.dll')
core.std.LoadPlugin(path=r'C:\vsplugins\genericfilters.dll')
core.std.LoadPlugin(path=r'C:\Program Files (x86)\VapourSynth\filters\temporalsoften.dll')
core.std.LoadPlugin(path=r'C:\Program Files (x86)\VapourSynth\filters\eedi3.dll')

core.avs.LoadPlugin(path=r'C:\vsplugins\avisynthfilters.dll')
core.avs.LoadPlugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\mt_masktools-26.dll')
core.avs.LoadPlugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\RemoveGrain_v10pre1.dll')

ret = core.ffms2.Source(source=r'C:\Garslan\Videos\Videoclips\1990-2000\Babybird - Atomic Soda ( HD ).mp4')
ret = core.std.Trim(ret, 0, 1500)
ret = haf.LSFmod(ret)

last = ret

VapourSynth - Multithread
import vapoursynth as vs
import sys
import havsfunc as hf
core = vs.Core(threads=0)
haf = hf.HAvsFunc(core)

core.std.LoadPlugin(path=r'D:\Downloads\ffms2.dll')
core.std.LoadPlugin(path=r'C:\vsplugins\genericfilters.dll')
core.std.LoadPlugin(path=r'C:\Program Files (x86)\VapourSynth\filters\temporalsoften.dll')
core.std.LoadPlugin(path=r'C:\Program Files (x86)\VapourSynth\filters\eedi3.dll')

core.avs.LoadPlugin(path=r'C:\vsplugins\avisynthfilters.dll')
core.avs.LoadPlugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\mt_masktools-26.dll')
core.avs.LoadPlugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\RemoveGrain_v10pre1.dll')

ret = core.ffms2.Source(source=r'C:\Garslan\Videos\Videoclips\1990-2000\Babybird - Atomic Soda ( HD ).mp4')
ret = core.std.Trim(ret, 0, 1500)
ret = haf.LSFmod(ret)

last = ret

I encoded the clip with XviD default parameters and the performance results are:

Run 1:

AviSynth Ellapsed time: 79587ms / 00:01:19.5870000
VapourSynth SingleThread Ellapsed time: 153168ms / 00:02:33.1680000
VapourSynth Multithread Ellapsed time: 81528ms / 00:01:21.5280000

Run 2:
AviSynth Ellapsed time: 80519ms / 00:01:20.5190000
VapourSynth SingleThread Ellapsed time: 153752ms / 00:02:33.7520000
VapourSynth Multithread Ellapsed time: 84267ms / 00:01:24.2670000

AviSynth beat VapourSynth in single thread mode hands down. It even beat VapourSynth in multithread mode.
I guess the heavy use of imports and mixed filters doesn't make VapourSynth usable for "production" level scripts.

Next time, I'll try a simple script, with no filters, and a real script (if I can manage to port it to VapourSynth)
and see the results.

P.S.
In VirtualDub, pressing F2 does reloads the script, but it doesn;t reload the whole python environment, meaning the imports etc.
Try to load a script with imports, and then comment them out from the script and press F2. It should not work, yet it does...

Still, I believe that VapourSynth can become the new standard, if the most popular AviSynth filters are ported to it.
And I mean natively, not with python scripts...

Keep up the good work! :D

[Myrsloik]

Uh... did you run the comparison using only avisynth filters? Because that's what's really important. That and if you use eedi3 force the filter itself to be single threaded. And how many cores does your cpu have?

As for cleaning out the python environment it already is being done almost as much as is possible. It's simply designed as having global state to be annoying, or so my theory goes.

[gpower2]

Well, I certainly used mixed filters, I mean, I only wanted to test LSFMod, which I use a lot with AviSynth, but to use it with VapourSynth, you need a lot of dependencies.
And since it's an avsi avisynth script, I can't import it directly in VapourSynth, correct? (I thought I saw someone wrote an avisynth script parser for VapourSynth, but I didn't find it now)

The test pc in my case has a Q9505 Core2 Quad-Core CPU @ 2.83GHz and 8GB RAM.

Do you have some particular test case in mind?

I also have a 930 i7 and 18GB RAM at home, so I could also test something there...

[Myrsloik]

The test case has to be like this:
1. Only use avisynth filters, both in avisynth and vs so it's exactly the same filter code running. It's the core performance I want to compare.
2. Make sure all filters in it don't secretly do multithreaded stuff, eedi3 especially so
3. Any simple avisynth script will do as a start. It may even be better to start small and only do ffms.Source() and avisource.avisource() and then adding things on to that.

Those are my guidelines for testing. (yes, I know that vs avisource obviously is slightly different but it should perform identically)

[kolak]

All these speed issues with avs filters are not related to prefetching problem?

http://forum.doom9.org/showthread.php?p=1610787#post1610787

[Myrsloik]

All these speed issues with avs filters are not related to prefetching problem?

http://forum.doom9.org/showthread.php?p=1610787#post1610787

Prefetching is the biggest problem at least. I think.

[[ReX]]

I spotted typo on Adub's patch to invert_example.c.

// Once all frames are ready, the the filter will be called with arAllFramesReady. It is now time to

Not that his patch added it, there's where I saw it. ;)

[Adub]

Damn [Rex], you've got a good eye. I don't know how I missed that 'the' while I was combing the source code. I was purposefully looking for that very thing!

[gpower2]

Made another performance test, as requested by Myrsloik.

PC Used
Q9505 Core2 Quad-Core CPU @ 2.83GHz, 8GB RAM, Win7 x64 Enterprise

Software Used
VapourSynth R18
VirtualDub 1.10.3
XviD 1.3.2 vfw (koepi build)
AviSynth 2.5.8 (official vanilla version from http://www.avisynth.org)
FFMS2 r739 (from http://forum.doom9.org/showthread.ph...32#post1607732)

Scripts tested

With 720p mp4 video:

AviSynth - SingleThread FFMS2
LoadCPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll")
FFVideoSource(source = "Babybird - Atomic Soda ( HD ).mp4", track = -1, cache = true, \
cachefile = "Babybird - Atomic Soda ( HD ).mp4.ffindex", \
fpsnum = -1, fpsden = 1, pp="", threads = 1, timecodes = "Babybird - Atomic Soda ( HD ).mp4.tcodes.txt", seekmode = 1)

AviSynth - MultiThread FFMS2
LoadCPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll")
FFVideoSource(source = "Babybird - Atomic Soda ( HD ).mp4", track = -1, cache = true, \
cachefile = "Babybird - Atomic Soda ( HD ).mp4.ffindex", \
fpsnum = -1, fpsden = 1, pp="", threads = -1, timecodes = "Babybird - Atomic Soda ( HD ).mp4.tcodes.txt", seekmode = 1)

VapourSynth SingleThread -SingleThread FFMS2
import vapoursynth as vs
import sys
core = vs.Core(threads = 1)
core.std.LoadPlugin(path = r'C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll')
ret = core.ffms2.Source(source = r'Babybird - Atomic Soda ( HD ).mp4',
track = -1, cache = 1,
cachefile = r"Babybird - Atomic Soda ( HD ).mp4.ffindex",
fpsnum = -1, fpsden = 1, threads = 1, seekmode = 1,
timecodes = r"Babybird - Atomic Soda ( HD ).mp4.tcodes.txt")
last = ret

VapourSynth SingleThread - MultiThread FFMS2
import vapoursynth as vs
import sys
core = vs.Core(threads = 1)
core.std.LoadPlugin(path = r'C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll')
ret = core.ffms2.Source(source = r'Babybird - Atomic Soda ( HD ).mp4',
track = -1, cache = 1,
cachefile = r"Babybird - Atomic Soda ( HD ).mp4.ffindex",
fpsnum = -1, fpsden = 1, threads = -1, seekmode = 1,
timecodes = r"Babybird - Atomic Soda ( HD ).mp4.tcodes.txt")
last = ret

VapourSynth MultiThread - SingleThread FFMS2
import vapoursynth as vs
import sys
core = vs.Core(threads = 0)
core.std.LoadPlugin(path = r'C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll')
ret = core.ffms2.Source(source = r'Babybird - Atomic Soda ( HD ).mp4',
track = -1, cache = 1,
cachefile = r"Babybird - Atomic Soda ( HD ).mp4.ffindex",
fpsnum = -1, fpsden = 1, threads = 1, seekmode = 1,
timecodes = r"Babybird - Atomic Soda ( HD ).mp4.tcodes.txt")
last = ret

VapourSynth MultiThread - MultiThread FFMS2
import vapoursynth as vs
import sys
core = vs.Core(threads = 0)
core.std.LoadPlugin(path = r'C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll')
ret = core.ffms2.Source(source = r'Babybird - Atomic Soda ( HD ).mp4',
track = -1, cache = 1,
cachefile = r"Babybird - Atomic Soda ( HD ).mp4.ffindex",
fpsnum = -1, fpsden = 1, threads = -1, seekmode = 1,
timecodes = r"Babybird - Atomic Soda ( HD ).mp4.tcodes.txt")
last = ret

With 288p mp4 video:
The same as above, with different source file.

With 320p avi video:
AviSynth - AviSource
AviSource("C:\Garslan\Videos\Videoclips\2001-2009\Banned, Uncensored & Uncut Music Videos\Madonna - Erotica(Banned Version).avi")

VapourSynth SingleThread - VS avisource
import vapoursynth as vs
import sys
core = vs.Core(threads = 1)
core.std.LoadPlugin(path = r'C:\Program Files (x86)\VapourSynth\filters\avisource.dll')
ret = core.avisource.AVISource(r'C:\Garslan\Videos\Videoclips\2001-2009\Banned, Uncensored & Uncut Music Videos\Madonna - Erotica(Banned Version).avi')
last = ret

VapourSynth MultiThread - VS avisource
import vapoursynth as vs
import sys
core = vs.Core(threads = 0)
core.std.LoadPlugin(path = r'C:\Program Files (x86)\VapourSynth\filters\avisource.dll')
ret = core.avisource.AVISource(r'C:\Garslan\Videos\Videoclips\2001-2009\Banned, Uncensored & Uncut Music Videos\Madonna - Erotica(Banned Version).avi')
last = ret


Results

AviSynth - SingleThread FFMS2 [720p]: Ellapsed time: 269908ms / 00:04:29.9080000
AviSynth - MultiThread FFMS2 [720p]: Ellapsed time: 277995ms / 00:04:37.9950000
VapourSynth MultiThread - MultiThread FFMS2 [720p]: Ellapsed time: 282046ms / 00:04:42.0460000
VapourSynth MultiThread - SingleThread FFMS2 [720p]: Ellapsed time: 275250ms / 00:04:35.2500000
VapourSynth SingleThread -SingleThread FFMS2 [720p]: Ellapsed time: 271664ms / 00:04:31.6640000
VapourSynth SingleThread - MultiThread FFMS2 [720p]: Ellapsed time: 280996ms / 00:04:40.9960000

AviSynth - SingleThread FFMS2 [288p]: Ellapsed time: 16168ms / 00:00:16.1680000
AviSynth - MultiThread FFMS2 [288p]: Ellapsed time: 19572ms / 00:00:19.5720000
VapourSynth MultiThread - SingleThread FFMS2 [288p]: Ellapsed time: 16548ms / 00:00:16.5480000
VapourSynth MultiThread - MultiThread FFMS2 [288p]: Ellapsed time: 17411ms / 00:00:17.4110000
VapourSynth SingleThread -SingleThread FFMS2 [288p]: Ellapsed time: 16192ms / 00:00:16.1920000
VapourSynth SingleThread - MultiThread FFMS2 [288p]: Ellapsed time: 17246ms / 00:00:17.2460000

AviSynth - AviSource [320p]: Ellapsed time: 27360ms / 00:00:27.3600000
VapourSynth MultiThread - VS avisource [320p]: Ellapsed time: 28255ms / 00:00:28.2550000
VapourSynth SingleThread - VS avisource [320p]: Ellapsed time: 27361ms / 00:00:27.3610000

Singlethread VapourSynth doesn't seem to reach singlethread AviSynth performance, while multithread VapourSynth barely makes it.

I used the same ffms2.dll for both AviSynth and VapourSynth.
Encoded via VFW interface with VirtualDub and XviD.

[sven_x]

I think for performance testing one should chose the fastest encoder that is available (or even no encoding). Otherwise most of the CPU usage will be used for encoding.

[gpower2]

I think for performance testing one should chose the fastest encoder that is available (or even no encoding). Otherwise most of the CPU usage will be used for encoding.

Well, there is also the HDD bottleneck you should take in mind. ;)

Also, the results are quite consistent, so I don't think that using any other encoder would make any difference, apart from the different numbers...

[kolak]

I don's see any big difference. You could also note CPU and RAM usage.
Also- all what you have tested is mainly ffms2 decoding performance or encoding speed. You could simply run analysis pass in Vdub to get just processing speed (no encoding).

[Adub]

How is everyone testing the higher bit-depth functionality of Vapoursynth? I'd love to get some samples and/or a workflow for testing input above 8-bits.

[Myrsloik]

How is everyone testing the higher bit-depth functionality of Vapoursynth? I'd love to get some samples and/or a workflow for testing input above 8-bits.

Either using the resizer to convert random 8bit junk to 10 or 16bit or with blankclip. I suppose ffms2 and 10bit h264 files would do as well...

[kolak]

I tested quite few- ProRes, DNxHD, v210 , AVC-I with dithering, resizing and all works fine.

[Adub]

Does ffms2 support up to 16-bit input?

If so, Kolak, what bit-depths are the clips that you are testing with? Do they go up to 16-bit? Would you mind posting a few samples for me to download?

[kolak]

Yes, as far as I know ffms2 will read 16bit files. My samples are mostly 10bit. Can't share, most with copyrights.
You can find some ProRes etc files on the web, eg.

http://www.blackmagicdesign.com/support/detail?sid=3948&pid=11735&leg=false&cp=true&os=win

Alexa ProRes files in LOG color space, so you can also play with LUT files to get proper colors :)

VS also has support for b48r format (16bit RGB), which is used inside MOV- it's introduced as a part of some bigger idea, which may become reality one day :)

[qyot27]

From my tests with high bit depth H.264 (12- and 14-bit 4:2:0, 4:2:2, and 4:4:4), FFMS2 opens them just fine, VapourSynth passes them through as 16-bit to y4m, and as long as the build of mpv/x264/ffmpeg/whatever can accept the extended y4m format, you're pretty much golden on that front. May or may not need stream fixing with ffmpeg as a middle step, though (remember, the extended y4m is still experimental; you've gotta use -strict -1 for it to pipe them through).

You just need to make sure the build of FFMS2 is using mainline FFmpeg as the library backend, since the fork doesn't support >10-bit for H.264 (and for all I know, it doesn't support >10 & <16 in rawvideo either; there was also a bug report for mpv that showed as much).

The aforementioned samples. Six files: 4:2:0, 4:2:2, and 4:4:4 in 12-bit and 14-bit. The source actually came from an editing project, so no audio (it wouldn't matter, either).
http://www.mediafire.com/?9jcjn111habg32x

You can verify the bit depth/colorspace using MediaInfo, and play them directly using any fairly recent build of mpv (at least). I do also have RGB samples in 12- and 14-bit H.264, but either they weren't generated correctly, or all the kinks haven't been hammered out of FFmpeg's decoding paths for those cases yet (which is what I think is the more likely scenario). They'll play, and the colorspace is recognized as gbrp[12/14]le, but they're a deep pink/green instead of the correct colors. That's why I didn't include them in the 7z.

[sneaker_ger]

You could also get 16 bit PNGs of Sintel for example:
http://media.xiph.org/sintel/

Works fine with Chikuzen's image reader plugin.

[Adub]

Woot! Success!

I just succesfully tested my CUDA enhancments, and they work!! Had some trouble with some damn integer truncation for a bit, as well as pitch calculation, but I re-learned middle school really quick. :P

It's still currently slower than CPU, but I completely expected that. I'm going to start integrating more of the GPU work into the core, which will offer a more seamless dev experience and less work in each filter.

So as of now, the invert filter works. I'm going to streamline a lot of code, and look at porting more filters, but I just wanted to report initial success (finally).

[LoRd_MuldeR]

I got a question:

The recommended way to encode from VapourSynth with x264 seems to be using a pipe:
"python script.py | x264 --demuxer y4m --output encodedfile.mkv -"

But: Unless we we properly set "--frames N", x264 will not be able to display progress when reading from a pipe.

So what would be the most simple way to programmatically detect the correct frame count from a given VapourSynth script file?

For Avisynth I would open the script with avs2yuv and then parse the text output.

I guess the same thing could be done with Python. But I'm not very good at Python. A small example would be appreciated! :)


What I would need is something like:
Python.exe "detect_framecount.py" "C:\Some Path\Script we are going to pipe into x264.py"

And ideally it would write something like this to the STDOUT:
Number of frames: 12345