[gstreamer-bugs] [Bug 321532] Support device setting in cdda:// URI

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Tue Nov 15 10:57:03 PST 2005


Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=321532
 GStreamer | gst-plugins-good | Ver: 0.9.x





------- Additional Comments From Aaron Bockover  2005-11-15 18:57 -------
Because without URI support, it's easy to break or cause inconsistencies with
other applications, unless the burden is placed _on_ the "consumer" application,
which is fine, except for one little detail: all the consumer applications
basically end up doing the same thing, potentially with little differences (we
have thus far that I know of: cdda://<track>/<device> (mplayer),
cdda://<device>:<track> (RhythmBox) cdda://<track>#<device> (Banshee). Totem
probably has a scheme too, maybe it's like the RB scheme. The point is, all of
these applications realize they have to handle URIs for audio CDs, so why should
the underlying framework not handle them? At least then there would be a
consistent convention.

Say Nautilus wants to tell the default media player to play an audio CD in my
non-default drive. The best way for this is... a URI, like we have for accessing
all other types of media. Now the default media player has to handle that URI on
its own because it's not supported in the underlying media framework. There are
many media players, which would all then have essentially duplicate code to
handle this. That just doesn't make sense. Why are you treating a track on a CD
like it's anything different than an ogg file on a local or remote host? Doesn't
that conflict with the ideals of GStreamer?

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.




More information about the Gstreamer-bugs mailing list