[gst-devel] Re: GtkMediaPlayer widget
jel at ntlworld.com
Tue Dec 16 15:09:09 CET 2003
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
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
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 :)
More information about the gstreamer-devel