Vapoursynth

[Keiyakusha]

http://forum.doom9.org/showpost.php?p=1590957&postcount=1650

Yeah, definitely missed that. Thanks! It works now.

EDIT: one more question, it is not possible to open 10bit video now? It says something about vfw but I can't read it,anything that reads .vpy crashes too fast.
edit2: by the way 10bit useful not only for x264. me, and I believe not only me use it for more professional stuff. some things like 10bit dnxhd are pretty much standard for delivering intermediate files. thankfully after all we got nicely hacked ffms2 for avisynth with high bitdepth and different subsampling support ^__^

[kolak]

For the fake avi stuff you need another layer like that old vfapi stuff or avfs. I could try to quickly port avfs and make it vsfs if the current solution isn't good enough.

I looked at v210 but it's packing made me nauseous just to look at. I suppose I'll add it sooner or later but it's a shame it turned out to be the most popular. Microsoft defines very sane and clean planar formats officially too. What a shame... over 8 bit output will come. But it's a bit lower in priority since to my knowledge x264 is the only thing that truly benefits from it. Correct me if I'm wrong.

vsfs would be great- avfs works very well as it presents script as "normal uncompressed avi", so every app is happy with it. It also works stable.

v210 is definitely the most universal format for 10bit and I think they made it packed to save bits.
Is it possible to have some 10bit working color space in one format (easy to implement and to work with) and have v210 implemented in vsfs only as final output? If this is easier than it would also work.

v210 spec can be found here:

https://developer.apple.com/quicktime/icefloe/dispatch019.html#v210

[JEEB]

v210 is definitely the most universal format for 10bit and I think they made it packed to save bits.
It is the most "universal" format for 10bit in MOV (and thus possibly with the pro tools). Please leave that stuff out of Vapoursynth and pipe its 10bit output to ffmpeg/avconv or something, they can convert the bits into the correct thing, and they can mux it into mov correctly. Myrsloik knows of the format and it's not something he most probably will support any time soon, because it is a major PITA to do so.

Also the v210 "support" in VirtualDub is as far as I know something that doesn't work anywhere else, so that can, if you pardon my french, go suck itself. v210 is only "standard" in mov. I would much rather see the support for the saner, proper 10bit formats be added in VDub instead of a random format not meant for in-program use, but for creating an actual mov file for transport for loading it into something else. And for that, we have ffmpeg/avconv to do it for you. You just have to feed them the 10bit YCbCr.

Thank you.

[active1]

will vapoursynth support outputing more than 8 bits? and will vdub be able to preview the +8bit.vpy script?

[JEEB]

will vapoursynth support outputing more than 8 bits?
Vapoursynth has been able to output >8bit stuff for quite a while already. That is why the Vapoursynth ffms2 plugin can output >8bit stuff as well, which was never officially implemented on the Avisynth side as it was a hack.

and will vdub be able to preview the +8bit.vpy script?
No idea what colorspaces can be used in the VFW interface. Also I have no idea what colorspaces VDub can take in. IIRC it doesn't support the MS-specified 10bit+ YCbCr formats at least. It is an open source application though, so things can be implemented.

[Keiyakusha]

EDIT: one more question, it is not possible to open 10bit video now? It says something about vfw but I can't read it,anything that reads .vpy crashes too fast.

Just want to rephrase this a bit
Lets say I want to open any 10 (or more) bit file supported by ffmpeg using ffms2 in vapoursynth and then preview it in something. How should I do this correctly?
From what I understand VDub needs to add support for planar colorspaces, then how do I convert colorspace to somthing VDub already understands? 8bit YV12 for example

edit: this? Bicubic(clip=clip, format=vs.YUV420P8) why bicubic and not something else? how it is related to colorspace conversion if no subsampling involved? And it seems it crashes anyway.

[active1]

Vapoursynth has been able to output >8bit stuff for quite a while already. That is why the Vapoursynth ffms2 plugin can output >8bit stuff as well, which was never officially implemented on the Avisynth side as it was a hack.

i meant outputing more than 8bit with using the vfw module

.
No idea what colorspaces can be used in the VFW interface. Also I have no idea what colorspaces VDub can take in. IIRC it doesn't support the MS-specified 10bit+ YCbCr formats at least. It is an open source application though, so things can be implemented.
i hope that vapoursynth will be able to do it :)

[Reel.Deel]

then how do I convert colorspace to somthing VDub already understands? 8bit YV12 for example.

This allows you to preview 10-bit video as 8-bit in VDub.
.......
# 10-bit source
src = core.ffms2.source(source=r"C:\10 bit.mkv")

# Change bit depth to 8-bit
src = core.resize.Bicubic(clip=src, format=vs.YUV420P8)

# Ouput for VDub
last = src

Also, you can change Bicubic to any of the other resize listed here (http://www.vapoursynth.com/doc/functions/resize.html).


------------

@ Myrsloik

Is there any dithering going on when converting YUVxxxP16 to lower bit depths?

[hajj_3]

python 3.3 final is out now: http://python.org/download/

Maybe you could release a new build using Visual Studio.NET 2010 now :) I wonder if windows 8 has the C++ 2010 pre-installed?

[JEEB]

@ Myrsloik
Is there any dithering going on when converting YUVxxxP16 to lower bit depths?
Yes, depends on the swscale linked into vapoursynth, after the dither package gets implemented we should get various things for that.

Of course for preview you could just convert it to RGB straight away (and after the dither package gets ported you'd have more ways to do that, too) :)

[Keiyakusha]

This allows you to preview 10-bit video as 8-bit in VDub.

Also, you can change Bicubic to any of the other resize listed

Thanks. I used it a bit wrong. Now it works. I know that I can change resize, but what is the difference? I'm not doing any scaling or chroma conversion.

Is there any dithering going on when converting YUVxxxP16 to lower bit depths?
want to add to JEEB's answer that swscale does poor ordered dithering... at least ffms2 supports only that. it was my request some time ago to add something better

[Reel.Deel]

I know that I can change resize, but what is the difference? I'm not doing any scaling or chroma conversion.

Sorry, must of misunderstood your last post.


Bicubic(clip=clip, format=vs.YUV420P8) why bicubic and not something else?

[Myrsloik]

Thanks. I used it a bit wrong. Now it works. I know that I can change resize, but what is the difference? I'm not doing any scaling or chroma conversion.


want to add to JEEB's answer that swscale does poor ordered dithering... at least ffms2 supports only that. it was my request some time ago to add something better

There most likely is no difference since the scalers probably don't get involved at all.

[lansing]

Another thing you should try first though is only having absolute paths in your script. The other thing is running your script in python and see if it works at all with the paths you have.

Yes, I figured it's the path that's causing it.

how do I write it for the import path if my vpy file is on the desktop, and python was installed at "C:\Python32" ?

______________________________

And a few more things I spotted:

- the uninstaller shortcut was missing in the start menu.
- vapoursynth installer defaulted the python directory as python32. I updated python to 3.3 today and vapoursynth installer throws out an error
- a context menu on creating a new blank vpy file should be added
- there's a pop up sometime asking system reboot after i uninstalling vapoursynth


And I did some benchmarking with x264 preset ultrafast comparing avisynth and vapoursynth.


avs FFVideoSource("test.avi") 524fps x264 cpu usage: 100%
vpy Source("test.avi") 285fps x264 cpu usage: ~50% python.exe cpu usage: 30%


the python.exe cpu usage seems to bottleneck the speed.

[mastrboy]

avs avisource("test.avi") 524fps x264 cpu usage: 100%
vpy ffms2("test.avi") 285fps x264 cpu usage: ~50% python.exe cpu usage: 30%



For the test to be comparable should you not have used FFVideoSource in avisynth rather than avisource?

[Myrsloik]

Yes, I figured it's the path that's causing it.

how do I write it for the import path if my vpy file is on the desktop, and python was installed at "C:\Python32" ?

______________________________

And a few more things I spotted:

- the uninstaller shortcut was missing in the start menu.
- vapoursynth installer defaulted the python directory as python32. I updated python to 3.3 today and vapoursynth installer throws out an error
- a context menu on creating a new blank vpy file should be added
- there's a pop up sometime asking system reboot after i uninstalling vapoursynth


And I did some benchmarking with x264 preset ultrafast comparing avisynth and vapoursynth.


avs avisource("test.avi") 524fps x264 cpu usage: 100%
vpy ffms2("test.avi") 285fps x264 cpu usage: ~50% python.exe cpu usage: 30%


the python.exe cpu usage seems to bottleneck the speed.

1. The shortcut isn't missing. I believe it's actually the guideline of the week to put that stuff in remove programs only.
2. The python module is built for 3.2 and will only work with that version. It's how annoying python on windows is.
3. I'll put it on the to-do list. Personally I never use those options so I don't notice it missing.
4. Of course. A file was in use and a reboot is needed to delete it. It's safe to just install over for upgrades though.

Can you do the same benchmark but pipe the input to x264 and skip the vfw stuff? It'll help me find the bottleneck

[lansing]

For the test to be comparable should you not have used FFVideoSource in avisynth rather than avisource?

typo by me, actually they were both ran with ffvideosource

[lansing]

Can you do the same benchmark but pipe the input to x264 and skip the vfw stuff? It'll help me find the bottleneck

they were done without the vfw thing already, tested well over 50k frames

vpy:

import vapoursynth as vs
import sys

core = vs.Core(accept_lowercase=True)
core.std.LoadPlugin(r'C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll')
src = core.ffms2.Source(r"test.avi")

src.output(sys.stdout, y4m=True)

___________________________________

cmd:
python test.vpy | x264 --preset ultrafast --demuxer y4m --output vpy_ben.mkv -




avs:

ffvideosource("test.avi")

___________________________________

cmd:
x264 --preset ultrafast --output avs_ben.mkv test.avs

[kolak]

It is the most "universal" format for 10bit in MOV (and thus possibly with the pro tools). Please leave that stuff out of Vapoursynth and pipe its 10bit output to ffmpeg/avconv or something, they can convert the bits into the correct thing, and they can mux it into mov correctly. Myrsloik knows of the format and it's not something he most probably will support any time soon, because it is a major PITA to do so.

Also the v210 "support" in VirtualDub is as far as I know something that doesn't work anywhere else, so that can, if you pardon my french, go suck itself. v210 is only "standard" in mov. I would much rather see the support for the saner, proper 10bit formats be added in VDub instead of a random format not meant for in-program use, but for creating an actual mov file for transport for loading it into something else. And for that, we have ffmpeg/avconv to do it for you. You just have to feed them the 10bit YCbCr.

Thank you.

Hmmm?

v210 is supported by almost every single software- from Vdub, through ffmpeg, Premiere, .... ending at high end grading tools and all preview cards- BM, AJA etc.
It works for AVI the same as for MOV- one can be re-wrapped with no problem. Whole broadcast industry uses v210, so it's not something rare. As I said- it's the most supported 10bit format out there (except DPX, but this is an image sequence).
Vdub is happy with v210- don't know about any problems with Vdub and v210 and I use it quite a lot.

I know that it's not a easy format to work with (for processing), that's why I said it can exist only on final output stage. This, what I'm talking about is eg. fake AVI (like current avfs showing up as YUY2), which would have v210 format. This would make it working with 99% existing software- there is no other 10bit format with such a broad support.
It's all about linking script to outside apps at higher than 8bit precision. Current avfs works very well, but only for 8bit. It's also about not have to render big v210 file, but use fake AVI as this is very useful solution. AVFS works very well and I hope there will be 10bit version of it.

[lansing]

ok i was able to solve my problem with the vd crashing from a kind forum member, it was caused by me setting the encoding of my vpy file to UTF-8, changing it back to ANSI solves it.

And since now I got the fake avi working, I will do some benchmarking with AVSMeter on pure avs and vpy in a avs wrapper, will report.

[Pat357]

I still have crashes in Vdub upon opening this script :

import vapoursynth as vs
import sys
core = vs.Core(accept_lowercase=True)
core.std.LoadPlugin(r'k:\programs\ffms2-r725-icl\ffms2.dll')
## src = core.ffms2.Source(r'k:\film\Battleship (2012) HDRip\Battleship.2012.mkv')
ret = core.ffms2.Source(r"k:\film\Battleship (2012) HDRip\Battleship.2012.mkv")
## src.output(sys.stdout, y4m=True)
last = ret

It works if I use "sys.stdout" and pipe the result to x264.

What do I need to modify to open it in vdub/MPC-HC/AVISource ?
Is there a FourCC specified for the VFW format ? Is this needed ?

I've r10 installed (=checked using "print(c.version())")

[lansing]

phaeron from virtualdub confirm (http://forums.virtualdub.org/index.php?act=ST&f=2&t=21254&) adding supports for vpy extension.


And i'm having small issue with argument having float value, like fft3dfilter(sigma=1.0) . I have to add a decimal in order for it to work, if i put "1" it will return invallid argument.

[Keiyakusha]

ok i was able to solve my problem with the vd crashing from a kind forum member, it was caused by me setting the encoding of my vpy file to UTF-8, changing it back to ANSI solves it.

And since now I got the fake avi working, I will do some benchmarking with AVSMeter on pure avs and vpy in a avs wrapper, will report.

By the way, this is interesting question. Can we have unicode support for .vpy files?

Edit: What are the names of planar colorspaces for 4:4:4 8+bit material? I know only these: P016,P010,P216,P210, but this is only 420 and 422. Microsoft website mentions something like Y410, but they are packed? So Vapoursynth have no choice but support something more than planar colorspaces?

[Chikuzen]

EDIT: my miss understanding, deleted

What are the names of planar colorspaces for 4:4:4 8+bit material? I know only these: P016,P010,P216,P210, but this is only 420 and 422. Microsoft website mentions something like Y410, but they are packed? So Vapoursynth have no choice but support something more than planar colorspaces?

It is not a name but FourCC(Identifier) which you have said.
They will be defined if Microsoft, other companies, or an person is needed.
Since Microsoft had not used the YUV444-Planar format yet in MediaFoundation, it is not exists now.

[Keiyakusha]

Edit: i wanted to ask if it possible to open image sequences in VS, but from what I see in documentation just now:ImageReader/ImageWriter none -- Planned, contributions welcomeit seems not. For example I'd like to open sequence of 5000 16bit per component PNG's or PSD's as 24000/1001fps video. I guess we need VS plugin based on DevIL for that. Well, 32bit per component hdr, psd, tiff should be an option too. From what I understand DevIL is capable of doing this.


They will be defined if Microsoft, other companies, or an person is needed.
Since Microsoft had not used the YUV444-Planar format yet in MediaFoundation, it is not exists now.
I see. But is it something that can be defined in vapoursynth? Won't it be better to just implement packed variants that already exist?

[Chikuzen]

Edit: i wanted to ask if it possible to open image sequences in VS
I wrote vsavsreader as a substitute until plugins for VS are developed.
You can use avisynth's ImageSource vis that.

I see. But is it something that can be defined in vapoursynth? Won't it be better to just implement packed variants that already exist?
VS has already defined those format names.
try as follows
>>> import vapoursynth
>>> print(help(vapoursynth))
you will find them at the end of descriptions.

[Keiyakusha]

I wrote vsavsreader as a substitute until plugins for VS are developed.
You can use avisynth's ImageSource vis that.
Yes I know about your handy plugin, thanks. But unfortunately avisynth is not capable of opening high bitdepth image sequences in any way. There is no even hacks for that (or I just never heard of them).
Of course 8bit images is possible, but there is no reason for me to have 8bit sequences, there is nice lossless video formats. There is no good lossless formats for 8+ bitdepth though... At least not the ones that are free and supported by different software

[Myrsloik]

they were done without the vfw thing already, tested well over 50k frames

___________________________________

cmd:
x264 --preset ultrafast --output avs_ben.mkv test.avs
[/code]

I've reproduced it. But I'm not quite sure why it happens. I also redid the comparison with avs2yuv (to add the piping overhead in both cases) and avisynth is then still 50% faster.

[Pat357]

Nice, I have VFW working with MPC & AVISource, but I get access violations with VirtualDUB v1.9.11.
I've tried the newer beta vdub v1.10.2, but got same problem.

Any idea what could be wrong ?
Thanks in advance !

crash report :


VirtualDub crash report -- build 32842 (release)
--------------------------------------

Disassembly:
00000000: 0000 add [eax], al <-- FAULT
00000002: 0000 add [eax], al
00000004: 0000 add [eax], al
00000006: 0000 add [eax], al
00000008: 0000 add [eax], al
0000000a: 0000 add [eax], al
0000000c: 0000 add [eax], al
0000000e: 0000 add [eax], al
00000010: 0000 add [eax], al
00000012: 0000 add [eax], al
00000014: 0000 add [eax], al
00000016: 0000 add [eax], al
00000018: 0000 add [eax], al
0000001a: 0000 add [eax], al
0000001c: 0000 add [eax], al
0000001e: 0000 add [eax], al
00000020: 0000 add [eax], al
00000022: 0000 add [eax], al
00000024: 0000 add [eax], al
00000026: 0000 add [eax], al
00000028: 0000 add [eax], al
0000002a: 0000 add [eax], al
0000002c: 0000 add [eax], al
0000002e: 0000 add [eax], al
00000030: 0000 add [eax], al
00000032: 0000 add [eax], al
00000034: 0000 add [eax], al
00000036: 0000 add [eax], al
00000038: 0000 add [eax], al
0000003a: 0000 add [eax], al
0000003c: 0000 add [eax], al
0000003e: 0000 add [eax], al
00000040: 0000 add [eax], al
00000042: 0000 add [eax], al
00000044: 0000 add [eax], al
00000046: 0000 add [eax], al
00000048: 0000 add [eax], al
0000004a: 0000 add [eax], al
0000004c: 0000 add [eax], al
0000004e: 0000 add [eax], al
00000050: 0000 add [eax], al
00000052: 0000 add [eax], al
00000054: 0000 add [eax], al
00000056: 0000 add [eax], al
00000058: 0000 add [eax], al
0000005a: 0000 add [eax], al
0000005c: 0000 add [eax], al
0000005e: 0000 add [eax], al
00000060: 0000 add [eax], al
00000062: 0000 add [eax], al
00000064: 0000 add [eax], al
00000066: 0000 add [eax], al
00000068: 0000 add [eax], al
0000006a: 0000 add [eax], al
0000006c: 0000 add [eax], al
0000006e: 0000 add [eax], al
00000070: 0000 add [eax], al
00000072: 0000 add [eax], al
00000074: 0000 add [eax], al
00000076: 0000 add [eax], al
00000078: 0000 add [eax], al
0000007a: 0000 add [eax], al
0000007c: 0000 add [eax], al
0000007e: 0000 add [eax], al
00000080: 0000 add [eax], al
00000082: 0000 add [eax], al
00000084: 0000 add [eax], al
00000086: 0000 add [eax], al
00000088: 0000 add [eax], al
0000008a: 0000 add [eax], al
0000008c: 0000 add [eax], al
0000008e: 0000 add [eax], al
00000090: 0000 add [eax], al
00000092: 0000 add [eax], al
00000094: 0000 add [eax], al
00000096: 0000 add [eax], al
00000098: 0000 add [eax], al
0000009a: 0000 add [eax], al
0000009c: 0000 add [eax], al
0000009e: 0000 add [eax], al
000000a0: 0000 add [eax], al
000000a2: 0000 add [eax], al
000000a4: 0000 add [eax], al
000000a6: 0000 add [eax], al
000000a8: 0000 add [eax], al
000000aa: 0000 add [eax], al
000000ac: 0000 add [eax], al
000000ae: 0000 add [eax], al
000000b0: 0000 add [eax], al
000000b2: 0000 add [eax], al
000000b4: 0000 add [eax], al
000000b6: 0000 add [eax], al
000000b8: 0000 add [eax], al
000000ba: 0000 add [eax], al
000000bc: 0000 add [eax], al
000000be: 0000 add [eax], al
000000c0: 0000 add [eax], al
000000c2: 0000 add [eax], al
000000c4: 0000 add [eax], al
000000c6: 0000 add [eax], al
000000c8: 0000 add [eax], al
000000ca: 0000 add [eax], al
000000cc: 0000 add [eax], al
000000ce: 0000 add [eax], al
000000d0: 0000 add [eax], al
000000d2: 0000 add [eax], al
000000d4: 0000 add [eax], al
000000d6: 0000 add [eax], al
000000d8: 0000 add [eax], al
000000da: 0000 add [eax], al
000000dc: 0000 add [eax], al
000000de: 0000 add [eax], al
000000e0: 0000 add [eax], al
000000e2: 0000 add [eax], al
000000e4: 0000 add [eax], al
000000e6: 0000 add [eax], al
000000e8: 0000 add [eax], al
000000ea: 0000 add [eax], al
000000ec: 0000 add [eax], al
000000ee: 0000 add [eax], al
000000f0: 0000 add [eax], al
000000f2: 0000 add [eax], al
000000f4: 0000 add [eax], al
000000f6: 0000 add [eax], al
000000f8: 0000 add [eax], al
000000fa: 0000 add [eax], al
000000fc: 0000 add [eax], al
000000fe: 0000 add [eax], al

Built on Aegis on Fri Dec 24 13:18:44 2010 using compiler version 1400

Windows 6.1 (Windows Vista x64 build 7601) [Service Pack 1]

EAX = 05e67f78
EBX = 0280fce8
ECX = 05e67f04
EDX = 05e67f78
EBP = 0018f67c
ESI = 0280e898
EDI = 0280e89c
ESP = 0018f61c
EIP = 00000000
EFLAGS = 00210202
FPUCW = 027f
FPUTW = ffff

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'VirtualDub'...

...reading address 00000000.

Pointer dumps:

EAX 05e67f78: 705c3a4b 72676f72 5c736d61 68747970 765f6e6f 2e322e33 65745c33 2e317473
EBX 0280fce8: 005fab98 00000001 00000000 0280e880 0280e880 00000000 00000000 00000100
ECX 05e67f00: 00000002 05e67f78 00000000 00000000 00000000 00000023 0000002f 00000000
EDX 05e67f78: 705c3a4b 72676f72 5c736d61 68747970 765f6e6f 2e322e33 65745c33 2e317473
ESI 0280e898: 005fa240 05e67efc 05e67ef0 00000001 17ad34de 80000000 00000056 00000000
EDI 0280e898: 005fa240 05e67efc 05e67ef0 00000001 17ad34de 80000000 00000056 00000000
ESP 0018f618: 05e67f04 6bff1e18 05e67f78 05e67f20 0280e89c 0280e898 0280fce8 0280fce8
0018f638: 0018f694 0053000e 656853a3 6bff7188 0018fbb0 00000000 00000000 0050000f
0018f658: 656853a3 00000000 04d3e980 027b0358 759f9e62 0018f6c8 0018f6cc 6bff18a4
0018f678: 05e67ef0 0018f6d8 6bff1dac 0280e89c 0280e898 0280fce8 0018f624 0018f6fc
EBP 0018f678: 05e67ef0 0018f6d8 6bff1dac 0280e89c 0280e898 0280fce8 0018f624 0018f6fc
0018f698: 0018f764 772471d5 0041f7e0 fffffffe 771fe38c 771fe0f2 00000010 00000000
0018f6b8: 771fe046 00730000 04d3e980 0018f72c 00000002 0018f728 6bff186a 05e67ef0
0018f6d8: 0018f72c 6bff2444 0280e89c 0280e898 0280fce8 0018f704 771fe023 028f8f00

Thread call stack:
6bff1e18: vsvfw!DllCanUnloadNow [6bff0000+14a0+978]
759f9e62: ole32!CoCreateInstanceEx [759b0000+49d4e+114]
6bff18a4: vsvfw!DllCanUnloadNow [6bff0000+14a0+404]
6bff1dac: vsvfw!DllCanUnloadNow [6bff0000+14a0+90c]
771fe38c: ntdll!RtlInitUnicodeString [771d0000+2e228+164]
771fe0f2: ntdll!RtlAllocateHeap [771d0000+2e046+ac]
6bff186a: vsvfw!DllCanUnloadNow [6bff0000+14a0+3ca]
6bff2444: vsvfw!DllCanUnloadNow [6bff0000+14a0+fa4]
771fe023: ntdll!RtlFreeHeap [771d0000+2dfa5+7e]
771fe023: ntdll!RtlFreeHeap [771d0000+2dfa5+7e]
005b2fb6: malloc()
004c74c4: AVIReadHandlerTunnelW32::AVIReadHandlerTunnelW32()
004c76ab: CreateAVIReadHandler()
004ce98b: InputFileAVI::Init()
772035a7: ntdll!RtlImageNtHeader [771d0000+33184+423]
7720389a: ntdll!RtlImageNtHeader [771d0000+33184+716]
75738443: USER32!GetClassLongW [75720000+183a8+9b]
772038be: ntdll!RtlImageNtHeader [771d0000+33184+73a]
7720389a: ntdll!RtlImageNtHeader [771d0000+33184+716]
7573d184: USER32!GetWindowLongA [75720000+1d156+2e]
7573d190: USER32!GetWindowLongA [75720000+1d156+3a]
7573d190: USER32!GetWindowLongA [75720000+1d156+3a]
77203492: ntdll!RtlImageNtHeader [771d0000+33184+30e]
7573d190: USER32!GetWindowLongA [75720000+1d156+3a]
7575f962: USER32!GetCursor [75720000+3f6e0+282]
7720389a: ntdll!RtlImageNtHeader [771d0000+33184+716]
77203492: ntdll!RtlImageNtHeader [771d0000+33184+30e]
7573717a: USER32!IsWindow [75720000+17136+44]
7573692a: USER32!gapfnScSendMessage [75720000+15fc8+962]
75737290: USER32!GetPropW [75720000+17227+69]
75737276: USER32!GetPropW [75720000+17227+4f]
75737257: USER32!GetPropW [75720000+17227+30]
75738e0d: USER32!RemovePropW [75720000+18dbd+50]
75738de4: USER32!RemovePropW [75720000+18dbd+27]
6e6876a5: uxtheme!GetThemeBool [6e670000+16651+1054]
6e687650: uxtheme!GetThemeBool [6e670000+16651+fff]
757362fa: USER32!gapfnScSendMessage [75720000+15fc8+332]
75736d91: USER32!GetThreadDesktop [75720000+16c63+12e]
75736d51: USER32!GetThreadDesktop [75720000+16c63+ee]
75736ce9: USER32!GetThreadDesktop [75720000+16c63+86]
75736d91: USER32!GetThreadDesktop [75720000+16c63+12e]
75736d51: USER32!GetThreadDesktop [75720000+16c63+ee]
75736de8: USER32!GetThreadDesktop [75720000+16c63+185]
75736df3: USER32!GetThreadDesktop [75720000+16c63+190]
75736df3: USER32!GetThreadDesktop [75720000+16c63+190]
75739a21: USER32!FindWindowW [75720000+198fd+124]
771ef8ca: ntdll!NtCallbackReturn [771d0000+1f8b8+12]
75739a49: USER32!FindWindowW [75720000+198fd+14c]
771e010a: ntdll!KiUserCallbackDispatcher [771d0000+100dc+2e]
7573692a: USER32!gapfnScSendMessage [75720000+15fc8+962]
7575cdb3: USER32!DialogBoxIndirectParamW [75720000+3cbf3+1c0]
7575cf5c: USER32!DialogBoxIndirectParamAorW [75720000+3ce54+108]
7577cb58: USER32!DialogBoxParamA [75720000+5cb0c+4c]
004cc7d9: InputFileAVI::promptForOptions()
00464e4e: VDProject::Open()
0051d29e: VDAutoLogger::VDAutoLogger()
00453e5c: OpenAVI()
0046c491: VDProjectUI::MenuHit()
75736b00: USER32!gapfnScSendMessage [75720000+15fc8+b38]
004794a0: VDUIFrame::DefProc()
0046da41: _catch$?MainWndProc@VDProjectUI@@IAEJIIJ@Z$0()
00465ac0: VDProjectUI::WndProc()
00479b65: VDUIFrame::StaticWndProc()
757362fa: USER32!gapfnScSendMessage [75720000+15fc8+332]
75736d3a: USER32!GetThreadDesktop [75720000+16c63+d7]
75736ce9: USER32!GetThreadDesktop [75720000+16c63+86]
771e010a: ntdll!KiUserCallbackDispatcher [771d0000+100dc+2e]
757377c4: USER32!CharPrevW [75720000+1768c+138]
757460dc: USER32!PeekMessageA [75720000+25f74+168]
75737bca: USER32!DispatchMessageA [75720000+17bbb+f]
00452596: WinMain@16()
005b78db: __tmainCRTStartup()
74b4339a: kernel32!BaseThreadInitThunk [74b30000+13388+12]
77209ef2: ntdll!RtlInitializeExceptionChain [771d0000+39e8f+63]
77209ec5: ntdll!RtlInitializeExceptionChain [771d0000+39e8f+36]

-- End of report

[Chikuzen]

I've reproduced it. But I'm not quite sure why it happens. I also redid the comparison with avs2yuv (to add the piping overhead in both cases) and avisynth is then still 50% faster.

Isn't it based on the difference in Bitblt() of avisynth and vapoursynth?
avisynth has ISSE optimized one, but ffms2 for VS has only pure C++ code.

[Myrsloik]

Isn't it based on the difference in Bitblt() of avisynth and vapoursynth?
avisynth has ISSE optimized one, but ffms2 for VS has only pure C++ code.

The one in VS is sse2 optimized. I disassembled msvcr100.dll myself and took a look. Did you really think microsoft wouldn't optimize such a common function as memcpy?

Oh, and the output is never explicitly copied in that way. It's passed to the WriteFile()

[lansing]

Nice, I have VFW working with MPC & AVISource, but I get access violations with VirtualDUB v1.9.11.
I've tried the newer beta vdub v1.10.2, but got same problem.

Any idea what could be wrong ?
Thanks in advance !



have you try changing the vpy's encoding to ANSI like i mention a few posts back? Did your script contain non English letter? Try make it all in English if that's the case.

Have you follow the instruction exactly the R10 update blog said? Like switching the "file of type" first before opening the vpy file?

http://www.vapoursynth.com/


if you got it to work with the avisource avs wrapper, it shouldn't be a problem opening the original vpy file with virtualdub.

[Pat357]

if you got it to work with the avisource avs wrapper, it shouldn't be a problem opening the original vpy file with virtualdub.
Got it working now ! Thanks a lot !
Don't know what exactly caused the problems : I deleted all registry settings from vdub, restarted PC and voila, it worked.
The codepage settings is a good tip to check if things all sudden "break" again.

[Keiyakusha]

Not sure if I did it right. Does everything really as good as it seems? Well maybe not that good, but It seems there is some improvements over pure avisynth.
so i made this script:
import vapoursynth as vs
import sys
core = vs.Core(threads=4)
core.std.LoadPlugin(path=r"..\ffms2.dll")
core.avs.LoadPlugin(path=r"..\mvtools2.dll")
ret=core.ffms2.Source(r"..\test8.mkv")
src=ret
c = core.avs.MSuper(c1=src,pel=2, sharp=1)
bv3 = core.avs.MAnalyse(c1=c, isb = 1, delta = 3, overlap=4)
bv2 = core.avs.MAnalyse(c1=c, isb = 1, delta = 2, overlap=4)
bv1 = core.avs.MAnalyse(c1=c, isb = 1, delta = 1, overlap=4)
fv1 = core.avs.MAnalyse(c1=c, isb = 0, delta = 1, overlap=4)
fv2 = core.avs.MAnalyse(c1=c, isb = 0, delta = 2, overlap=4)
fv3 = core.avs.MAnalyse(c1=c, isb = 0, delta = 3, overlap=4)
ret = core.avs.MDegrain3(c1=src,c2=c,c3=bv1,c4=fv1,c5=bv2,c6=fv2,c7=bv3,c8=fv3,thSAD=400)
last=ret

test clip is an SD 480p 8bit 24fps video
1) I opened this in avisynth via vfw module and checked speed. it was around 20.8fps, cpu load 30%
2) I ran the same script but in pure avs environment, speed was around ........ 8.77fps, cpu load 13%
3) Same as #2, but I enabled avisynth's multithreading with 4 threads. Speed: 27.8fps, cpu load 52%
3.5) Same as #3, but FFMS2 limited to 1 thread......................................... 30fps, cpu load 52%
4) Same as #2, but I enabled avisynth's multithreading with 8 threads. Speed: 36.8fps, cpu load 100%
5) doing the same as #1 but setting vs Core to 8 threads results.................. 21.6fps, cpu load 35% with spikes up to 52%

Now I need to chose which one is best compromise between speed/resources used ^__^
P.S.
I used mvtools from SVP and latest not broken SET's avisynth, measured with avsmeter 1.20

[Pat357]

1) I opened this in avisynth via vfw module and checked speed. it was around 20.8fps, cpu load 30%
3.5) Same as #3, but FFMS2 limited to 1 thread......................................... 30fps, cpu load 52%

It seems (1) and (3.5) are close to each other if you look at fps / %cpu (efficiency).

5) doing the same as #1 but setting vs Core to 8 threads results.................. 21.6fps, cpu load 35% with spikes up to 52%
Not exactly the best scaling I've ever seen :p
Something must be wrong : I can't believe the scaling is *that* bad !

[Myrsloik]

It seems (1) and (3.5) are close to each other if you look at fps / %cpu (efficiency).

Not exactly the best scaling I've ever seen :p
Something must be wrong : I can't believe the scaling is *that* bad !

The scaling isn't that bad. It's the vfw module that is. Unlike clip.output() it doesn't have multiple output frames going at once (the output function by default is doing 10 frames at once to keep throughput up).

Redo the test with script.py > NUL and it should reach near 100% cpu usage. Also, this isn't ricersynth, setting more threads than cores in vs most likely won't do you any good.

[Keiyakusha]

It seems (1) and (3.5) are close to each other if you look at fps / %cpu (efficiency).
Yep. It looks like so. But if in #1 case vapoursynth's processing uses totally separate threads from avisynth's one and then just supplies avisynth with frames, then by adding some more avisynth filters it may be more efficient than going pure AVS path. And my processing never limited to MDegrain only. I also didn't tried limiting ffms2 to 1 thread in vapoursynth's case, it may add few frames per second too. Edit: but this may be not an option for HD video, because 1 thread won't be fast enough to prepare decoded frames...

It seems (1) and (3.5) are close to each other if you look at fps / %cpu (efficiency).
its not that bad as it looks. see avisynth's #4, 50% cpu is capable of doing 30fps (tested cpu is 8 cores btw), but 100% only ~37fps? where all those resources are going!? I wonder if SET is hiding something like SETI@home in his builds ^__^
at least vapoursynth doesn't eats CPU that much if it can't make use of it.

[06_taro]

Test some clips, avsr/avs/native:

vs-ffms-avsr.py
#!/bin/env python
# coding: utf-8

import vapoursynth as vs
import sys

core = vs.Core()

core.std.LoadPlugin(path=r"d:\Program Files\Media\VapourSynth\vsavsreader.dll")
ret = core.avsr.Eval(r"""FFVideoSource("e:\test_clip-1280x720_8bpp.mp4")""")

ret.output(sys.stdout, y4m=True)

vs-ffms-avs.py
#!/bin/env python
# coding: utf-8

import vapoursynth as vs
import sys

core = vs.Core()

core.avs.LoadPlugin(path=r"d:\Program Files\Media\VapourSynth\ffms2.dll")
ret = core.avs.FFVideoSource(r"e:\test_clip-1280x720_8bpp.mp4")

ret.output(sys.stdout, y4m=True)

vs-ffms-native.py
#!/bin/env python
# coding: utf-8

import vapoursynth as vs
import sys

core = vs.Core()

core.std.LoadPlugin(path=r"d:\Program Files\Media\VapourSynth\ffms2.dll")
ret = core.ffms2.Source(r"e:\test_clip-1280x720_8bpp.mp4")

ret.output(sys.stdout, y4m=True)

At first I found avsr was slightly faster (really slightly, no more than 2%), meaning totally use avs runtime wrapper was faster, but I was aware that ffms2.dll in my avs plugin directory was an old version r700 compiled by SAPikachu. Replaced it by latest r725 icl version (didn't find a gcc+msvc version) and re-tested, avsr version was the slowest of all, but the difference was not that large as in some posts in the last pages:
http://www.nmm-hd.org/upload/get~JDDMbfbPmBg/avsr-avs-native.png

Test clip was 1280x720 8-bit avc in mp4, avisynth.dll was 2.60 MT 28 Aug by SEt, and VapourSynth was r10. CPU usage was about the same, ~87% on my i7-2670qm, as I had set the affinity of bash and its child processes to 0x7F and all other CPU-comsuming processes in the background ( mainly browsers ) to 0x80.

Also tested on some other 8-bit sources, and in most cases the results were similar.

[AzraelNewtype]

There is no good lossless formats for 8+ bitdepth though... At least not the ones that are free and supported by different software

I use lossless hi10p h.264 weekly, x264 has no qualms about generating it, and ffms2 can read it back in. In fact, in vs, it will read it back at native 10-bit rather than dithering to 8-bit like the avs version of the function. It's Neat.

[Myrsloik]

I've released r11. Update to Python 3.3 before installing. More or less completes the VFW stuff and fixes the performance issues. Redo the VFW benchmarks with this version and see what happens...

Here's a blog post as usual.
R11 – VFW returns and Python 3.3 (http://www.vapoursynth.com/2012/10/r11-vfw-returns-and-python-3-3/)

[kolak]

What are the 8bit+ formats supported- P210?

[Myrsloik]

P010, P016, P210, P216 are the ones I added. I tested with mpc-hc and madvr. I didn't add any 444 formats because the ones specified by ms are packed only.
As usual pushing to have other programs support these formats is appreciated.

[kolak]

v210, ProRes seams to be fine and madVR reports P210 :) I hope for better support for these formats.

What do I have to type in resizer format to scale in P210 format?

[Myrsloik]

v210, ProRes seams to be fine and madVR reports P210 :) I hope for better support for these formats.

What do I have to use to scale in P210 format?

To scale in? I don't understand what you mean. The format constants are YUV420P10/16 and YUV422P10/16 for use with the resizers if that's what you mean.

[kolak]

Sorry- yes in resizer :)

It works, but I don't have anything to convert P210 format to eg v210, to be useful :)
Need to wait for some solutions :(

[lansing]

forget about this benchmarks because I messed up output big time

[pie]

I'm not sure if I'm doing something wrong, but whenever I try to feed a 10-bit h264 clip as input (using ffms2) (P010 format?) I'm getting 'Frame returned not of the declared type' whenever I try to output it.

Edit:
Ok my bad - was passing it to a filter first which probably doesn't even support 10-bit input.

[Keiyakusha]

I use lossless hi10p h.264 weekly, x264 has no qualms about generating it, and ffms2 can read it back in. In fact, in vs, it will read it back at native 10-bit rather than dithering to 8-bit like the avs version of the function. It's Neat.

unfortunately professional editing software not allows to save output in h264 10-bit lossless, and I need format that can contain 16bit(or 32) information more often than 10bit.
Edit: actually this is not a problem. I was just saying that ability to process this kind of images in vapoursynth will be good. Since it doesn't have bitdepth limitations.

[JEEB]

Sorry- yes in resizer :)

It works, but I don't have anything to convert P210 format to eg v210, to be useful :)
Need to wait for some solutions :(
As I said, if you want v210 you go and push out the raw yuv420p10 into ffmpeg or avconv, and then output v210. Vapoursynth python scripts output their stuff to stdout so it has already been possible for quite a while.

v210 is not an in-memory colorspace that you want to use for moving of pictures in memory for other filters/applications, as it starts packing values into the "leftover" bits of the used bytes to save space. Which makes sense for file output (get a somewhat smaller file size), but makes exactly zero sense as something that would get used deliver pictures from within memory IMHO.

[active1]

i have an error on ubuntu after compiling vapoursynth

i compiled it successfully with the install instruction and i get this error after:
import vapoursynth as vs
import sys
and when:
c = vs.Core()

AttributeError: 'module' object has no attribute 'Core'

python version is 3.2.2
NOTE: i tried that before 24 hours, so vapoursynth was in r10

vfw now has support for the P010, P016, P210, P216 formats, tested in mpc-hc with madvr
great!! :thanks: