[gst-devel] My media player hackings

[Benjamin O. <in...@pu...>]

Ok, here it is:
The totally not working, absolutely useless media player hack.
It's available at http://home.arcor-online.de/lvs/gstmediaplayer-.tar.gz
bad:
- It's broken, though the error is in the core - the autoplugger doesn't
work.
- Makefiles and stuff are not clean (as you see with the missing version
number)
- It's not having half of the features of the CVS version
- It only works with GNOME2 Gstreamer, I suppose. I've not tested it with
GNOME1.
good:
- The architecture is hopefully cleaner.
- That's it.
It's basically just good to look at the source. Maybe not even that. ;)

What I did:
I modified gstplay.[ch] to be what I think is cleaner. All other files are
basically just hacked to allow this files to be tested.


The theory behind it:

The API:
GstPlay provides three writable properties to the application and hides
the other information details.
The first option is the URI defining the file to play.
The second option is the state, which should mostly equal the state of the
pipeline.
The third option is the position in the stream. This option is not
implemented because of missing possibilities in the core.
Feedback is given to the application with the use of signals. Two signals
are implemented right now: INFORMATION (for metadata) and STATE_CHANGE.
Other signals may be implemented, I haven't thought about them much yet.

The idea:
GstPlay should provide a simple, yet powerful abstraction layer for
playing anything Gstreamer supports. The main goal for me was to achieve,
that the developer using GstPlay does not have to look further then this
object to get everything going. For example he does not have to know what
"iterate" means.
Because of this, the modification possibilities should be small. Since
there are only three properties, this probably works.
On the other hand the feedback should be as great as possible to allow for
good feedback to the user by the application. Feedback is implemented
using signals. So in short: There should be little properties, many
signals and no need to look at other Gstreamer code/docs.

The implementation theory:
GstPlay contains a pipeline. This pipeline contains 4 elements:
1) a source element
This element is picked every time a new location is specified. It is
picked automagically from the list of available plug Ins, from file to
midi to v4l.
2+3) audio/video sink elements
These elements are picked semi-automatically. The idea is to support many
configurable output plugins like in Winamp or XMMS. Normal people probably
prefer oss/alsa and xvideo, but you could want to use GstPlay to rip CDs
to Mp3. This should be supported, too. But these sinks must be
configurable: options for mp3 encoding, encoding algorithm for MPEG
encoding, you name it. So you probably can't just select from a list of
standard elements.
4) The autoplugger
The autoplugger element simply connects the source with the sinks, at
least in theory.

btw: You should be able to create as many GstPlay objects as you
like, having them output anywhere you want at the same time. You should be
able to have sound output from a mediaplayer, a mail applet "You've got
mail" and the beep from a warning message box via the oss output plugin at
the same time. At least this was my idea.

Things that should/could be done next:
- Get that thing working. This will probably involve fixing the static
autoplugger.
- Get somebody do the event stuff. Events need proper definition and
implementation in important elements. Today only EOS works, most elements
don't know about other
events, INFO events can't be accessed without private headers and so on.
- Make the media player give a little more feedback. The first step would
be to get the status area working.
- Implement the playlist properly.
- i18n and l10n
- Fix build issues.
- Bugfixing Gstreamer core and plugins

Things that should be done later:
- More event stuff like implementing in noncommon plug-ins
- URI handling
- configuration things.
- output plugins? (Plugouts?)
- Bugfixing everything
- Find a way for prefetching author/title/songlength information for
tracks on the playlist
- Create nifty programs using GstPlay, like Nautilus views, TV or
mediaplayer panel applets and so on.


And one last point to make you all discuss:
IMHO we should stop supporting GNOME1 and concentrate on getting something
usable for GNOME2. Until this player is really usable for end users
nobody will care about GNOME1 anymore.


An now I'm going to bed and sleep.

Benjamin