GNOME Bugzilla – Bug 325847
[gnomevfssrc] port iradio tag changes from 0.8
Last modified: 2006-04-21 09:34:54 UTC
Patch coming soon. Tested with rhythmbox and gst-launch.
Created attachment 56809 [details] [review] patch I'm not sure if the pull mode activation hack is the right thing to do (and I don't really like it, in any case), but I couldn't see any other way to do it.
*** Bug 328689 has been marked as a duplicate of this bug. ***
People who try this patch should update the core as well, so that typefinding works reliably, instead of depending on how many bytes of data the first network read happens to return: 2006-02-14 Tim-Philipp Müller <tim at centricular dot net> * plugins/elements/gsttypefindelement.c: (gst_type_find_element_chain): When typefinding is unsuccessful in the chain function, don't error out immediately. .... What were the issues with this patch? The "hackiness"? Something else?
So, following on from some discussion on what to do about this yesterday... There are actually a whole bunch of things done in the gnomevfssrc plugin for 'iradio mode'. I think most of them should be moved. 1) sending the appropriate headers to get shoutcast/icecast to send metadata for mp3 streams, and parsing response headers. Has to be done here. 2) The 'x-audiocast' UDP metadata stuff. Runs a seperate thread. Does anyone know of _any_ servers that actually produce/use this, that are in active use? I'd rather kill it off if, as I suspect, nobody uses it. 3) Parsing the shoutcast/icecast metadata out of the raw data, and forwarding the remainder. This should certainly be done in a seperate plugin (which would also help other http plugins that want to implement this) 4) Special properties on the element for other 'iradio mode' headers. Shouldn't we just be pushing these things as bus tag messages? If people are happy to see x-audiocast support go, I'll try and work up a patch to do all of this later this week. Mike
One thing i don't like about this is the "iradio-mode" property. It somehow doesn't seem right to unconditionally set this from playbin for all http:// URIs. If that's unproblematic and doesn't interfere with 'normal http', then we don't need the property and gnomevfssrc can just do its stuff, can't we? (Or was it just to start up the additional UDP stuff?)
Yeah, iradio-mode is fairly harmless. It just makes gnomevfssrc send an extra HTTP header or two. All the rest of the behaviour is triggered from response headers (which we'll only get if we sent those headers initially). On non-shoutcast/icecast/whatever servers, those headers will just get ignored, so they're safe enough to send always. Of course, we need to keep all these stupid properties because they're part of our API, but we don't actually need to DO anything with them. So iradio-mode can just be ignored, the others (which are read-only string properties) can just return nothing, and we can doc them as deprecated.
I remembered why iradio mode isn't harmless. If we default to on, then, once gnomevfssrc is cleaned up to not internally demux the metadata: gst-launch gnomevfssrc location=http://some.icecast.server/ ! filesink location=streamdump.mp3 will give you an undecodable 'mp3' file. Which is bad.
In an effort to reproduce this bug, I tried: gst-launch gnomevfssrc location=http://some.icecast.server/ iradio-mode=1 ! filesink location=streamdump.mp3 and I got a proper mp3 file. Am I missing something or has the internal demux been fixed?
*** Bug 338148 has been marked as a duplicate of this bug. ***
Being handled in #333657, marking this as duplicate. *** This bug has been marked as a duplicate of 333657 ***