[Bug 738298] souphttpsrc: add 'pause-mode' property
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Mon Oct 13 03:34:03 PDT 2014
https://bugzilla.gnome.org/show_bug.cgi?id=738298
GStreamer | gst-plugins-good | unspecified
--- Comment #5 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-10-13 10:33:59 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > I think this should only be done if accept-ranges is declared by the server,
>
> This makes sense for the "pure" HTTP use case but is going to be problematic
> when using the dlnasrc element. DLNA defines its own HTTP field for servers to
> advertise that they support "byte range" (see "7.5.4.3.2.22 MT HTTP header:
> Range (server)" in the spec). Some servers (like the MCVT tool) only use this
> field so we wouldn't be able to use "pause range" on those.
>
> Also, in theory, a DLNA server could support only "time range" requests (which
> is DLNA specific) so we'd still want to be able to support "time pause" in that
> case.
Yeah, that's why I think all this DLNA mess should be handled differently
without adding DLNA specifics to souphttpsrc but by making souphttpsrc more
extensible.
> > Independent of that you should not look at the pipeline state, but instead look
> > if downstream is blocked. Data processing happens (and should!) in paused.
>
> Do you mean I shouldn't catch the state change in
> gst_soup_http_src_change_state()? What's the proper way to know if the src pad
> is accepting data or not?
I don't know unfortunately... maybe timeout if create was not called for a
longer time.
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list