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 12th July 2018, 16:08   #41  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,529
Quote:
Originally Posted by MysteryX View Post
There are indeed risks with downloading DLLs from unknown sources. However, one needs to do special work to run code in a DLL, it won't happen automatically, and most viruses within DLLs will be auto-detected by a good anti-virus.

Running a Python script by double-clicking on a file (for users who may not even know what VapourSynth is), however, can seriously limit the adaptation of VapourSynth. If that's the reason FFMPEG hasn't added native support for it, then I fully understand. In a business or production environment, have to be *VERY* careful where the scripts are coming from and where they are running. I don't think many people realize that. I also don't think Kaspersky will scan the Python raw script for malicious code.

I would say that this, combined with the lack of audio support, are the 2 things most limiting the adaptation of VapourSynth.
In Avisynth, all you have to do is get someone to load your DLL by saying it does something cool, and it turns out that pretty much everyone would. You can't even inspect that without being an expert programmer/reverser.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
foxyshadis is offline   Reply With Quote
Old 12th July 2018, 16:30   #42  |  Link
ChaosKing
Registered User
 
Join Date: Dec 2005
Location: Germany
Posts: 1,363
And If you are really evil you could try to overwrite files with http://avisynth.nl/index.php/ImageWriter
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth
VapourSynth Portable FATPACK || VapourSynth Database || https://github.com/avisynth-repository
ChaosKing is offline   Reply With Quote
Old 12th July 2018, 18:22   #43  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,189
I see a clear difference between having security risks on a development machine for someone using Avisynth/VapourSynth and downloading various DLLs, compared to a production server using FFMPEG without any awareness of what VapourSynth/Avisynth even are.

If you take risks on your local machine, that's one thing.

If a server environment is at risk simply by using FFMPEG because it auto-loads a risky script engine (without admin awareness), that's something else.
MysteryX is offline   Reply With Quote
Old 28th February 2019, 02:28   #44  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 4,389
Using Wolfberry's FFMpeg build with vpy support , direct vapoursynth input is about 50% speed compared to vspipe to the same ffmpeg . I would have expected marginally faster for direct vpy demuxer. Script is just QTGMC . I tried specifying different ffmpeg -threads values as an input argument. Any ideas, or am I doing something wrong? Could it be a cache issue ?

https://forum.doom9.org/showthread.p...31#post1866931

Code:
vspipe --y4m input.vpy - | "ffmpeg" -f yuv4mpegpipe -i - -an -f null NUL

Code:
"ffmpeg" -f vapoursynth -i input.vpy -an -f null NUL

EDIT #1: but another test of just reading a MP4 video with lsmash (no other filters, just source filter), direct vapoursynth is about 1.4-1.5x faster than vspipe to ffmpeg

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

Is it specific to this ffmpeg build, or do other people get different results with their own build ?

Last edited by poisondeathray; 28th February 2019 at 03:10.
poisondeathray is offline   Reply With Quote
Old 28th February 2019, 07:27   #45  |  Link
HolyWu
Registered User
 
HolyWu's Avatar
 
Join Date: Aug 2006
Location: Taiwan
Posts: 752
Quote:
Originally Posted by poisondeathray View Post
Is it specific to this ffmpeg build, or do other people get different results with their own build ?
It seems that there is something wrong with wm4's vapoursynth demuxer implementation. Below ffmpeg_1 uses the official implementation, while ffmpeg_2 uses the implementation from Stephen.

Test1
Code:
from vapoursynth import core
core.max_cache_size = 12 * 1024
clip = core.ffms2.Source(r'test.mp4')
clip.set_output()
Code:
>vspipe -y test.vpy - | ffmpeg_1 -hide_banner -benchmark -f yuv4mpegpipe -i - -f null -
Input #0, yuv4mpegpipe, from 'pipe:':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p(progressive), 1920x1080, 50 fps, 50 tbr, 50 tbn, 50 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf58.20.100
    Stream #0:0: Video: wrapped_avframe, yuv420p, 1920x1080, q=2-31, 200 kb/s, 50 fps, 50 tbn, 50 tbc
    Metadata:
      encoder         : Lavc58.35.100 wrapped_avframe
Output 1250 frames in 7.06 seconds (177.05 fps)24.20 bitrate=N/A speed=3.68x
frame= 1250 fps=181 q=-0.0 Lsize=N/A time=00:00:25.00 bitrate=N/A speed=3.62x
video:654kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=0.109s stime=4.516s rtime=6.912s
bench: maxrss=16848kB


>ffmpeg_1 -hide_banner -benchmark -f vapoursynth -i test.vpy -f null -
Input #0, vapoursynth, from 'test.vpy':
  Duration: 00:00:25.00, start: 0.000000, bitrate: 0 kb/s
    Stream #0:0: Video: wrapped_avframe, yuv420p, 1920x1080, 50 tbr, 50 tbn, 50 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (wrapped_avframe (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf58.20.100
    Stream #0:0: Video: wrapped_avframe, yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 50 fps, 50 tbn, 50 tbc
    Metadata:
      encoder         : Lavc58.35.100 wrapped_avframe
frame= 1250 fps=238 q=-0.0 Lsize=N/A time=00:00:25.00 bitrate=N/A speed=4.76x
video:654kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=27.969s stime=0.312s rtime=5.256s
bench: maxrss=975760kB


>ffmpeg_2 -hide_banner -benchmark -f vapoursynth -i test.vpy -f null -
Input #0, vapoursynth, from 'test.vpy':
  Duration: 00:00:25.00, start: 0.000000, bitrate: 0 kb/s
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080, 50 fps, 50 tbr, 50 tbn, 50 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf58.20.100
    Stream #0:0: Video: wrapped_avframe, yuv420p, 1920x1080, q=2-31, 200 kb/s, 50 fps, 50 tbn, 50 tbc
    Metadata:
      encoder         : Lavc58.35.100 wrapped_avframe
frame= 1250 fps=201 q=-0.0 Lsize=N/A time=00:00:25.00 bitrate=N/A speed=4.02x
video:654kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=34.578s stime=3.328s rtime=6.224s
bench: maxrss=984464kB
Test2
Code:
from vapoursynth import core
core.max_cache_size = 12 * 1024
clip = core.ffms2.Source(r'test.mp4')
clip = clip.std.BoxBlur(hradius=2, vradius=2).misc.AverageFrames(weights=[1] * 5)
clip.set_output()
Code:
>vspipe -y test.vpy - | ffmpeg_1 -hide_banner -benchmark -f yuv4mpegpipe -i - -f null -
Input #0, yuv4mpegpipe, from 'pipe:':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p(progressive), 1920x1080, 50 fps, 50 tbr, 50 tbn, 50 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf58.20.100
    Stream #0:0: Video: wrapped_avframe, yuv420p, 1920x1080, q=2-31, 200 kb/s, 50 fps, 50 tbn, 50 tbc
    Metadata:
      encoder         : Lavc58.35.100 wrapped_avframe
Output 1250 frames in 19.06 seconds (65.57 fps)24.80 bitrate=N/A speed=1.34x
frame= 1250 fps= 66 q=-0.0 Lsize=N/A time=00:00:25.00 bitrate=N/A speed=1.33x
video:654kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=0.203s stime=4.469s rtime=18.845s
bench: maxrss=16848kB


>ffmpeg_1 -hide_banner -benchmark -f vapoursynth -i test.vpy -f null -
Input #0, vapoursynth, from 'test.vpy':
  Duration: 00:00:25.00, start: 0.000000, bitrate: 0 kb/s
    Stream #0:0: Video: wrapped_avframe, yuv420p, 1920x1080, 50 tbr, 50 tbn, 50 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (wrapped_avframe (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf58.20.100
    Stream #0:0: Video: wrapped_avframe, yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 50 fps, 50 tbn, 50 tbc
    Metadata:
      encoder         : Lavc58.35.100 wrapped_avframe
frame= 1250 fps= 24 q=-0.0 Lsize=N/A time=00:00:25.00 bitrate=N/A speed=0.478x
video:654kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=84.891s stime=0.922s rtime=52.273s
bench: maxrss=1152720kB


>ffmpeg_2 -hide_banner -benchmark -f vapoursynth -i test.vpy -f null -
Input #0, vapoursynth, from 'test.vpy':
  Duration: 00:00:25.00, start: 0.000000, bitrate: 0 kb/s
    Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 1920x1080, 50 fps, 50 tbr, 50 tbn, 50 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf58.20.100
    Stream #0:0: Video: wrapped_avframe, yuv420p, 1920x1080, q=2-31, 200 kb/s, 50 fps, 50 tbn, 50 tbc
    Metadata:
      encoder         : Lavc58.35.100 wrapped_avframe
frame= 1250 fps= 68 q=-0.0 Lsize=N/A time=00:00:25.00 bitrate=N/A speed=1.37x
video:654kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
bench: utime=137.797s stime=3.359s rtime=18.304s
bench: maxrss=1189088kB
HolyWu is offline   Reply With Quote
Old 8th March 2019, 14:12   #46  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,225
Post #26 in this thread linked to a copy of it on pastebin.

I think I'll probably have to switch to it also, since I could never seem to get the official implementation to cross-compile right, despite following the steps provided earlier to get the Python lib encapsulated correctly.

Last edited by qyot27; 8th March 2019 at 14:15.
qyot27 is offline   Reply With Quote
Old 27th April 2019, 15:59   #47  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 4,389
Thanks Wolfberry ; does this recent one have wm4 or Stephen patch ?
poisondeathray is offline   Reply With Quote
Old 28th April 2019, 03:32   #48  |  Link
Wolfberry
Helenium(Easter)
 
Wolfberry's Avatar
 
Join Date: Aug 2017
Location: Hsinchu, Taiwan
Posts: 99
I'm sure this build uses Stephen's implementation, but I haven't done any tests.
__________________
Monochrome Anomaly
Wolfberry is offline   Reply With Quote
Old 28th April 2019, 05:10   #49  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 4,389
Quote:
Originally Posted by Wolfberry View Post
I'm sure this build uses Stephen's implementation, but I haven't done any tests.
Some quick tests - in terms of speed wise it seems to be working as expected

Why isn't Stephen implementation the official one ?

Last edited by poisondeathray; 28th April 2019 at 05:12.
poisondeathray is offline   Reply With Quote
Old 28th April 2019, 22:50   #50  |  Link
Pat357
Registered User
 
Join Date: Jun 2006
Posts: 452
Quote:
Originally Posted by qyot27 View Post
Post #26 in this thread linked to a copy of it on pastebin.

I think I'll probably have to switch to it also, since I could never seem to get the official implementation to cross-compile right, despite following the steps provided earlier to get the Python lib encapsulated correctly.
Unfortunately I can't help you with this specific issue, but I have a request :
could you consider to make a new FFMS2 compile with the libaom decoder replaced by dav1d ?
On relative simple scripts, the just decoding from AV1 takes a lot of CPU with libaom, while dav1d is at least 4x faster on modern CPU's.

With the following videos, I can't get even real-time speed when using liboam :

https://www.elecard.com/storage/vide..._13.9mbps.webm

https://www.elecard.com/storage/vide..._22.7mbps.webm

Last edited by Pat357; 28th April 2019 at 23:05.
Pat357 is offline   Reply With Quote
Old 28th April 2019, 23:31   #51  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 4,389
Quote:
Originally Posted by Pat357;1873061I have a request :
could you consider to make a new FFMS2 compile with the libaom decoder replaced by dav1d ?
On relative simple scripts, the just decoding from AV1 takes a lot of CPU with libaom, while dav1d is at least 4x faster on modern CPU's.

With the following videos, I can't get even real-time speed when using liboam :

[url
https://www.elecard.com/storage/video/Stream3_AV1_4K_13.9mbps.webm[/url]

https://www.elecard.com/storage/vide..._22.7mbps.webm

Wolfberry posted ffms2 builds with libdav1d in the other thread

https://forum.doom9.org/showthread.php?t=176198

Quote:
FFMS2:

ffmpeg 4.2-dev N-93683-g163bb087f8
libdav1d 0.2.2-0d7aa95d
libopenjpeg 2.3.1
mbedTLS 2.16.1
poisondeathray is offline   Reply With Quote
Old 29th April 2019, 00:06   #52  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,225
Quote:
Originally Posted by Pat357 View Post
Unfortunately I can't help you with this specific issue, but I have a request :
could you consider to make a new FFMS2 compile with the libaom decoder replaced by dav1d ?
On relative simple scripts, the just decoding from AV1 takes a lot of CPU with libaom, while dav1d is at least 4x faster on modern CPU's.
You mean like the builds I released in January and March of this year?
qyot27 is offline   Reply With Quote
Old 30th April 2019, 02:52   #53  |  Link
hydra3333
Registered User
 
Join Date: Oct 2009
Location: crow-land
Posts: 540
Quote:
Originally Posted by qyot27 View Post
... since I could never seem to get the official implementation to cross-compile right, despite following the steps provided earlier to get the Python lib encapsulated correctly.
Quote:
Originally Posted by Wolfberry View Post
ffmpeg-4.2-dev-N-93696-g45048ece81-win64-static

Code:
ffmpeg version N-93696-g45048ece81 Copyright (c) 2000-2019 the FFmpeg developers

built with gcc 9.0.1 (Built by Wolfberry) 20190426 (prerelease)

configuration: --enable-amf --enable-avisynth --enable-bzlib --enable-cuda --enable-d3d11va --enable-ffnvcodec --enable-frei0r --enable-gray --enable-iconv --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libcdio 
--enable-libdav1d --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-liblensfun --enable-libmfx --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-librubberband 
--enable-libsnappy --enable-libsoxr --enable-libsrt --enable-libssh --enable-libtesseract --enable-libvidstab --enable-libvmaf --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg 
--enable-libzmq --enable-lzma --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-openssl --enable-pthreads --enable-sdl2 --enable-vapoursynth --enable-zlib --enable-gpl --enable-version3
Would it be possible to post the build scripts ? That'd likely help the many.
hydra3333 is offline   Reply With Quote
Old 30th April 2019, 11:39   #54  |  Link
richardpl
Registered User
 
Join Date: Jan 2012
Posts: 149
That build is unsafe for using.
richardpl is offline   Reply With Quote
Old 30th April 2019, 12:00   #55  |  Link
Wolfberry
Helenium(Easter)
 
Wolfberry's Avatar
 
Join Date: Aug 2017
Location: Hsinchu, Taiwan
Posts: 99
Do you mean the auto-detection of .vpy extension?

That's in the original implementation found at post #26

I can try revert that part to the official implementation by wm4.

Or do you mean something else?

If you feel unsafe then don't use it. It's simple
__________________
Monochrome Anomaly

Last edited by Wolfberry; 30th April 2019 at 12:30.
Wolfberry is offline   Reply With Quote
Old 30th April 2019, 17:27   #56  |  Link
Pat357
Registered User
 
Join Date: Jun 2006
Posts: 452
Quote:
Originally Posted by richardpl View Post
That build is unsafe for using.
Why is that ?
Pat357 is offline   Reply With Quote
Old 4th May 2019, 11:12   #57  |  Link
hydra3333
Registered User
 
Join Date: Oct 2009
Location: crow-land
Posts: 540
Thanks !
hydra3333 is offline   Reply With Quote
Old 4th May 2019, 16:49   #58  |  Link
sl1pkn07
Pajas Mentales...
 
Join Date: Dec 2004
Location: Spanishtán
Posts: 478
that patch is safe to push to upstream?
__________________
[AUR] Vapoursynth Stuff
[AUR] Avisynth Stuff
sl1pkn07 is offline   Reply With Quote
Old 4th May 2019, 23:17   #59  |  Link
Pat357
Registered User
 
Join Date: Jun 2006
Posts: 452
@Wolfberry
Your latest FFmpeg build N-93755-ga5387f983d (20190504) seems to be broken for me.

If I do "ffplay -i "d:\path.to\a.mkv", I get the normal text output on screen, but the window that should show the video is white with the typical "windows wait" icon that stays there for about 5 seconds after the window closes.
The 5 seconds seems to be interdependent from the video-length: same for a 20s fragment or a full film (90-210min).

Also Avisynth scripts or VS scripts produce the same scenario, even when I specify "ffplay -f vapoursynth -i a.vpy"

Your previous version N-93696-g45048ece81 posted from 2019-04-30 is working perfect.

I have VS R45 installed on my system (not port.)

From my Windows log I have :
Code:
Foutbucket 1498974882443012356, type 4
Naam van gebeurtenis: APPCRASH
Antwoord: Niet beschikbaar
Id van CAB-bestand: 0

Handtekening van probleem:
P1: ffplay.exe
P2: 0.0.0.0
P3: 00000000
P4: msvcrt.dll
P5: 7.0.17134.1
P6: 5cbba6fd
P7: c0000005
P8: 000000000005cc53
P9: 
P10:

Last edited by Pat357; 4th May 2019 at 23:48. Reason: attached windows-log info : appcrash
Pat357 is offline   Reply With Quote
Old 5th May 2019, 15:00   #60  |  Link
Wolfberry
Helenium(Easter)
 
Wolfberry's Avatar
 
Join Date: Aug 2017
Location: Hsinchu, Taiwan
Posts: 99
After some investigation, the culprit was LTO.

I saw there are some improvements in LTO optimizations in GCC 9, so I decided to give it a try.

It turns out that LTO was still more or less broken for ffmpeg, at least in MinGW.
__________________
Monochrome Anomaly

Last edited by Wolfberry; 12th May 2019 at 15:30.
Wolfberry is offline   Reply With Quote
Reply

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 12:35.


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