Intent to get Avisynth working under Linux.

[kevina]

Hi,

In the coming months I plan to get Avisynth working under Linux with the help of Wine/Winelib (A Windows Emulator for Linux). I have started a sourceforge project, Avisynth-Linux (http://sourceforge.net/projects/avisynth-linux/), to this effect. I also wrote a C API for Avisynth so that Gcc compiled programs can use
Avisynth.

Based on what the Wine people are telling the easiest way to use Avisynth under Linux is to run Avisynth in a separate process and use some sort if IPC to communicate with it. This is what I plan on doing to start with. I particular I plan on using (possibly named) pipes to communicate with the process. This is not very efficient but it is the simplest. In fact I have written a small windows application to that effect. It will run an avs script and save the raw data as a yuv4mpeg file (think raw yv12 with a header). If this is run with Wine the outfile can be a FIFO (named pipe). Of course this is just a start.

Once my application is compiled with Winelib is no longer limited to windows API calls. In can also use Linux ones. This means I can more easily communicate with native Linux applications. This means for one thing, that I can avoid having to copy frame data around. But in order to do this I need to 1) Set up a shared memory region and 2) Get Avisynth to allocate its frame data from that region. Thus I would like to know how difficult it would be to get Avisynth to alloc memory for frame data from a specific region of memory.

My ultimate goal is to be able to use Avisynth as a shared library in Linux. This is far more difficult but possible. Some clever hackers (in the good sense) managed to figure out how to use windows (and eventually quicktime, and real) codecs under Linux without the need of wine. I release that Avisynth people wouldn't know much about how how they did it, but I was wondering if you could give me some insight on how difficult doing so with Avisynth might be? Ie, how much of the
Windows API does wine use compared to a windows codec?

Thanks in advance.

[sh0dan]

It doesn't sound that difficult.

If you look at how frames are passed to VFW, you'll notice that AviSynth already places the final frames in a memory region given by VFW. This should go into shared memory instead. See STDMETHODIMP CAVIStreamSynth::Read() / ReadHelper() in main.cpp

So I think it should be quite possible to replace the current VFW code with something that talks though the wine API. I don't see any reason for all frames to be placed in shared memory.

[kevina]

Thanks for the info. Is it possible to control the pitch of the final frame? So for example if an application wants the frame data to be in a solid block of memory ie pitch=width, can AVISynth honor the request?

[sh0dan]

Yes - this is actually what ReadHelper is doing (in the "ugly" code).

There is no pitch in VFW, but all lines are assumed to be 4-byte aligned. Instead change the bitblit to:

BitBlt((BYTE*)lpBuffer, row_size, frame->GetReadPtr(), pitch, row_size, frame->GetHeight());

BitBlt((BYTE*)lpBuffer+(row_size*frame->GetHeight()), row_size/2, frame->GetReadPtr(PLANAR_V), frame->GetPitch(PLANAR_V), frame->GetRowSize(PLANAR_V), frame->GetHeight(PLANAR_V));

BitBlt((BYTE*)lpBuffer+(row_size*frame->GetHeight()+frame->GetHeight(PLANAR_U)*row_size/2), row_size/2, frame->GetReadPtr(PLANAR_U), frame->GetPitch(PLANAR_U), frame->GetRowSize(PLANAR_V), frame->GetHeight(PLANAR_U));


lpBuffer is the output buffer. Performancewise I would recommed you to align pitch to 16 (also for UV).

[Bidoche]

For frames in shared memory, can you afford all frames to be allocated there (we are talking about Mo of shared mem)
If not, how will it decide which should and which should not ?

[kevina]

Originally posted by Bidoche
For frames in shared memory, can you afford all frames to be allocated there
I belive so. I can just set aside a fixed region of virtual memory for shared data. It doesn't necessary have to be allocated.

@sh0dan

Thanks for the info. I will study the Avisynth code some before I get back to you.

[Bidoche]

virtual memory ?
It is where the frames will be processed, it should be fast

[Richard Berg]

If all you need on the shared memory area is frame data, it could be as simple as overloading IClip's operator new.

On a quasi-related note: anyone know if Softwire is cross-platform? Changing the rest of the code to Softwire might be the ticket to crossing the asm/nasm barrier.

edit: I wrote this post last night and didn't submit it until now. Looks like the others have a good handle on it.

[sh0dan]

Softwire is (or should be) crossplatform, but rewrting functions will take time. I still prefer ordinary inline assembler, since it is faster to write, and somewhat easier to debug. I do however use it, if there something to be gained from it (loop unrolling, dynamic insertion of code, etc).

As mentioned above, only the final requested frame needs to be in shared memory. I guess that way the porting issue is rather small, as it isn't an internal videoframe. A special import filter for delivering frames from linux -> AviSynth should also be rather easy (compared to a complete port at least).

[Bidoche]

@Richard Berg

overloading IClip::operator new won't help, the memory allocation is done somewhere in VideoFrameBuffer.

[kevina]

A complete port will also mean that Avisynth plugins will also need to be ported which means that it will not be nearaly as usefull. That is why I want to use it as is.

[geoffwa]

Couldn't all of Avisynth's plugins be ported to the C-plugin format?

[sh0dan]

Realisticly I don't think many of the current plugin writers would care enough to port them themselves, as there is no real gain by using the C-API, expect compiler independence.

Furthermore there is no real point in doing so, except if AviSynth itself is ported for platform independence, which would probably be a lot of work.

For now I think it's a good idea to stick to the current idea, and make the C-API transparent to the end user, and let it be up to plugin writers to choose which API to write for. That way a slow migration is also possible.

[Bidoche]

Would the plugins really need to be ported ?
They only have to deal with the avisynth dll, they don't have to see the OS.
Or I am missing something ?

[MrTibs]

Um...Could I ask a stupid question?

Could Wine DLL's and underlying code be expanded to support all the Windows API calls that Avisynth makes? Wouldn't this go further by (perhaps) expanding support for other complimentary video programs like Vdub and TMPG? This would also allow a single development stream for Avisynth.

I haven't looked into it... just asking.

[cweb]

Has there been any progress on this front...
both with and without wine, etc?

[cweb]

I installed the latest wine source release under linux (2.6 kernel).

I reinstalled the latest 2.5.5 alpha avisynth.

I ran virtualdubmod which couldn't open avs files.

I tried to run MakeAVI from ffvfw which was enlightening...
It complained that mpeg2dec was not a known function.
So I added a LoadPlugin line for it. (The registry should contain the entry for autoloaded plugins but it didn't, a wine problem. I could edit the registry text file of wine directly later).

Well I managed to get makeavi to accept the avs file, but when I tried to get it to create the fake avi, I got an 'error in AVIFileOpen'.

I wonder what would happen if I created a fake avi under Windows and then opened that using Virtualdubmod under wine (in Linux).

[cweb]

I just did that, for fun..
Virtualdubmod under wine says 'couldn't locate decompressor for format AVIS (unknown).(only DIRECT STREAM COPY directshow interface is available, not vfw in other words)

It allowed me to save using direct stream copy into an avi file..
I opened it again using virtualdubmod which said the file has fourcc AVIS, decompressor RGB16.

I tried to view it using mplayer, but the result as expected was:

AVI file format detected.
AVI_NI: No audio stream found -> no sound.
AVI: No audio stream found -> no sound.
VIDEO: [AVIS] 720x480 16bpp 29.970 fps 1.0 kbps ( 0.1 kbyte/s)
Clip info:
Software: VirtualDubMod 1.5.4.1 (build 2066/release)
vo: X11 running at 1280x1024 with depth 24 and 32 bpp (":0.0" => local display)
==========================================================================
Cannot find codec matching selected -vo and video format 0x53495641.
Read DOCS/HTML/en/codecs.html!
==========================================================================

[albertgasset]

For me Avisynth works under Wine 20040505, but it crashes often when opening the scripts, and always if there's an error in the script. I use VirtualDub, VirtualDubMOd crashes at start. Also, Xvid and ffvfw work fine, but no luck with DirectShow codecs nor mp3. Maybe playing with Wine config would help.

Avisynth 3.0 will run on Linux, so we'll be able to enjoy at 100% this great FREE tool in a FRRE operative system ("free" as in speech, of course).

[cweb]

I'll keep trying...
Yes, I am looking forward to avisynth 3 (which will help reduce the need for Windows for me) under linux.

[bill_baroud]

Avisynth 3.0 will run on Linux

where did you read that ? Bidoche is not doing it, and it still will need a major rewrite for linux. but yeah, the avisynth 3 internal's code should not be tied to the win api (iirc).

[Wilbert]

where did you read that ? Bidoche is not doing it, and it still will need a major rewrite for linux. but yeah, the avisynth 3 internal's code should not be tied to the win api (iirc).
People are working on it! I guess Bidoche can tell you more about the progress.

[Kurosu]

People are really working on the linux port. It's yet a bit hard to compile (needs gcc 3.x, stlport, freetype, boost and libavcodec/format), and several key utilities such as video source and text overlay aren't yet usable, as they are totally from scratch. For that reason, they aren't yet in CVS. The core code is however nicely portable. It's almost possible to do a showcase under linux, but no input plugin for gstreamer/mplayer/... has been written yet, so that's just frame/audio dumping.

[Bidoche]

I got two guys working in the linux port.
Unfortunatly they keep complaining to me when about code problems ;)

Actually, 3.0 is now compiling with gcc on linux (provided you exclude vfw and gdi stuff)
It's almost compiling with mingw too, but there is a conflict in VFW headers.

The asm inline code has been converted to nasm (ie the few that 3.0 is using for now)
Some replacement code has been made for some things ( _aligned_malloc, timing code)

The biggest problem now is to replace the gdi stuff used to render text.

caro is investigating freetype for that (3.0 may end up using freetype for windows too)


Anyway, the 3.0 architecture is mostly done, I am now in the process of converting filters to it.
It's a long and boring work who doesn't necessarily request great C++ skill (depends of filters)
So I could help on doing it.


I could use proposals for the promised API too.
I'd rather have the ones who will use it make the proposal (at least for a 1st draft)

They know what they need. I don't.

[jernst]

That's a really good news !

With the ongoing port of gstreamer to windows the directshow stuff could be replaced with gstreamer and we'll have avisynth work the same on both platforms.

thanks to everybody involved into this !

[geoffwa]

How is Avisynth going to serve video frames anywhere sans Video for Windows?

(really curious here)

[bill_baroud]

ok, great news then, i must have missed some update on the linux port :)

How is Avisynth going to serve video frames anywhere sans Video
for Windows?

using another api like directshow or gstreamer, but it will not be "avisynth" anymore, but something like "gsynth" ;)

if i'm not wrong, avisynth 3.0 is now a very portable and modular "core", which allows the (easily) addition of other api to this core.

[shevegen]

Three little symbols

WOW

:)

[ well in fact AviSynth caused me most of the fun when i was using Windows, i mean using it was incredibly cool ( oh and yeah thanks to the other AviSynth gurus who helped me on problems, like wilbert and co ) ]

[Shubin]

Thinking about AVISynth for Linux I came to the following proposal : a fork.

Maybe it would be easier to make a program completely independent from VfW. Operating on files only. Command-line.
This version should work for both Windows and Unix.
Also with command-line options allowing to render only
some range of frames. But keeping script language and plugins.
Of course things like directshowsource will not work.

[Leak]

Maybe it would be easier to make a program completely independent from VfW.
Congratulations, you've just described AviSynth 3.0 (http://avisynth3.unite-video.com/news.html)... :)

[Shubin]

Congratulations, you've just described AviSynth 3.0 (http://avisynth3.unite-video.com/news.html)... :)

What can I say ? It's great ! Two things are missing : documentation and binary packages. Hope they'll be there soon.

I'll try it.

[d'Oursse]

we're also looking for developpers ;)

binary package: i've made some, but as avs3 is not ready yet, i don't think it's usefull
documentation: which one ? installation ? design ? creation of plugin ?