[MPlayer-dev-eng] [RFD] Something...

D Richard Felker III dalias at aerifal.cx
Sat Apr 12 00:42:25 CEST 2003


On Fri, Apr 11, 2003 at 09:29:40PM +0100, Dave Lambley wrote:
> Hi,
> 
> Is this the kind of thing gstreamer is for? You may be could interface
> the mplayer demuxers and codecs to it?

And have it be slow as hell....

Seriously, I can't talk bad about gstreamer since I've never looked at
it, but as far as I can tell, MPlayer is the *only* video
playing/processing program that takes *any* notice of performance
whatsoever. While the other progs are copying the picture around
multiple times, using bloated slow api's, etc., MPlayer has a decent
(but still not perfect) system whereby codecs, filters, and output
drivers negotiate capabilities, process video in its native colorspace
when possible, direct render or slice render between filters and to
the output driver, etc.

Therefore, a *good* universal media manipulation project would need to
evolve out of MPlayer and what was learned through this project, or
else be written by someone very competent with a good theoretical
understanding of the performance issues involved.

Also there's the issue that many other projects have all sorts of
automake junk, bloated dependencies, etc.... I honestly don't know
where gstreamer stands on this stuff.

Rich

> On Fri, 2003-04-11 at 20:37, Andriy Gritsenko wrote:
> >     Hi, community!
> > 
> >     For last two or three months I got an idea. May be Arpi will laught
> > on me but I didn't see G2 project yet and that idea may be too alike of
> > G2... :)
> >     What I want? I want to have universal media manipulation project.
> > Player, or encoder, even video editor with any interface: commandline, or
> > text mode interface, or Gui, or remote, etc.
> >     What I wrote last time about the config parser and Gui was about that
> > idea. :)  How I see it?
> > 
> >                         +-----------+
> >                         |  Filters  |
> >                         +-----------+
> >                             | | | (2)
> >            +----+     +---------------+     +----+
> > Audio/  -->|    |---->|   Sequencer   |---->|    |
> >  video     |    |---->| & audio/video |---->|    |--> Output
> > sources -->|    |---->| syncronizator |---->|    |
> >            +----+ (1) +---------------+ (3) +----+
> >     Input modules             | (4)         Output modules
> >                         +-----------+
> > (1) - input API         |  Control  |
> > (2) - filters API       |  modules  |
> > (3) - output API        +-----------+
> > (4) - control API
> > 
> >     Each module may be statically or dynamically (via dlopen() syscall)
> > linked to the core. Core does only few functions:
> > 1) registers/opens/closes modules;
> > 2) [un]registers audio/video streams;
> > 3) contains API for intermodule transactions (forward control from
> >   control module to all other);
> > 4) creates audio/video threads (input->filters->output);
> > 5) does audio/video sincronization.
> > 
> >     All other will do modules. All these have very limited API and due to
> > that is very flexible. :)  So we could have MPlayer, MEncoder and MEditor
> > from the same program by adding different modules. :)
> >     Arpi, do you want me to cooperate with you? :)  I think I have at
> > last to look at your G2 project, I'll do it after weekend.
> > 
> >     With the best wishes.
> >     Andriy.
> > 
> > _______________________________________________
> > MPlayer-dev-eng mailing list
> > MPlayer-dev-eng at mplayerhq.hu
> > http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> > 
> 
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng



More information about the MPlayer-dev-eng mailing list