From: <pa...@ik...> - 2000-12-04 17:58:10
|
Hello everyone! As you all know, there are many separate video-player projects for Linux currently going on. I'm asking you, the developers, should we create something like 'linux-video-dev-mailinglist' ? 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..). What do you think, is there need for this kind of mailinglist? I could set up that list. All comments are welcome! - Pasi Kärkkäinen, pa...@ik... |
From: Dirk F. <fa...@ti...> - 2000-12-05 17:36:11
|
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 ;-) 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. > 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. > 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. Greetings Dirk ---------------------------------------------------------------- Dirk Farin University Mannheim / Dept. Circuitry and Simulation B 6,26 EG, room 0.10 / D-68131 Mannheim / Germany email: fa...@ti... ---------------------------------------------------------------- |
From: <pa...@ik...> - 2000-12-06 14:47:34
|
allow: post On Tue, 5 Dec 2000, Dirk Farin 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 ;-) 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, pa...@ik... |
From: Andres S. <sa...@rp...> - 2000-12-06 23:19:15
|
i think a project (not a ml, but an actual project or spec) of this nature is an excellent idea. however, there are certain problems that go along with this, depending upon how it is designed. mostly, they are legal in nature. just how _would_ this be handled? you could take the windows approach: define an API, and have that API pass off video/audio streams to their proper codecs. for example, if i want to decode a divx file, supply lib<whatever>'s API with the filename ("foo.avi"), and it will load an avi decoding library. windows does this by loading dlls, and having them handle the decoding. the nice thing about this approach is, you're just defining the interface; implementations are in their own standard libraries, you don't have to worry about their licenses. there could also be a nice callback system set up in this fashion; codecs register themselves, so while your default OS/distro includes libfoo_decode.so you can install libfoo_decode_faster.so, which registers itself w/ the standard video api for all .foo decode and encode requests. this approach would suffer from "dll hell"; libraries would have to be distributed, you'd have a multitude of codec implementations all fighting with each other. the other approach is to try to implement everything yourselves; if i want to decode a .mpg (mpeg-1) file, lib<whatever> calls it's internal mpeg decoder. this will supply a nice standardized video library, and is the preferred method. however, the legal issues here are going to be huge. assume one wants to decode/encode divx movies; you could take the approach avifile takes, which is to use pieces of wine, and load the win32 dll to handle it. if the goal is to handle multiple formats, there will probably be a lot of code borrowed from projects with incompatibile licenses, not to mention non-free (speech) dlls. this would mean exclusion by folks like debian and the fsf; without them, something would surely not be considered "standard", at least not under linux. anyways, forgive that rather long bit of rambling. my question is, how much would this library/API hope to accomplish? is the goal to simply provide an interface, or some kind of implementation as well? On Wed, Dec 06, 2000 at 04:47:27PM +0200, Pasi K?rkk?inen wrote: > On Tue, 5 Dec 2000, Dirk Farin 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 ;-) 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, pa...@ik... > > > _______________________________________________ > Xmps-devel mailing list > Xmp...@li... > http://lists.sourceforge.net/mailman/listinfo/xmps-devel -- "... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed." - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, rr...@te... |
From: Bob M. <rsm...@st...> - 2000-12-06 16:15:42
|
Pasi K=E4rkk=E4inen [pa...@ik...] wrote: >=20 > I just registered a project called "Open Media Interface" to the > sourceforge. Let's see if they'll accept it. >=20 > That project is dedicated to creating a good api/plugin/codec-system for > Linux (and other unices). Something like we have in windows.. >=20 > 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. >=20 > 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. 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. -- Bob |
From: <pa...@ik...> - 2000-12-06 21:07:12
|
allow: post On Wed, 6 Dec 2000, Bob McElrath wrote: > Pasi Kärkkäinen [pa...@ik...] 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, pa...@ik... |
From: Ryan D. <ry...@me...> - 2000-12-06 20:24:41
|
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. By the way, AFAIK, OpenStream is not dead, and is still being backed and developed by Indrema. -- Ryan Drake ry...@me... |
From: <pa...@ik...> - 2000-12-06 21:12:40
|
allow: post On Wed, 6 Dec 2000, Ryan Drake 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, pa...@ik... |
From: <pa...@ik...> - 2000-12-13 20:32:17
|
allow: post On Wed, 6 Dec 2000, Pasi Kärkkäinen wrote: > > On Wed, 6 Dec 2000, Ryan Drake 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.. > 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, pa...@ik... |
From: David O. <dav...@re...> - 2000-12-06 17:11:29
|
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: > On Tue, 5 Dec 2000, Dirk Farin 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 ;-) 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. :-) (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 | `--------------------------------------> da...@li... -' |
From: Yoann V. <yo...@ma...> - 2000-12-06 14:57:38
|
Pasi Kärkkäinen <pa...@ik...> writes: > allow: post > > On Tue, 5 Dec 2000, Dirk Farin 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. don't you think you're duplicating a little what oms does ? -- -- Yoann http://www.mandrakesoft.com/~yoann/ Tiniest "mesures unities?" - lenght : millimeter - volume : milliliter - intelligence : military man |
From: Jarrod B. J. <jbj...@pa...> - 2000-12-06 15:44:28
|
As written by Yoann Vandoorselaere (yo...@ma...): > don't you think you're duplicating a little what oms does ? Since when is anything in Linux multimedia *not* a duplication of effort? :) Seriously though, regardless of the mission of OMS, it's no closer to defining the standard for Unix multimedia than any other player with plugins. I might even go so far as to say that just from philosophy, it is already further away than the vaporous project being discussed. Why would I say this? Because OMS is/includes a high quality player. At this point in time, there is no clear, definitive media player for Unix as yet. What this means to most developers working on players is that there is wide open opportunity to have a piece of Open Source fame, and no developer is ready to give up their chance for a spotlight to play second string for other projects which may make his/her project lose attention. This is the way that many Open Source developers are selfish (including myself) I think it is a good idea for a standard to be worked on completely independent of any player. This is part of what makes projects like smpeg such a success. It may include players, but they are, by design, not very comprehensive and therefore insufficient for the needs of most. Players of this sort associated with a project are non-threatening to developers with their own projects, so they are more likely to contribute and improve on smpeg. So basicly, I am saying that OMS is not a good media standard because the player is just too good, ironically enough. |
From: Yoann V. <yo...@ma...> - 2000-12-06 15:53:01
|
Jarrod Benjami Johnson <jbj...@pa...> writes: > As written by Yoann Vandoorselaere (yo...@ma...): > > don't you think you're duplicating a little what oms does ? > Since when is anything in Linux multimedia *not* a duplication of effort? :) > > Seriously though, regardless of the mission of OMS, it's no closer to defining > the standard for Unix multimedia than any other player with plugins. Is there any other multimedia / (DVD ?) player using plugins ? > I might > even go so far as to say that just from philosophy, it is already further away > than the vaporous project being discussed. > > Why would I say this? Because OMS is/includes a high quality player. > At this point in time, there is no clear, definitive media player for Unix as > yet. What this means to most developers working on players is that there is > wide open opportunity to have a piece of Open Source fame, and no developer > is ready to give up their chance for a spotlight to play second string for > other projects which may make his/her project lose attention. This is the > way that many Open Source developers are selfish (including myself) > > I think it is a good idea for a standard to be worked on completely independent > of any player. This is part of what makes projects like smpeg such a success. > It may include players, but they are, by design, not very comprehensive and > therefore insufficient for the needs of most. Players of this sort associated > with a project are non-threatening to developers with their own projects, so > they are more likely to contribute and improve on smpeg. Ok, I basically agree with what you are saying, but I'm affraid you didn't look at what does *currently* exist. You say : <quote> > I think it is a good idea for a standard to be worked on completely independent > of any player. This is part of what makes projects like smpeg such a success. > It may include players, but they are, by design, not very comprehensive and > therefore insufficient for the needs of most. </quote> Talking about Oms, this only mean you didn't even bothered to understand how it work. In Oms, the player does almost nothing (only drawing an interface), and using *liboms* functions. *liboms* is a library that is dealing with plugins issues (loading the right plugins for this kind of stream, etc etc), and with many kind of plugins (codec audio, codec video, output video, output audio, etc). So this library is completly player independant, and could be used by any player to be able to provide complete multimedia support. > So basicly, I am saying that OMS is not a good media standard because the player > is just too good, ironically enough. And what you just said is plain wrong :-) -- -- Yoann http://www.mandrakesoft.com/~yoann/ An engineer from NVidia, while asking him to release cards specs said : - "Actually, we do write our drivers without documentation." |
From: Jarrod B. J. <jbj...@pa...> - 2000-12-06 16:07:42
|
As written by Yoann Vandoorselaere (yo...@ma...): > Jarrod Benjami Johnson <jbj...@pa...> writes: > > Is there any other multimedia / (DVD ?) player using plugins ? Yes, xmms, xmps, Xtheater, xanim come to mind, even if some of the plugin architectures suck. > > Ok, I basically agree with what you are saying, > but I'm affraid you didn't look at what does *currently* exist. At the time most of these projects, OMS was not a pre-existing entity, most all plugin based players have roughly the same age, except xanim and xmms kinda are a bit older... > > You say : > > <quote> > > I think it is a good idea for a standard to be worked on completely independent > > of any player. This is part of what makes projects like smpeg such a success. > > It may include players, but they are, by design, not very comprehensive and > > therefore insufficient for the needs of most. > </quote> > > Talking about Oms, > this only mean you didn't even bothered to understand how it work. > In Oms, the player does almost nothing (only drawing an interface), > and using *liboms* functions. Drawing an interface is enough to be threatening to most people with projects. Xtheater is not exactly a library, it takes an opposite approach, the part that draws stuff is built into a very simple library, and xtheater itself serves the purpose that liboms serves by servicing media interface requests and configuration file stuff. Perhaps a backwards approach, but still, on a technical level has pretty equal merits. > > *liboms* is a library that is dealing with plugins issues (loading the right > plugins for this kind of stream, etc etc), and with many kind of plugins > (codec audio, codec video, output video, output audio, etc). > So this library is completly player independant, and could be used by any player > to be able to provide complete multimedia support. Never said that the library could not be used by other players, just said that the default one is pretty good, so people may not wish to develop UI applications with it in mind. Of course for the backends, this is perfect, but does not really entice any existing UIs to scrap their own backends to use it until many many many things get developed to make it impractical to develop independently. All projects working on this go against each other in this respect. So long as features remain equivalent and popularity seems equivalent, a common standard will not be agreed upon. |
From: <pa...@ik...> - 2000-12-06 15:35:22
|
On 6 Dec 2000, Yoann Vandoorselaere wrote: > Pasi Kärkkäinen <pa...@ik...> writes: > > > allow: post > > > > On Tue, 5 Dec 2000, Dirk Farin 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. > > don't you think you're duplicating a little what oms does ? > It might be. If I have understood oms correctly, it tries to create a full "mediaplayer" for linux. The project I am talking about would only take care of input (read) and output (write) plugins/codecs for different mediaformats. It would have nothing to do with a full "mediaplayer" itself. The set of codecs/libraries/whatever created in my project could be used by existing and upcoming players and editors to provide easily access to many fileformats. libmpeg2 (that is used by oms) could be used as a basis of mpeg2-plugin for Open Media Interface. So, I'm talking about creating a "standard" way of of accessing different fileformats (.mpg, .avi, .mov, etc). The idea behind this comes from the big amount of different videoplayers for linux currently. They all have their own way of accessing files (some use libmpeg2 + some other libraries and so on). With Open Media Interface all of those players could just use some API specified by the project to access all kind of different fileformats. Maybe OMS could use Open Media Interface too? Please comment on this :) That's what I'm thinking about. - Pasi Kärkkäinen, pa...@ik... |
From: Yoann V. <yo...@ma...> - 2000-12-06 15:46:10
|
Pasi Kärkkäinen <pa...@ik...> writes: > On 6 Dec 2000, Yoann Vandoorselaere wrote: > > > Pasi Kärkkäinen <pa...@ik...> writes: > > > > > allow: post > > > > > > On Tue, 5 Dec 2000, Dirk Farin 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. > > > > don't you think you're duplicating a little what oms does ? > > > > It might be. If I have understood oms correctly, it tries to create a full > "mediaplayer" for linux. > > The project I am talking about would only take care of input (read) and > output (write) plugins/codecs for different mediaformats. what oms also does... > It would have > nothing to do with a full "mediaplayer" itself. > > The set of codecs/libraries/whatever created in my project could > be used by existing and upcoming players and editors to provide easily > access to many fileformats. > > libmpeg2 (that is used by oms) could be used as a basis of mpeg2-plugin > for Open Media Interface. > > So, I'm talking about creating a "standard" way of of accessing different > fileformats (.mpg, .avi, .mov, etc). what oms does. > The idea behind this comes from the big amount of different videoplayers > for linux currently. They all have their own way of accessing files (some > use libmpeg2 + some other libraries and so on). With Open Media Interface > all of those players could just use some API specified by the project to > access all kind of different fileformats What liboms does... [same player play again]. -- Unix IS user friendly. It's just selective about who its friends are. |