GNOME Bugzilla – Bug 678546
hlsdemux: supply a more useful user-agent
Last modified: 2018-11-03 13:12:27 UTC
The hlsdemux component use the default uri handler to fetch the required resources. When this is HTTP(s) based, it talks to a remote server and exchanges a user-agent that the remote server can use to log the client type and serve specific content to work around known implementation bugs, etc. A simple "gst-launch playbin uri=xxx" playback on my system reports the user-agent: GStreamer souphttpsrc libsoup/2.38.1 Compared to CoreMedia based players this is rather uninformative, where a sample agent is: AppleCoreMedia/1.0.0.11E53 (Macintosh; U; Intel Mac OS X 10_7_4; en_us) I suggest to construct a slightly more informative user-agent, like: GStreamer/1.0.0 hlsdemux/0.11.92.1 libsoup/2.38.1 In order to do this reliably (since there is no standardised user-agent get/set interface) I suggest to always try to use the "souphttpsrc" plugin to fetch the required files, and only use the default uri handler when it fails. I will attach patches with both features,
Created attachment 216928 [details] [review] hlsdemux: fetch uri's with souphttpsrc whenever possible
Created attachment 216929 [details] [review] hlsdemux: try to set a user-agent
Instead of relying on souphttpsrc you could as well check if the element has an "user-agent" property which takes string arguments. See element_has_property() in gst-plugins-base/gst/playback/gstplaysink.c for example.
(In reply to comment #3) > Instead of relying on souphttpsrc you could as well check if the element has an > "user-agent" property which takes string arguments. See element_has_property() > in gst-plugins-base/gst/playback/gstplaysink.c for example. I considered this but I think this is risky since it makes assumptions about the functionality of potentially unknown modules. I don't see a way that we can guarantee that a "user-agent" property works as expected. The souphttpsrc property is already a bit wonky since it interprets a trailing space character in the agent to mean that it should insert an extra string at the end with the libsoup version. Basing the fetching around a known module also opens up further possibilities, like specifying the cookies and auth headers, or possibly a custom timeout value which might be useful.
(In reply to comment #4) > (In reply to comment #3) > > Instead of relying on souphttpsrc you could as well check if the element has an > > "user-agent" property which takes string arguments. See element_has_property() > > in gst-plugins-base/gst/playback/gstplaysink.c for example. > > I considered this but I think this is risky since it makes assumptions about > the functionality of potentially unknown modules. I don't see a way that we can > guarantee that a "user-agent" property works as expected. The souphttpsrc > property is already a bit wonky since it interprets a trailing space character > in the agent to mean that it should insert an extra string at the end with the > libsoup version. While this is potentially true, we're doing the same in other elements too already. This is a bit like an implicit interface and other, new elements (if automatically used) should if possible mimic the behaviour and interface of existing elements. (This thing about the extra space is interesting though, doesn't really make sense, does it? :) ) > Basing the fetching around a known module also opens up further possibilities, > like specifying the cookies and auth headers, or possibly a custom timeout > value which might be useful. Same as above, any new http source should just do the same as souphttpsrc if it wants to work as good.
Any updates?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/74.