cannot load frame server avi into Vapoursynth

[_Al_]

EDIT2, October 2019
just tested it properly, video only, this is solved without any workarounds now. Using Vapoursynth 64bit, Magix Vegas 15 Pro and debugmode frame server 3.0 which uses 64bit driver now (or whatever terminology is correct).
So using that frame server 3.0 (not 2.14) , exporting my_server.avi, where that avi could be loaded into 64bit Vapoursynth with core.avisource.AVISource(my_server.avi)

************************************************** **********

EDIT, it is solved now, using win 7:

My problem was that I used 64bit applications and debugmode frame server was 32bit,
but as of February 2018, it seams to be fixed, user tmp170422 made 64bit extension for debugmode frame server, so far it works for Windows 7, https://forum.videohelp.com/threads/387939-64bit-DebugMode-FrameServer#post2511273
So I downloaded that zip and followed whatever that readme.txt statedfrom that thread and using with Sony Vegas 10,
I have installed latest Python3 and then Vapoursynth64bit (vapoursynth installs in Program Files (x86) so don't be confused as I was) script looks like this (using QTGMC in Vapoursynth uses 100% of CPU!):

#Vaporsynth 64bit installed,
#video is frame served in 64bit from Vegas debugmode frame server, checked values: RGB32 and Write audio as PCM samples
#but Vapoursynth treats video only, it does not passes audio thru
#video is served as interlaced NTSC DV, bottom field first - that is Sony Vegas Project properties setting

input = r'D:\path_to_file\server64.avi'

import vapoursynth as vs
import havsfunc as haf
core = vs.get_core()


video = core.avisource.AVISource(input)
#video = video.text.ClipInfo()
video = core.std.SetFrameProp(video, prop="_FieldBased", intval=1) #intval=1 for bff , 2 for tff, 0 for frame based
video = core.resize.Point (clip=video, format=vs.YUV420P8, matrix_s="470bg", range_s="full")
video = haf.QTGMC(video, Preset='Slower', TFF=False)
#video = video.text.ClipInfo()
video.set_output()

using a command line to encode that script,
vspipe.exe comes with Vapoursynth, you find it where you install it or if you unzip portable version:

vspipe.exe  Vapoursynth_script.vpy - --y4m |x264_64bit.exe" --sar 8:9 --demuxer y4m --crf 18 --output out.h264 -

or playing the script in a media player:

vspipe.exe  Vapoursynth_script.vpy - --y4m | mpv.exe -

you can pass an argument into that script, example you delete that line where you define variable input and set input here,
with frame server avi, you'd perhaps not use it, but for other types of files:

vspipe.exe  --arg "input=D:/path/DV.avi" Vapoursynth_script.vpy - --y4m | mpv.exe -

so you can make quick batch script, passing clip as argument and just changing videofile, you can play/encode file after file based just on one model script,
for example playing a directory full of DV.avi's, again you'd need a different VS script for that , that above script, loading frame server, it is loading RGB32 and changing it to YUV,
if you load real DV avi in it, it would throw error

@echo off
for %%a in ("*.avi") do vspipe.exe --arg "input=D:/path/%%~na.avi" Vapoursynth_script.vpy - --y4m | mpv.exe -fullscreen -

or creating a virtual avi, so any aplication that loads avi would load it (avfs.exe comes with Vapoursynth as well):

avfs.exe  Vapoursynth_script.vpy

that creates virtual avi in C:\Volumes directory, in this case:
C:\Volumes\Vapoursynth_script.vpy\Vapoursynth_scri pt.avi

also VirtualDub FilterMode 64 loads Vapoursynth script directly!


************************************************** ******************************
original question below:



I use Sony Vegas v10, exporting AVI thru Debugmode FrameServer. I have Vapoursynth 64 setup here. Windows x64 as well. I cannot load it into Vapoursynth thru any of these loading lines - avisource.AviSource, avisource.AVIFileSource, avisource.OpenDMLSource and ffms2 :

I tried to add different flavors for avisource like:
fourcc="dvsd" or, fourcc="dfsc" or even alpha=False , no luck , if fourcc is specified it says it cannot load frame 0

otherwise DV.avi works, using avisource.AVISource or ffms2, I even made QTGMC work, just this is a problem , frame server.

I was trying even: AVFS.exe server.avs cmd line, that should bridge that 64bit Vapoursynth and 32 bit Avisynth but I got error log that it could not find Avisynth.dll

trying vavsreader.dll (Avisynth script loading into Vapoursynth) failed, most likely because of that 32bit avisynth. vs. Vapoursynth 64.

Did anyone loaded frame server AVI into Vapoursynth?

[shekh]

DebugMode FrameServer is not packaged 64Bit decoder driver, only 32Bit. Because of this I included the decoder directly into VDFM btw.
To bridge into VapourSynth you should be able to do this:
vegas (DebugMode FrameServer) -> 32Bit VapourSynth (AVISource->VS FrameServer) -> 64Bit VapourSynth (AVISource).

I don't know actually if VS FrameServing is cross-process or not. The middle frameserver can also be VDFM.

I know this is ugly

[poisondeathray]

I use 64bit vegas => dfs => 32bit avs => avfs => 64bit vpy

I use pismo file mount for avfs 32bit avs script mounts , avfs.exe from vapoursynth for 64bit avs script mounts .

Because avisynth+ MT x64 is so much faster (for things like QTGMC) , that's also how I load from vegas (64bit vegas => dfs => 32bit avs => avfs => 64bit avs+ MT) . Even with the added overhead, its significantly faster than the old avisynth MT directly from vegas

[_Al_]

thanks, I actually used both advice's combined:
first of all, did not check and compare quality or if it crashes after a long time, just tested about 20s video,
good news, it uses 100% CPU

-exporting dfms from Vegas, as RGB32 (Vegas internally uses that so no point to export YUV)
- loading it into Avisynth script, I still have here Avisynth 2.6 installed, naming that script for example server.avs
- running AVFS.exe from Vaporsynth 32 portable, it is easy that exe has just one parameter: "AVFS.exe" "server.avs"
- so virtual server.avi is created in C:\volume\server.avi directory
- loading that server.avi into Vapoursynth 64 portable.

Is all that color space, range corrections in that script correct?
If it is correct, I guess I could go from RGB24 to YUV422 use qtgmc and after that changing it to 4:2:0 and full range. Would the quality improve. Downside would be perhaps much slower performance.

#this is portable Vaporsynth 64bit
video_input = r"C:\Volumes\server.avs\server.avi"
import vapoursynth as vs
import havsfunc as haf
core = vs.get_core()
#RGB32; Vegas dmfs->Avisynth 32bit->AVFS.exe(from portable Vapoursynth 32bit)->AVI loaded here 
video = core.avisource.AVISource(video_input)
video = core.fmtc.matrix (clip=video, mat="601", col_fam=vs.YUV, bits=16)
video = core.fmtc.resample (clip=video, css="420")
video = core.fmtc.bitdepth (clip=video, bits=8)
video = haf.QTGMC(video, Preset='Slower', TFF=False)
#Vegas dmfs serves limited range, not full
video = core.resize.Point(video, range_in_s="limited", range_s="full")
#video = video[0:120] #trim 120 frames for testing
#video = video.text.ClipInfo()
video.set_output()

[poisondeathray]

1) I would use vegas' studio to computer RGB preset before exporting. It's actually more accurate. You can test on color bars etc... because those presets perform an actual YUV <=> studio RGB conversion - ie. it does a perfect reversal , whereas avisynth/vapoursynth's "PC" matrix is only a close approximation to what vegas did on import. (There is an actual "studio RGB" function by trevlac for avisynth too but only for avisynth 2.5)

2) But if do end up doing all those manipulations in vapoursynth, most people use zimg now, instead of fmtc . It's integrated now into vapoursynth. It basically does everything, and has arguments for everything, bitdepth conversions, colorspace, transfer, sampling, matrices, etc... It's faster on most setups as well in benchmarks , and it's constantly being updated. Firesledge, the fmtc /dither author is basically inactive now.
http://www.vapoursynth.com/doc/functions/resize.html

3) I still found avisynth+ MT x64 to be slightly faster for QTGMC . But a few scripts and functions are faster in vapoursynth . More support has been added in avisynth+ , but vapoursynth handles manipulating higher bit depths better too

[_Al_]

I posted that below before reading your post. Will look into it with that RGB. Also will check that zimg. Main reason for Vapoursynth usage is not only QTGMC but also switching to linux perhaps, and all that python structure seams to work well. I do not need old avisynth scripts, plugins, just basics. Of course dmfs is not for linux that is just sorting here for windows.


All references to RGB 24 in the post above are wrong,
I must have exported RGB32 from Vegas, because RGB24 does not work with AVFS.exe, but RGB32 does.

also, interesting thing, loading NTSC DVavi into Vapoursynth using ffm2 loads it correctly as YUV411P8 (perhaps in Avisynth as well, not sure now)
so it needs to be corrected into YUV420P8 before encoding or processing. In Vapoursynth this seams to work:

video_input = r"D:\temp\DV.avi"
video_input_ffindex = r"D:\temp\DV.ffindex"

import vapoursynth as vs
import havsfunc as haf   #havsfunc is main qtgmc function  #https://forum.doom9.org/showthread.php?t=166582
core = vs.get_core()

video = core.ffms2.Source(video_input, cachefile = video_input_ffindex) #reads as YUV411P8
video = core.fmtc.resample (clip=video, css="444")
video = core.fmtc.resample (clip=video, css="420")
video = core.fmtc.bitdepth (clip=video, bits=8) 
video = haf.QTGMC(video, Preset='Slower', TFF=False)
video.set_output()

loading NTSC DVavi with source.AVISource:

video = core.avisource.AVISource(video_input)

it interprets it as YUV420P8 , I could not select that 411 , following this:
video = core.avisource.AVISource(video_input, pixel_type="YV411")
gives error for that line:
vapoursynth.Error: AVISource: the video decompressor couldn't produce Y41B output

So is it correct to use ffms2 for NTSC DV avi loading?
I guess yes, as oppose avisynth.AVISource loading.

But still clearing up and establishing those color , range transfers

[poisondeathray]

yes, ffms2 will return 4:1:1 for NTSC DV , in both avisynth and vapoursynth . One negative as you already know, is it will generate an index (clutter, takes extra time, but you can disable it with cache=False)

AVISource will use whatever VFW decoder you have configured , in both avisynth and vapoursynth. (I have not seen a VFW decoder that will return 4:1:1 for NTSC DV)

[poisondeathray]

Actually my bad - I think you still need fmtc for interlaced manipulations . I don't think zimg has that switch exposed in the vapoursynth version.

Whenever you convert RGB<=>YUV or even 444<=>422<=>420 it has to be done in interlace aware manner when using interlaced material



Actually my bad again . Apparently it takes the clip properties into account now. You can override the behaviour manually with SetFrameProp and prop="_FieldBased" with 1,2,3 , but Resize does it correctly when clip properties are interlaced

e.g. override for TFF

clip = core.std.SetFrameProp(clip, prop="_FieldBased", intval=2)

#    0 = Frame Based
#   1 = Bottom Field First
#   2 = Top Field First

[_Al_]

To elaborate on that RGB24 vs. RGB32 while frame serving from Vegas:

From Vegas it should be exported as RGB32 and Vapoursynth 64 reads that AVI (via Avisynth32bit and AVFS.exe from 32bit Vapoursynt) as RGB24. I think that is correct, because alpha channel is left out somewhere along the way. It looks like a likely explanation. If that avi is frame served from Vegas as RGB24 and again loaded into Vapoursynth 64 (thru Avisynth and AVFS.exe) , it gives error:

Traceback (most recent call last):
File "src\cython\vapoursynth.pyx", line 1830, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:36860)
File "D:/temp/qtgmc test.vpy", line 7, in 
video = core.avisource.AVISource(video_input)
File "src\cython\vapoursynth.pyx", line 1722, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:35000)
vapoursynth.Error: AVISource autodetect: couldn't open file 'C:\Volumes\server.avs\server.avi'
Error code: 2

[poisondeathray]

Either RGB24 or RGB32 works for me through vegas, dfs , avfs and vpy

But the vpy discards the alpha (even when it's a valid alpha) . Something in my memory vaguely remembering about python handling for array of 2 clips (RGB + A) . You're supposed to be able to specify video[0] or video[1].set_output() but I can't retrieve the alpha (but it's valid, I can open it with avisynth and use showalpha() to check it ) .

[_Al_]

I tried to include and leave out that line with std.SetFrameProp:

video_input = r"C:\Volumes\server.avs\server.avi"
import vapoursynth as vs
import havsfunc as haf
core = vs.get_core()
#RGB32 from Vegas dmfs->Avisynth 32bit->AVFS.exe(from portable Vapoursynth 32bit)->AVI loaded here as RGB 24
video = core.avisource.AVISource(video_input)
video = core.std.SetFrameProp(video, prop="_FieldBased", intval=1) #intval=1 for bff , 2 for tff, 0 for frame based
video = core.resize.Point (clip=video, format=vs.YUV420P8, matrix_s="470bg") 
video = haf.QTGMC(video, Preset='Slower', TFF=False)
video.set_output()

comparing both outcomes, they look identical under zoom. Did not try to resize.

Then I was comparing Studio RGB to Computer RGB in Vegas vs. selecting "limited to full range" in Vapoursynth, including that line after QTGMC line:
video = haf.QTGMC(video, Preset='Slower', TFF=False)
video = core.resize.Point (video, range_in_s="limited", range_s="full")
Histogram showed some bands if it was done in Vapoursynth, as if VS used some alghoritm where some values were missing,
also Vegas did not let it go into illegal values that much (it was recorded with those illegal values), Vapoursynth copied original basically
visually almost the same, so basically if encoding it makes not that a difference:

[poisondeathray]

1) in motion, you will get chroma ghosting artifacts unless the conversion from RGB to YUV was done properly . It might be more difficult to see on a low chroma quality DV source, but it should still be there. Some source filters will convey the properties correctly including field order, but AVISource will not. It's analagous to ConvertToYV12(interlaced=false) vs. ConvertToYV12(interlaced=true) for RGB to YUV interlaced conversion in avisynth. I verified this - if clip properties did not indicate field based or interlaced, the resize will do it progressively (you can check with clipinfo ; it's sort of like info() in avisynth) . When you convert RGB to YV12 (or YUV420P8), you are resizing the chroma planes. If that's done progressively on interlaced content, you will get chroma ghosting artifacts. I like the way avisynth does it in the filter argument better (interlaced=true vs. false), but that's just me, it's what I'm used to

2) for the histogram "banding", its the same as avisynth manipulations. You can include the dither argument in resize for the standard to full range expansion conversion if you want to smooth the histogram. Same idea as smoothlevels in avisynth, or levels (dither=true) . Also if you do it all once, it should be faster and technically higher quality. (ie do it all with resize command with converting RGB to YUV)

3) the differences I was talking about for vegas studio RGB conversion reversal vs. avisynth or vapoursynth "PC" or full range "reversal" is about +/-2 instead of +/-4 for the latter . It's easier to see on bars / known values . It's definitely more accurate compared to input values; this lower accuracy expected, because you're not using the actual studio RGB function in avisynth or vapoursynth (unless someone ports trevlacs function or rewrites it). You're supposed to "fix" illegal values in vegas , but if you color manipulate/filter as well , the color accuracy difference compared to input might be less relevant - it depends on scenario or what you're doing

[_Al_]

oh, ok, colorspace change and full range change in one line caused those "gaps" in histogram to disappear, also quality is much better after zooming on edges (especially redish colors). I did not look if and how to use dither in this case, maybe later.

video = core.resize.Point (clip=video, format=vs.YUV420P8, matrix_s="470bg", range_s="full")

So about that interlace awareness, is it a correct approach to change color space in Vapoursynth, in this case RGB ->YUV, just using SetFrameProp to "flag" it, that it is fieldbased and then make color change? So that "resize.method()" , is it interlace aware of that prop value? :

video = core.avisource.AVISource(interlaced_input)
video = core.std.SetFrameProp(video, prop="_FieldBased", intval=1) # 1 for bff
video = core.resize.Point (clip=video, format=vs.YUV420P8, matrix_s="470bg",  range_s="full")

I do not resize in above example. Resizing interlaced video to get interlaced video again I found workflow using fmtconv using separatefields and then doubleweave, but nowadays it is good for making DVD only , out of interlace content only I guess, maybe broadcast stations need some interlaced content as well.
to get 720x480, interlaced from HD interlaced I found some HolyWu's script, changed it to 420 out, in video is YUV as well:

video = core.std.SeparateFields(clip=video, tff=False)  #False for bff, True for tff
video = core.fmtc.resample(clip=video, w=720, h=240, css="444", kernel="spline36", interlaced=1)
video = core.fmtc.matrix(clip=video, mats="709", matd="601")
video = core.fmtc.resample(clip=video, css="420", interlaced=1)
video = core.fmtc.bitdepth(clip=video, bits=8)
video = core.std.DoubleWeave(clip=video, tff=False)
video = video [::2]
video.set_output()

That seams to be "setFrameProp" independent.
And in Avisynth we added low pass filter as well, it is not included there

[poisondeathray]

Yes, internal resize takes into account clip properties. If ClipInfo says fields, it will apply resize or any operations like RGB<=>YUV like interlaced=true. If unknown or progressive, it will apply it like interlaced=false . fmtc is FrameProp independent , because it hasn't been updated in a few years. Instead, it has switches interlaced=True/False

[_Al_]

oh great, thanks
text.ClipInfo() prints field handling as "unknown" but after prop is set it reports bottom field first.

[_Al_]

I canot load Vapoursynth Script into VirtualDub Filter Mod .

I have portable Vapoursynth 64bit, and latest 40881 VDFM 64 bit as well.

AVIImport Filter error: (Unknown) (80040154)

Is there something special that needs to be done?

[poisondeathray]

I canot load Vapoursynth Script into VirtualDub Filter Mod .

I have portable Vapoursynth 64bit, and latest 40881 VDFM 64 bit as well.

AVIImport Filter error: (Unknown) (80040154)

Is there something special that needs to be done?

I usually just drop and drag . But I have installed version of vapoursynth ,not sure if that makes a difference

Is it a valid script ? Does it open with vsedit ?

*But there might be an issue with the newest one 40881 ; it doesn't seem to want to display (it opens, but I get blank/white screen). But only with certain pixel formats. RGB24 seems to display ok for example

[poisondeathray]

But I don't get the error message of AVIImport error ... It opens, just to a blank/white screen for me, for some pixel formats

What pix fmt you sending ? Problems in 40881 for me: (but YUV444P10 didn't display in older versions either for me)
seems like 10bit issue

RGB24 ok
YUV420P8 ok
YUV420P10 bad
YUV422P8 ok
YUV422P10 bad
YUV420P8 ok
YUV444P10 bad

[shekh]

I canot load Vapoursynth Script into VirtualDub Filter Mod .

I have portable Vapoursynth 64bit, and latest 40881 VDFM 64 bit as well.

AVIImport Filter error: (Unknown) (80040154)

Is there something special that needs to be done?

VD does not work with portable *synth, it depends on vfw driver installed in system.

[shekh]

But I don't get the error message of AVIImport error ... It opens, just to a blank/white screen for me, for some pixel formats

What pix fmt you sending ? Problems in 40881 for me: (but YUV444P10 didn't display in older versions either for me)
seems like 10bit issue

RGB24 ok
YUV420P8 ok
YUV420P10 bad
YUV422P8 ok
YUV422P10 bad
YUV420P8 ok
YUV444P10 bad

Weird. I have VapourSynth-R38 and it works fine.
YUV420P10: as P010 format
YUV422P10: as P210 format
YUV444P10: as Y410 format (same for YUV444P16 too)

Edit: also tried R42, all ok.

[_Al_]

Is it a valid script ? Does it open with vsedit ?

yes

VD does not work with portable *synth, it depends on vfw driver installed in system.

I was afraid that was the thing. I will have to try to install VS. That new VD looks really nice. It is tempting although I try to set up things here for linux as well.

[poisondeathray]

But I don't get the error message of AVIImport error ... It opens, just to a blank/white screen for me, for some pixel formats

What pix fmt you sending ? Problems in 40881 for me: (but YUV444P10 didn't display in older versions either for me)
seems like 10bit issue

RGB24 ok
YUV420P8 ok
YUV420P10 bad
YUV422P8 ok
YUV422P10 bad
YUV420P8 ok
YUV444P10 bad

Weird. I have VapourSynth-R38 and it works fine.
YUV420P10: as P010 format
YUV422P10: as P210 format
YUV444P10: as Y410 format (same for YUV444P16 too)

Edit: also tried R42, all ok.

Not sure why . R42 also

I would expect 40716 to exhibit the same issue if it was a system VFW issue

They open, and file=>file information looks correct, correct framerate, frames etc... just a blank/white screen

I checked the options=>preferences for AVI and Display and they are the same for 40881 and 40716 here

vsedit works for all those, but I think it's QT5 based

[shekh]

poisondeathray, can you save uncompressed AVI from that script in 40716 (I assume there it works?) and open the same AVI in 40881?
If it still does not work please share that AVI
or maybe the script+source, if it is simple.

PS: now I see it, behaviour is wrong when "decode format" is set to anything but "autoselect".

[poisondeathray]

poisondeathray, can you save uncompressed AVI from that script in 40716 (I assume there it works?) and open the same AVI in 40881?
If it still does not work please share that AVI
or maybe the script+source, if it is simple.

Yes it works, and the physical AVI opens (and displays) in 40881

[poisondeathray]

PS: now I see it, behaviour is wrong when "decode format" is set to anything but "autoselect".

But that's what it's set to, by default...

Did you need anything else ? It's reproducible on my end with very simple script. eg.. take RGB image, convert to YUV422P10 . In 40716, this works and you can export v210 AVI which can be opened in 40881

But the script fed directly into 40881 has white screen. There is some "thinking", some CPU usage too like it's using 1 core to try to get the thing to display or something. But you can "gracefully" exit still, by closing video file or application completely (it's not some hard lockup or crash)

[shekh]

I also found a problem with display preferences, I have good display with "Use Direct3D 9" enabled, but otherwise gray panes with many formats. script/AVI does not matter.
Can you verify this as well?

[poisondeathray]

I also found a problem with display preferences, I have good display with "Use Direct3D 9" enabled, but otherwise gray panes with many formats. script/AVI does not matter.
Can you verify this as well?

I usually have use directx for display panes disabled, on all vdub/vdfm versions

(Because can cause inconsistencies between different computers / GPU setups)

But playing with the various options, saving/exit/restart => still white/blank screen

(It also doesn't explain why it would work with 40716 when disabled; above I said I checked AVI and Display settings between the two, and they matched)

And I did simple things like reboot too...

[poisondeathray]

I also re-downloaded from sourceforge (in case there was some sort of corrupt archive, I downloaded from VH originally) , same result

If I had to guess, it has something do to do with this commit

update 2 (build 40879)

fixed P210 support

polished support for formats: P010, P210, P016, P216 (input/output)

But it's hard to debug something if you can't reproduce it on your end

[shekh]

I think it is almost clear now. There is part missing in "gdi display mode" which you are using. These P010 etc formats become new/unknown and also Y410 and several other formats did not work in previous builds.
What is making this difficult is your note "and the physical AVI opens (and displays) in 40881" - it shouldn't!

[poisondeathray]

What is making this difficult is your note "and the physical AVI opens (and displays) in 40881" - it shouldn't!

But that specific example was v210 , does that matter ? File=>file information says internal DIB decoder (v210) . I have in preferences directly decode uncompressed YCbCr (YUV) sources enabled