Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VapourSynth

Reply
 
Thread Tools Search this Thread Display Modes
Old 14th December 2017, 23:08   #2881  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,657
Quote:
Originally Posted by Myrsloik View Post
Same as the old import vapoursynth as vs. You can also do things like
Code:
from vapoursynth import core, RGB24, someotherformat, ...
If you want to refer to them without the vs prefix. Python has loads of ways to import things.
I'm referring to these:
Code:
core.std.BlankClip(format=vs.YUV420P8, length=1000, color=[n, 128, 128])
lansing is offline   Reply With Quote
Old 14th December 2017, 23:16   #2882  |  Link
AzraelNewtype
Registered User
 
AzraelNewtype's Avatar
 
Join Date: Oct 2007
Posts: 135
Did... you... try

Code:
from vapoursynth import YUV420P8
?
AzraelNewtype is offline   Reply With Quote
Old 14th December 2017, 23:40   #2883  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,657
Quote:
Originally Posted by AzraelNewtype View Post
Did... you... try

Code:
from vapoursynth import YUV420P8
?
That would be really odd if we need to import every little thing we're going to use in the first line. For example, I'm going to use COMPATBGR32, RGB24, YUV420P8 and RGBS in a script, so that would be:
Code:
from vapoursynth import COMPATBGR32, RGB24, YUV420P8, RGBS
lansing is offline   Reply With Quote
Old 15th December 2017, 00:33   #2884  |  Link
AzraelNewtype
Registered User
 
AzraelNewtype's Avatar
 
Join Date: Oct 2007
Posts: 135
Yes that is correct. This is how python namespace pollution works. Alternately, don't pollute your namespace.
AzraelNewtype is offline   Reply With Quote
Old 17th December 2017, 04:00   #2885  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,345
avisource, alpha channel questions


R40 x64

There seems to be problems with the alpha channel using AVISource on an RGB32(RGBA) AVI with a valid alpha channel (I tested uncompressed, lagarith, ut video codec) . The same AVI is ok in avisynth, and showalpha() shows the correct alpha

Code:
import vapoursynth as vs
core = vs.get_core()
video = core.avisource.AVISource(r'F:\blah.avi', pixel_type="RGB32", alpha=True)
#video[0].set_output() 
video[1].set_output()
It's not completely black, there are some pixels here and there that are non black, but it's definitely corrupt.

alpha channel seems to work ok with other things, e.g. on an imagemagick RGBA png sequence , video[1].set_output() would show the correct alpha



Q2) How do you send RGB32 data to something else ? . If python holds it as an array, how would you encode, say an RGBA png sequence with ffmpeg ?
poisondeathray is offline   Reply With Quote
Old 17th December 2017, 13:28   #2886  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
Quote:
Originally Posted by poisondeathray View Post
avisource, alpha channel questions


R40 x64

There seems to be problems with the alpha channel using AVISource on an RGB32(RGBA) AVI with a valid alpha channel (I tested uncompressed, lagarith, ut video codec) . The same AVI is ok in avisynth, and showalpha() shows the correct alpha

Code:
import vapoursynth as vs
core = vs.get_core()
video = core.avisource.AVISource(r'F:\blah.avi', pixel_type="RGB32", alpha=True)
#video[0].set_output() 
video[1].set_output()
It's not completely black, there are some pixels here and there that are non black, but it's definitely corrupt.

alpha channel seems to work ok with other things, e.g. on an imagemagick RGBA png sequence , video[1].set_output() would show the correct alpha



Q2) How do you send RGB32 data to something else ? . If python holds it as an array, how would you encode, say an RGBA png sequence with ffmpeg ?
1. I think I found part of the issue. Can I have a sample with a few frames to test if I succeeded in fixing it? I think it broke during some refactoring and nobody noticed...

2. There's actually no easy way to do that. I mean ideally you'd output RGBAP but the default output handling doesn't take this into consideration. How about a solution like this:

Code:
clip.set_output(alpha=alpha_clip)
And then it'd be output as GBRAP. Or something like that, thoughts?
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 17th December 2017, 18:15   #2887  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,345
UT Video ULRA , alpha channel sample
Code:
http://www.mediafire.com/file/lsb7cz35387ow1z/UTVideo_ULRA.avi
Let me know if you need any other samples / codecs etc...


Quote:
Originally Posted by Myrsloik View Post
Code:
clip.set_output(alpha=alpha_clip)
And then it'd be output as GBRAP. Or something like that, thoughts?
I think that should work, but would alpha=True be more consistent ? Or would you have to define the alpha_clip specifically ?
poisondeathray is offline   Reply With Quote
Old 17th December 2017, 19:26   #2888  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
Quote:
Originally Posted by poisondeathray View Post
UT Video ULRA , alpha channel sample
Code:
http://www.mediafire.com/file/lsb7cz35387ow1z/UTVideo_ULRA.avi
Let me know if you need any other samples / codecs etc...




I think that should work, but would alpha=True be more consistent ? Or would you have to define the alpha_clip specifically ?
How else would it know what the alpha information is?
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 18th December 2017, 17:49   #2889  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
R41-test2

Fixes alpha handling in avisource and not much else.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 20th December 2017, 01:43   #2890  |  Link
kgrabs
Registered User
 
Join Date: Jan 2017
Posts: 28
I think something is up with the "bits" and "floatout" parameters of std.Lut/Lut2, you can "evaluate" it but previewing and encoding crash:

Code:
import vapoursynth as vs
core = vs.core

clip = core.std.BlankClip(format=vs.GRAY8)

core.std.Lut(clip, lut=[0]*256, bits=16).set_output()

Script was successfully evaluated. Output video info:
Frames: 240 | Time: 0:00:10.000 | Size: 640x480 | FPS: 24/1 = 24 | Format: Gray16

Crash on preview
Code:
import vapoursynth as vs
core = vs.core

clip = core.std.BlankClip(format=vs.GRAY8)

core.std.Lut(clip, lutf=[0.]*256, bits=32, floatout=True).set_output()

Script was successfully evaluated. Output video info:
Frames: 240 | Time: 0:00:10.000 | Size: 640x480 | FPS: 24/1 = 24 | Format: GrayS

Crash on preview
~Edit~

So, std.BoxBlur seems to be really, really slow at copying planes. The difference between splitting to GRAY clips and using the planes parameter is huge

Code:
args = dict(hradius=2, hpasses=1, vradius=2, vpasses=1)

clip = core.std.BlankClip(None, 1920, 1080, vs.YUV444PS, 500)
core.std.BoxBlur(clip, planes=[0], **args).set_output()

Time elapsed: 0:07.476 - 66.88474253259326474108 FPS

clip = core.std.BlankClip(None, 1920, 1080, vs.GRAYS, 500)
core.std.BoxBlur(clip, **args).set_output()

Time elapsed: 0:02.996 - 166.90969959623313911834 FPS

Last edited by kgrabs; 20th December 2017 at 12:48.
kgrabs is offline   Reply With Quote
Old 20th December 2017, 20:12   #2891  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
I'll look into the first one - FIXED NOW. Second is memory bw limited due to blankclip having to fill all 3 planes. Set keep=1 in blankclip and you'll see that it's really close. Or should be at least...
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet

Last edited by Myrsloik; 20th December 2017 at 22:00. Reason: FIXED IT
Myrsloik is online now   Reply With Quote
Old 27th December 2017, 15:20   #2892  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
R41-test4
It's a test version because some fairly big changes have been made for the alpha output part. To use this simply do clip.set_output(alpha=alpha_clip) and it will be output through vspipe. Note that Y4M doesn't get alpha and can't be combined with it. Test it well.

Code:
r41:
updated to zimg v2.7
added convenient alpha output to vspipe and vsscript, set_output() in python now takes a second optional alpha clip which will be used for this
fixed avisource leaking one frame reference on destruction
updated plugin list to be more consistent with links to source/binaries and doom9 discussion thread
fixed lut triggering a fatal error when the bits argument is used
fixed regression that prevented alpha output from working in avisource
removed dependency on the now deprecated codecvt header
fixed memory leak where modifyframe wouldn't release the function reference when done
fixed a rare memory leak that could happen if the core was freed before the last frame 
fixed a memory leak that would happen if a python videoframe object was instantiated
imwri will no longer write alpha to images unless an alpha clip is specified
improved imwri's input and output format guessing, now integer and float image formats will most likely be returned in native precision
imwri now requires hdri support since it's enabled by default in version 7, as a result of there only being one major configuration the namespace is now always imwri
stackvertical now properly rejects compat formats instead of producing unexpected output
the default initial cache size now also depends on the number of threads used
fixed negative frame request error listing the parent node name instead of the correct name
fixed expr clamping of 9-15 bit output, previously it would clamp to 16bit
fixed corrupted output in expr when mixing int and float for input and output (pinterf)
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 28th December 2017, 13:07   #2893  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
I did some more testing and R41-test4 should be considered RC quality.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 30th December 2017, 19:49   #2894  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
R41-RC1

Fixes an avisource crash and some minor typos. Also lots of imwri changes but that's a separate thread.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 31st December 2017, 17:24   #2895  |  Link
kgrabs
Registered User
 
Join Date: Jan 2017
Posts: 28
About the BoxBlur thing, there's still a pretty big difference

Code:
#Main
from vapoursynth import core, GRAY, YUV, YUV444PS
args = dict(hradius=2, hpasses=1, vradius=2, vpasses=1, planes=[0])

# Use "planes"
clip = core.std.BlankClip(None, 1920, 1080, YUV444PS, 2000, keep=1)
clip = core.std.BoxBlur(clip, **args)
clip.set_output()
# Time elapsed: 0:27.135 -  73.70663065422803583715 FPS

# Split to Gray
clip_yuv = core.std.BlankClip(None, 1920, 1080, YUV444PS, 2000, keep=1)
clip = core.std.ShufflePlanes(clip_yuv, 0, GRAY)
clip = core.std.BoxBlur(clip, **args)
clip = core.std.ShufflePlanes([clip, clip_yuv], [0,1,2], YUV)
clip.set_output()
# Time elapsed: 0:11.011 - 181.64144952606065430700 FPS
The difference isnt as evident with 8 bit though:

Time elapsed: 0:05.794 - 345.20685825648109812391 FPS (split to gray)
Time elapsed: 0:07.107 - 281.39460754565209299471 FPS (use "planes")

PS sry for being lazy and taking like a week to do it :^)

Edit: Rather than also being 73fps like the "use planes" test, changing it to planes=[0,1,2] is actually only about 63fps. PPS I used R41-RC1

Last edited by kgrabs; 31st December 2017 at 17:37.
kgrabs is offline   Reply With Quote
Old 31st December 2017, 18:27   #2896  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
Quote:
Originally Posted by kgrabs View Post
About the BoxBlur thing, there's still a pretty big difference

Code:
#Main
from vapoursynth import core, GRAY, YUV, YUV444PS
args = dict(hradius=2, hpasses=1, vradius=2, vpasses=1, planes=[0])

# Use "planes"
clip = core.std.BlankClip(None, 1920, 1080, YUV444PS, 2000, keep=1)
clip = core.std.BoxBlur(clip, **args)
clip.set_output()
# Time elapsed: 0:27.135 -  73.70663065422803583715 FPS

# Split to Gray
clip_yuv = core.std.BlankClip(None, 1920, 1080, YUV444PS, 2000, keep=1)
clip = core.std.ShufflePlanes(clip_yuv, 0, GRAY)
clip = core.std.BoxBlur(clip, **args)
clip = core.std.ShufflePlanes([clip, clip_yuv], [0,1,2], YUV)
clip.set_output()
# Time elapsed: 0:11.011 - 181.64144952606065430700 FPS
The difference isnt as evident with 8 bit though:

Time elapsed: 0:05.794 - 345.20685825648109812391 FPS (split to gray)
Time elapsed: 0:07.107 - 281.39460754565209299471 FPS (use "planes")

PS sry for being lazy and taking like a week to do it :^)

Edit: Rather than also being 73fps like the "use planes" test, changing it to planes=[0,1,2] is actually only about 63fps. PPS I used R41-RC1
Sigh, you're right. I forgot to do the last optimization in the code so all planes are transposed even if no blurring is done to them. Will fix it since it will give nice speedups in many scripts...
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 6th January 2018, 22:04   #2897  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
R41 RC2

Should fix BoxBlur not copying planes the fastest possible way. Otherwise no real changes from RC1. So test BoxBlur a bit to verify that I got it right.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 9th January 2018, 20:09   #2898  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
R41 released. The usual post about it. Have fun with less shitty alpha support.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Old 10th January 2018, 07:53   #2899  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,345
Quote:
It’s now possible to pass a second alpha clip to set_output() in scripts and vspipe will output it.
How exactly is the vspipe output for alpha supposed to work ?


Quote:
Originally Posted by Myrsloik View Post
How about a solution like this:

Code:
clip.set_output(alpha=alpha_clip)
And then it'd be output as GBRAP. Or something like that, thoughts?


Is it like this ?

Code:
clip[0].set_output(alpha=clip[1])
vspipe --info reports RGB24




What exactly is COMPATBGR32 ? I know it's for legacy purposes, sometimes RGB flip , but does it carry a valid alpha or is it a "dummy" alpha ? or something completely different. I figured it was remotely similar to "RGB32" in avsiynth-ese
poisondeathray is offline   Reply With Quote
Old 10th January 2018, 10:56   #2900  |  Link
Myrsloik
Professional Code Monkey
 
Myrsloik's Avatar
 
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
Quote:
Originally Posted by poisondeathray View Post
How exactly is the vspipe output for alpha supposed to work ?






Is it like this ?

Code:
clip[0].set_output(alpha=clip[1])
vspipe --info reports RGB24




What exactly is COMPATBGR32 ? I know it's for legacy purposes, sometimes RGB flip , but does it carry a valid alpha or is it a "dummy" alpha ? or something completely different. I figured it was remotely similar to "RGB32" in avsiynth-ese
It works like you guessed. If you check the info output from vspipe it also says "alpha: yes" or something similar.

Compatbgr32 is simply packed bgra with dummy alpha. It only exists for avisynth compatibility reasons.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet
Myrsloik is online now   Reply With Quote
Reply

Tags
speed, vaporware, vapoursynth

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 14:07.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.