[livid-dev] Re: Linux-video-dev Mailinglist

Hello,

As you all know, there are many separate video-player
projects for Linux currently going on.

And nobody wants to cancel his project, because everyone
thinks, his is the only one that’s worth working on
(me too :wink: Every player so far has its pros and cons.
Mine for example lacks a GUI, others have nice looking
skin capable GUIs but don’t work at all. So working
together could help us a lot.

That’s correct.

I’m asking you, the developers, should we create
something like ‘linux-video-dev-mailinglist’ ?

I’d like to have a forum where the developers could
exchange experience and MMX/SSE optimized code, which
is tedious to write.

I think we can arrange that.

The list could be used to discuss about common API’s and things
that are related to developing video-players and plugins for them for
Linux (and maybe for other Unices as well…).

This list could be too late for decoder development, but
I’m also very interested in encoder development. As there is
not much usable encoder code written, we could perhaps all
come together and congregate our efforts in this piece of
software. Writing good encoders is far more difficult than
writing decoders, as it requires more than doing some DCT
and some searching for motion vectors.

I’ve initiated an MPEG-1/2/4 encoder project on sourceforge
(www.sourceforge.net/projects/mpegvideo) and hope that
the sourceforge team will finally achieve to give me CVS
access. There’s nearly no code written yet, but I’ll put
the old sources of my SAMPEG encoder there, which can then
be plundered.

I just registered a project called “Open Media Interface” to the
sourceforge. Let’s see if they’ll accept it.

That project is dedicated to creating a good api/plugin/codec-system for
Linux (and other unices). Something like we have in windows…

By creating such a system, people could continue developing their
own players (or editors or whatever) and have easy access to all supported
fileformats. Both reading and writing to those formats.

Comments?

  • Pasi K?rkk?inen, @Pasi_KarkkainenOn Tue, 5 Dec 2000, Dirk Farin wrote:

NOTE!

Think twice before doing “reply all” on this,
as I left all the mailing lists in the CC.

Wed, 06 Dec 2000 Pasi K?rkk?inen wrote:

Hello,

As you all know, there are many separate video-player
projects for Linux currently going on.

And nobody wants to cancel his project, because everyone
thinks, his is the only one that’s worth working on
(me too :wink: Every player so far has its pros and cons.
Mine for example lacks a GUI, others have nice looking
skin capable GUIs but don’t work at all. So working
together could help us a lot.

That’s why I’m working on the MAIA plugin and integration API, and the reason
why I’m trying to make it usable for more than high end audio processing.

Short story:

1. I was developing an audio sequencer for Windows. Of course, the
   useless real time performance of Windows forced me to move on to...

2. RTLinux. Incredible RT performance (few ?s worst case scheduling
   latencies), but there were no audio drivers. I started writing
   a kernel API compatible Driver Programming Interface to make porting
   easier.

3. Starting to design my audio engine for RTLinux, I soon realized that
   I'd need a plugin API and lots of plugins. I joined the Linux Audio
   Dev mailing list, and all of a sudden, I found myself in the middle
   of a wild plugin API design discussion.

4. Meanwhile, a viable alternative to RTLinux (for audio applications)
   came along: The Linux/lowlatency patch. This allows SCHED_FIFO
   threads to schedule with worst case latencies low enough to process
   audio with 2.1 ms latency. (Beats BeOS at it's own game, and that's
   without bypassing the standard APIs, or requiring high end hardware.)

5. The plugin API discussion soon resulted in LADSPA. It's a simple,
   VST1.0 style audio plugin API, written mainly by Richard M. Furse.
   It does a great deal of what the audio hackers need, and it's easy
   to use. However, One Size Does Not Fit All, which was clearly
   indicated the other week, when the list was again flooded with
   plugin API related threads.

6. The MAIA project (formerly called MuCoS) was never put on hold, and
   is now close to the alhpa testing stage.

The ongoing discussions and other factors have influenced me during the design
stage, and the result is that MAIA is now designed from the ground up to deal
with everything that LADSPA does, the people have been missing in LADSPA (most
importantly timestamped events), and a few other things, such as allowing
plugins to deal with all kinds of data, rather than just the 32 bit floats
that are hardcoded into LADSPA, VST 1.0, VST 2.0 etc.

As to audio functionality, MAIA aims to provide basically the same
functionality as the VST 2.x plugin API (allows plugins to be loaded as shared
libraries and executed in whatever thread the host decides on; usually a single
dedicated audio thread for all plugins), and the ReWire standard (allows
multiple applications to run their audio processing in the same thread, in
order to achieve sample accurate sync, and the lowest possible system latency).

Both off-line and real time processing will be supported, but the latter is the
main focus, as that’s where you’ll find the most important problems that we need
to address.

[…]

I just registered a project called “Open Media Interface” to the
sourceforge. Let’s see if they’ll accept it.

That project is dedicated to creating a good api/plugin/codec-system for
Linux (and other unices). Something like we have in windows…

By creating such a system, people could continue developing their
own players (or editors or whatever) and have easy access to all supported
fileformats. Both reading and writing to those formats.

That sounds very much like what we’re doing around the audio community. :slight_smile:

(Except that we prefer to view it from the real time streaming perspective,
which sometimes results in a different terminology. For example “files” are
painfully slow and unreliable WRT timing, so we use heavily buffered “disk
butler threads” to deal with them. Normal plugins are never allowed access files
directly. Likewise, multithreading scheduling latency is a serious issue for
real time audio, so we have to run all plugins in the same thread, at least on
current operating systems, for acceptable reliability and audio latency.)

What I want to do is to have the different kinds of media handled in a more
"organized" manner than by using entirely different plugin APIs and protocols.

Basically, we’re all dealing with the same semantics. Only frame rates and data
types differ. If the same low level interface is used for all kinds of plugins,
we get advantages like implicit audio/video sync, engines that can easilly
handle both audio and video plugins, common solutions for network streaming,
harddisk recording, automation and so on.

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’> On Tue, 5 Dec 2000, Dirk Farin wrote:

Ok, I think everyone knows our viewpoints now, so I’ll shut up.
One correction though, xanim has, as of late, been able to dynamically load
the playback modules, so it too, has a plugin architecture of sorts…

My only addition to this whole thing is that the communications point
(whatever reads/writes streams - be they files, RTP connections, …) and
whatever handles compression/decompression shouldn’t require a GUI…
(btw - where IS OMS? I can’t find it. stoopid search engines…)

I actually think it’s quite silly that anything other than the actual
display portion require a GUI of any kind.
(sorry - pet peave with 90% of these operations… SDL’s mpeg player’s
pretty much the only exception that I’ve seen)

If you’re going to make something modular, make it -modular-

hrm also an observation that CODECs for Quicktime and AVI are pretty
similar with different metadata seeds (ie: headers) but same information.
I haven’t yet checked into other CODEC-able media formats…

G’day, eh? :slight_smile:
- Teunis who’s coding not paying lots of attention right now :)On Wed, 6 Dec 2000, Jarrod Benjami Johnson wrote:

Pasi K?rkk?inen [@Pasi_Karkkainen] wrote:

I just registered a project called “Open Media Interface” to the
sourceforge. Let’s see if they’ll accept it.

That project is dedicated to creating a good api/plugin/codec-system for
Linux (and other unices). Something like we have in windows…

By creating such a system, people could continue developing their
own players (or editors or whatever) and have easy access to all supported
fileformats. Both reading and writing to those formats.

Comments?

Scouring through the pile of “dead” projects on sourceforge, there is
also “openstream” (http://openstream.sourceforge.net) which seems to
have the same goal. (for other similar dead projects, see also on
sourceforge: retina, libmedia, linvsii) OpenStream appears to have the
backing of Indrema and Precision Insight. It also appears to be dead.
Does anyone know what happened to this project? If it still exists, we
should consider pooling resources.

Openstream and libmedia seem to be close to what I was thinking about.
Both projects also seem not to be going on.

I mailed to the openstream-people and asked what’s going on. We’ll see…

After wrestling with the 30+ pieces of software claiming to do something
with video on linux, and having 29+ of them fail in one way or another,
I really want to see this happen. Cancelling dead projects and
pooling developer resources on one library/api/plugin system would be in
all our best interests.

Absolutely.

  • Pasi K?rkk?inen, @Pasi_KarkkainenOn Wed, 6 Dec 2000, Bob McElrath wrote:

Bob McElrath wrote:

Scouring through the pile of “dead” projects on sourceforge, there is
also “openstream” (http://openstream.sourceforge.net) which seems to
have the same goal. (for other similar dead projects, see also on
sourceforge: retina, libmedia, linvsii) OpenStream appears to have the
backing of Indrema and Precision Insight. It also appears to be dead.
Does anyone know what happened to this project? If it still exists, we
should consider pooling resources.

After wrestling with the 30+ pieces of software claiming to do something
with video on linux, and having 29+ of them fail in one way or another,
I really want to see this happen. Cancelling dead projects and
pooling developer resources on one library/api/plugin system would be in
all our best interests.

Just to contribute a little to this discussion: IMHO Any "standard"
video playback system should be 1. Not linux- or x86-specific, 2.
Network-transparent, and 3. Licensed so that non-open-source codecs may
be supported. I don’t know how well oms fits in with any of these.

Yep, that’s exactly what I was thinking about.

By the way, AFAIK, OpenStream is not dead, and is still being backed and
developed by Indrema.

I contacted the authors, we’ll see. If they don’t have plans for active
development of openstream maybe we should try something different…

  • Pasi K?rkk?inen, @Pasi_KarkkainenOn Wed, 6 Dec 2000, Ryan Drake wrote:

Ok, I think everyone knows our viewpoints now, so I’ll shut up.
One correction though, xanim has, as of late, been able to dynamically load
the playback modules, so it too, has a plugin architecture of sorts…

My only addition to this whole thing is that the communications point
(whatever reads/writes streams - be they files, RTP connections, …) and
whatever handles compression/decompression shouldn’t require a GUI…
(btw - where IS OMS? I can’t find it. stoopid search engines…)

OMS: www.linuxvideo.org

I agree with you. “standard” fileformat access-library should NOT require
a GUI of any kind. It also should not be platform dependant. And it should
provide common API for all fileformats (if possible).

There is a lot of code that could be ported to this kind of
fileformat-acccess library, libavi, smpeg, libquicktime etc…

I actually think it’s quite silly that anything other than the actual
display portion require a GUI of any kind.
(sorry - pet peave with 90% of these operations… SDL’s mpeg player’s
pretty much the only exception that I’ve seen)

If you’re going to make something modular, make it -modular-

Yep.

hrm also an observation that CODECs for Quicktime and AVI are pretty
similar with different metadata seeds (ie: headers) but same information.
I haven’t yet checked into other CODEC-able media formats…

  • Pasi K?rkk?inen, @Pasi_KarkkainenOn Wed, 6 Dec 2000, winterlion wrote:

On Wed, 6 Dec 2000, Jarrod Benjami Johnson wrote:

I actually think it’s quite silly that anything other than the actual
display portion require a GUI of any kind.
(sorry - pet peave with 90% of these operations… SDL’s mpeg player’s
pretty much the only exception that I’ve seen)

Hey! Didn’t I patch it to do that? :wink: Thanks!

-bill!
(who uses console every once in a while :wink: )

Wed, 06 Dec 2000 winterlion wrote:> On Wed, 6 Dec 2000, Jarrod Benjami Johnson wrote:

Ok, I think everyone knows our viewpoints now, so I’ll shut up.
One correction though, xanim has, as of late, been able to dynamically load
the playback modules, so it too, has a plugin architecture of sorts…

My only addition to this whole thing is that the communications point
(whatever reads/writes streams - be they files, RTP connections, …) and
whatever handles compression/decompression shouldn’t require a GUI…
(btw - where IS OMS? I can’t find it. stoopid search engines…)

I actually think it’s quite silly that anything other than the actual
display portion require a GUI of any kind.
(sorry - pet peave with 90% of these operations… SDL’s mpeg player’s
pretty much the only exception that I’ve seen)

If you’re going to make something modular, make it -modular-

Exactly.

That’s what MAIA is all about, BTW.

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

Bob McElrath wrote:

Scouring through the pile of “dead” projects on sourceforge, there is
also “openstream” (http://openstream.sourceforge.net) which seems to
have the same goal. (for other similar dead projects, see also on
sourceforge: retina, libmedia, linvsii) OpenStream appears to have the
backing of Indrema and Precision Insight. It also appears to be dead.
Does anyone know what happened to this project? If it still exists, we
should consider pooling resources.

After wrestling with the 30+ pieces of software claiming to do something
with video on linux, and having 29+ of them fail in one way or another,
I really want to see this happen. Cancelling dead projects and
pooling developer resources on one library/api/plugin system would be in
all our best interests.

Just to contribute a little to this discussion: IMHO Any "standard"
video playback system should be 1. Not linux- or x86-specific, 2.
Network-transparent, and 3. Licensed so that non-open-source codecs may
be supported. I don’t know how well oms fits in with any of these.

Yep, that’s exactly what I was thinking about.

By the way, AFAIK, OpenStream is not dead, and is still being backed and
developed by Indrema.

I contacted the authors, we’ll see. If they don’t have plans for active
development of openstream maybe we should try something different…

The developers of openstream told me, that they will make a public release
in the beginning of next year.

I think I’m going to wait for that and see if we really have need for
another project.

  • Pasi K?rkk?inen, @Pasi_KarkkainenOn Wed, 6 Dec 2000, Pasi K?rkk?inen wrote:

On Wed, 6 Dec 2000, Ryan Drake wrote: