Created attachment 256512 [details]
Source code for dlnasrc element.

Created attachment 256513 [details]
Source code for dlnasrc element

Thank you for your contribution, it looks very promising.

From a quick read of the source code, here are some comments:

- In gtk-doc style, at the top of the source file, can you add some documentation explaining what this is for, what it does, how to use it, preferably with example pipelines. Can you please include references to the relevant bits of the DLNA spec? Are these parts public?
- Please run the .c file through gst-indent, although you're already 99% there
- Don't declare variable in the middle of blocks, it should all be C89
- No C++-style // comments, only C-style /* */
- While you're at it, clean up the  comments obvious to people familiar with GStraemer/GObject
- Function doc should be in gtk-doc style, not doxygen style
- Add G_PARAM_SPEC_STATIC_STRINGS when adding properties
- Please replace the empty dispose() method with a finalize() method and free everything in the object (mostly the strings?), they're currently being leaked
- Why do you do the head request manually instead of using libsoup? The current code is not portable to Windows.
- struct_str should probably be a GString instead.. But you should use libsoup instead of re-implementing HTTP, that would remove a lot of code I think
- What's the point of the cl_name property ?
- It is safe to call g_free (NULL), so if (x) g_free(x); can be replaced with g_free(x);
- You may want to create a "virtual" protocol like dlnahttp:// and dlnahttps:// to allow it to be auto-plugged. Probably rank it as SECONDARY instead of PRIMARY-1
- gst_play_marshal_VOID__OBJECT_BOOLEAN is declared but doesn't exist
- Please add a state_change method to GstElement that will fail the NULL->READY transition if souphttpsrc can't be created
- You need to create the ghostpad in the init function, not when setting the uri. It is declared as static
- Please don't do the HEAD request in the set URI call, but only on the READY->PAUSED transition. 
- Don't use g_try_malloc0(sizeof(...))... then not check if the memory was allocated. Please use g_slice() instead. Generally don't waste time with g_try_malloc(), GLib assumes all over the place that memory allocations don't fail (and otherwise calls abort())
- For the npt parser, you may want to look at parse_npt_time() in gst-plugins-base/gst-libs/gst/rtsp/gstrtsprange.c

Are you planning to also contribute the dtcp-ip support? If you're not, then it shouldn't be used, elements in the upstream repositories shouldn't rely /use secret elements. You may want to architect it in a way that allows you to do dtcp-ip processing in an element that follows the source in your pipeline or something like that. Or maybe make the dtcpsrc could be a further container around dlnasrc.

For the protocol something like http+dnla:// might be a good idea. Other than what Olivier said, please also attach the next version as a patch against gst-plugins-bad :)

Thanks for the above suggestions.  I will implement them and supply an updated patch.  

As for the dtcp-ip support, I am planning on submitting the dtcpip element so I think don't think it will be a secret element and current architecture is sufficient.

I would also mention that the dtcp-ip element will not actually perform decryption.  DTCP is governed by a "secret" specification that is managed by DTLA (www.dtcp.com) and only member organizations can access the spec and produce implementations.  Our solution abstracts the actual DTCP stack via an API that is accessed by making function calls to runtime-loaded DSO.  Our intention is to provide a solid GStreamer element that becomes functional once someone plugs in their proprietary DTCP implementation.  Additionally, our element will support pass-thru of packets (with no decryption) for testing purposes.

Part of the feedback we would like to get from the GStreamer developers is regarding our design for this "abstraction" and whether or not this sort of element would even be accepted by GStreamer.

(In reply to comment #6)
> I would also mention that the dtcp-ip element will not actually perform
> decryption.  DTCP is governed by a "secret" specification that is managed by
> DTLA (www.dtcp.com) and only member organizations can access the spec and
> produce implementations.  Our solution abstracts the actual DTCP stack via an
> API that is accessed by making function calls to runtime-loaded DSO.  Our
> intention is to provide a solid GStreamer element that becomes functional once
> someone plugs in their proprietary DTCP implementation.  Additionally, our
> element will support pass-thru of packets (with no decryption) for testing
> purposes.
> 
> Part of the feedback we would like to get from the GStreamer developers is
> regarding our design for this "abstraction" and whether or not this sort of
> element would even be accepted by GStreamer.

In general this sounds acceptable (the DTCP element) but of course we'd have to see the implementation first :) Let's talk about that in another bug once you submitted a patch for it.

I tried to issue the HEAD when transitioning from READY to PAUSED but I need info from the HEAD to setup the custom bin.  If I try to delay setting up the bin, I get the following error:
** (gst-launch-1.0:12622): WARNING **: add element stream

I get it when I don't link all elements in a custom bin when the uri is set.  I need to issue a HEAD to get more info and was told not to issue the HEAD until state change from READY to PAUSED.  I need info returned by the HEAD so I think I have to do it when the uri is set.  If I do it there, everything links up otherwise pipeline does not link up.

The "cl-name" property is so that an application can determine if the source is the dlnasrc.  If it wasn't a source, it would be named something like dlnasrc0 and one could easily tell it was dlnasrc.  Is there a more elegant way to do this rather than creating a property?

Can you use gst_element_get_name? http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstElement.html#gst-element-get-name

(In reply to comment #10)
> Can you use gst_element_get_name?
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstElement.html#gst-element-get-name

Unfortunately it gets named by playbin as "source" so gst_element_get_name() just returns "source".

You might be able to use something in GType to do this, like g_type_is_a:

https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#g-type-is-a

For example:

    bool is_dlnasrc = g_type_is_a (G_OBJECT_TYPE (src), G_TYPE_DLNASRC);

That assumes you can #include the header with G_TYPE_DLNASRC though. There's also g_type_name if you can't do that:

https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#g-type-name

This does seem kind of hacky though, so I'm not sure how the GStreamer maintainers will feel about it.

Or you can do:

fact = gst_element_get_factory(elem);
if (fact)
  name = gst_plugin_feature_get_name (GST_PLUGIN_FEATURE(fact));

Or g_type_get_name(G_OBJECT_TYPE (src))... as GST_TYPE_DLNASRC won't be availabel as headers for plugins are not installed.

Is there any other way of controlling how playbin selects the source other than modifying the element rank?  I explored using a virtual protocol such as dlnahttp or dlnahttps. This would require the URI to be specified with "dlnahttp" as the protocol, correct? i.e. "dlnahttp://blah.blah.com/test.mpg"?  I don't think this will work since the dlnasrc needs to handle URIs which are driven by other application layers as will be "http" or "https".  Is there any other options?  Signal handling?

Well, even if you have a signal to select the source (which we don't have), that means you have something else between the upper layer application and playbin? Can't this layer just translate "http:" into "http+dlna:" ?

Or you could have a very-high ranked element that handles http, does autodetection of the actual protocol somehow and then creates the correct element for that.

I think the main problem here is that the DNLA people failed to define a distinctive URI scheme for their protocol and reused and existing one for something different. Same as the DASH/HLS/SmoothStreaming people. Nothing we can change now but it has to be worked around somewhere.

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.

> It doesn't seem to fit the "typefind" paradigm.

Well, it fits the caps negotiation paradigm. If the source already knows the media type of the stream, it should set just the caps, then the typefinding step is bypassed. This is already done in http sources for e.g. application/x-icy and maybe also raw audio samples.

Also see bug #705991 which adds encryption support too, where elements are then autoplugged based on caps.

I tried setting the media type to "application/x-dtcp1" but playback fails with the following error:

0:00:00.244731691 21593 0xb5702180 INFO        GST_ERROR_SYSTEM gstelement.c:1858:gst_element_message_full:<uridecodebin0> posted warning message: No decoder available for type 'application/x-dtcp1'.

It looks like a media type = application/x-icy has a special demuxer based on the following comment in gstsouphttpsrc.c:
"souphttpsrc will output data with a media type of application/x-icy, in which case you will need to use the #ICYDemux element as follow-up element to extract the Icecast metadata and to determine the underlying media type."

I was assuming the dtcp decrypter element would just be a filter hooked up to souphttpsrc with a sink cap of "application/x-dtcp1" and a src cap of "ANY".  But looking closer at icydemux, it appears that it needs to be a "dtcp demux" element instead of just a simple filter.  It needs more logic to handle sticky events, type finding, etc., correct?

No, that shouldn't be the problem. Does your plugin have a rank > 0 ? The "klass" must also container either "Demuxer" or "Parser", probably parser in your case.

I wanted to remove the logic from dlnasrc which determined if the content was encrypted and if it was, added the dtcp decrypter filter to the container "manually".  I thought the preferred way was to do something similar to the way souphttpsrc handles application/x-icy and to have a "dtcp demuxer" type element?

Actually the classification should be Decoder as this "decodes" aka decrypts the stream. If that element (could be basetransform based) has a high enough rank (>= MARGINAL) and accepts the caps, it will be automatically plugged by decodebin.

A demuxer has the special notion that it converts a single stream to multiple streams, which is not the case here. A parser is handled differently in that it is preferred over decoders of the same type, and magic is added in decodebin if it's a parser/converter (e.g. h264parse which can convert to bytestream or avc format). So this here should clearly be a decoder.

OK - it should be a "decoder" rather than a "demuxer".  Does it need to have the type finding and sticky event handling that the icydemuxer does to get around the problem I described in comment #21?

I will modify dtcp filter element to be basetransform based and make it a decoder so it is selected by decodebin via magic.

I modified the dtcp filter element to extend from basetransform.  I added static metadata with "Decoder".  I can build the pipeline manually, but it won't autoplug.  The autoplugging fails with "No decoder available for type 'application/x-dtcp1'.  I also see this error message prior:
Sticky event misordering, got 'caps' before 'stream-start'.  What are the steps to get autoplugging working?  I must be missing something :(.

What's the rank of your element and the classification? Setting caps before stream-start sounds like you manually set the caps in your element instead of letting basetransform handle all that for you.

The rank was none(0). I changed it to GST_RANK_PRIMARY and now I see the element getting initialized but ends up spinning in an endless loop.  This happens right after the "caps before stream-start" error so it must be a side effect of not setting up the caps correctly. 

How do I "let basetransform handle" the caps setting?  I am not setting the caps explicitly although a create static pad templates for both src and sink pads for the element.  Is this correct?

I added a transform_caps() method to my element so now it plugs and I no longer have the recursive loop.  I still have the "caps before stream-start" error.  Any suggestions to where I should look to track that down?

Pretty hard to say, can you post your element somewhere maybe ? Does the dtcp decryptor know about the caps of what will come out? Are you on IRC? You'll probably get a quicker reply on the #gstreamer channel on FreeNode.

Based on discussions on XChat, the consensus was that the dlnasrc should hook up the dtcpip element and not utilize autoplugging.

The dlnasrc needs to serve two roles - one as the source of a gstreamer pipeline and also as a helper element for running within Webkit. Since it needs to support these two usage modes, I am wondering if dlnasrc should be split into two elements or if it is better to have it operate in two modes.  

In the first mode, dlnasrc needs to be a bin which includes souphttpsrc and a decrypter element.

In the second mode, dlnasrc is a "helper/filter/passthru" element where it adds just the decrypter element.  It also needs to receives seek events so it can adjust HTTP GET headers, but not be the source of the pipeline.

I added a "passthru-mode" property which instructs dlnasrc to setup the bin without souphttpsrc but with a sink pad.  So instead of two elements, it has two modes.

Any suggestions of which is the preferred approach?

Also, another direction would be to abandon dlnasrc and just make all modes to souphttpsrc.  This would require souphttpsrc to because a bin.  I was trying to minimize the changes to souphttpsrc but maybe this would be a preferable route.

Correct typos in the above comment::  Also, another direction would be to abandon dlnasrc and just make all modifications to souphttpsrc.  This would require souphttpsrc to become a bin.  I was trying to minimize the changes to souphttpsrc but maybe this would be a preferable route.

Can you put the rationale for not autoplugging the dtcpip element from the IRC discussion here?


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?

Here is the xchat discussion about autopluggin:

[landerson] autoplugging question, I have an element which extends from basetransform I implemented a transformcaps() function because the src caps are application/x-dtcp1 and sink caps are any the element transitions into the paused state fine but when playbin tries to go to playing, it gets stuck in a recursive loop where is creates more and more dtcpip elements.  I think my transformcaps() is doing the right thing when it's call with direction=sink, it returns what is desired on the src which is ANY when its called with direction=src, it returns what is desired on the sink which is application/x-dtcp1.  What could be causing the recursion?
I also get a "got 'caps' before 'stream-start' warning prior to recursion but that would mean the your output caps are the same as your input
[stormer]: I didn't intend that - I want my input caps to be x-dtcp1 and output caps to be ANY.  Did I implement transformcaps() incorrectly?
[stormer]: well, probably not ANY in transform caps, you need fixed caps after that do you really don't know what is encrypted ?  btw, I'm missing a bit of context, x-dtcp1 comes out of dlnasrc directly ?
[landerson]: correct - souphttpsrc is doing http transfer, we're decrypting by stripping off everything and left with the av stream just as if it was not encrypted
[landerson]: y - application/x-dtcp1 is dlna
[stormer]right, make sense, so are you using gst-launch-1.0 ?
[landerson]: I could use the mime type supplied as the media type in caps but I rather have the stream "discovered" just like it is for non-encrypted content
[landerson]: using gstreamer-1.0, both gst-launch-1.0, test program and webkit
[stormer]yes, very often the caps will be generic, unless it's HLS, is that possible to serce HLS from DLNA ?  anyway, what I wanted to say is run with -v, check for dtcpdec.GstPad:src and check the caps
that's the output caps you have negotiated, if they are application/x-dtcp1 it means there a bug in your transform caps
[landerson]: ok - thank you very much. I will look to see what they are.
[stormer]: note, you can easily trace caps using GST_DEBUG_OBJECT (obj, "My Cap are %" GST_PTR_FORMAT, caps)
[landerson]: one last question :) - is it ok for dtcp dec to have input caps of x-dtcp1 and output caps of ANY? Or does it have to be a media type?
[stormer]: yes, it's ok, normally it will instruct decodebin to go into type finding mode
[landerson]: I printed out src & sink pad caps and they are null  when extending from basetransform, where should they be set?  I am trying to mimic what is done in videoconvert & audioconvert but I am missing something
[stormer]: I might have forgotton the context, what is it about ?
[landerson]: from conversation on Friday - I can paste the content if that is the proper "etiquette" for xchat, starts with autoplugging question, I have an element which extends from basetransform
[stormer]:ah right
[landerson]: src & sink pad caps are NULL
[stormer]: did you call gst_element_class_add_pad_template() and stuff, as in the ends it's a element and need similar setup ? like in gst_video_convert_class_init()
[landerson]: yes - created pad templates for both with static caps
[stormer]: also note that there is specialized base transform if you doing only audio or video, GstVideoFilter and GstAudioFilter, I forgot what you where transforming though ... is you plugin built as a shared object ? if so what do you see in gst-inspect, does that looks ok ?
[landerson]: Pad Templates:
SRC template: 'src'
Availability: Always
Capabilities:
ANY
SINK template: 'sink'
Availability: Always
Capabilities:
application/x-dtcp1
it looks like what I want - encrypted content coming in any content coming out.  I'm confused what I need to override from basetransform
looking at the other "normal" transform elements, it looks like they all override "fixate_caps" 
[stormer]yes, because they often want to influence what caps are preferred during fixation for example, videoscale elements might want to prefer the srccaps width&height values.  I think you need only fixate_caps() and transform(), unless the decryption is in-place ? 
[landerson]no transform_caps()? 
[stormer]And in your case, this influence is easy, you always output ANY as a fixed caps 
[landerson]: so you're saying fixate_caps() should always return "ANY", right? Let me check the code 
[stormer]: for fixate I think so yes, dv sound right to you too ? 
[tim]: that doesn't make sense really.  you're doing the opposite of fixating if you return ANY :) 
[stormer]:well, what shall be used for a stream that need to be typefind ? 
[landerson]: it looks like fixate_caps() takes a direction so for sink=application/x-dtcp1 and src=ANY 
[tim]: you can't make decodebin plug additional typefinders.  ANY is not a fixed caps you can set 
[stormer]:how does it work for a source then ? 
[tim]: decodebin will always plug a typefind element after the source.  well, as input.  so it's hardcoded, whcih mean a decrypting element need to be a bin to plug typefinders somehow. You don't need a typefind element to do typefinding but it could be a bin too.
[stormer]landerson is trying to implement a DTCPIP decrypter element, for DLNA, but the decrypted output is of type ANY (we don't know yet), what would you propose ? 
[tim]I guess it depends where in the pipeline it goes, but it sounds like you need to do typefinding unless you get the content type communicated some other way.  
[stormer]short story, you can't really use Basetransform sorry about it being miss-leading 
[tim]I think the plan was a dlnasrc (you'll find that in bugzilla for review), that may produce x-dtcp1 instead of ANY landerson: I think the simpliest would be to hide the decrypter int he dlnasrc src (whic iirc is a bin), and implement the decrypter on top of GstElement, as it does not fit a basetransform baseclass, unless someone has a better idea
[stormer]basically you'd plug the decrypter yourself :-S
[landerson]that was my original approach but i thought it would be better to have it autoplug rather than having dlnasrc hook it up manually 
[stormer]: it's a bit the limit of my knowledge of it, __tim or slomo might be better help if it's about auto-pluggin this ... 
[landerson]: thanks for all the help & I will go with my original approach unless someone suggests something else during the next round of review of the dlnasrc element

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.

(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?

Not sure I agree with the conclusion from that IRC discussion, also didn't sound like it really was a conclusion?

What you probably want is either typefinding inside your decrypter element, or the caps being in the application/x-dtcpip1 caps as another field (that's what is done for cenc), so that your decrypter can add that on the srcpad instead of typefinding.

Autoplugging this should work just fine, as it should for cenc.


Note that for typefinding you don't need the typefind element. There are some helper functions in libgstbase: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/gstreamer-libs-GstTypeFindHelper.html

(In reply to comment #40)
> Not sure I agree with the conclusion from that IRC discussion, also didn't
> sound like it really was a conclusion?
> 
> What you probably want is either typefinding inside your decrypter element, or
> the caps being in the application/x-dtcpip1 caps as another field (that's what
> is done for cenc), so that your decrypter can add that on the srcpad instead of
> typefinding.
> 
> Autoplugging this should work just fine, as it should for cenc.
> 
> 
> Note that for typefinding you don't need the typefind element. There are some
> helper functions in libgstbase:
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/gstreamer-libs-GstTypeFindHelper.html

Agreed - I left it open for additional feedback.  Sounds like you have an approach that might work.  I will investigate that.

(In reply to comment #39)
> That sounds like it should be different elements. But why can't webkit create
> dlnasrc, and that then creates webkitwebsrc instead of souphttpsrc internally?

This made me think of another option: dlnasrc could have a "source" property (like playbin). If it's not set, the dlnasrc creates a souphttpsrc. If it is set, the dlnasrc uses whatever it is. Would that work?

(In reply to comment #42)
> (In reply to comment #39)
> > That sounds like it should be different elements. But why can't webkit create
> > dlnasrc, and that then creates webkitwebsrc instead of souphttpsrc internally?
> 
> This made me think of another option: dlnasrc could have a "source" property
> (like playbin). If it's not set, the dlnasrc creates a souphttpsrc. If it is
> set, the dlnasrc uses whatever it is. Would that work?

Sure, but why not just gst_element_make_from_uri()?

(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?  

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.

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

How receptive would GStreamer be to have dlnasrc have a very high rank so that souphttpsrc is never autoplugged?  It seems like the virtual protocol is the preferred option.

IMO the virtual protocol, but that's just my opinion. Like you don't want to autoplug rtspsrc for HTTP URIs just because it might be RTSP over HTTP... just that for RTSP they were clever enough to define a new URI scheme (rtsph).

The reason I thought it might be good to make souphttpsrc do this is that DLNA's protocol is a superset of HTTP (I think?), so we should be able to connect to DLNA servers as a normal HTTP client, then switch to DLNA-mode if we detect that the server supports it. I think the main differences are that there are extra headers and that the content might be encrypted.

Here's the approach I'm proposing:

1. dlnasrc will use a virtual protocol: "dlna+http & dlna+https".
This will require applications to be aware they want dlna support and they will need to prepend "dlna" to uri.  This allows souphttpsrc to be the source for "normal" http".  WebKit's GStreamer media player will need to prepend "dlna" to URI.

2. dlnasrc will strip off "dlna" from protocol and select the source to use via the gst_element_make_from_uri().  When running within webkit, this will select  webkitwebsrc and when running outside, it will select souphttpsrc.

3. webkitwebsrc will need to have an "extra-headers" property so dlnasrc can add the additional dlna headers to the HTTP GET request similar to what is done with souphttpsrc.

With this approach, there is no need for dlnasrc to be two elements or operate in two modes.

What do you guys think of this approach?

Adding support to souphttpsrc would be better than making dlnasrc highest ranked HTTP element in any case (and what do we do when someone invents yet another HTTP protocol that doesn't get a new URI scheme?)... however are you going to add every single protocol out there that is on top of HTTP to souphttpsrc? I think this solution also does not scale and is rather ugly

(In reply to comment #49)
> Here's the approach I'm proposing:
> 
> [...]
> 
> What do you guys think of this approach?

Sounds like a good plan IMHO

What are you going to do for the DRM part?

(In reply to comment #48)
> The reason I thought it might be good to make souphttpsrc do this is that
> DLNA's protocol is a superset of HTTP (I think?), so we should be able to
> connect to DLNA servers as a normal HTTP client, then switch to DLNA-mode if we
> detect that the server supports it. I think the main differences are that there
> are extra headers and that the content might be encrypted.

If we follow the approach I outlined, dlnasrc will only be in "DLNA-mode" (include dlna type headers) if the server supports them. If there is no dlna support on the server, souphttpsrc or webkitwebsrc will operate like a "normal" HTTP client.

(In reply to comment #52)
> What are you going to do for the DRM part?

I will explore the suggestion you made in Comment #40 after I get the approach I outline in Comment #49 working.

Another option is to modify decodebin to just put a typefind element whenever it doesn't have caps.

As discussed on IRC a long time ago, comment 55 is not feasible. And the solution should be that the typefinding should happen inside the element.

I suspect that I'll end up finishing this, but I'm not sure at the moment. I hope to have a better idea by the end of the week. Sorry about the communication delays.

(In reply to comment #49)
> 1. dlnasrc will use a virtual protocol: "dlna+http & dlna+https".
> This will require applications to be aware they want dlna support and they will
> need to prepend "dlna" to uri.  This allows souphttpsrc to be the source for
> "normal" http".  WebKit's GStreamer media player will need to prepend "dlna" to
> URI.


So how should playbin-using apps figure out if they can use "dlna+" uris or not?

Checking for a specific elements availablility with gst_element_factory_find() or something sounds wrong... Trying with a "dlna+" prepended uri and if that does not work, retrying with an unmodified uri maybe?

(In reply to comment #58)
> (In reply to comment #49)
> > 1. dlnasrc will use a virtual protocol: "dlna+http & dlna+https".
> > This will require applications to be aware they want dlna support and they will
> > need to prepend "dlna" to uri.  This allows souphttpsrc to be the source for
> > "normal" http".  WebKit's GStreamer media player will need to prepend "dlna" to
> > URI.
> 
> 
> So how should playbin-using apps figure out if they can use "dlna+" uris or
> not?
> 
> Checking for a specific elements availablility with gst_element_factory_find()
> or something sounds wrong... Trying with a "dlna+" prepended uri and if that
> does not work, retrying with an unmodified uri maybe?

For example, or gst_element_make_from_uri() or checking with the other elementfactory API.

Brandon, Lori, any plans of getting code and updates on this ?

I don't really plan to work on this anymore.

I would potentially have interest in such a thing, but didn't we discuss on GUADEC 2017 that the approach needs to be different? Unfortunately I never got the project to work on it, though

Yes, the approach should be unified with the existing HTTP elements.

I'm going to close this due to lack of activity for the past 5 years and no supporter of the code. We know about the issue (and code) and will tackle it once someone has time.