Vapoursynth

[Keiyakusha]

Originally Posted by Reel.Deel

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.

Originally Posted by Reel.Deel

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]

Originally Posted by Keiyakusha

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.

Originally Posted by Keiyakusha

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

[Myrsloik]

Originally Posted by Keiyakusha

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]

Originally Posted by Myrsloik

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]

Originally Posted by lansing

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]

Originally Posted by lansing

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]

Originally Posted by mastrboy

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]

Originally Posted by Myrsloik

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]

Originally Posted by JEEB

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 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]

Originally Posted by 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.

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 welcome

it 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.

Originally Posted by Chikuzen

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]

Originally Posted by Keiyakusha

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]

Originally Posted by Chikuzen

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]

Originally Posted by lansing

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]

Originally Posted by Myrsloik

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.