Gst 0.10 "Roadmap"

[Mark Kretschmann]

On Thursday 08 June 2006 19:35, paulc2 at optonline.net wrote:
> What I'm working toward is reinstating Mark's Shoutcast StreamProvider
> class, except in gst 0.10 engine rather than in Amarok proper (notice the
> spelling :) - and having it feed an updated streamsrc like it was in gst
> 0.8.

[snip]

> Consequently it was my idea to allow either builtin stream handling or
> streamprovider depending on the setting of a configure parameter.  So
> something like --with-gst-builtinstreams or --with-gst-streamprovider or
> something like that (suggestions welcome).

I'm worried that this will add additional complexity, especially for bug 
reports. "Which engine did you use?", "Which stream source did you use?". The 
more code paths you add, the more difficult things get to debug. I would 
suggest to settle for one solution only.

> The first thing I'd like to know is if this is something that is considered
> desirable, or if there are reasons why we wouldnt want to do this and I've
> been wasting my time.

Generally I have no problem with this approach, but it can become hard to 
maintain. For instance the stream source with GST 0.8 on _some_ boxes had 
issues when the stream stalled, while on other boxes it worked just fine. I 
was never able to find the cause. This might have been a bug in GStreamer 
0.8, or simply my lack of understanding of the API, I cannot tell.

> Second, we used to advertise that we handled 'all stream types supported by
> KIO'.  In later gst 0.8 versions, it seems that we were only handling http
> streams, unless I'm reading the code wrong, but it would be a small matter
> to have local files handled by gst filesrc, http streams handled by
> streamprovider,  cds handled by the cdda, and 'all others' handled by KIO. 
> Do we want to get away from KIO streams?  Another thought would be to add
> yet-another-configure option to allow KIO streams.

IIRC we did support KIO streams in all 1.3 versions. However, since KIO 
neither supports seeking nor metadata in KDE3, its usefulness was limited. 
IMHO not worth bringing back.

> So, I welcome comments...

Hmm, difficult to say. All in all, I trust in StreamProvider's correctness for 
parsing Shoutcast streams. It's a fairly mature solution and works well. The 
difficult part may be to interface it with GStreamer, which was the sore 
point in Amarok 1.3.

Sadly, even if you get StreamProvider to work well, it will still only support 
http, but not mms or rtsp, like xine does. But I guess Shoutcast still makes 
for 80% or so of the interesting streams, so that's acceptable.

-- 
Mark