On Wed, 2005-07-06 at 02:13 -0400, Charles Schmidt wrote: > 3. Modify the httpclientsrc implementation in bugzilla to have settable > properties for extra headers. uris would be handed to RBPlayer in the > form of daap://. RBPlayer would fudge them into http:// uris, force > playbin to use the new httpclientsrc, and add the extra headers to it. > > Number 3 is probably the "best" solution: > It solves multiple problems. Namely: this one and adds a non-gnomevfs > http:// handler for GStreamer. However, I believe it is the most > challenging, and does end up with some "hackish" code inside RBPlayer. I agree that (3) is the most "elegant" solution in that it doesn't put things in places where they don't really fit (i.e. gnome-vfs). As to having some "hackish" code to deal with setting the properties, etc - I'm going to need something virtually identical for audio cd support (to deal with non-/dev/cdrom devices). After a discussion with some of the gstreamer developers on #gstreamer a couple of days ago, I have learnt that there is a signal that gets emitted from playbin, after the source element in constructed, but before it is used for anything. This can be used to set properties that are requires for playback. I've got some thoughts on how to do this, but it involves exposing a small amount gstreamer stuff to other parts of RB. Step 2 below involves storing the http headers, cd device, or whatever in the RhythmDbEntry - how to do this in a backend-neutral way I'm not sure, because the values are specific to gstreamer. That said, we have removed the xine backend, my cd audio source _requires_ gstreamer, and the other options for DAAP have gstreamer-specific bits; substantial parts would need to be rewritten to support any non-gstreamer backend. 1) Make rb-player take a RhythmDbEntry instead of a simple uri, it can get the uri from the entry, so this should be a (relatively) simple change. I'm not aware of any particular reasons against doing this, but I don't know too much about the internals of rb-player. 2) Add a new field to RhythmDbEntry which lists a mapping of property names and values that need to be set for the source element. Have rb-player-gst register a callback for the, which would grab the names/values from the entry, and set them on the property. I think this would be one way to solve the issue of how to set properties on the source element. However there is still an issue for DAAP: > The request-id starts at 1, and every time you request another song it > needs to increment one. The request-id isn't something that depends only on the entry to play, it depends on staeful information, which makes it a bit complex. I'm not sure on the best way to fit this into my above scheme. Cheers, James "Doc" Livingston -- We all enter the world in the same way: naked... screaming... soaked in blood. But if you live your life right, that kind of thing doesn't have to stop there.
Attachment:
signature.asc
Description: This is a digitally signed message part