AvxSynth: a Linux port of AviSynth

[videophool]

Originally Posted by videophool

We have found a problem where AvxSynth is causing a segfault when there is a script error.

Root cause has been identified, and fix is in progress.
http://code.google.com/p/avxsynth/issues/detail?id=6

[sl1pkn07]

i make pkgbuild for ArchLinux

http://aur.archlinux.org/packages.php?ID=57829

have patches for fix panths and other "fix"

greetings

[videophool]

Originally Posted by sl1pkn07

i make pkgbuild for ArchLinux

http://aur.archlinux.org/packages.php?ID=57829

have patches for fix panths and other "fix"

greetings

Thanks for the contribution.

[qyot27]

If the user normally compiles mplayer themselves (and leaves the prefix alone, resulting in it installing the binary to /usr/local/bin), it results in a broken pipe due to AVXEdit and avxSynthFrameServer looking in /usr/bin rather than simply querying the $PATH. After I copied mplayer from /usr/local/bin to /usr/bin it worked fine.

[qyot27]

Also, I'm not sure of what the issue is, but it's not wanting to load FFMS2, resulting in the 'There is no function called FFVideoSource' error. The plugin is in ~/.AVXSynth/plugins. Things I'm unsure of here:

*Is all the building the prerequisites as shared necessary, or was that done simply out of Debian conventions? I tried building FFMS2 as static and as shared to link to ffms2avs, and neither one produced a working plugin. It takes too long to build FFmpeg on here, so I was only able to test with a static build of it. Not sure if that matters, as I'd think the only part that needs to be a shared object is the final plugin built by ffms2avs' Makefile, but that's only basing it on how the Windows plugins work.

*I also was using git master and SVN trunk versions rather than the point releases. Maybe that has something to do with it?




EDIT 2012-03-25: Yeah, I'm pretty sure it was because I didn't build FFmpeg as shared. I tested it again today with a shared FFmpeg, shared FFMS2, and then remade ffms2avs (+ the patch posted from the AUR) and it seemed to work fine opening a file and then resizing it.

Due to how messy this could potentially get with existing installs of those libraries (either from the distro repos or user-compiled), I'd strongly favor being able to use non-system copies of FFmpeg and FFMS2 to link against, as well as being able to use a static version of FFmpeg (if that truly is at the root of that issue I noted above). Of course if this was already planned, then just ignore me.

[videophool]

Originally Posted by qyot27

f course if this was already planned, then just ignore me.

The project could use an install expert to sort these things out. The current team is all SW developers, and our focus has been mainly on getting the framework ported and running.

[sl1pkn07]

hello. is possible add suport to compile with GCC 4.7.0?

greetings

[videophool]

Originally Posted by sl1pkn07

hello. is possible add suport to compile with GCC 4.7.0?

greetings

Haven't tried yet. Are you seeing problems?

[sl1pkn07]

yes:

http://paste.kde.org/447110
http://paste.kde.org/447116

and not GCC 4.7.0 related:

http://paste.kde.org/447122

and:

make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.

greetings

[videophool]

Originally Posted by videophool

We will look at integrating the revised SoftWire. Our current version of AvxSynth has the built-in resize routines stubbed out and set to call into ffmpeg (they use SoftWire). This will be our first SoftWire test.

Our SoftWire investigation is not going well. We cannot even get the SoftWire test code to run on gcc 64.

[Mr VacBob]

Is SoftWire a JIT library? In that case you might be having problems with the ABI difference between Win64 and ELF/amd64. Basically some xmm registers need to be saved outside of calls into the Win64 system.

I took a quick look through the source and noticed some uses of things like 'unsigned', 'long', 'InterlockedIncrement' which probably indicate portability problems or 32/64bit bugs. 'unsigned' on loop counters can lead to overflow bugs and inhibits compiler optimization, while 'long' never has the size you want it to have, and use of atomic counters is bad unless you're very sure it makes the code thread-safe.

That said, if you inherited that code from AVISynth maybe it's best not to change it downstream.

As for all the non-JITted assembly I see commented out, it'd be best to port it to use x264's yasm library, which will also be good for AVISynth Win64.

Then you're only left with the portability problem of getting all the external plugins to work…

[videophool]

Originally Posted by Mr VacBob

Is SoftWire a JIT library? In that case you might be having problems with the ABI difference between Win64 and ELF/amd64. Basically some xmm registers need to be saved outside of calls into the Win64 system.

I took a quick look through the source and noticed some uses of things like 'unsigned', 'long', 'InterlockedIncrement' which probably indicate portability problems or 32/64bit bugs. 'unsigned' on loop counters can lead to overflow bugs and inhibits compiler optimization, while 'long' never has the size you want it to have, and use of atomic counters is bad unless you're very sure it makes the code thread-safe.

That said, if you inherited that code from AVISynth maybe it's best not to change it downstream.

As for all the non-JITted assembly I see commented out, it'd be best to port it to use x264's yasm library, which will also be good for AVISynth Win64.

Then you're only left with the portability problem of getting all the external plugins to work…

Some posters on this thread had suggested that AviSynth 2.6 included SoftWire that had been successfully ported to gcc and Win64. Since AvxSynth still needs a good cross-platform optimization model, we decided to investigate to see if we could get SoftWire running with AvxSynth. The initial results are not encouraging.

[sh0dan]

Since softwire is abandoned by the original developer, and I think all 64 bit is mostly untested, you might want to look at asmjit, which is very similar, and enable you to do JIT code that is 32/64 and Windows/Linux compatible, you might want to use that instead -it looks very similar and nice.

http://code.google.com/p/asmjit/

[videophool]

Originally Posted by sh0dan

Since softwire is abandoned by the original developer, and I think all 64 bit is mostly untested, you might want to look at asmjit, which is very similar, and enable you to do JIT code that is 32/64 and Windows/Linux compatible, you might want to use that instead -it looks very similar and nice.

http://code.google.com/p/asmjit/

Thanks. We will take a look.

[verydoomed]

I went to the website and compared to installing Regular windows avisynth this is SOOOO complicated that I am not even going to try.Even the first line of the instruction was a real put off "Install ubuntu-11.10" No thanks I much prefer my Mint 10.10 and am not willing to move to 11.10 I'll just have to stick with Avisynth under wine. I watched the youtube video also but I am not clear, will you be able to save your script and open it in some video editor on linux? or a simple equivalent to virtual dub?

[videophool]

Originally Posted by verydoomed

I went to the website and compared to installing Regular windows avisynth this is SOOOO complicated that I am not even going to try.Even the first line of the instruction was a real put off "Install ubuntu-11.10" No thanks I much prefer my Mint 10.10 and am not willing to move to 11.10 ... I watched the youtube video also but I am not clear, will you be able to save your script and open it in some video editor on linux? or a simple equivalent to virtual dub?

We are a small team of sw devs without adequate resources to test on many platforms, or develop a good installer. You can probably install on other Linux platforms, and if someone provides the instructions, we will post them on the wiki.

Once AvxSynth is proven stable, we will work on an ffmpeg component so that any app that supports ffmpeg will be able to open .avs scripts. As for a Virtual-Dub like app, it would be great if an industrious developer decided to make such a contribution. In the mean time, we have a very simple editor, AvxEdit, and the frame server that we use ti pipe to X264.

Originally Posted by verydoomed

I'll just have to stick with Avisynth under wine.

We find avisynth/wine to be very unstable, and it is subject to licensing problems with MSFT libraries. With a small committed community, avxsynth could quickly achieve the stability and support needed to replace the avs/wine hack.

[Yellow_]

Originally Posted by videophool

Once AvxSynth is proven stable, we will work on an ffmpeg component so that any app that supports ffmpeg will be able to open .avs scripts. As for a Virtual-Dub like app, it would be great if an industrious developer decided to make such a contribution.

Sounds great.

There are a number of NLE type ffmpeg based applications available for Linux that'll offer more than Virtualdub functionality as is.

Blender has a video editor of sorts, but also a nodal based compositor and tracker/stabilizer, compositor soon to be OpenCL, code well on the way just not in trunk yet.

Kdenlive NLE with underlying MLT (Media Lovin Toolkit) is ffmpeg based. http://www.mltframework.org/twiki/bin/view/MLT/

[avxanne]

We have updated the the ffmpegsource plugin and renamed it to avxffms2. This updated code (check out recent code at www.avxsynth.org) should fix the issue some people were experiencing where the system could not find FFVideoSource(). Please delete the old libffms2avx.so from the ~/.AVXSynth/plugins/ directory so that avxsynth will pick up FFVideoSource from libavxffms2.so. This version was tested with the ffms 2.17 and libav 0.7.4

The source code of the plugin can also be found in the avxsynth_plugin branch of the ffmpegsource project svn tree.
http://code.google.com/p/ffmpegsource/source/browse/

[sl1pkn07]

please fix compile with gcc 4.7.0 (now in core in archlinux). or...

Note: I'M NOT PROGRAMMER. i asked a chat friend programmer

avxSynthFrameServer part:

g++ -Wl,-R/usr/lib/avxsynth/plugins -Wl,-R/usr/lib/avxsynth -Wl,-R/usr/lib/ -Wl -L../../../avxcommon -lavxcommon  
-L../frameserverlib -lavxframeserver -lpthread -lm -ldl    ./src/main.o -Wl -L../../../avxcommon -lavxcommon  -L../frameserverlib -lavxframeserver -lpthread -lm -ldl  -o avxSynthFrameServer
g++: error: unrecognized command line option '-Wl'
g++: error: unrecognized command line option '-Wl'
make[2]: *** [avxSynthFrameServer] Error 1

change this:

LIBS = -Wl $(AVXCOMMON_LIB) $(FRAMESERVER_LIB) $(SYSLIBRARIES)

to this:

LIBS = -Wl,$(AVXCOMMON_LIB) -Wl,$(FRAMESERVER_LIB) -Wl,$(SYSLIBRARIES)

i'm not sure if it is the correct, but compile without error


avsynth builtinfuntions part:

src/filters/focus.cpp: In function 'void avxsynth::AFH_YUY2_C(unsigned char*, int, int, int, int)':
src/filters/focus.cpp:522:6: error: redeclaration of 'unsigned char y'
src/filters/focus.cpp:507:11: error: 'int y' previously declared here
make: *** [src/filters/focus.o] Error 1

with this fix the issue?

		uc y_     = ScaledPixelClip(p[x*2+0] * center_weight + (yy + p[x*2+2]) * outer_weight);
		yy       = p[x*2+0];
		p[x*2+0] = y_;

with this compile. but make other warnings:

/common/include/source  -c src/audio/audio.cpp -o src/audio/audio.o
src/audio/audio.cpp: In member function 'virtual void avxsynth::ResampleAudio::GetAudio(void*, avxsynth::__int64, avxsynth::__int64, avxsynth::IScriptEnvironment*)':
src/audio/audio.cpp:1403:37: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
src/audio/audio.cpp:1448:38: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

and http://paste.kde.org/453290


ffms plugin part

http://paste.kde.org/453296

i dont know is related by avaxanne update or gcc 4.7

i test with ffmpeg distro package and libav 0.8.1 (same issue)

what is the diference between LibAV 0.7.4 and libav 0.8.1? (libav 0.7.4 don't compile with gcc 4.7)

greetings

[qyot27]

It seems that a different problem with FFMS2 has crept up. Now it complains about av_pix_fmt_descriptors being undeclared, resulting in a load failure and therefore FFVideoSource once again not being found. FFmpeg-git from early this morning, FFMS2-r670, AvxSynth r124.

Of course, I was also playing with trying to get it to load an FFMS2 that had the FFmpeg libs statically linked into it when this happened, but this doesn't seem like it'd be related to that.