Le 5 nov. 06 à 02:17, Yen-Ju Chen a écrit :
On 11/3/06, Guenther Noack <[EMAIL PROTECTED]> wrote:
The MplayerInterface class in Mplayer seems to be pretty usable to
me.
I guess creating a framework that contains a MediaPlayer protocol and
this class will be all that needs to be done. (This way, we can also
still change back to GStreamer if it really doesn't work with
Mplayer.)
Please keep in mind the podcast-playing capabilities that we can get
from that. :-))) (I'm so motivated! :-))
O.K. I got Babbler work with mplayer.
MultimediaKit is the one talking to mplayer.
Babbler is the user interface.
It currently only supports play and pause.
It also play video within the NSWindow, not a separate window.
If you want to play podcast or other stream,
you can use 'openapp Babbler stream_type://uri'
I still prefer gstreamer in the future.
Unfortunately, it doesn't play a mms stream I would like to hear.
So mplayer works better for now. :)
But because of mplayer, MultimediaKit is under GPL.
Just entering lately in the discussion… but would it be possible to
adopt our own API and put each backend code (glue code for gstreamer,
mplayer) in a dedicated bundle? Then MultimediaKit could be licensed
under both LGPL and LGPL, that would allows to use mplayer backend in
a GPL application and still uses MultimediaKit with another backend
in non-GPL applications.
This is perhaps overkill if we dedice to set our choice on one
backend ultimately. What do you think?
For the MultimediaKit, we may adopt QuickTimeKit API at least
partially (the non QT specific stuff), specially thinking about
QTMovieView and QTMovie classes. I don't know whether it's possible/
interesting?
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
