Trouble playing HTTP-URIs gapless in "playbin"

[Henner Zeller]

On 18 April 2013 01:30, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:

> On Wed, 2013-04-17 at 23:46 -0700, Henner Zeller wrote:
>
> Hi,
>
> > Did any of the developers had a chance to take a look ? I might want
> > to investigate the reasons next weekend, but it might be helpful to
> > have some rough plan of action.
> >
> > This is essentially a regression from 0.10: gapless playing of
> > non-file URIs used to work with the suggested about-to-finish
> > callback, but doesn't with 1.0.
> > (but in 0.10 it was leaking threads...)
>
> It sounds like a bug. Please file a bug report in bugzilla:
>
>  http://gstreamer.freedesktop.org/bugs/


Thanks, filed
 https://bugzilla.gnome.org/show_bug.cgi?id=698306


>
> I don't think there's much you can do wrong in your sample app (though I
> have not looked at it).
>
> Cheers
>  -Tim
>
> >
> > On 15 April 2013 23:13, Henner Zeller <h.zeller at acm.org> wrote:
> >         Hi,
> >         I am maintainer of gmrender-resurrect [1], a UPnP renderer
> >         (forked from the dormant 'gmrender' project). It is using
> >         gstreamer as backend.
> >
> >
> >         Using the gstreamer "playbin" feature to set the next URI in
> >         an "about-to-finish" callback, this UPnP renderer successfully
> >         implements gapless playback, alas, not without trouble.
> >
> >
> >         It turns out, that playing gapless with inputs from HTTP-URLs
> >         is leaking threads, up to the point that things stop working.
> >         This is with gstreamer-0.10. With gstreamer-1.0 setting HTTP
> >         URLs in the "about-to-finish" callback does not seem to work
> >         at all.
> >
> >
> >         This _does_ work with local file-URIs, so I believe this has
> >         to do with different handling of network resources vs. local
> >         resources, i.e. buffering, probably a separate thread handling
> >         the network input (and it would explain why this hasn't been
> >         noticed before, because the usual use-case is to read from
> >         files).
> >
> >
> >         To reproduce, I created simplified test-code including
> >         Makefile and test-sound in this public git repository that
> >         illustrates the behavior:
> >
> >
> >           https://github.com/hzeller/gstreamer-gapless-test
> >
> >
> >         All it does is to re-set the original URI back once the
> >         "about-to-finish" callback is called ... and exhibiting the
> >         described behavior:
> >           - gstreamer-0.1: runs out of threads on gapless playing URIs
> >           - gstreamer-1.0: does not handle well having the URI set in
> >         about-to-finish callback.
> >            - both work with file URIs
> >
> >
> >         Instructions to reproduce are under
> >
> >
> https://github.com/hzeller/gstreamer-gapless-test/blob/master/README.md
> >
> >
> >
> >         Maybe, this is a usage error, but I suspect it to be a bug. If
> >         you can confirm that this _should_ work, then I am happy to
> >         file a bug, and probably dig into the code to help working on
> >         a fix.
> >
> >
> >         Thanks,
> >           Henner.
> >
> >
> >         [1] https://github.com/hzeller/gmrender-resurrect
> >
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130418/d4f58c17/attachment-0001.html>