AvxSynth: a Linux port of AviSynth

[videophool]

We are happy to announce AvxSynth, a native port of AviSynth 2.5.8 running on Ubuntu 32/64. Details can be found here: www.avxsynth.org.

[TheFluff]

Interesting. I see you've made a slightly modified FFMS2 source plugin; if you want to have your own branch of FFMS2 on the official repository for that, feel free to contact me. Or is the plan to make the plugin interfaces compatible?

[Guest]

Very nice work, videophool! I have been able to play video via an Avisynth script in a VirtualBox Ubuntu 64. Sweet!

This will make a lot of people very happy.

DG tools for Linux now becomes a real possibility.

[videophool]

Interesting. I see you've made a slightly modified FFMS2 source plugin; if you want to have your own branch of FFMS2 on the official repository for that, feel free to contact me. Or is the plan to make the plugin interfaces compatible?

Definitely interested in a branch on the official FFMS2 repository.

[mastrboy]

now this is interesting, but i'm guessing regular .dll plugins won't work and have to be recompiled to a ELF binary?

[videophool]

now this is interesting, but i'm guessing regular .dll plugins won't work and have to be recompiled to a ELF binary?

You cannot use the Windows dll plugins. However, most of the ones that we have looked at can be ported (at least the C-code implementations).

[LaTo]

Very nice work!!! I will try next week!

[Yellow_]

Will it be possible or is it already possible to patch ffmpeg / libav with .avs file support for Linux like the avisynth support compile option on Windows.

Just thinking about Linux ffmpeg based NLE's like kdenlive and media toolkits like MLT to be able to handle .avs files as if movie, audio or image files.

Although I happily use Avisynth + AVSPmod via wine on Linux this is really excellent news.

[Selur]

Nice!

[ajk]

This is excellent news! Will have to have a look at the code at some point. Is there any intention to support multithreading right from the ground up? Did not see a mention on the site at a glance, but will keep reading.

[SEt]

What I don't understand is why everyone starts with 2.5.8. First x64 port, then this. 2.6 may be called 'alpha' but works actually better than 2.5.8 and still a bit alive.

[videophool]

We started with the stable 2.5.8 branch. Our objective was to get 2.5.8 functionality in Linux quickly and with minimal risk.

[SEt]

As I said, it's only called 'stable'. Development of 2.6 is just stalled in the middle, so it's 'alpha' feature-wise, not stability-wise.

[hajj_3]

very nice indeed, are you guys a company or something as it says you are hiring an avisynth guy, if so did you port this so that your company software can work on linux using avxsynth or something?

great job, i'm sure more video software will become available on linux over the coming months and years as a result of this.

[videophool]

Since our work was a business decision we worked from the stable 2.5.8 branch, the same branch that we use for production encodes. However, we have established a porting model for AviSynth, and it would take a few committed developers about 2 months to port 2.6, if they were so motivated. That is left as an exercise for the reader.

[videophool]

Will it be possible or is it already possible to patch ffmpeg / libav with .avs file support for Linux like the avisynth support compile option on Windows.

Just thinking about Linux ffmpeg based NLE's like kdenlive and media toolkits like MLT to be able to handle .avs files as if movie, audio or image files.

Although I happily use Avisynth + AVSPmod via wine on Linux this is really excellent news.

It would certainly be possible to get avxsynth support into ffmpeg. Something we'd like to see.

[Yellow_]

Cheers, ooooh I'm up and running, the last step 'Build Test' instructions threw me a bit not knowing KDev but by that time the executables we're built in the folder anyway. Going to play. :-) Thanks again.

**EDIT**

Ok, error trying to replicate your Youtube Demo but FFVideoSource not found, looking in my /home/.AVXSynth/plugins folder all plugins except ffms2avs are there, going back to the KDev project and trying to build the ffms2avs gives me this error:

compiling avsutils.cpp (g++)
compiling ffswscale.cpp (g++)
compiling avssources.cpp (g++)
compiling ffpp.cpp (g++)
In file included from src/ffpp.cpp:21:0:
src/ffpp.h:33:37: fatal error: libpostproc/postprocess.h: No such file or directory
compilation terminated.
make[1]: *** [src/ffpp.o] Error 1

So I assume libpostproc in libav doesn't build by default, so added it to the ./configure line for libav, --enable-postproc, rebuilt libav, back into KDev project and built the ffms2avs plugin and we're away, WOOT! :-)

**EDIT**EDIT**

Ok first test something simple opened a flagged full range luma, h264AVC MOV off a DSLR, using FFVideoSource and histogram=classic, output is scaling luma 16 - 235 in the waveform, played back in MPlayer.

If this is ffms2 v2.16 rather than 2.15 or 2.17 then that'll be the reason, known to be buggy and fixed in later revisions.

I did download 2.17-src and it made a 2.16-1_amd64 deb package?

Apart from that the script works, plays the file and segfaults at the end of playback. :-(

ALERT : Module=appInterface,Address=src/avxSynthAppInterface.cpp:453,Type=Alert,Message=Reached end of stream at frame #475
Segmentation fault

I'm aware this is WIP and extremely impressed non the less. Netflix eh?

[tin3tin]

Wow, this is just the best Avisynth news in a long time. Just one question - why do you create your own IDE(AvxEdit), can't the wxPython (http://www.wxpython.org/download.php) of AvsP(mod) used in Linux?

[videophool]

Just one question - why do you create your own IDE(AvxEdit), can't the wxPython (http://www.wxpython.org/download.php) of AvsP(mod) used in Linux?

We needed a tool to help demo our work. Did not spend a lot of time working on AvxEdit, and prefer a more full-featured tool. Hope that someone will take on this project, as we are focused on stability, and completing the migration of our processes to Linux.

[videophool]

If this is ffms2 v2.16 rather than 2.15 or 2.17 then that'll be the reason, known to be buggy and fixed in later revisions.

...

Apart from that the script works, plays the file and segfaults at the end of playback. :-(

ALERT : Module=appInterface,Address=src/avxSynthAppInterface.cpp:453,Type=Alert,Message=Reached end of stream at frame #475
Segmentation fault



There was a typo in the setup instructions. It referred to 2.17, but the install instruction had pkgversion="2.16".

I am not seeing the segfault. can you give some repro steps?

[Guest]

I see a hang at the end of stream, not a segfault. Let a stream play to the end. Then the Mplayer window cannot be closed with its X button. But it can if the video is still playing.

[Yellow_]

It segfaults for me with DV, HDV & h264 AVC, with a simple one line script just using FFVideoSource("path to file") played to the end as here, a 475 frame stream, preparing to fetch frame 475, Reached end of stream at frame #475.

INFO : Module=appInterface,Address=src/avxSynthAppInterface.cpp:444,Type=Info,Message=Preparing to fetch frame #475 (475 frame of the stream)
INFO : Module=core::main,Address=src/core/main.cpp:921,Type=Info,Message=0x2ba6c70->CAVIStreamSynth::Read(1 samples at 475)
INFO : Module=core::main,Address=src/core/main.cpp:922,Type=Info,Message= buffer: 3551232 bytes at 0x7f52b20cf010
ALERT : Module=appInterface,Address=src/avxSynthAppInterface.cpp:453,Type=Alert,Message=Reached end of stream at frame #475
Segmentation fault


Other info from the console:

INFO : Module=avssources,Address=src/avssources.cpp:39,Type=Info,Message=Creating AvisynthVideoSource

INFO : Module=avssources,Address=src/avssources.cpp:186,Type=Info,Message=AvisynthVideoSource creation successful

INFO : Module=core::expression,Address=src/core/parser/expression.cpp:551,Type=Info,Message=Call: histogram
INFO : Module=core::cache,Address=src/core/cache.cpp:717,Type=Info,Message=Cache:19fde80: Setting cache hints (hints:2, range:999 )
INFO : Module=core::main,Address=src/core/main.cpp:634,Type=Info,Message=0x1c12ba0->CAVIStreamSynth(video)
INFO : Module=core::main,Address=src/core/main.cpp:1037,Type=Info,Message=0x1c12ba0->CAVIStreamSynth::ReadFormat() (video)
INFO : Module=core::main,Address=src/core/main.cpp:1037,Type=Info,Message=0x1c12ba0->CAVIStreamSynth::ReadFormat() (video)
INFO : Module=appInterface,Address=src/avxSynthAppInterface.cpp:92,Type=Info,Message=Retrieved video info
INFO : Module=appInterface,Address=src/avxSynthAppInterface.cpp:93,Type=Info,Message========================
INFO : Module=appInterface,Address=src/avxSynthAppInterface.cpp:94,Type=Info,Message=Video width = 2176
INFO : Module=appInterface,Address=src/avxSynthAppInterface.cpp:95,Type=Info,Message=Video height = 1088
INFO : Module=appInterface,Address=src/avxSynthAppInterface.cpp:119,Type=Info,Message=Color format = YV12
INFO : Module=appInterface,Address=src/avxSynthAppInterface.cpp:122,Type=Info,Message=Bits per pixel = 12
INFO : Module=appInterface,Address=src/avxSynthAppInterface.cpp:123,Type=Info,Message=Image bytes = 3551232
INFO : Module=appInterface,Address=src/avxSynthAppInterface.cpp:444,Type=Info,Message=Preparing to fetch frame #0 (0 frame of the stream)
INFO : Module=core::main,Address=src/core/main.cpp:921,Type=Info,Message=0x1c12ba0->CAVIStreamSynth::Read(1 samples at 0)
INFO : Module=core::main,Address=src/core/main.cpp:922,Type=Info,Message= buffer: 3551232 bytes at 0x7f9e64c17010
INFO : Module=core::cache,Address=src/core/cache.cpp:411,Type=Info,Message=Cache:19fde80: generating frame 0, cache from 475 to -1
INFO : Module=core::avxsynth,Address=src/core/avxsynth.cpp:1838,Type=Info,Message=Frame buffer memory used: 3551296
INFO : Module=core::cache,Address=src/core/cache.cpp:411,Type=Info,Message=Cache:1c138a0: generating frame 0, cache from 475 to -1
INFO : Module=core::avxsynth,Address=src/core/avxsynth.cpp:1838,Type=Info,Message=Frame buffer memory used: 6684800
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.


And Mplayer version is 'MPlayer SVN-r34338-4.5.2 (C) 2000-2011 MPlayer Team'

Playing any of the test videos above via a CLI Mplayer ends cleanly with Exiting... (End of file) and back to command prompt, no segfault so don't think MPlayer is the problem. But also assume this is using my system ffmpeg install not libav built for AVXSynth.

Mplayer console output:

==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 48000 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0->192000)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
Unsupported PixelFormat 61
Unsupported PixelFormat 53
Movie-Aspect is undefined - no prescaling applied.
VO: [xv] 1920x1088 => 1920x1088 Planar YV12
A: 3.3 V: 2.3 A-V: 0.998 ct: 0.030 0/ 0 119% 19% 1.6% 50 0



There was a typo in the setup instructions. It referred to 2.17, but the install instruction had pkgversion="2.16".

Ok, so what to do here? Luma is scaling. :-(

[pbristow]

Excellent timing, guys! The more I read about Windows 8, the more I think "Well, that's the end of serious computing on the Windows platform..." =:o\ Now I know that at least AVIsynth still has a future. (Phew!)

[mandarinka]

Well... it also relies on the treasure of plugins, and thus you could say that its future is its past - and until you are able to load (or perhaps port) dll plugins and use masktools/mvtools (I guess that qtgmc will be the ultimate test, heh), that means our dear Windows (8 is not going to be that bad).

[videophool]

It segfaults for me with DV, HDV & h264 AVC, with a simple one line script just using FFVideoSource("path to file") played to the end as here, a 475 frame stream, preparing to fetch frame 475, Reached end of stream at frame #475.


We believe that the segfault is resolved. We will update the source shortly.

http://code.google.com/p/avxsynth/issues/detail?id=1&thanks=1&ts=1331575727

[videophool]

I see a hang at the end of stream, not a segfault. Let a stream play to the end. Then the Mplayer window cannot be closed with its X button. But it can if the video is still playing.

AvxEdit does not hang but there is no way to close the MPlayer window. It is annoying. http://code.google.com/p/avxsynth/issues/detail?id=2&thanks=2&ts=1331576013

[Wilbert]

@videophool,

Great stuff!!! Guess i will need to install Ubuntu again. This link (http://avisynth.org/mediawiki/Known_Issues) contains a list of bugs in v2.58 (most of them are fixed in v2.60/CVS), perhaps you can backport these fixes into your builds.
Also which filters don't have a C++ version?

[videophool]

@videophool,
Great stuff!!! Guess i will need to install Ubuntu again. This link (http://avisynth.org/mediawiki/Known_Issues) contains a list of bugs in v2.58 (most of them are fixed in v2.60/CVS), perhaps you can backport these fixes into your builds.

We will check the bug list, and start working on the critical issues. Hoping that the AviSynth community will join in the effort to move this project forward, as we are a small team, and will be focused mostly on issues that block our deployment.


Also which filters don't have a C++ version?
You can check the wiki for the list of ported built-in functions (many are untested). Third-party will need to be ported. We looked at a few, and most were developed with inline assembly, and thus porting was not trivial. We are hoping that the authors of many of the third-party plugins will be motivated to port their work. http://code.google.com/p/avxsynth/wiki/BuiltinFunctions

[videophool]

did you port this so that your company software can work on linux using avxsynth or something?


As mentioned on the site, our motivation is getting our video encoding process off of Windows systems, primarily as a cost-savings, but also for efficiency and ease-of-use (most of our cloud systems are running Linux, and it is preferred to have a single OS).

it says you are hiring an avisynth guy,

We are looking for help with QA.

[videophool]

We have checked in fix for the segfault.

[videophool]

AvxSynth adds a new error handling model designed specifically for automated encoding processes. Rather than generating error video frames, the error is logged, and an exception is thrown to the application. This model is discussed here (http://code.google.com/p/avxsynth/wiki/ErrorHandling)

[videophool]

I see a hang at the end of stream, not a segfault. Let a stream play to the end. Then the Mplayer window cannot be closed with its X button. But it can if the video is still playing.

The fix for this issue was checked in today.

[Guest]

Oh cool, thanks for that.

I'm playing with porting fiters. The VC++ GUI has it all over Kdev, but that's just an annoyance.

Have you looked at performance yet? I imagine you miss some important ASM code. The decode rate seems to be less than under Windows.

[videophool]

Oh cool, thanks for that.
Have you looked at performance yet? I imagine you miss some important ASM code. The decode rate seems to be less than under Windows.

Since we are using ffmpeg for decoding and scaling I expect that these have similar performance as in Windows. The other functions such as color format conversion, text overlay, etc., are not as efficient, because these are all in C code. The ASM is commented out. We are hoping that other contributors will join the project, and help us to get this ported.

[kypec]

I can imagine that Linux needs some other arrangement of input/output data passed through the stack/pointers than Windows does but the body of native ASM functions could stay the same for any OS running on identical CPU architecture, or not?

[videophool]

I can imagine that Linux needs some other arrangement of input/output data passed through the stack/pointers than Windows does but the body of native ASM functions could stay the same for any OS running on identical CPU architecture, or not?

The problem is that most of the asm code in AviSynth and the plugins that we looked at has been written as inline assembly, which is not usable with Win64 (not sure about gcc 64). We are definitely interested in help porting this code.

[videophool]

Included in the AvxSynth toolkit is a frame server application that delivers the decoded frames to stdout. The output from the frame server can be piped to X264. See the Wiki here (http://code.google.com/p/avxsynth/wiki/AvxSynthFrameServer) for instructions on using AvxSynth with x264.

[Wilbert]

The ASM is commented out. We are hoping that other contributors will join the project, and help us to get this ported.
videophool is offline Report Post IP
SEt converted all the .asm stuff to yasm a while ago: http://forum.doom9.org/showthread.php?p=1312666#post1312666 (see one of the older versions). I guess you can use that (although it's based on v2.60)???

[smok3]

So there is a possibility to have this ported to ffmpeg with the use of all the cool external filters? and a nice mplayerish preview window as well? And it will run on OSX? :)

:thanks:

[videophool]

So there is a possibility to have this ported to ffmpeg with the use of all the cool external filters? and a nice mplayerish preview window as well? And it will run on OSX? :)

:thanks:

Anything is possible, limited only by the interest and enthusiasm of the larger Linux community.

[videophool]

We have a new help-wanted wiki for interested developers here. (http://code.google.com/p/avxsynth/wiki/HelpWanted?ts=1331771465&updated=HelpWanted) Specifically:


Developers to port the optimized assembly for the various video and audio functions (all porting must be Win32/64 and Linux32/64 compatible). In particular, we would like to port key functions such as color space conversion.

Developer(s) to write a more full-featured AVXEdit application with syntax highlighting, and parameter help (like AvsEdit?).

Testers skilled in AviSynth?, Windows, and Linux, to help complete the test matrix for the set of ported functions.

Autoconf and cmake expert to build Linux installable package.

[Guest]

I hope we can discuss here the requirements for your item 2. For example, AVXEdit needs a numbered timeline with arbitrary navigation, like VirtualDub.

[Yellow_]

With regard to item2, Its probably expanding the brief too far but if a tool like Virtualdub was to be discussed then what about considering extending an actively developed and mature Linux based media toolkit called MLT. It uses ffmpeg, Frei0r etc and is also a playout server for broadcast.

http://www.mltframework.org/twiki/bin/view/MLT/

MLT is xml based and forms the base of a number of Linux NLEs including Kdenlive which is without doubt the most usable NLE on Linux at the current time.

www.kdenlive.org

Any extension of MLT can then be made accessible in kdenlive seperately by kdenlives active devs if need be.

Or would a nodal based approach rather than Non Linear be more suitable.

[IanB]

Interesting development. Pity you chose 2.58 as a base instead of 2.6 ....... sigh

For exception handling there is already a catchable implementation through the IAvisynthClipInfo class, see Virtualdubs source for how to uses it. The painting of the error text is only a fallback in the VFW export stub (which almost everything else currently uses). Any app that uses the C or C++ API has to explicitly handle script and runtime errors, there is no text painting there.

For ASM support the chosen solution is to use the Avisynth modified Softwire by Sh0dan. The Softwire in 2.6 has been adapted for 64bit, but it hasn't had much (any?) of a workout. It is hoped all future core development will use this instead if inline MSVC Asm. A thought to aid 64bit porting was to declare inbuilt register aliases like PAX, PBX, ... which would be EAX, EBX, ... in 32 bit and RAX, RBX, ... in 64 bit, this was envisioned to be a bit like the INTPTR type in C/C++ and would allow memory pointer arithmetic parts of the code to be 32/64 bit agnostic. The assumption being the 1st 64 bit cut would just be the 32 bit algorithm recut as 64bit. Enhanced versions in the future could take advantage of the extra registers and instructions to have faster versions, much like we have C++, MMX, iSSE and SSE2 versions of code now.

Also on the 64 bit vapourware list is to have the Script AVSValue int and float types to be 64bit integers and doubles, as the 2 pointer types, clip and string, have to become 64 bit anyway.

There was also some vague idea about borrowing some code from Wine to load windows .dll plugins in a Linux version. 90% of Avisynth plugins are pure algorithm code with no system calls, these would be a doddle to host in a Linux address space.

[videophool]

Interesting development. Pity you chose 2.58 as a base instead of 2.6 ....... sigh

We are very committed to this project so we will look at 2.6 features and bug fixes that should be merged to avxsynth. Also we invite 2.6 contributors to join the AvxSynth project, and help us with this effort.


For ASM support the chosen solution is to use the Avisynth modified Softwire by Sh0dan. The Softwire in 2.6 has been adapted for 64bit, but it hasn't had much (any?) of a workout. It is hoped all future core development will use this instead if inline MSVC Asm.
A version of Softwire that is win/GCC 32/64 compatible would be very cool, and a good way to optimize the filters.


//A thought to aid 64bit porting was to declare inbuilt register aliases like PAX, PBX, ... which would be EAX, EBX, ... in 32 bit and RAX, RBX, ... in 64 bit, this was envisioned to be a bit like the INTPTR type in C/C++ and would allow memory pointer arithmetic parts of the code to be 32/64 bit agnostic. The assumption being the 1st 64 bit cut would just be the 32 bit algorithm recut as 64bit. Enhanced versions in the future could take advantage of the extra registers and instructions to have faster versions, much like we have C++, MMX, iSSE and SSE2 versions of code now.


Is anybody working on this effort?


There was also some vague idea about borrowing some code from Wine to load windows .dll plugins in a Linux version. 90% of Avisynth plugins are pure algorithm code with no system calls, these would be a doddle to host in a Linux address space.

A Win32 to Linux64 thunking layer? How cool would that be!

[Robert Martens]

This is wonderful news, great work on the port! I'm not much when it comes to Linux, but after installing a pair of Ubuntu VMs (32/64 bit) and banging my head against KDev and CMake for a couple of days, I've gotten one of my plugins to compile and run, all with much less effort than I'd expected. I'm sure to have loads of capital-f Fun setting up a new build process that can properly handle both versions, but for the time being I have a few questions:

First, am I the only one having trouble when linking against ffms2 2.17? I downloaded the source from the googlecode project, and configured/built/installed it successfully, but when running AVXEdit and attempting to load a clip with FFVideoSource (or even just using ColorBars().KillAudio().PointResize(320,240)) I get an undefined symbol error with regard to GetSwsContext. Uninstalling 2.17 with Synaptic and replacing it with 2.16 (as delivered in the AvxSynth checkout), everything works as expected. This is hardly a proper bug report, but I don't want to be any more obnoxious than necessary, so I'm leaving out the details in case this is a known issue. Or if I've just missed something obvious. Which would be shocking.

Next up is what I suppose is more a general freshman developer question than anything. I'd like to keep one set of source files for both versions of a plugin if possible; would it be incredibly stupid to #ifdef a "using namespace avxsynth" directive, or at least a set of "using avxsynth::SuchAndSuch" declarations in my source files? I understand those are dangerously poor form if they can be avoided, but they seem to be the cleanest way to handle cross platform concerns in this case. Is there a more intelligent way to handle the avxsynth namespace that I simply haven't learned of yet?

My final concern is about source distribution. On Windows we all redistribute the copy of avisynth.h that we used to build our library; do we distribute avxplugin.h (and everything else in the avx_root/include/ directory) for Linux, or is it assumed everyone using the software has the source code installed? I know the Linux community is much more comfortable with downloading and building from source than most in the Windows world, but if I'm not mistaken it's possible and increasingly common to have binary releases even there. Am I correct in thinking that the avx_root/include/ directory (minus the .svn repository) is all I need to package along with my source?

That's an annoying number of question marks for one post, and I know I'm revealing an embarrassing lack of experience in the *nix world here, but I'm supremely excited at the prospect of making my trivial toy plugins available to an even larger group of people who couldn't care less, so I'd like to clear up as many details as I can.

[videophool]

banging my head against KDev and CMake for a couple of days, I've gotten one of my plugins to compile and run, all with much less effort than I'd expected.


Yes, KDev can be frustrating. So much in VC that we all take for granted.


would it be incredibly stupid to #ifdef a "using namespace avxsynth" directive


We chose to namespace avxsynth due to ffmpeg collisions, and our desire to see avxsynth well supported in ffmpeg. the #ifdef using namespace solution seems to be reasonable.


My final concern is about source distribution ...


We would like to have a real install package so that you do not have to walk through these manual steps. Any volunteers out there?

[Wilbert]

A version of Softwire that is win/GCC 32/64 compatible would be very cool, and a good way to optimize the filters.
As I understand it, it is GCC 32/64 compatible. From the readme: "Jude Venn: helped porting SoftWire to UNIX/Linux by providing alternative functions for the Microsoft specific code (File.hpp, String.hpp, CharType.hpp). He also wrote Makefile.gcc to easily compile SoftWire with GCC.". Or isn't the porting finished?

[videophool]

As I understand it, it is GCC 32/64 compatible. From the readme: "Jude Venn: helped porting SoftWire to UNIX/Linux by providing alternative functions for the Microsoft specific code (File.hpp, String.hpp, CharType.hpp). He also wrote Makefile.gcc to easily compile SoftWire with GCC.". Or isn't the porting finished?

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.

[active1]

hi
im having a problem when i try to play the script
when i open AVXEdit and write a simple script, like this:

ffvideosource("/path/to/my/file.mkv")

then, AVXEdit disapear and don't open mplayer like when i type version()

:thanks: