[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