[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 #18 from Lori Anderson <grandocap at gmail.com> 2013-11-11 17:52:46 UTC ---
As part of investigating using the "virtual protocol" approach, another
question was raised.  Currently, the dlnasrc uses the URI and queries the
server through a HEAD request to determine if the content is encrypted.  If the
content is encrypted, it creates a decrypter element and links it to
souphttpsrc as part of the dlnasrc's bin.  Is this the "right gstsreamer way"
to do this or should the dlnasrc change its src caps media type to
"application/x-dtcp1" and leverage autoplugging/typefind to find the decrypter
element and hook it up?  The dlnasrc encrypted case seems somewhat different
from other typefind functions in that it would need to use the URI and issue a
HEAD request to "typefind" if this is "application/x-dtcp1" content, it doesn't
even look at the stream data as other type find functions do.  It doesn't seem
to fit the "typefind" paradigm.

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