Re: GtkMediaPlayer widget
- From: Lee Braiden <jel ntlworld com>
- To: Gnome Multimedia Hackers <gnome-multimedia gnome org>, GNOME Desktop Hackers <desktop-devel-list gnome org>, Gstreamer-Devel <gstreamer-devel lists sourceforge net>
- Subject: Re: GtkMediaPlayer widget
- Date: Tue, 16 Dec 2003 19:20:37 +0000
On Tuesday 16 Dec 2003 6:45 pm, Ryan Gammon wrote:
> Lee Braiden wrote:
> >If we don't decide on a solution, but
> >instead provide abstractions to hedge our bets, all we're doing is adding
> >layers of inefficiency.
>
> I am not proposing another layer or abstraction. I do not want to wrap
> all the functionality of all the media frameworks.
>
> I want to create a clear, consice, simple media player interface that
> media engines could implement. This is not a wrapper. The interface has
> no overhead implications.
Well, simply in terms of a PLAY command... how would you do that? To me, you
either use an existing framework directly, including it's enumerations etc,
or you wrap it, and create a level of abstraction.
For me, the best case scenario is a well-defined, clean API for a multimedia
framework like gstreamer, and (perhaps) some system in GTK to integrate that
framework.
Ideally, you would not be telling GTK to play it, but simply asking GTK to
embed it, and give you a handle for the media framework's object. Then, you
use the already well-defined gstreamer API to actually manipulate that
object, knowing it will work 100% within GTK.
Perhaps I'm missing something, but I can't imagine another way that doesn't
wrap calls/command codes for PLAY, STOP, etc. Not if you want it to be
independant.
Whatever way I look at it, I can't imagine a way to provide a standardised
GTKMediaWidget that can be implemented by two different frameworks without
requiring abstraction of some (significant) level.
Again; I can't see the need for this dual-framework approach. GStreamer is a
fairly well-established framework, and, as far as I am aware, it provides
everything needed in terms of codec and hardware abstraction.
All I can imagine is that this is some attempt to establish a Helix-based
player as a de-facto standard by putting it into GTK first. Yet I see no
reason for it to be there at all -- as I understand it, Helix has done it's
best to avoid implementing its codecs in other players, and so is decidedly
*against* integration, except INTO Helix players/apps.
As such, I'd again repeat my point that the helix project should, from a
purely GNOME perspective, be writing codecs (or wrappers for their codecs)
and apps for gstreamer, rather than an entirely separate framework.
In my opinion, unless you can identify some fundamental flaw in gstreamer that
needs to be corrected, I see no reason not to consider it *the* GNOME
framework, and to integrate it tightly. Whether that is done at GTK level or
elsewhere is up to the relevant people.
Having said all that, you should probably be aware that I'm not working on
GTK, and so you don't have to justify yourselves to me, except as a member of
the community :)
--
Lee.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]