View Full Version : Vapoursynth
Myrsloik
1st October 2012, 13:13
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
great!! :thanks:
I'm not sure why it won't work for you. Did you use a recent cython version? Does print(vs.YUV420P8) work?
My sources tell me that this happened with some revisions. Try updating to the latest revision.
kolak
1st October 2012, 13:13
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.
Understand this, that's why I said it can be implemented on final level/output in some tool like avfs. Can this be done?
JEEB
1st October 2012, 13:52
Understand this, that's why I said it can be implemented on final level/output in some tool like avfs. Can this be done?
Yes? As far as I know you can get raw 10bit YCbCr that ffmpeg/avconv understands from Vapoursynth, and you can output v210 from it. See a part of the post you yourself quoted.
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.
it would be something like ffmpeg/avconv -f rawvideo -s WIDTHxHEIGHT -pix_fmt yuv422p10le -i - -c:v v210 out.mov
from the ffmpeg/avconv side. Just pipe yuv422p10le or the be alternative from vapoursynth (and switch the pix_fmt as needed). I am assuming that a lone - will work as the marker for "input comes from stdin".
Myrsloik
1st October 2012, 14:02
Now I need some input on which frame statistics to implement. If you generalize all of the functions in avisynth you get these 6 left. I've seen that difference is used a lot but are there any of these I could skip? I can't remember seeing the min/max/median used ever.
You can also suggest new ones if they're not too complicated.
Average(clip)
Difference(clip1, clip2)
PlaneMax(clip, float threshold)
PlaneMin(clip, float threshold)
PlaneMedian(clip)
PlaneMinMaxDifference(clip, float threshold)
The full list here:
http://avisynth.org/mediawiki/ScriptClip
Keiyakusha
1st October 2012, 14:17
Is it possible to mimic histogram(mode=luma) function of avisynth? So the output will be exactly the same? I wonder how that will look with 8+ bit streams... For me this is probably most often used function in avisynth, not counting ffms2 as source filter.
Well, actually there can be one difference. avisynth's histogram mode-luma have a bug/feature, while keeping colorspace intact it expands tv levels to PC and user have no control over that. Also I don't see why it should be limited to luma only. Specifying which plane you want to see as an option should be not bad idea.
kolak
1st October 2012, 14:31
Yes? As far as I know you can get raw 10bit YCbCr that ffmpeg/avconv understands from Vapoursynth, and you can output v210 from it. See a part of the post you yourself quoted.
it would be something like ffmpeg/avconv -f rawvideo -s WIDTHxHEIGHT -pix_fmt yuv422p10le -i - -c:v v210 out.mov
from the ffmpeg/avconv side. Just pipe yuv422p10le or the be alternative from vapoursynth (and switch the pix_fmt as needed). I am assuming that a lone - will work as the marker for "input comes from stdin".
Thanks, but this is not my goal. I use ffmpeg, when needed to create v210, but I don't want big file :)
What I want is to turn script into fake AVI v210 file, to avoid rendering time and save space. I want exactly the same as avfs does, but with v210 format at the output as this would make it compatible with every software I use. My whole v210 idea is just for broad compatibility with many different software. As far as I understand you have to implement v210 format into avfs. AVFS author was not interested in it, as before there was no proper 10bit format in avisynth. Now it has changed, so I hope such a tool will be done. I can donate money for it, no problem. At the end it's not that difficult is it (I'm not a programmer, so can't judge)?
Andouille
1st October 2012, 14:36
Is it possible to mimic histogram(mode=luma) function of avisynth? So the output will be exactly the same? I wonder how that will look with 8+ bit streams... For me this is probably most often used function in avisynth, not counting ffms2 as source filter.
Well, actually there can be one difference. avisynth's histogram mode-luma have a bug/feature, while keeping colorspace intact it expands tv levels to PC and user have no control over that. Also I don't see why it should be limited to luma only. Specifying which plane you want to see as an option should be not bad idea.
The equivalent version with masktools is near 3 times faster
mt_lut (expr="x 16 &u 17 x 15 &u - 1 x 15 &u + ? 14 *", u=-128, v=-128)
edit: assuming there is a vapoursynth version of masktools
Myrsloik
1st October 2012, 14:51
The equivalent version with masktools is near 3 times faster
mt_lut (expr="x 16 &u 17 x 15 &u - 1 x 15 &u + ? 14 *", u=-128, v=-128)
edit: assuming there is a vapoursynth version of masktools
See the documentation for std.lut (and lut2).
JEEB
1st October 2012, 15:32
What I want is to turn script into fake AVI v210 file, to avoid rendering time and save space. I want exactly the same as avfs does, but with v210 format at the output as this would make it compatible with every software I use. My whole v210 idea is just for broad compatibility with many different software.
Tell me software that takes in v210 in AVI. As far as I know, that pretty much limits itself to VirtualDub. It is only standard in Quicktime's media format (mov) as far as I know.
I would be happy to be proven otherwise though, but I'm not exactly counting on it :P
Edit: Take in as in actually in 10bit 4:2:2. There are VFW components from "Drastic.tv" and another from something called "AJA". I am very much unsure if those will actually give 10bit YCbCr to most applications in, in which case whether or not it's 10bit loses all meaning. Not to mention that the V210 used by those might be a completely different thing compared to the one used in Quicktime. But as I said, you may surprise me if you choose so.
Keiyakusha
1st October 2012, 15:41
Tell me software that takes in v210 in AVI.
pretty much any professional software? AfterEffects would be good example. It happily creates and takes it.
edit: believe it or not, even photoshop takes it. you need extended version to enable video editing
Reel.Deel
1st October 2012, 15:49
I can confirm Sony Vegas accepts and creates avi V210.
Avi created with Vegas.
Format : YUV
Codec ID : v210
Codec ID/Hint : AJA Video Systems Xena
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Compression mode : Lossless
JEEB
1st October 2012, 15:52
pretty much any professional software? AfterEffects would be good example. It happily creates and takes it.
Is that really in AVI?
Is that really the same type of V210 that is used in MOV? Or is it something else?
Is it really natively supported, or is it random VFW modules that are being used, as this usually makes it harder to believe that the application is actually giving out 10bit YCbCr in there instead of the VFW encoder encoding whatever it is given into 10bit YCbCr (which could be OK if it is the one doing the possible RGB->YCbCr conversion and it is doing it well)? As for decoding, the same things can be asked about how and in what sense the stuff gets loaded in.
I'm sorry for being a possible arse, but I just know way too well that the truth inside certain "pro" workflows aren't as good as they are made to sound. Using something like the V210 from Apple only makes sense to get hacked somewhere if it really, really is supported in VFW/AVI properly. Otherwise it really has zero reason to exist anywhere close to any output format for something like VapourSynth.
Edit:
Just heard that in most cases the VFW V210 "decoders" available in most cases output RGB to the calling application. How is this better than just putting out RGB to begin with, and do some !VirtualDub applications actually support the format as actual 10bit YCbCr?
Pat357
1st October 2012, 15:53
Where can I get "VSavsreader.dll" from Chikuzen ?
StainlessS
1st October 2012, 15:55
VSavsreader by Chikuzen
http://forum.doom9.org/showthread.php?t=165957
Keiyakusha
1st October 2012, 16:05
Is that really in AVI?
Is that really the same type of V210 that is used in MOV? Or is it something else?
Is it really natively supported, or is it random VFW modules that are being used, as this usually makes it harder to believe that the application is actually giving out 10bit YCbCr in there instead of the VFW encoder encoding whatever it is given into 10bit YCbCr (which could be OK if it is the one doing the possible RGB->YCbCr conversion and it is doing it well)? As for decoding, the same things can be asked about how and in what sense the stuff gets loaded in.
I think mediainfo answers 1st 2 questions.
3rd not sure if I fuly understand you, but it doesn't depends on anything in windows to be able to read or write that
this it creates and reads edit: it is not converted to anything, I'm getting real 10bit stuff when open this file. this is why they made it to begin with.
Format : AVI
Format/Info : Audio Video Interleave
File size : 63.3 MiB
Duration : 501ms
Overall bit rate : 1 060 Mbps
Writing application : Adobe After Effects CS6 (Windows)
Video
ID : 0
Format : YUV
Codec ID : v210
Codec ID/Hint : AJA Video Systems Xena
Duration : 501ms
Bit rate : 1 061 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Compression mode : Lossless
Bits/(Pixel*Frame) : 21.333
Stream size : 63.3 MiB (100%)
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
File size : 63.3 MiB
Duration : 501ms
Overall bit rate mode : Constant
Overall bit rate : 1 060 Mbps
Writing library : Apple QuickTime
ゥTIM : 00:00:00:00
ゥTSC : 2997
ゥTSZ : 125
Video
ID : 1
Format : YUV
Codec ID : v210
Codec ID/Hint : AJA Video Systems Xena
Duration : 501ms
Bit rate mode : Constant
Bit rate : 1 061 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Compression mode : Lossless
Bits/(Pixel*Frame) : 21.333
Stream size : 63.3 MiB (100%)
JEEB
1st October 2012, 16:21
3rd not sure if I fuly understand you, but it doesn't depends on anything in windows to be able to read or write that
That indeed does answer most of my questions, but the final one is actually the most important. Does this enable you really, really to get 10bit YCbCr into those applications as such, like in theory you are getting on the QT side?
If yes, then it kind of makes sense. Adding this overcomplicated format that can barely be called "raw" (you can't just call out a certain pixel without doing bit-based parsing) just to have you get YUY2 or RGB out of it really makes no sense, and that is why I have been so adamant on the actual users of this format (mainly kolak, who seemingly is rather out-of-touch with the technical issues) to be sure that they are actually getting 10bit YCbCr out of it.
Edit: Meh, if someone wants to implement it its their own thing. I just seemingly got tired of someone poking/spamming about it all the time while it was probably better off being implemented in something that possibly isn't VapourSynth itself, but something that possibly uses the API or the output from VapourSynth.
lansing
1st October 2012, 16:27
I wanted to load a avs core function like TemporalSoften, since it doesn't have it's own dll, how do i call it in vpy?
ajp_anton
1st October 2012, 16:57
Now I need some input on which frame statistics to implement. If you generalize all of the functions in avisynth you get these 6 left. I've seen that difference is used a lot but are there any of these I could skip? I can't remember seeing the min/max/median used ever.
You can also suggest new ones if they're not too complicated.
Average(clip)
Difference(clip1, clip2)
PlaneMax(clip, float threshold)
PlaneMin(clip, float threshold)
PlaneMedian(clip)
PlaneMinMaxDifference(clip, float threshold)
The full list here:
http://avisynth.org/mediawiki/ScriptClipIsn't PlaneMinMaxDifference just PlaneMax-PlaneMin? Haven't tried it, just going by the name.
Can't difference be done using lut2 and average?
I've used Max and Min a few times. Please don't go the Apple route and remove everything that's not absolutely crucial, leave something for people to play around with =).
Maybe you should name them all Plane[...], e.g. PlaneAverage etc. Then add an argument for choosing which luma/chroma/RGB plane to use.
Keiyakusha
1st October 2012, 17:14
That indeed does answer most of my questions, but the final one is actually the most important. Does this enable you really, really to get 10bit YCbCr into those applications as such, like in theory you are getting on the QT side?
Well, I wasn't following your discussion with kolak, sorry. I just spotted interesting question. Personally I don't use this format, I prefer something losslessly compressed. After importing, software reports that it have trillions of colors, but i never did any tests to check if this is really so. But I don't think they will implement this just to dither it silently at some point. Any formats that are supported and opened not via directshow are opened without conversions.
Pat357
1st October 2012, 17:52
Well, I wasn't following your discussion with kolak, sorry. I just spotted interesting question. Personally I don't use this format, I prefer something losslessly compressed. After importing, software reports that it have trillions of colors, but i never did any tests to check if this is really so. But I don't think they will implement this just to dither it silently at some point. Any formats that are supported and opened not via directshow are opened without conversions.
Isn't the Windows VfW engine used to open these files ?
What happens if you drop such a v210 file in MPC-HC/MadVR ?
What exact error do you get (if any) ?
kolak
1st October 2012, 17:53
Tell me software that takes in v210 in AVI. As far as I know, that pretty much limits itself to VirtualDub. It is only standard in Quicktime's media format (mov) as far as I know.
I would be happy to be proven otherwise though, but I'm not exactly counting on it :P
Edit: Take in as in actually in 10bit 4:2:2. There are VFW components from "Drastic.tv" and another from something called "AJA". I am very much unsure if those will actually give 10bit YCbCr to most applications in, in which case whether or not it's 10bit loses all meaning. Not to mention that the V210 used by those might be a completely different thing compared to the one used in Quicktime. But as I said, you may surprise me if you choose so.
Almost every editing software: Premiere, Vegas, Edius, FCP, Lightgworks, grading software: Resolve, Scratch, etc (through ref MOV), all capture cards/their software: AJA, BlackMagic, Blufish444 etc, most open source software: Vdub, ffmpeg....
It's actually hard to name software, which does not open v210 AVI or MOV. Whole broadcast industry is based on v210 (if I'm correct HD-SDI standard uses v210 format).
It's the same format for MOV and AVI and can be easily re-wrapped with eg ffmpeg.
Myrsloik
1st October 2012, 17:55
Isn't PlaneMinMaxDifference just PlaneMax-PlaneMin? Haven't tried it, just going by the name.
Can't difference be done using lut2 and average?
I've used Max and Min a few times. Please don't go the Apple route and remove everything that's not absolutely crucial, leave something for people to play around with =).
Maybe you should name them all Plane[...], e.g. PlaneAverage etc. Then add an argument for choosing which luma/chroma/RGB plane to use.
I'm not quite pulling an Apple, I just happen to be a single unemployed human being who codes between applying for jobs. That's why I try to spread the functions as much as possible, so if you can synthesize a function in 3 steps or less from the available ones then I won't implement it... for now.
That reminds me, I should try to extract some of the more useful avisynth core functions as a separate plugin.
kolak
1st October 2012, 18:00
Isn't the Windows VfW engine used to open these files ?
What happens if you drop such a v210 file in MPC-HC/MadVR ?
What exact error do you get (if any) ?
If you have 10bit VFW codec (Drastic, AJA, BM , LAV, Cineform etc) it gets decoded to some 8bit format (YUY2, RGB etc) and passed to be displayed/processed. This is when some software does not support 10bit natively.
With something like madVR it gets displayed at 10bit directly.
Most of the software will read 10bit data directly also, so you can process it at high precision. This is whole idea to have access to "real 10bit" from almost every software and something like fake AVI (like avfs does for 8bit) is great solution to save space and make things easy and simple :)
kolak
1st October 2012, 18:02
Well, I wasn't following your discussion with kolak, sorry. I just spotted interesting question. Personally I don't use this format, I prefer something losslessly compressed. After importing, software reports that it have trillions of colors, but i never did any tests to check if this is really so. But I don't think they will implement this just to dither it silently at some point. Any formats that are supported and opened not via directshow are opened without conversions.
Yes- this is an "other" solution and I use it with lav decoder and avfs :) Sometime I need real 10bit data thought.
Keiyakusha
1st October 2012, 18:02
Isn't the Windows VfW engine used to open these files ?
What happens if you drop such a v210 file in MPC-HC/MadVR ?
What exact error do you get (if any) ?
no. not vfw
under x86 architecture I can play this file using LAV source filter+madvr because madvr supports direct v210 input, this is the only way I know. http://i.imgur.com/eZT99.png (without installing 3rd party software that I don't have anyway)
under pure x64 I have no way to play this outside editing software. and adobe dropped x86 support anyway.
edit: oops I'm slow...
JEEB
1st October 2012, 18:11
...
I already finished my discussion on this with the last edit I had, but it seems like I have to really "bend my point for you with iron wire", as the point seems to have gone over your head in any case.
First of all, yes -- V210 in MOV is a standard. That can be expected to work as advertised in QuickTime and related applications that use similar ways of loading the material up. I never said anything about that, and I knew that it's a more or less standard way of doing it on the Mac side of things (and Windows-based solutions that can load up V210 in MOV). My point and questioning was all the time only, and only about V210 in AVI and related Windows-based solutions.
In other words, I was more or less trying to find out if anyone had actually checked if that 10bit YCbCr that is in V210 was actually getting loaded as such from AVI. No-one so far has really said anything towards this, and the damn VFW components available from two different companies regarding this in most cases output RGB or possibly 8bit YCbCr. I know checking this in closed applications isn't easy, but it should be possible.
I hope you understand my point better now.
Disregarding that, the nature of V210 is what it is, and you are better off asking for it in some other context and less spammy. Or just get someone implement it for you, shouldn't be too hard if you can find someone with the time, interest and capabilities. Just don't spam it all the time.
kolak
1st October 2012, 18:18
I still don't see a problem (your point)- v210 is a way of storing RAW data (just packed) and (I assume) it's not that difficult to read this data natively and MANY apps do it.
I don't know other 10bit format, which is as well supported maybe except DPX or other image sequences- do you know any?
As far as I know it's bit more difficult to store v210 in AVI, but in the same time v210 in AVI is also very well supported (as per my other post).
8bit output is only for apps which don't support 10bit natively- similar to fact that some software may not support YUY2, but does RGB, so it needs "converter/codec" to read this data.
Yes- there is enough info in this thread about v210.
Keiyakusha
1st October 2012, 18:28
By the way until now I didn't know LAV decoder is able to "decode" (convert) v210, just found out about it! But anyway this is turned off by default, and as I said, adobe software supports x64 only, so LAV x86 won't work anyway.
edit: also not sure if this is related, but after JEEB mentioned YUV-RGB conversions I think I should note that premiere for example tries not to do conversion where it is possible. So depending on processing done, we can have yuv in - yuv out with no conversion to rgb (well, only for display)
kolak
1st October 2012, 19:00
Use LAV decoder and map your script as fake YUY2 AVI with avsp and load this to Adobe apps :)
Add distributor for multithreading with avsp.
Sorry for spam, but can't send private message to Keiyakusha.
JEEB
1st October 2012, 19:01
I still don't see a problem (your point)
My point was whether or not that pro stuff actually reads it natively or not from AVI, because it really would be completely and utterly useless if it would then just get converted to RGB or 8bit YCbCr when being read up. I know you want it, but I wanted to make sure that you can actually reap the damn rewards from what you are asking.
OK? Simple enough? That was it. And the thing that your posts about V210 were getting annoying. It's handled as a video codec instead of a colorspace in ffmpeg/libav for a reason.
Also, looking at the answers of people who are seemingly less oblivious, and giving them the benefit of doubt, it would seem that at least some of those tools actually read V210 properly from AVI instead of raping it. So that's it.
lansing
1st October 2012, 19:15
this reminds me a lot of the dude in the pcsx2 emulator development page a year back, who spam every revision updates asking to fix his precious super robot taisen game and thumbing down every single revision he sees. And one of the developer got so pissed and this happened:
http://code.google.com/p/pcsx2/source/detail?r=4525
kolak
1st October 2012, 19:16
My point was whether or not that pro stuff actually reads it natively or not from AVI, because it really would be completely and utterly useless if it would then just get converted to RGB or 8bit YCbCr when being read up. I know you want it, but I wanted to make sure that you can actually reap the damn rewards from what you are asking....
No problem- I just jumped few posts back and to answer your question- ALL software which I mentioned reads REAL data out of v210 AVI. ONLY software, which does not support v210 natively will use codec (AJA, BM etc), which will output some 8bit data (in most cases conversion is without any dithering, so quite crap). MOV support is bit better, but if you have v210 AVI you can make reference MOV and it also will work as this is the same raw data:). I hope it's clear now, v210 case is closed and I hope they will be some "port" from vpy to fake v210 AVI (or MOV).
Myrsloik
1st October 2012, 19:18
Now you're giving me ideas :sly:
kolak
1st October 2012, 19:23
At least can help in this way :)
active1
1st October 2012, 21:23
I'm not sure why it won't work for you. Did you use a recent cython version? Does print(vs.YUV420P8) work?
i used Cython-0.17.1
and print(vs.YUV420P8) give me the same error:
AttributeError: 'module' object has no attribute 'YUV420P8'
My sources tell me that this happened with some revisions. Try updating to the latest revision.
ok, i will :)
lansing
1st October 2012, 22:24
how do you run test using the "$ time..." command? I try typing it in my cmd and it said $ is not regconized
mastrboy
1st October 2012, 22:42
how do you run test using the "$ time..." command? I try typing it in my cmd and it said $ is not regconized
It's not a builtin windows command, you can install cygwin to get most of the basic *nix commands for windows.
(And the $ is just the PS1 variable, just like prompt in windows cmd, so the command is just "time")
Mug Funky
2nd October 2012, 03:23
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.
hehe... hope the dream isn't gone.
i wouldn't dare add to the v210 spam without adding to your donation bucket (and i'm broke-arse at the moment), but i'll give you a little background on the way it's like that.
basically it goes down the pipes that way, and the standards came from a time when computers were big and dumb and storage was precious (and mostly tape-based). capture cards grab this v210 off the SDI cables as-is, demux the audio channels and the video, and stuff it all into whatever container the software wants.
quicktime itself will load v210 avi files no problem (as will qtinput in avisynth, which is a lifesaver)
blackmagic's capture program will only capture v210 in avi on PC's, but will do mov on mac
CCE 2 and 3 will take v210 avi files and do the right thing with them
sonic's blu-ray encoder takes it too, without issue
like i say, not trying to spam, not requesting a feature, but just offering some of my experience with the format. it is what it is because that's how it comes off the cables, and every facility is wired with the same cables unfortunately. when HD-SDI came in, they of course made it backward-compatible and used the same packing, even though they were in a position to make things a bit easier for developers :)
lansing
2nd October 2012, 06:52
After a couple of days of testing, i'm pretty safe to say that right now vapoursynth is about 2.5x faster than the official Avisynth overall, with cpu usage range from 70-80%; and about 30% slower than avisynth mt.
The memory control was just very nice,
official avs: 300MB always
avs-mt: 580MB+ always
vapoursynth: < 130MB.
And for mdegrain1 blocksize=16, i even got 45MB.
Myrsloik
2nd October 2012, 09:19
After a couple of days of testing, i'm pretty safe to say that right now vapoursynth is about 2.5x faster than the official Avisynth overall, with cpu usage range from 70-80%; and about 30% slower than avisynth mt.
The memory control was just very nice,
official avs: 300MB always
avs-mt: 580MB+ always
vapoursynth: < 130MB.
And for mdegrain1 blocksize=16, i even got 45MB.
Now for the obvious question. On how many cores? 4?
What if you set the number of threads to cores+1 in your computer?
lansing
2nd October 2012, 14:22
Now for the obvious question. On how many cores? 4?
yes, AMD Athlon2 X4 635.
For official avs, only one core was working; vapoursynth, all 4 cores working in balance
update:
setting vs.Core(threads=cores+5) results vary between +-3% comparngs to threads=cores
update 2:
here's the benchmarks done with "time", clip 720x480, 5000 frames, all done on 4 cores:
Keiyakusha
2nd October 2012, 15:53
Wanted to compare some mvtools versions. Same script as I posted before, FFMS2 1 thread, through vfw, VS r11:
mvtools-v2.5.11.3 vsCore_4_threads 19.28FPS ~46%CPU
mvtools-2.5.11.9-svp vsCore_4_threads 25.18FPS ~46%CPU
mvtools-v2.5.11.3 vsCore_9_threads 22.30FPS ~70%CPU
mvtools-2.5.11.9-svp vsCore_9_threads 29.68FPS ~70%CPU
mvtools-2.6.0.5-dither vsCore_9_threads if I try to open it in whatever way, host application just closes without saying anything, and pure python only writes this: "YUV4MPEG2 C420 W720 H480 F24000:1001 Ip A0:0", without saying anything ^__^
^ dither mt-true in this case
mvtools-2.6.0.5-dither vsCore_4_threads 18.44FPS ~46%CPU
mvtools-2.6.0.5-dither vsCore_9_threads 21.12FPS ~70%CPU
^ dither mt-false
Also singlethreaded FFMS2 is not a bottleneck. Adding more threads actually slows processing.
lansing
2nd October 2012, 16:08
mvtools-2.6.0.5-dither vsCore_9_threads if I try to open it in whatever way, host application just closes without saying anything, and pure python only writes this: "YUV4MPEG2 C420 W720 H480 F24000:1001 Ip A0:0", without saying anything ^__^
for the dither one, you need to set mt=false on all manalyse, msuper, and mdegrain in order to work in vpy
Myrsloik
2nd October 2012, 16:09
mvtools-2.6.0.5-dither vsCore_9_threads if I try to open it in whatever way, host application just closes without saying anything, and pure python only writes this: "YUV4MPEG2 C420 W720 H480 F24000:1001 Ip A0:0", without saying anything ^__^
That's odd, I actually used the dither mvtools for my testing here. After I finish my current request, v210 and vsfs, I'll try to figure out why vs isn't as fast as it could be.
Interesting benchmarks, keep them coming. They help me identify where to look to improve things.
Keiyakusha
2nd October 2012, 16:16
for the dither one, you need to set mt=false on all manalyse, msuper, and mdegrain in order to work in vpy
Oh I see, had no idea this matters. Well I added dither version to above post
mvtools-2.6.0.5-dither vsCore_4_threads 18.44FPS ~46%CPU
mvtools-2.6.0.5-dither vsCore_9_threads 21.12FPS ~70%CPU
That's odd, I actually used the dither mvtools for my testing here. After I finish my current request, v210 and vsfs, I'll try to figure out why vs isn't as fast as it could be.
Interesting benchmarks, keep them coming. They help me identify where to look to improve things.
Sorry didn't know I need to use mt-false in dither version
lansing
2nd October 2012, 22:48
just out of curiosity, does it matters to have a 64bit vapoursynth going along with a 64bit python? Will it be faster than 32bit vapoursynth + 32bit python right now? Or am I talking nonsense here?
Myrsloik
2nd October 2012, 22:53
just out of curiosity, does it matters to have a 64bit vapoursynth going along with a 64bit python? Will it be faster than 32bit vapoursynth + 32bit python right now? Or am I talking nonsense here?
It will be exactly the same with the existing ported filters. Except that you can't use any avisynth filters. A 64bit windows version is scheduled for when the plugins and other things are ready for it.
It does however run perfectly well in 64bit on linux if you really need those extra pointless bits RIGHT NOW(tm)
Reel.Deel
3rd October 2012, 14:27
Hello, I was trying to do some speed test with nnedi3 but I encountered something different.
Only when I use ffms2 followed by nnedi3, the frames return out of order in both stdout and vfw. I loaded ffms2 as std and avs and I still had the same problem.
Strangely if I load the video with ffms2 alone and save it losslessly (ut video) and load it back up with ffms2 followed by nnedi3, I get no problem. :confused:
I tried multiple source filters like DGDec, DGDecNV, VsAvsReader and they all work fine with nnedi3. ffms2 followed by nnedi3 works fine in Avisynth.
The test clip is from a NTSC DVD. Here's the clip. (http://www.mediafire.com/?zv5hxduox4hh6ld)
Here's the output (http://www.mediafire.com/?019swxqp4idp4hc) with the frames out of order.
I used both ffms2 r725 icl (http://forum.doom9.org/showthread.php?p=1592858#post1592858) and icl 2 (http://forum.doom9.org/showthread.php?p=1593190#post1593190). Same problem.
import vapoursynth as vs
import sys
core = vs.Core(accept_lowercase=True, threads=4)
# Load Filters
core.std.LoadPlugin(path=r'C:\Vapoursynth\FFMS2\ffms2.dll')
#core.avs.LoadPlugin(path=r'C:\Vapoursynth\FFMS2\ffms2.dll')
core.avs.LoadPlugin(path=r'C:\Vapoursynth\NNEDI3\nnedi3.dll')
# Source
src = core.ffms2.source(source=r'C:\VapourSynth\test\test.m2v',threads=1)
#src = core.avs.FFVideoSource(source=r'C:\VapourSynth\test\test.m2v',threads=1)
# Proccesing
src = core.avs.nnedi3(c1=src,field=-2,nsize=6,nns=2)
# Ouput for VDub
last = src
# Output for pipe
#last.output(sys.stdout, y4m=True)
Are_
3rd October 2012, 15:05
ffms has problems with certain containers, and the slower the filter chain the problem becomes worse.
Can you test if remuxing into mkv solves it?
Reel.Deel
3rd October 2012, 15:27
ffms has problems with certain containers, and the slower the filter chain the problem becomes worse.
Can you test if remuxing into mkv solves it?
Yes that indeed solve it. Should of known better. :o
The odd thing is that it works fine in Avisynth without having to remux into mkv. :confused:
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.