GNOME Bugzilla – Bug 751372
adaptivedemux: set user-agent and cookie to download the fragments
Last modified: 2017-12-07 08:18:39 UTC
Because the http src element in hlsdemux is not set the cookie and user-agent like upstream src element, forbidden(403) error is occurred when it try to download the data fragments. In some cases, user-agent and cookie is needed to set to connect the http server. < How to test > with browser application on PC, myspace.com -> Videos -> select one vod and get m3u8 url from code try to play the VOD with gst-launch # gst-launch-1.0 playbin uri="copied vod url(m3u8)" --> forbidden error is occurred when it try to download fragment in souphttpsrc in hlsdemux.
Created attachment 305911 [details] [review] adaptivedemux: set user-agent and cookie to download fragment data I make a patch to set user-agent and cookie to download fragment. When I did the test with below bug patch, gst-launch can play the VOD in myspace.com. - related bug item of souphttpsrc for handling query https://bugzilla.gnome.org/show_bug.cgi?id=751371
Created attachment 307357 [details] [review] adaptivedemux: set user-agent and cookie I uploaded new patch to get user-agent and cookie info from custom downstream event of souphttpsrc.
This patch changes the API of gsturidownloader (in gst-plugins-bad/gst-libs/gst/uridownloader/). Not sure if this means it needs to wait until 1.6. Any of the maintainers would be able to answer this.
(In reply to Luis de Bethencourt from comment #3) > This patch changes the API of gsturidownloader (in > gst-plugins-bad/gst-libs/gst/uridownloader/). Not sure if this means it > needs to wait until 1.6. > > Any of the maintainers would be able to answer this. Not sure if we want to change this API again, how about going with gst_uri_downloader_fetch_uri_full? Another approach is to have those as properties of the uridownloder and they would be used on every request from that object.
IMHO we can change that API as much as we want, I wouldn't consider it as public API and we don't even ship the headers and stuff in cerbero for it either.
(In reply to Sebastian Dröge (slomo) from comment #5) > IMHO we can change that API as much as we want, I wouldn't consider it as > public API and we don't even ship the headers and stuff in cerbero for it > either. Ok, but in any case I think cookies and user-agent should be a persistent property across downloads. Having a gst_uri_downloader_set_user_agent and set_cookies seem to make more sense to me. Eunhae, how do you get the cookies that you want to set on the uridownloader?
(In reply to Thiago Sousa Santos from comment #6) > Eunhae, how do you get the cookies that you want to set on the uridownloader? It will be included in the response-header(Set-Cookie filed). adaptivedemux can get the cookie by parsing the sticky event with http header which is sent by souphttpsrc.
It seems that this server lifted the cookies restriction. I seem to be able to play all the videos with current master. Any other test urls available?
See bug #780140 for a way of sharing the cookies (in-memory) inside the same pipeline. Does that solve your problems? Also why do you need to set the user-agent the same way as upstream, and why is it not the same anyway (the default setting)? :)
(In reply to Sebastian Dröge (slomo) from comment #9) > See bug #780140 for a way of sharing the cookies (in-memory) inside the same > pipeline. Does that solve your problems? > > Also why do you need to set the user-agent the same way as upstream, and why > is it not the same anyway (the default setting)? :) I think the bug #780140 can be a solution. However the issue state is reopen at the moment and I can not find the souphttpsrc patches at latest release (1.12.3). Can I take it at downstream without additional consideration?
See the later comments in that bug, you need to apply some patches to libsoup to prevent a thread-safety issue there
*** This bug has been marked as a duplicate of bug 780140 ***