My guess is that there's no installer installed in the bots and gst_install_plugins_supported() returns false, so we don't even get a permission request because no installer will be launched.
Skipped for now in r188205.
Carlos Lopez, I think we need gstreamer1.0-packagekit on the bots?
So I tried hooking up missing media plugin permission requests in Epiphany the other day. I tested various websites but never saw a request. I also the exact same page that is used by this test: <html><body><video src=\"test.mp4\" autoplay></video></body></html> with some test.mp4 file in the same directory. But WebKit never creates a permission request. It doesn't work in MiniBrowser either. I think it's broken, and we never noticed because this test has always been skipped. Missing codec notifications are working just fine for me in e.g. Totem.
(In reply to comment #3) > the other day. Er, a strange expression to use for "just now"
Because we now white-list supported codecs based on what's installed, because that's what you wanted :)
(In reply to comment #5) > Because we now white-list supported codecs based on what's installed, > because that's what you wanted :) See bug 135972
So how is this supposed to work?
I'm afraid you won't trick the gst codec installer unless our player has video/mp4 in the mime-type cache it builds.
(In reply to comment #8) > I'm afraid you won't trick the gst codec installer unless our player has > video/mp4 in the mime-type cache it builds. So it seems like our options are: * Deprecate this API, because it can never work * Decide that YouTube is broken (is it?) and convince YouTube engineers to fix it so that we can bring back the codec installer Is this right? Is there another option? I don't want to break YouTube under any circumstances.
I'm not sure what to do... On the end-user POV I think I'd like this to work: 1. user opens youtube video in Epiphany 2. a prompt appears asking permission to install H264 codec 3.a user accepts, codec is installed, playback starts 3.b user refuses, the decision about refusing H264 is stored somewhere on-disk, the webm version of the video starts to play
(In reply to comment #10) > I'm not sure what to do... > > On the end-user POV I think I'd like this to work: I agree on that desired behavior, but it seems like we don't know how to make it possible.
Can you check that adding video/mp4 in mime-type set at least triggers the codec installer?
(In reply to comment #12) > Can you check that adding video/mp4 in mime-type set at least triggers the > codec installer? Unfortunately that does not trigger the codec installer (tested Vimeo, the test page in comment #3, Epiphany and MiniBrowser).html><body><video src=\"test.mp4\" autoplay></video></body></html>
Seems like an issue with our jhbuild (as usual). Try this: export GST_INSTALL_PLUGINS_HELPER=$PWD/gst-codec-install-helper.sh and in gst-codec-install-helper.sh: #!/bin/sh echo "Installation of gst plugin requested..." echo $@ exit 0 (make it executable of course :)) Then try to load a mp4 video after making sure video/mp4 is in the mime-type set and you'll see MiniBrowser showing the permission request.
I don't think the API is broken. We should (partly at least) revert the changes made to the player. If video/mp4 isn't in the supported mime-types list there is no chance the codec installer fires up when a h264 video is being loaded. Then some investigation is needed to know what to do when the user refuses to install a codec. In that case the player should likely fire a load error so that the next <source> element is probed.
(In reply to comment #15) > We should (partly at least) revert the changes made to the player. If > video/mp4 isn't in the supported mime-types list there is no chance the > codec installer fires up when a h264 video is being loaded. Do you know how to do it without breaking YouTube? YouTube is more important than this API. Ideally the behavior would be something along the lines of: * Try H.264, see it's not supported by the client * Fallback to WebM if supported by the server * Run codec installer only server does not have WebM available
(In reply to comment #16) > (In reply to comment #15) > > We should (partly at least) revert the changes made to the player. If > > video/mp4 isn't in the supported mime-types list there is no chance the > > codec installer fires up when a h264 video is being loaded. > > Do you know how to do it without breaking YouTube? YouTube is more important > than this API. > > Ideally the behavior would be something along the lines of: > > * Try H.264, see it's not supported by the client > * Fallback to WebM if supported by the server > * Run codec installer only server does not have WebM available I don't see how that would work. What's wrong with the proposal in comment 10 ?
(In reply to comment #17) > I don't see how that would work. What's wrong with the proposal in comment > 10 ? Hm, I didn't read it properly the first time, sorry. The problem is we should only show "additional media codecs are required" if they are really actually required. If a WebM version of the video is available, we need to try playing it *before* giving up and saying it cannot be played with currently-available codecs, right? I think getting that right so we have a seamless user experience on YouTube is more important than having support for installing missing codecs, though of course I'd like to be able to do both.
Hey Charlie, do you think our install missing media codecs API is fixable? If not, we will have to deprecate it. That would be a shame as this is an important feature that is not currently functional, but we really can't have missing codec prompts appearing for regular YouTube videos.
I started looking at this, but it seems like a default build of webkit has a gstreamer with mp4 support. Is there a way to turn that off or another format that would allow me to reproduce this bug?
(In reply to Ms2ger from comment #20) > I started looking at this, but it seems like a default build of webkit has a > gstreamer with mp4 support. Is there a way to turn that off or another > format that would allow me to reproduce this bug? You can temporarily move the plugin file away for instance.
So, probably now would be a good time to decide how to handle this: (In reply to Michael Catanzaro from comment #19) > do you think our install missing media codecs API is fixable? > If not, we will have to deprecate it. That would be a shame as this is an > important feature that is not currently functional, but we really can't have > missing codec prompts appearing for regular YouTube videos. (In reply to Michael Catanzaro from comment #18) > The problem is we > should only show "additional media codecs are required" if they are really > actually required. If a WebM version of the video is available, we need to > try playing it *before* giving up and saying it cannot be played with > currently-available codecs, right? I think getting that right so we have a > seamless user experience on YouTube is more important than having support > for installing missing codecs, though of course I'd like to be able to do > both.
And what if the user had no VPX codec installed? You can't work around the codec installer. I already suggested a solution in comment 10. Please read it again.
(In reply to Philippe Normand from comment #23) > And what if the user had no VPX codec installed? The desired behavior would be to run the missing codec installer if and only if no suitable codecs to play the video are installed. > You can't work around the codec installer. I already suggested a solution in > comment 10. Please read it again. If that's the best we can do, then OK. It'll be fine so long as the decision about refusing H264 is stored somewhere on disk, so the prompt only occurs once per missing codec, and not again and again. Where would you store it, and will that be the responsibility of WebKit or Epiphany?
(In reply to Michael Catanzaro from comment #24) > (In reply to Philippe Normand from comment #23) > > And what if the user had no VPX codec installed? > > The desired behavior would be to run the missing codec installer if and only > if no suitable codecs to play the video are installed. > > > You can't work around the codec installer. I already suggested a solution in > > comment 10. Please read it again. > > If that's the best we can do, then OK. It'll be fine so long as the decision > about refusing H264 is stored somewhere on disk, so the prompt only occurs > once per missing codec, and not again and again. Where would you store it, > and will that be the responsibility of WebKit or Epiphany? WebKit could notify the app with a signal that the required codec installation was denied and Epiphany could store the result in a cache file perhaps.
(In reply to Philippe Normand from comment #25) > WebKit could notify the app with a signal that the required codec > installation was denied and Epiphany could store the result in a cache file > perhaps. What would the WebKit API look like? Epiphany already has a permissions request cache (EphyPermissionsManager), but it's keyed on the website's security origin (protocol, host, and port). This storage would need to be keyed on the codec instead, so we would not be able to use EphyPermissionsManager for this.
Note I have WIP code for this at https://git.gnome.org/browse/epiphany/log/?h=wip/missing-codecs
Phil's proposal still seems like the best path forward. We just need to know what the new API would look like.
Since this has been broken for seven years, and there are no plans to fix it, we should remove it in bug #239132.