[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 #45 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2013-12-04 15:17:59 UTC ---
(In reply to comment #44)
> (In reply to comment #39)
> > (In reply to comment #38)
> > > 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, [...]
> > >
> > > 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.
> > 
> > That sounds like it should be different elements. But why can't webkit create
> > dlnasrc, and that then creates webkitwebsrc instead of souphttpsrc internally?
> 
> What would the two elements look like?  They would need to share common code. 
> One would act as a filter and one act as a source, right?  

Yes, but I still don't think this is a clean solution for this problem.

> In terms of webkitwebsrc creating a dlnarc, right now playbin creates the
> source which is webkitwebsrc due to the really high rank.  So in order to have
> webkit create a dlnasrc, dlnasrc would have to have the really high rank + 1
> unless we went with a "virtual" protocol. 
>
> I have explored using a "virtual" protocol, such as "dlna+http" and having
> dlnasrc support that protocol.  It has the undesired side affect of requiring
> the URI to be modified by the application to include the "dlna" portion.  I'm
> not sure how receptive WebKit would be to modifying URIs.

Well, you would need to only change it when passing to GStreamer from WebKit. I
think the main problem here is still that the DLNA people added a new protocol
and stole the HTTP URI scheme for this...

So you either have to use such a new URI scheme, or give dlnasrc a very high
rank so that it is autoplugged for every URL with an HTTP URI scheme.

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