Gst 0.10 "Roadmap"

[Jeff Mitchell]

Paul--

As I pledged a week or so ago, I *am* planning on helping out with this.  I'm 
in the middle of moving/reoganizing/huge amounts of work/etc., which I had 
predicted would put me out of things for at least a week.  Hopefully sometime 
next week I can start helping out (though I'll have to read GStreamer docs 
first)   :-)

--Jeff

On Thursday 08 June 2006 14:53, Mark Kretschmann wrote:
> 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.