[Bug 709455] dlnasrc: new manager type element used for dlna specific HTTP transfers

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=709455
  GStreamer | gst-plugins-bad | 1.x

--- Comment #38 from Lori Anderson <grandocap at gmail.com> 2013-12-04 14:33:41 UTC ---
In response to:

>Changing souphttpsrc does not sound like a good plan to me, but can't you
>auto-detect the two use cases? Maybe based on the caps that downstream
>supports? What would it passthrough in the WebKit case, you mean that it
>wouldn't be a source element but instead get data from upstream?

The dlnasrc can't really detect which mode it should support.  I added the
"passthru-mode" property which tells the dlnasrc it should act like a filter
and not like a source.  When it is in the passthru-mode it creates a sometimes
sink pad. 

When running from within webkit, the webkitwebsrc creates dlnasrc, sets the
mode to passthru and hooks the dlnasrc's sink pad to it's appsrc src pad.  This
allows the dlnasrc to get seek events on its pad and setup the http GET headers
according to what is expected for dlna.  When webkitwebsrc sees the seek event
and it is using the dlnasrc, it gets the HTTP headers via a property from
dlnasrc rather than just using bytes & the Range header.  This is a workaround
since the appsrc callback for seek_data only supplies the position.  The
dlnasrc needs to see all the seek event fields to properly format the dlna HTTP
headers, especially if the rate is non-1x.

When dlnasrc is in "normal" mode, it is a bin acting as a source and internally
uses souphttpsrc as the source.  It gets the seek events and sets the extra
headers on souphttpsrc.

-- 
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.