souphttpsrc is able to share its session using GstContext nowadays. This is useful for session data (cookies, etc) reuse by adaptive streaming downloaders. Not sure we correctly handle this yet...
This is not possible. souphttpsrc is used for HLS and other things from the web process, while the soup session is in the network process
(In reply to Carlos Garcia Campos from comment #1) > This is not possible. souphttpsrc is used for HLS and other things from the > web process, while the soup session is in the network process Sure, but nothing prevents the player to forge a SoupSession upon request.
(In reply to Carlos Garcia Campos from comment #1) > This is not possible. souphttpsrc is used for HLS and other things from the > web process Obligatory reminder that this will break when we sandbox the web process so that it doesn't have network access anymore (which is important)
(In reply to Michael Catanzaro from comment #3) > (In reply to Carlos Garcia Campos from comment #1) > > This is not possible. souphttpsrc is used for HLS and other things from the > > web process > > Obligatory reminder that this will break when we sandbox the web process so > that it doesn't have network access anymore (which is important) Then the webkit+http URI hack should be reverted.
(In reply to Philippe Normand from comment #4) > (In reply to Michael Catanzaro from comment #3) > > (In reply to Carlos Garcia Campos from comment #1) > > > This is not possible. souphttpsrc is used for HLS and other things from the > > > web process > > > > Obligatory reminder that this will break when we sandbox the web process so > > that it doesn't have network access anymore (which is important) > > Then the webkit+http URI hack should be reverted. That will not help. Even when we downloaded the HLS stuff with our src element, we did that in the web process. We need a media player associated to the src element for requests to be sent to the network process.
(In reply to Carlos Garcia Campos from comment #5) > (In reply to Philippe Normand from comment #4) > > (In reply to Michael Catanzaro from comment #3) > > > (In reply to Carlos Garcia Campos from comment #1) > > > > This is not possible. souphttpsrc is used for HLS and other things from the > > > > web process > > > > > > Obligatory reminder that this will break when we sandbox the web process so > > > that it doesn't have network access anymore (which is important) > > > > Then the webkit+http URI hack should be reverted. > > That will not help. Even when we downloaded the HLS stuff with our src > element, we did that in the web process. We need a media player associated > to the src element for requests to be sent to the network process. by media player you mean MediaPlayer*? If so that can be wrapped in a GstContext that the element would query from upstream elements.
Created attachment 331615 [details] Patch
Not asking review because the patch requires a bump to unreleased GStreamer 1.14 anyway.
Created attachment 331617 [details] Patch
Comment on attachment 331617 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=331617&action=review > Source/WebCore/ChangeLog:16 > + Note: This will break again whenever the web process gets > + sandboxed. When that happens we should use the webkit http src > + element for all network requests again. That means removing the > + webkit+http URL hack from the player and http src element. The web process sandbox is a short-term goal; if all goes according to plan (which never happens) I hope to have it ready in time for the 2.22 release. So I wonder if it makes sense to do this... is this really movement in the right direction?
(In reply to Michael Catanzaro from comment #10) > Comment on attachment 331617 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=331617&action=review > > > Source/WebCore/ChangeLog:16 > > + Note: This will break again whenever the web process gets > > + sandboxed. When that happens we should use the webkit http src > > + element for all network requests again. That means removing the > > + webkit+http URL hack from the player and http src element. > > The web process sandbox is a short-term goal; if all goes according to plan > (which never happens) I hope to have it ready in time for the 2.22 release. > So I wonder if it makes sense to do this... is this really movement in the > right direction? What do you mean by "this"? AFAIU when sandboxing is enabled the web process will no longer have network access, so that means the souphttpsrc element used by GStreamer's adaptivedemux to download HLS fragments will no longer work. They way to fix it would be to undo the webkit+http hacks mentioned above so that the network process is used to download fragments. I have a proof-of-concept patch which: 1. reverts the hack 2. enable MediaPlayer sharing between multiple webkitwebsrc elements so that the HTTP session data can be reused.
*** This bug has been marked as a duplicate of bug 189967 ***