HOWTO: AviSynth video processing with WINE

[avxsynthTesting]

Due to a rash of buildsystem-related commits to AvxSynth over the last few days, things are much easier to coalesce together now. FFmpeg and FFMS2 can now be built statically and linked in, and they no longer have to be installed to the system (so that existing versions won't conflict with the ones AvxSynth gets). In light of that, an updated set of instructions for building it:

snipped

First off, thank you for your interest in AvxSynth. I am a member of the AvxSynth team and am responsible for improving the build system. As such, I am very interested in your feedback. Please note that AvxSynth has an official forum thread at Doom9's forum. Additionally, we invite you to provide feedback at the official GitHub project page.

I have come here because your post shows as one of the top results on a Google search for AvxSynth, and would like to address some points before any confusion is caused:

1. AvxSynth libraries can be installed and run from /usr/local/lib without problem. You must run the command "sudo ldconfig" after installing any shared libraries. As of earlier today, the build system now does this automatically.

2. Attempting to link static libraries into shared libraries is non-portable. Specifically, attempting to do this on x86-64 will cause a linking error. Therefore, I would advise those intending to build their own copy of ffmpeg/libav to enable the shared libraries.

Thank you!

[qyot27]

First off, thank you for your interest in AvxSynth. I am a member of the AvxSynth team and am responsible for improving the build system. As such, I am very interested in your feedback. Please note that AvxSynth has an official forum thread at Doom9's forum. Additionally, we invite you to provide feedback at the official GitHub project page.

I've been responding on the Doom9 thread too. I reported the recently-resolved mplayer path issue there back in March, along with some other things that have also been resolved. I'm watching the Github repo and it's on my RSS feeds.

1. AvxSynth libraries can be installed and run from /usr/local/lib without problem. You must run the command "sudo ldconfig" after installing any shared libraries. As of earlier today, the build system now does this automatically.

That certainly explains it. The need to run ldconfig escapes me at times.

2. Attempting to link static libraries into shared libraries is non-portable. Specifically, attempting to do this on x86-64 will cause a linking error. Therefore, I would advise those intending to build their own copy of ffmpeg/libav to enable the shared libraries.

Wouldn't the linking error be solved by using position-independent code flags on all the dependencies? That's what a cursory Googling seemed to hint at. For x86-64 it's generally recommended to use that option anyway; the only reason I omitted it from my typical instructions is that I primarily work on x86 and it doesn't require it to be explicitly declared there.

[avxsynthTesting]

I've been responding on the Doom9 thread too. I reported the recently-resolved mplayer path issue there back in March, along with some other things that have also been resolved. I'm watching the Github repo and it's on my RSS feeds.


That certainly explains it. The need to run ldconfig escapes me at times.


Wouldn't the linking error be solved by using position-independent code flags on all the dependencies? That's what a cursory Googling seemed to hint at. For x86-64 it's generally recommended to use that option anyway; the only reason I omitted it from my typical instructions is that I primarily work on x86 and it doesn't require it to be explicitly declared there.

Unfortunately, due to some issues in ffmpeg/libav codebase, merely compiling with PIC options enabled is not sufficient. For more information, please see http://roundup.libav.org/issue1563 . In general, this is not a recommended operation, and I especially recommend new users to stick with shared libraries.

[qyot27]

Unfortunately, due to some issues in ffmpeg/libav codebase, merely compiling with PIC options enabled is not sufficient. For more information, please see http://roundup.libav.org/issue1563 . In general, this is not a recommended operation, and I especially recommend new users to stick with shared libraries.

Yeah, I ran into the problem last night when I finally tried it on a 64-bit install of 11.10. I only had enough energy last night to figure out, like in the bug report there, that it works if --disable-asm (and probably more specifically, --disable-mmx) is used.

I wondered about that, looked at the actual piece of FFmpeg source code that had the issue, gave up on that, then looked at how the C-plugin version of FFMS2 does it for normal AviSynth (which gave me an idea), and then tried a little bit more just now. Turns out that the only thing needed after the PIC flagging is to pass -Wl,-Bsymbolic to AvxSynth with --extra-ldflags. No need to disable assembly, everything linked and seemed to work just like it does on my 32-bit system.



Since I'm wondering about the comments about portability, is this pertaining to something internal to the code development process? Because the only use of 'portability' I'm used to is in reference to being able to use a piece of software built on computer A on similar computer B without problems, but I have a feeling that's not what was meant in those discussions and comments.

[avxsynthTesting]

Portability there is referring to running on multiple operating systems and machine architectures. Generally speaking, mixing static and shared libraries is not a well-defined operation on all systems. That said, AvxSynth is unlikely to ever run on anything but x86 and Linux so it is a bit of a moot point. It is interesting that you managed to compile the plugin with -Bsymbolic, but I'm reluctant to just add that into the build system.

[qyot27]

Portability there is referring to running on multiple operating systems and machine architectures. Generally speaking, mixing static and shared libraries is not a well-defined operation on all systems. That said, AvxSynth is unlikely to ever run on anything but x86 and Linux so it is a bit of a moot point. It is interesting that you managed to compile the plugin with -Bsymbolic, but I'm reluctant to just add that into the build system.

Although it would seem to be a little weird and kind of unelegant, it could be passed as a parameter. Something like --static-dep that has a warning that it's only relevant for x64. Alternatively that there could be some conditional detection of the dependencies that would be able to tell whether -Bsymbolic is needed and add it only as necessary. The latter option is what the FFMS2 trunk seems to do, as there's a check toward the end concerning whether -Wl,-Bsymbolic is needed.

While I had actually gotten the idea from looking at FFMS2's AviSynth C-plugin (since FFMS2 normally has the decoders/demuxers/parsers statically linked in when used on Windows, and I knew that in addition to that, that the plugin can be built as 64-bit for the 64-bit fork(s) of AviSynth), the -Bsymbolic fix was actually noted in that bug report from FFmpeg as the way to resolve it, toward the end.

[qyot27]

Since it's notable to the thread, VapourSynth has been getting attention lately. Obviously the advanced usage is beyond the scope of the thread and the INSTALL file that comes with the source tells you pretty much everything you need to do to build it, but having a post describing the methodology on Ubuntu specifically might be in order. I actually had this worked out a while ago, but wanted to wait for Quantal to be released so I could verify that the steps still worked.

VapourSynth scripts are written in Python, since VS itself is implemented as a Python module. So they're going to look different than AviSynth scripts.

First, follow the guide on getting FFmpeg compiled here:
https://ffmpeg.org/trac/ffmpeg/wiki/...mpilationGuide
(in the checkinstall step, use 7: in the pkgversion instead of 5: - otherwise, the system will try to replace it whenever libav-tools has an update)

You can probably use libav, but since I don't I'm not going to comment on it.

Installing the dependencies and building an up-to-date version of Cython:

sudo apt-get install libqtcore4 python3 python3-dev wget subversion
wget "http://pypi.python.org/packages/source/C/Cython/Cython-0.17.1.tar.gz#md5=f0bd2494dbe080a1185b61fa358135f2" -O - | tar -xzvf -
cd Cython-0.17.1
sudo python3 setup.py install

Building and installing VapourSynth itself:

svn checkout http://vapoursynth.googlecode.com/svn/trunk vapoursynth
cd vapoursynth
./bootstrap.py
./waf configure
./waf build
sudo ./waf install
sudo ./setup.py install
sudo ldconfig

Building and installing FFMS2:

svn checkout http://ffmpegsource.googlecode.com/svn/trunk ffms2
cd ffms2
./autogen.sh
./configure --enable-shared
make
sudo checkinstall --pkgname=ffms2 --pkgversion="1:$(./version.sh)-svn" --backup=no --deldoc=yes --fstrans=no --default
sudo ldconfig

The ./autogen.sh step is only necessary until the next time the build system for FFMS2 is regenerated officially. If you don't perform the autogen step, the VapourSynth interface won't get built.



Now, for the script. You could just look at the documentation, since it's explained there, but for the sake of making a complete post:

#!/usr/bin/python3
import vapoursynth as vs
import sys
core = vs.Core()
core.std.LoadPlugin("/usr/local/lib/libffms2.so")
ret = core.ffms2.Source("inputvideo.avi")
ret.output(sys.stdout, y4m=True)

As you can see, it's Python. The #!/usr/bin/python3 line forces the script to be interpreted by the correct version of Python (since 12.10 still ships with Python 2.7.3, you're going to have two different versions of Python installed, and this ensures you're using 3.2).

The syntax is explained at greater length in the official documentation.


To use it with something, first make the script (we'll call it vstestscript.vpy) executable:

chmod +x vstestscript.vpy

Now feed it to mplayer:

./vstestscript.vpy | mplayer -

Or this would work, if mplayer accepted ffmpeg's extended Y4M format that VS uses. To get around this, pipe it through ffmpeg first (part of the reason I advise to use bona-fide ffmpeg, and not libav):

./vstestscript.vpy | ffmpeg -i - -f yuv4mpegpipe - | mplayer -

In x264's case, support for the extended Y4M format is in the x264-devel branch, so hopefully there'll be an update soon that pushes it into the main branch. For those wondering, the reason for the extended format is because VS supports high bit depths, and so does the extended Y4M format. I have my doubts about the 'running it through ffmpeg first' thing actually preserving these higher bit depths (and possibly colorspaces), so hopefully we can get direct support of the extended Y4M or .vpy scripts into all of this stuff soon.

Seeing as the scripts are just normal Python, you could do more exotic things with them. Not that I know how to accomplish that, but the option is there.

[FakeOutdoorsman]

First, follow the guide on getting FFmpeg compiled here:
https://ffmpeg.org/trac/ffmpeg/wiki/...mpilationGuide
(in the checkinstall step, use 7: in the pkgversion instead of 5: - otherwise, the system will try to replace it whenever libav-tools has an update)

Thanks, I forgot about that one. The guide has been updated.

[qyot27]

Because this is relevant, both x264 and FFmpeg (and by extension, anything that uses libavformat, like mpv) now support opening AviSynth scripts on Linux and OSX directly by using AvxSynth. x264 enables it automatically, FFmpeg requires the --enable-avisynth option.