avisynth for Linux

[jonas]

Hi,

This thread is ment to gather information about how to port avisynth to Linux.
Since I'm mostly using WinXP and not Linux this isn't so important now for me, but I believe this to be one goal avithynth should try to achieve in a long term perspective.

With my limited knowledge I can only see to basic problems:

Video Input
Video Output

since these are based on videos video handling (as far as I see).

Of course there would always have to be a not optimised version of each function to support Unix on machines other than i386.

I have no clue on how video In- and Output is done in Linux, so I can't tell what has to be done.

Any comments and ideas are welcome. It would be nice if a avisynth developer had a comment or two as well.

ok, that’s all for now ;)
jonas

[Suzahara]

Well, a lot of code would obviously need to be rewritten as avisynth uses Windows registry entries, and this would need to be changed to the way Linux handles this sort of stuff. And I'm not sure how it would compile right now as it is. But it would definitely need a lot of reworking. And I'm not sure, but if it were ported over, it would probably need to be bundled as a part of transcode or something as I don't know how it would be used to "decode" the avs to the encoder, so it might have to be a part of the encoder. Although I suppose it could have a binary file of some type that could pipe out stuff to the encoder in some manner.

[omol]

Umm..... something like this?

#!/usr/bin/avisynth

# begin of dvdrip.avs

LoadPlugin("/usr/lib/avisynth/mpeg2dec3.so")
MPEG2Source("/tmp/video/vts_01.vob",cpu=4,idct=5)

(Some fancy plugin function, Blah blah blah....)

# EOF

And of course, the output should be raw video stream. Then you could pipe the output to a video encoder, something like mencoder. E.g.

omol@k5:~$ ./dvdrip.avs | mencoder - -o vts_01.avi

Feasible? Just a thought.

regards,
omol

[Suzahara]

I don't know that it would work exactly like that since an avs is not a binary file. That would just pipe out the text in it wouldn't it :confused: Or likely get an error saying that it's not a binary file.

[gabest]

Originally posted by jonas
I have no clue on how video In- and Output is done in Linux, so I can't tell what has to be done.Sorry for the OT-like question, but is there any multi-media API for linux yet? Maybe one should try create one or port vfw/dshow first.

[FishB8]

Porting vfw or dshow wouldn't be impossible, :rolleyes: as long as you port the rest of windows with it... It might be something you would look into when ReactOS starts to mature.

Yes, there is a Linux multimedia framework called Gstreamer (http://www.gstreamer.net/) I would suggest looking into it if you want to develope a Linux media application.

[ChristianHJW]

Originally posted by gabest Sorry for the OT-like question, but is there any multi-media API for linux yet? Maybe one should try create one or port vfw/dshow first.

Dshow for Linux : Gstreamer

VfW codec API for Linux : UCI ( Http://uci.sf.net )

VfW/AVI container replacement for Linux : make a guess :D

[gabest]

Just peeked gstreamer's docu, it is all in pure c... I know linux guys tend to code in that, but personally I wouldn't start anything without c++ and COM :P

[FishB8]

Gstreamer itself may be written in C (actually I'm not sure, I'm taking your word for it) but you don't have to mess with gstreamers source code unless you plan to contribute.

If you're developing a media application you CAN us C++. It doesn't matter what language Gstreamer is written in, what matters is what bindings it has built into it. Besides C, you can write programs that use Gstreamer in C++, C#, Java and Python (http://www.gstreamer.net/bindings/). (maybe someday they'll add perl too)

[Belgabor]

Originally posted by Suzahara
I don't know that it would work exactly like that since an avs is not a binary file. That would just pipe out the text in it wouldn't it :confused: Or likely get an error saying that it's not a binary file.


#!/usr/bin/avisynth


Would make it work like a shell script ;)
Clever approach, though I dunno enough about linux programming to tell if its feasible, certainly would be cool though :D

[ChristianHJW]

I will try to point Thomas van der Stichelen or Ronald Bultje to here, maybe they want to comment ( after having waited the 5 days reg period of course :D ). They dont like webboards too much AFAIK, so i cant promise anything ;) ... but if we will ever see AVISynth for Linux, then i guess Gstreamer would be the only sensible way ...

[Beelzebubu]

Hey Jonas,

as said before, GStreamer is probably the DirectShow replacement you're looking for. There's some others (xine, mplayer) but they're mostly player-oriented. Xine is pretty good at that, actually (have a look at their API refenerences if you want to know more - http://xine.sf.net/), but you probably want more than just 'player'-like capabilities. Complex pipeline building is definately something only GStreamer can do, currently. mplayer is mostly a piece of crap that has to be mentioned because it exists, but besides that, there's no point in looking at it.

A few features of GStreamer:
* it wraps most currently known codecs inside a common API (like dshow)
* because of this, it has support for virtually any format you could think of (codecs (divx, mjpeg, etc.), file formats (avi, asf, etc.), stream type (http, udp/network, local file, etc.), system in-/outputs (xvideo/overlay, SDL, framebuffer, libaa/text, OSS, ALSA, esd, mas, arts, etc.), anything)
* it's fairly extended in how it can be used

The obvious downside is that you'll need to learn to 'work with GStreamer', it's likely to be completely different from DShow (though I guess you already expected this ;) ).

If you need things like a GUI, registry, you shouldn't look at GStreamer, we're only a multimedia framework. Some good GUIs are Qt/KDE or Gtk+/Gnome. There's some apps for each of these that use GStreamer. If you use Qt/KDE, you'll want to use the Qt/C++ wrappers for GStreamer. For Gtk+/Gnome, you might want to either use Gtk-- (C++ wrapper for Gtk+) or use C instead of C++. Both KDE and Gnome have their own registry. For Gnome, this is called GConf, for KDE, I don't know the name (I do Gnome ;) ). Documentation for their APIs is available anywhere on the web. Main site for Gnome is http://developer.gnome.org/.

If you have any questions about GStreamer, just get on IRC (irc.freenode.net #gstreamer) to meet the developers. API references are also available online (http:/www.gstreamer.net/ -> Documentation). Hope this helps!

(thanks for the admins for getting rid of the 5-day delay :) )

[omol]

Originally posted by Suzahara
I don't know that it would work exactly like that since an avs is not a binary file. That would just pipe out the text in it wouldn't it :confused: Or likely get an error saying that it's not a binary file.

AVS is of course script. In *nix, scripts not necessarily output text. For example:-

#!/bin/sh

cat /bin/sh

# EOF

Run it and I would be surprised if it doesn't garble your terminal. Another example is shar. But of course to *nix purists, everything is text stream....;)

regards,
omol

[spyder]

Hmmm, this shell script type idea isn't bad....

It would be very nice. Especially if you could add in an encoder function and have the whole job run like this.

[Suzahara]

True. Shell scripts do not output text, however, is it possible for avisynth to do the same? And would it possibly work with video encoders?

[spyder]

Ok, I know this script idea can work. What do you place at the top of a Perl file? The same #!.... except you specify the Perl interpreter. So it must be possible to make a new scripting language with similar syntax. Since # is also the comment character in AVISynth, it could use the same syntax. All you need is a new interpreter. The only thing then is, you need to either have an app take the data from stdin and pipe it from the script, or add encoder functions to the language. This would make the encoding/editing process less interactive. Just an idea. I wish i could code more in C. Then I would just code this. :)

[omol]

Originally posted by spyder
I wish i could code more in C. Then I would just code this. :)

Unfortunately, AVISynth win32 code is in C++, and don't forget the GNU folks tend to break C++'s ABI compatibility in every major rev of GCC.... Let hopes this pain won't carry on to 3.2 -> 3.3.

regards,
omol

[spyder]

I was talking with a gstreamer developer earlier and he thinks this can be done as a simple interpreter for building a gstreamer pipeline based on the script. Someone with more time should look into it.

[cweb]

Has anyone attempted to use Winelib for this?

That might make the job easier...
Of course I read and tried AVS2AVI which might be the way to go actually..

[Xesdeeni]

I shouldn't be posting this, since I don't actually know what I'm talking about...but....

I thought one of the nice things about Linux was that applications could make use of shared libraries, which are also open source.

If a video application uses a library to read and write media files, can't the library itself just be replaced with one that recognizes .avs (or whatever) files, parses the script, and returns the processed data as if it came from a media file? It wouldn't work for apps that do their own parsing and decoding, but then AVISynth has the same problem under Windoze.

Is this too naive?

Xesdeeni

[mean]

Nope, you are right.
That's what "avisynth for linux" should be

my 0.02 Euros

[Belgabor]

Well, shared libs are nice, but the app has to be build to use them. You can to a command pipe without the final app needing to know what comes before. The other alternative would be making it a gstreamer component.

[c0p0n]

Originally posted by Beelzebubu
Hey Jonas,

There's some others (xine, mplayer) but they're mostly player-oriented. Xine is pretty good at that, actually (have a look at their API refenerences if you want to know more - http://xine.sf.net/), but you probably want more than just 'player'-like capabilities. [...]. mplayer is mostly a piece of crap that has to be mentioned because it exists, but besides that, there's no point in looking at it.

well, I suppose that you could make a better program than Mplayer... even while it, against Xine:
-Uses less CPU cicles to show the same
-has more features
-is much more stable
-has a better GUI handling
-has a not-confusing file open system
-has a huge codec DB

ps: I am not discussing about GStreamer or Xine, which are pretty good software. but when talking about other's work, you should be a bit more respectful. "I don't like that" should be fine, instead of "... a piece of crap".

[Blankman]

How about using Windows as a console, performing all the ripping and encoding on Linux/390, and sharing storage between the two with a SAN?

The back-end (Linux/390) could be a daemon, and the front-end (Windows) could be stateless.

[bilu]

Has anyone here heard of http://film.gimp.org ?

This is already used in movies and has a lot of scripting capabilities.

I think it can also be a candidate to an Avisynth port for Linux, what do you think?


Best regards,

Bilu