Gst 0.10 "Roadmap"

[Paul Cifarelli]

ok, that's cool.  I'll commit what I have this weekend - working or not 
(streamprovider is working fine, but i havent gotten streamsrc working yet)


On Thursday 08 June 2006 22:16, Jeff Mitchell wrote:
> 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.
>
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok