VideoHelp Forum
+ Reply to Thread
Results 1 to 26 of 26
Thread
  1. Member hydra3333's Avatar
    Join Date
    Oct 2009
    Location
    Australia
    Search Comp PM
    I see that nowadays ffmpeg can be built to accept vapoursynth input directly (and the audio at the same time if you like), no external piping commands etc, and processing it all on one commandline) eg
    Code:
    ffmpeg.exe -f vapoursynth -i "input.vpy" -i "audio_file-or-original_source_file.ts"-map 0:v:0 -map 1:a:0 ...
    I just gave it a try and it worked.

    Even better, I have an nvidia graphics card so was able to try encoding using ffmpeg's nvenc h.264 hardware encoder and output to .mp4.
    Some people grumble about relative nvenc video encoding quality, but I found for many home (non videophile) use cases it seems just fine ... and can be up to hundreds of times faster encoding than non-hardware encoding.

    If one uses gpu-accelerated plugins, eg denoising such as gpu variants of nlmeans, I found the end-to-end encoding speed went (in one 4k test case)
    Code:
    non-gpu-accelerated	~0.2 fps / 26128.659s
    to gpu-accelerated	~52 fps  / 77.095s
    ... 339 times the end-to-end encode speed (a 4k video in this test case) ... which for home uses seems well worth it

    My use case is legal time-shifted home TV viewing via a Raspberry Pi powered media server to chromecast devices on various TVs around the house, so videos must be deinterlaced and "old" TV shows denoised. I currently use VideoRedo to "QuickStreamFix" a source first, and DG's gpu-accelerated vapoursynth plugins as my preferences.

    Edit: IIRC, NVEncC accepts .vpy input too ?
    Quote Quote  
  2. Originally Posted by hydra3333 View Post
    I see that nowadays ffmpeg can be built to accept vapoursynth input directly (and the audio at the same time if you like), no external piping commands etc, and processing it all on one commandline) eg
    Code:
    ffmpeg.exe -f vapoursynth -i "input.vpy" -i "audio_file-or-original_source_file.ts"-map 0:v:0 -map 1:a:0 ...

    I noticed recent versions of ffmpeg are no longer compiled with the --enable-vapoursynth option. Is there a specific reason for that? Used to be very useful.
    Quote Quote  
  3. Member
    Join Date
    Feb 2006
    Location
    United States
    Search Comp PM
    Originally Posted by meimeiriver View Post
    Originally Posted by hydra3333 View Post
    I see that nowadays ffmpeg can be built to accept vapoursynth input directly (and the audio at the same time if you like), no external piping commands etc, and processing it all on one commandline) eg
    Code:
    ffmpeg.exe -f vapoursynth -i "input.vpy" -i "audio_file-or-original_source_file.ts"-map 0:v:0 -map 1:a:0 ...

    I noticed recent versions of ffmpeg are no longer compiled with the --enable-vapoursynth option. Is there a specific reason for that? Used to be very useful.
    see this thread - https://github.com/m-ab-s/media-autobuild_suite/issues/841
    Quote Quote  
  4. Member hydra3333's Avatar
    Join Date
    Oct 2009
    Location
    Australia
    Search Comp PM
    Originally Posted by october262 View Post
    Originally Posted by meimeiriver View Post
    Originally Posted by hydra3333 View Post
    I see that nowadays ffmpeg can be built to accept vapoursynth input directly (and the audio at the same time if you like), no external piping commands etc, and processing it all on one commandline) eg
    Code:
    ffmpeg.exe -f vapoursynth -i "input.vpy" -i "audio_file-or-original_source_file.ts"-map 0:v:0 -map 1:a:0 ...
    I noticed recent versions of ffmpeg are no longer compiled with the --enable-vapoursynth option. Is there a specific reason for that? Used to be very useful.
    see this thread - https://github.com/m-ab-s/media-autobuild_suite/issues/841
    I reckon that information is way out of date.

    I (re)build ffmpeg regularly using mingw64 & gcc under ubuntu with target win10x64, and use .vpy input every day without issue. (using standalone vapoursynth with ffmpeg copied into the same folder)

    Whilst I don't use MABS, I do take guidance from the build options specified by MABS and also those used by rdp, when using a derivative of deadsix27's build system:
    https://github.com/hydra3333/h3333_python_cross_compile_script_v100
    (PS please don't try that link yourself, it likely only works for me).
    Quote Quote  
  5. Thx, guys, for the info.
    Quote Quote  
  6. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by october262 View Post
    Originally Posted by meimeiriver View Post
    Originally Posted by hydra3333 View Post
    I see that nowadays ffmpeg can be built to accept vapoursynth input directly (and the audio at the same time if you like), no external piping commands etc, and processing it all on one commandline) eg
    Code:
    ffmpeg.exe -f vapoursynth -i "input.vpy" -i "audio_file-or-original_source_file.ts"-map 0:v:0 -map 1:a:0 ...

    I noticed recent versions of ffmpeg are no longer compiled with the --enable-vapoursynth option. Is there a specific reason for that? Used to be very useful.
    see this thread - https://github.com/m-ab-s/media-autobuild_suite/issues/841
    LOL wiiaboo's answer was excellent and straight-to-the-point.

    And it makes sense as well — MABS is for Windows and vapoursynth is Linux-centric plus trollish
    (since it uses Python, which suxxx by definition ).
    Image Attached Thumbnails Click image for larger version

Name:	wiiaboo-vpy-mabs-ffmpeg.jpg
Views:	27
Size:	151.0 KB
ID:	68966  

    "Programmers are human-shaped machines that transform alcohol into bugs."
    Quote Quote  
  7. Originally Posted by El Heggunte View Post
    Originally Posted by october262 View Post
    Originally Posted by meimeiriver View Post
    Originally Posted by hydra3333 View Post
    I see that nowadays ffmpeg can be built to accept vapoursynth input directly (and the audio at the same time if you like), no external piping commands etc, and processing it all on one commandline) eg
    Code:
    ffmpeg.exe -f vapoursynth -i "input.vpy" -i "audio_file-or-original_source_file.ts"-map 0:v:0 -map 1:a:0 ...

    I noticed recent versions of ffmpeg are no longer compiled with the --enable-vapoursynth option. Is there a specific reason for that? Used to be very useful.
    see this thread - https://github.com/m-ab-s/media-autobuild_suite/issues/841
    LOL wiiaboo's answer was excellent and straight-to-the-point.

    And it makes sense as well — MABS is for Windows and vapoursynth is Linux-centric plus trollish
    (since it uses Python, which suxxx by definition ).

    Actually, his butt-hurt response was a bit childish. and unprofessional.

    Also, not sure what you got against Python, but VapourSynth is a great frame server, with excellent filters for it, and vastly superior and more stable than, say, AviSynth.
    Quote Quote  
  8. Member hydra3333's Avatar
    Join Date
    Oct 2009
    Location
    Australia
    Search Comp PM
    Originally Posted by El Heggunte View Post
    vapoursynth is Linux-centric.
    cough, um, well, not too sure about that specific bit as it was touted as an avisynth replacement which was definitely a windows based product

    could not comment on any of the rest, as I try not to buy into those things.
    Quote Quote  
  9. Originally Posted by hydra3333 View Post
    Whilst I don't use MABS, I do take guidance from the build options specified by MABS and also those used by rdp, when using a derivative of deadsix27's build system:
    https://github.com/hydra3333/h3333_python_cross_compile_script_v100
    Did they ever fix the speed problems with the official patch using -f vapoursynth ? I haven't used either in a while, but I remember when you had more than 1 filter, the official version was much slower than the -f vapoursynth_alt "stephen" patch
    Quote Quote  
  10. Member hydra3333's Avatar
    Join Date
    Oct 2009
    Location
    Australia
    Search Comp PM
    [QUOTE=poisondeathray;2679776]
    Originally Posted by hydra3333 View Post
    Did they ever fix the speed problems with the official patch using -f vapoursynth ? I haven't used either in a while, but I remember when you had more than 1 filter, the official version was much slower than the -f vapoursynth_alt "stephen" patch
    Thank you for raising this.
    IDK, I missed (or forget) discussion about it, unsure why, so it'll be worth having a look at it ... unless someone already knows and can clarify. Links welcomed.
    Quote Quote  
  11. more like forgot

    you were there hydra, your thread, at least at the beginning

    vspipe was significantly faster; some speed issue with -f vapoursynth demuxer when using any other filters

    https://forum.doom9.org/showthread.php?p=1867060#post1867060

    EDIT #2: tested other source filters too lsmash, ffms2, other file types (mpeg2, avc); pretty consistent observation - direct read with only source filter is faster, but as soon as you add any additional filter in script (not just QTGMC, it can be anything like a denoiser, or even a simple resize only) it becomes slower than vspipe method at about 50% speed

    https://forum.doom9.org/showthread.php?p=1872977#post1872977
    Some quick tests - in terms of speed wise it seems to be working as expected

    Why isn't Stephen implementation the official one ?

    and then quot27 built ffmpeg with both, others started compiling with both, like patman IIRC, I stopped using vpy demuxer , it was too inconsistent

    https://forum.doom9.org/showthread.php?p=1875818#post1875818
    Said binaries include *both* VS demuxers. The upstream demuxer is still 'vapoursynth', and the other one is 'vapoursynth_alt'. It's easy to tell them apart because they return different data types as input: '-f vapoursynth' returns wrapped_avframe, '-f vapoursynth_alt' returns rawvideo. The upstream demuxer also doesn't honor relative file paths across directories (in just FFMS2? maybe in general?), while the alt demuxer does.
    Not sure of what the current status is...or if it's worth revisiting because I've been always using vspipe because it works, is fast, and is consistent. I remember the alt patch had some issues too, I can't recall exactly now
    Quote Quote  
  12. Member hydra3333's Avatar
    Join Date
    Oct 2009
    Location
    Australia
    Search Comp PM
    Ah, thanks again.
    Sometime around back then I left doom9 due to perceived excess rudeness coming my way, even though it is a wonderful source of information and has smart people attending
    Oh well, that's life.

    In my generic cross-compile, the build shows only this for vapoursynth
    Code:
    ffmpeg_OpenCL.exe -demuxers
    D  vapoursynth     VapourSynth demuxer
    I seem to recall doing some QnD tests on a non-alt and it seemed OK performance-wise, perhaps I only loaded DG's stuff and used OpenCL filters or something.

    I see per your links,
    https://forum.doom9.org/showthread.php?p=1875818#post1875818
    "The upstream demuxer is still 'vapoursynth', and the other one is 'vapoursynth_alt'.
    It's easy to tell them apart because they return different data types as input: '-f vapoursynth' returns wrapped_avframe, '-f vapoursynth_alt' returns rawvideo.
    The upstream demuxer also doesn't honor relative file paths across directories (in just FFMS2? maybe in general?), while the alt demuxer does."

    It seemed to imply an updated demuxer may perhaps be over at https://github.com/qyot27/FFmpeg however a quick cursory scan didn't spot anything of that nature.

    It's also mentioned in passing in ffmpeg-user:
    https://ffmpeg.org/pipermail/ffmpeg-user/2021-February/051871.html

    It doesn't seem like vapoursynth_alt made it into "ffmpeg proper" that I can see.

    I notice a patch for vapoursynth_alt over at MABS:
    https://raw.githubusercontent.com/m-ab-s/mabs-patches/master/ffmpeg/0001-Add-Alternati...-demuxer.patch
    and it is applied if vapoursynth is requested in the ffmpeg build.

    Since MABS does a patch, whether it gets built and linked or even works, IDK, I guess I'll try it and see what happens with the scripts I commonly use.

    Unless someone has more and better info ...

    OK, yes, vspipe is an option and I note your preference and view on comparative results and reliability.
    I did some tests initially and intuited a view that piping may have more of an overhead.
    I should do some comparative testing.

    Cheers


    edit: Of interest another (different) patch https://gist.github.com/Patman86/8f7ae3ef3f5a6631093548ed905f338f
    however I can't readily see which already-patched source it is applied to
    Last edited by hydra3333; 31st Jan 2023 at 05:44.
    Quote Quote  
  13. Originally Posted by hydra3333 View Post
    Since MABS does a patch, whether it gets built and linked or even works, IDK, I guess I'll try it and see what happens with the scripts I commonly use.

    Unless someone has more and better info ...
    I can't help you with compiling; I've only clicked through the MABS "easy" noob configuration

    Sometime around back then I left doom9
    It's like the "Mafia" - nobody ever really leaves Go back and ask quot27 or patman , because they compile with both demuxers. Ignore the other trolls and goons


    I seem to recall doing some QnD tests on a non-alt and it seemed OK performance-wise, perhaps I only loaded DG's stuff and used OpenCL filters or something.
    I remember pretty thorough testing, because the results were completely unexpected. DGSource vs. LSmash (CPU vs. CUVID) decoding (source filter choice didn't really make a difference), +/- 1 or more filters.

    I'd never use vapoursynth for just the source filter; I'd just use ffmpeg directly and skip vapoursynth. Basically "official" patch was broken IMO. Speed might be less of an issue if you had other bottlenecks (maybe slow CPU encoding like AV1), but if you're "GPU" encoding, you know that official patch is going to slow you down

    These are more recent windows results, it might be different for linux. FFmpeg binary built by Patman ~ 6 months old (the only one recent I could find with both demuxers) from here.
    https://www.mediafire.com/folder/vkt2ckzjvt0qf/StaxRip_Tools

    vspipe is reference at 100%
    ffmpeg pipe speed (or demuxer speed for -f vapoursynth, -f vapoursynth_alt)

    1080i29.97 AVC source
    DGSource + QTGMC
    103.8% -f vapoursynth_alt
    100.0% vspipe
    61.5% -f vapoursynth

    UHD AVC source
    DGSource + Spline16 downscale (zimg) to 1920x1080
    101.7% -f vapoursynth_alt
    100.0% vspipe
    72.6% -f vapoursynth

    UHD AVC source
    DGSource + Spline16 downscale (zimg) to 1920x1080 + SMDegrain
    100.0% -f vapoursynth_alt
    100.0% vspipe
    67.6% -f vapoursynth


    Unless someone fixed it in the last 6mo, the -f vapoursynth patch is basically useless for windows IMO. Maybe linux is not affected ?
    Quote Quote  
  14. Member hydra3333's Avatar
    Join Date
    Oct 2009
    Location
    Australia
    Search Comp PM
    OK, will give it a try with a home build.

    If you don't mind, how did you do your timings, was it from ffmpeg encode stats or a time either side or something ?


    edit:
    note to self, per https://ffmpeg.org/pipermail/ffmpeg-user/2021-February/051871.html
    Code:
    When piping a YUV format, the vspipe --y4m flag conveys the header info,
    pixel type, fps from the script; But the receiving ffmpeg pipe also has to
    indicate -f yuv4mpegpipe , otherwise it will be considered a raw video pipe
    (in that latter cause you wouldn't use --y4m)
    
    vspipe --y4m SCRIPT.vpy - | ffmpeg -f yuv4mpegpipe -i pipe: ...
    Last edited by hydra3333; 31st Jan 2023 at 18:09.
    Quote Quote  
  15. Originally Posted by hydra3333 View Post
    If you don't mind, how did you do your timings, was it from ffmpeg encode stats or a time either side or something ?
    very "rough" estimate - I ran it about 30-60 seconds for each run until steady state and read the fps.

    Like the doom9 post, it' s just measuring the pipe speed (or demuxer speed) as read by ffmpeg. There is no "encode stats", because there is no encode being tested. But a delta that large will have a significant impact on encoding speed , if the encoder/settings wasn't a bottleneck

    I found a more recent ffmpeg build that has vpy demuxer from a few days ago (again windows), same results, same "penalty" with -f vapoursynth
    https://jeremylee.sh/bins/
    Quote Quote  
  16. Note in newer vapoursynth versions vspipe uses -c y4m , not --y4m

    -f null NUL might be a windows thing too

    Code:
    vspipe -c y4m script.vpy - | "ffmpeg" -f yuv4mpegpipe -i - -f null NUL
    Code:
    "ffmpeg" -f vapoursynth -i script.vpy -f null NUL
    Code:
    "ffmpeg" -f vapoursynth_alt -i script.vpy -f null NUL
    I'm curious if linux has the same deficit; everything seems "better", "faster" on linux for encoding/codec stuff. If linux took a sh!t, it probably wouldn't even stink


    EDIT: And in case it was some artificial pipe speed doesn't translate into real world issues - I ran some nvenc encodes, the slowdown problem with -f vapoursynth when using more than a source filter translates to real encodes too. The delta is a bit larger on real encode
    Last edited by poisondeathray; 31st Jan 2023 at 19:05.
    Quote Quote  
  17. Member hydra3333's Avatar
    Join Date
    Oct 2009
    Location
    Australia
    Search Comp PM
    Originally Posted by poisondeathray View Post
    Note in newer vapoursynth versions vspipe uses -c y4m , not --y4m

    -f null NUL might be a windows thing too
    Thank you for that.

    Originally Posted by poisondeathray View Post
    I'm curious if linux has the same deficit; everything seems "better", "faster" on linux for encoding/codec stuff.
    I only have linux VMs, so no advantage in it for me. Wouldn't even begin to look at it on my Raspberry Pi; having said that, I did try building ffmpeg on it a year or so ago (no vapoursynth) however hardware accelerated encoding was severely limited by the prevailing ffmpeg and Pi codec code/interfaces.
    I guess I can look at ffmpeg/vapoursynth in a linux VM, I wonder if it all runs under wine or there's linux native build instructions somewhere for vapoursynth and ffmpeg.

    edit: ah. https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
    Last edited by hydra3333; 31st Jan 2023 at 21:05.
    Quote Quote  
  18. Member hydra3333's Avatar
    Join Date
    Oct 2009
    Location
    Australia
    Search Comp PM
    Initial results based on a build of ffmpeg git head as at today including MABS's vapoursynth_alt patch.
    It's sort of the same as poisondeathray says except that patch for vapoursynth_alt yields terrible results.

    NOTE: ffmpeg/vapoursynth single-filter
    Code:
    import vapoursynth as vs		# this allows use of constants eg vs.YUV420P8 
    from vapoursynth import core	# actual vapoursynth core 
    core.std.LoadPlugin(r'C:\SOFTWARE\Vapoursynth-x64\DGIndex\DGDecodeNV.dll') # do it like gonca https://forum.doom9.org/showthread.php?p=1877765#post1877765 
    core.avs.LoadPlugin(r'C:\SOFTWARE\Vapoursynth-x64\DGIndex\DGDecodeNV.dll') # do it like gonca https://forum.doom9.org/showthread.php?p=1877765#post1877765 
    # NOTE: deinterlace=1, use_top_field=True for "Interlaced"/"TFF" "AVC"/"MPA1L2" 
    video = core.dgdecodenv.DGSource(r'G:\HDTV\TEST\TEST-VSPIPE-vs-DIRECT-INPUTS\test_mpeg2.ts.mpg.dgi', deinterlace=1, use_top_field=True, use_pf=False) 
    video = core.avs.DGSharpen(video, strength=0.2) 
    video = vs.core.text.ClipInfo(video) 
    video.set_output()
    1. vspipe chugged along quickly, but I'm unsure what to make of its Time% stats given the Times numbers.

    Code:
    "C:\SOFTWARE\Vapoursynth-x64\VSPipe.exe" --progress --filter-time --container y4m "G:\HDTV\TEST\TEST-VSPIPE-vs-DIRECT-INPUTS\test_mpeg2.ts.mpg.vpy" - > NUL 
    Output 127326 frames in 77.69 seconds (1638.83 fps)
    Filtername           Filter mode   Time (%)   Time (s)
    DGSource             unordered       98.90      76.84
    DGSharpen            parreq          64.12      49.81
    ClipInfo             parallel        50.36      39.12
    2. using vspipe

    ffmpeg using output -f null NUL
    frame=127326 fps=1568 q=-0.0 Lsize=N/A time=01:24:53.00 bitrate=N/A speed=62.7x

    ffmpeg with nvenc h.264 encoding
    frame=127326 fps=675 q=14.0 Lsize= 1242115kB time=01:24:52.88 bitrate=1998.0kbits/s speed= 27x

    3. using -f vapoursynth -i something.vpy

    ffmpeg using output -f null NUL
    frame=127326 fps=840 q=-0.0 Lsize=N/A time=01:24:53.00 bitrate=N/A speed=33.6x

    ffmpeg with nvenc h.264 encoding
    frame=127326 fps=684 q=14.0 Lsize= 1242115kB time=01:24:52.88 bitrate=1998.0kbits/s speed=27.4x

    4. using -f vapoursynth_alt -i something.vpy

    ffmpeg using output -f null NUL
    frame=127326 fps=126 q=-0.0 Lsize=N/A time=01:24:53.00 bitrate=N/A speed=5.05x

    ffmpeg with nvenc h.264 encoding
    frame=127326 fps=119 q=14.0 Lsize= 1242115kB time=01:24:52.88 bitrate=1998.0kbits/s speed=4.77x


    Of interest

    It's fair to say I won't be using that patch for vapoursynth_alt, given the apparent ffmpeg "fps" and "speed" results,

    Without ffmpeg encoding, using vspipe close to doubled the apparent ffmpeg fps and speed ... I wonder how much if anything is due to work being shifted back to vspipe on a 12-core ?

    With ffmpeg encoding included, the apparent ffmpeg fps and speed were about the same.
    No advantage for vspipe here (it has been reliable enough for my uses).
    That may perhaps change when qtgmc or something is used ?
    Last edited by hydra3333; 1st Feb 2023 at 09:01.
    Quote Quote  
  19. Member hydra3333's Avatar
    Join Date
    Oct 2009
    Location
    Australia
    Search Comp PM
    Initial results based on a build of ffmpeg git head as at today excluding MABS's vapoursynth_alt patch.

    NOTE: ffmpeg/vapoursynth multi-filter

    Code:
    import vapoursynth as vs		# this allows use of constants eg vs.YUV420P8 
    from vapoursynth import core	# actual vapoursynth core 
    core.std.LoadPlugin(r'C:\SOFTWARE\Vapoursynth-x64\DGIndex\DGDecodeNV.dll') # do it like gonca https://forum.doom9.org/showthread.php?p=1877765#post1877765 
    core.avs.LoadPlugin(r'C:\SOFTWARE\Vapoursynth-x64\DGIndex\DGDecodeNV.dll') # do it like gonca https://forum.doom9.org/showthread.php?p=1877765#post1877765 
    #core.std.LoadPlugin(r'C:\SOFTWARE\Vapoursynth-x64\vapoursynth64\plugins\fft3dfilter.dll') 
    #core.std.LoadPlugin(r'C:\SOFTWARE\Vapoursynth-x64\vapoursynth64\plugins\libawarpsharp2.dll') 
    #core.std.LoadPlugin(r'C:\SOFTWARE\Vapoursynth-x64\vapoursynth64\plugins\assrender.dll') 
    # NOTE: deinterlace=1, use_top_field=True for "Interlaced"/"TFF" "AVC"/"MPA1L2" 
    video = core.dgdecodenv.DGSource(r'G:\HDTV\TEST\TEST-VSPIPE-vs-DIRECT-INPUTS\test_mpeg2.ts.mpg.dgi', deinterlace=1, use_top_field=True, use_pf=False) 
    video = core.fft3dfilter.FFT3DFilter(clip=video, sigma=2.00) 
    video = core.warp.AWarpSharp2(video) 
    video = core.assrender.Subtitle(video, r'This is a test subtitle', style="sans-serif,18,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,0.9,0.5,3,2,2,2,1") 
    video = vs.core.text.ClipInfo(video) 
    video.set_output()
    OK, using multiple cpu filters fft3dfilter/libawarpsharp2/assrender stretched the runtimes.

    1. multifilter, vspipe chugged along

    Code:
    "C:\SOFTWARE\Vapoursynth-x64\VSPipe.exe" --progress --filter-time --container y4m "G:\HDTV\TEST\TEST-VSPIPE-vs-DIRECT-INPUTS\test_mpeg2.ts.mpg.multifilter.vpy" - > NUL 
    Output 127326 frames in 602.07 seconds (211.48 fps)
    Filtername           Filter mode   Time (%)   Time (s)
    AWarpSharp2          parallel       282.58    1701.35
    FFT3DFilterInv0      parreq          99.46     598.79
    FFT3DFilterMain0     parallel        92.45     556.61
    FFT3DFilterTrans0    parreq          65.54     394.59
    DGSource             unordered       36.41     219.19
    FFT3DFilterMain1     parallel        26.62     160.27
    FFT3DFilterMain2     parallel        26.53     159.75
    FFT3DFilterInv2      parreq          21.09     126.98
    FFT3DFilterInv1      parreq          20.87     125.65
    FFT3DFilterTrans2    parreq          15.94      95.95
    FFT3DFilterTrans1    parreq          15.93      95.92
    ClipInfo             parallel         5.99      36.07
    Subtitle             parreq           5.57      33.52
    ShufflePlanes        parallel         0.04       0.22
    With multiple filters, down to 211.48 fps from 1638.83 fps however it is a meaningless comparison

    2. using vspipe

    multifilter, vspipe&ffmpeg using output -f null NUL
    frame=127326 fps=213 q=-0.0 Lsize=N/A time=01:24:53.00 bitrate=N/A speed=8.51x
    This is our vspipe&ffmpeg reference speed, with no gpu encoding, to compare with 3. below.
    I think it represents the speed at which vspipe can process the filters and pipe the frames and ffmpeg can accept them and get rid of them without encoding.
    Windows caching ... possibly kicks in somewhere, maybe around here.

    multifilter, vspipe&ffmpeg with nvenc h.264 encoding
    frame=127326 fps=205 q=11.0 Lsize= 1241804kB time=01:24:52.88 bitrate=1997.5kbits/s speed=8.19x
    This is our vspipe&ffmpeg reference speed, with gpu encoding, to compare with 3. below.
    It's close enough to "with no gpu encoding" above not to matter.

    3. using -f vapoursynth -i something.vpy

    multifilter, ffmpeg using output -f null NUL
    frame=127326 fps= 38 q=-0.0 Lsize=N/A time=01:24:53.00 bitrate=N/A speed=1.53x
    Wow that's horribly slow.

    multifilter, ffmpeg with nvenc h.264 encoding
    frame=127326 fps= 35 q=11.0 Lsize= 1241800kB time=01:24:52.88 bitrate=1997.5kbits/s speed=1.41x
    And that's even slower.


    Of interest

    Run on an amd 3900X 12-core with 32Mb memory and an nvidia 2060-Super gpu and WD black 7200rpm disk, Win11 Pro.
    ffmpeg is built x64, vapoursynth is the x64 version.

    Well well, multi-filter direct input .vpy into ffmpeg without encoding is much slower than the equivalent of vspipe into ffmpeg without encoding.
    vspipe/ffmpeg at fps=213 speed=8.51x vs ffmpeg/vpy at fps= 38 speed=1.53x

    Goodness me, that does not appear intuitive but definitely aligns with poisondeathray reports when using mutiple filters, even with latest ffmpeg.
    Interestingly, Resource Monitor says ffmpeg cpu hovers around 6% and has 50 threads.
    Something funny must be going on within vapoursynth underneath ffmpeg ?

    One could expect vapoursynth to just deliver processed frames back to ffmpeg, but obviously not.
    Doubly funny since as poisondeathray points out the abominable behaviour seems to occur when vapoursynth uses multiple filters.
    Yes the above is not a fair comparison, however it reconfirms poisondeathray's findings when using "current" ffmpeg git head and latest release of vapoursynth latest and compatible python.

    So, it looks like it's time for me to change over to use vspipe instead of using direct .vpy input to ffmpeg

    Thank you for the really good information, poisondeathray !
    Quote Quote  
  20. Originally Posted by hydra3333 View Post

    Goodness me, that does not appear intuitive but definitely aligns with poisondeathray reports when using mutiple filters, even with latest ffmpeg.
    Just 1 filter besides the source filter was enough to avoid -f vapoursynth, I think if it's a "CPU" filter . You tested DGSharpen for your "source filter plus one" filter test. I tested core.resize.Spline16. And for that , -f vapoursynth_alt was the fastest. I'll check some "GPU" filters and see if they differ from your results, and some opencl filters

    Originally Posted by poisondeathray View Post
    UHD AVC source
    DGSource + Spline16 downscale (zimg) to 1920x1080
    101.7% -f vapoursynth_alt
    100.0% vspipe
    72.6% -f vapoursynth

    It might not just be "CPU" vs "GPU" filter; there are some vapoursynth cache functions that affect results. Maybe "auto" is not ideal for direct ffmpeg demuxer

    http://www.vapoursynth.com/doc/functions/video/setvideocache.html
    Quote Quote  
  21. Member hydra3333's Avatar
    Join Date
    Oct 2009
    Location
    Australia
    Search Comp PM
    OK. My -f vapoursynth_alt wasn't the best first off, don't know why.

    Anything I can do to assist ?

    Interestingly, trimming to be a 2 minute clip and using the same .vpy
    video = core.text.CoreInfo(video, alignment=7, scale=2)
    direct .vpy seems to use 60% of the cache used by vspipe.

    Code:
    vspipe
    maximum framebuffer cache size 4,294,967,296
    Used framebuffer size            320,911,680
    
    direct .vpy
    maximum framebuffer cache size 4,294,967,296
    Used framebuffer size            191,699,904
    I'm tempted to tinker with
    https://www.vapoursynth.com/doc/functions/video/setvideocache.html
    and perhaps even
    https://www.vapoursynth.com/doc/functions/general/setmaxcpu.html

    edit:
    setmaxcpu makes no difference. can't get setvideocache to work, but probably anticipate no diff there either.
    Last edited by hydra3333; 1st Feb 2023 at 18:01.
    Quote Quote  
  22. Originally Posted by hydra3333 View Post
    OK. My -f vapoursynth_alt wasn't the best first off, don't know why.

    Anything I can do to assist ?
    I think the slower the script, but larger the penalty for -f vapoursynth

    But your -f vapoursynth_alt results were quite different than mine - it doesn't really matter, I'm just curious and none of these results are going to prevent me from using vspipe
    Quote Quote  
  23. -f vapoursynth_alt seems pretty fast on some quick tests for me; but I mentioned it above that I remember some other inconsistent results with -f vapoursynth_alt (I'm trying to find the details) , and that's why I've been using vspipe that last few years (since that thread)

    Maybe I'll ask wiiaboo to look at it hahaha I never called him idiot or anything bad . It would be nice to have a vpy demuxer in ffmpeg that works well and reliably
    Quote Quote  
  24. I guess DGSharpen + core.Text would be considered 2 filters. Deinterlace=1 for DGSource isn't really a filter, but it's slower than not deinterlacing

    I can't reproduce the "slowness" you experienced with -f vapoursynth_alt with several variations of test scripts. I used GPU filters, OpenCL filters, core.Text... It was always similar to vspipe, usually a bit faster.

    For me -f vapoursynth was always the slowest by a significant margin, except when using source filter only . Even for source filter + 1 fast GPU filter. DGSource on a progressive source , + DGSharpen , -vf vapoursynth is penalized
    Quote Quote  
  25. Member hydra3333's Avatar
    Join Date
    Oct 2009
    Location
    Australia
    Search Comp PM
    Originally Posted by poisondeathray View Post
    it doesn't really matter, I'm just curious and none of these results are going to prevent me from using vspipe
    Same here !
    I just spent a couple of hours converting all of my stuff across to use vspipe instead of direct .vpy input to ffmpeg.
    Had some fun debugging errors caused by new pipe symbols in ECHO and REM statements as generated by a bunch of vbscript ... REM doesn't necessarily REM out a full line Yes, I'm a retired dinosaur.

    Originally Posted by poisondeathray View Post
    Maybe I'll ask wiiaboo to look at it hahaha I never called him idiot or anything bad . It would be nice to have a vpy demuxer in ffmpeg that works well and reliably
    That would be really nice !
    I suspect wiiaboo won't want to debug ffmpeg interfacing with vapoursynth, though, on the basis MABS "only" provides an ffmpeg build system.
    You never know your luck though

    I skimmed the doom9 thread where you mentioned, and the issue has been around for a while. A couple of people have had a go i.e. quot27 and patman however nothing was finalised that I can find from googling "vapoursynth_alt" even though it is mentioned in ffmpeg-user https://ffmpeg.org/pipermail/ffmpeg-user/2021-February/051871.html

    I'm slightly tempted to look a this https://gist.github.com/Patman86/8f7ae3ef3f5a6631093548ed905f338f "Last active 10 months ago" which appears to be a patch on top of a vapoursynth_alt patch, however its status is unclear (it may never have been built for all I know).
    @poisondeathray would it be possible for you to ask patman about it over on doom9 ?

    Originally Posted by poisondeathray View Post
    DGSource on a progressive source , + DGSharpen , -vf vapoursynth is penalized
    It's odd isn't it. DGSource on an interlaced source , + DGSharpen , -vf vapoursynth is not penalized on my kit.
    Nothing to do with portable vapoursynth on top of portable python, surely.
    Quote Quote  
  26. Originally Posted by hydra3333 View Post
    I'm slightly tempted to look a this https://gist.github.com/Patman86/8f7ae3ef3f5a6631093548ed905f338f "Last active 10 months ago" which appears to be a patch on top of a vapoursynth_alt patch, however its status is unclear (it may never have been built for all I know).
    @poisondeathray would it be possible for you to ask patman about it over on doom9 ?
    Patman's last Doom9 post was Aug 5/2020 and last activity Jan 21/2021 . You might have better luck contacting on github, but I'll try a PM
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!