I see this error in stderr for a bunch of tests on the GTK release bot: The glvideoflip GStreamer element isn't available. Video mirroring and rotation functionalities are thus disabled. That's a WebKit bug since the glvideoflip GStreamer element needs to be either built in our JHBuild environment or installed by install-dependencies. What's supposed to be pulling it in?
(In reply to Michael Catanzaro from comment #0) > I see this error in stderr for a bunch of tests on the GTK release bot: > > The glvideoflip GStreamer element isn't available. Video mirroring and > rotation functionalities are thus disabled. > > That's a WebKit bug since the glvideoflip GStreamer element needs to be > either built in our JHBuild environment or installed by > install-dependencies. What's supposed to be pulling it in? You need to have graphene installed when building gstreamer*, so the glvideoflip automatically gets built. graphene is still not available on debian stretch, its on testing. I have been told this warning is harmless and you are safe to ignore it (unless you care about video mirroring/rotation functionalities of course)
It's cluttering our layout test results, which is not acceptable. I think we'll need to add graphene to our JHBuild environment, and have the right GStreamer plugins package (-base? -good? -bad?) depend on it.
(In reply to Michael Catanzaro from comment #2) > It's cluttering our layout test results, which is not acceptable. > > I think we'll need to add graphene to our JHBuild environment, and have the > right GStreamer plugins package (-base? -good? -bad?) depend on it. bad.
FYI, this warning is not WebKit output but IIRC OpenWebRTC one.
Created attachment 319180 [details] Patch
There's still a huge number of tests with stderr output, but this cuts fixes ~15 or so.
Comment on attachment 319180 [details] Patch I think that instead of doing this, we can add a patch for openwebrtc on the jhbuild recipe that comments out the warning (its at local/owr_video_renderer.c). That way we keep the jhbuild smaller and quicker to build.
graphene and meson take almost no time to build since they're small and don't use Autotools! A patch would work too, but I have a suspicion that openwebrtc would not be complaining about the missing element if it were not important for WebRTC.
(In reply to Michael Catanzaro from comment #8) > graphene and meson take almost no time to build since they're small and > don't use Autotools! > Ok. Can you at least add a <pkg-config> entry to avoid building graphene when the developer already installed it from the distro? > A patch would work too, but I have a suspicion that openwebrtc would not be > complaining about the missing element if it were not important for WebRTC. Then I hope to see some new test passing after this lands like webrtc/video-rotation.html :)
(In reply to Carlos Alberto Lopez Perez from comment #9) > Ok. > > Can you at least add a <pkg-config> entry to avoid building graphene when > the developer already installed it from the distro? No, because graphene depends on glib, and glib is in our jhbuild environment. The system version of graphene could easily require newer symbols than are provided by our glib.
(In reply to Michael Catanzaro from comment #10) > (In reply to Carlos Alberto Lopez Perez from comment #9) > > Ok. > > > > Can you at least add a <pkg-config> entry to avoid building graphene when > > the developer already installed it from the distro? > > No, because graphene depends on glib, and glib is in our jhbuild > environment. The system version of graphene could easily require newer > symbols than are provided by our glib. Mmm..... good point.
Comment on attachment 319180 [details] Patch Please watch the bots after landing for possible breakages.
OK, I'll watch.
Committed r221284: <http://trac.webkit.org/changeset/221284>
Unfortunately release bot has died for unrelated reasons, and all other GTK test bots are behind. The GTK buildbots are fine and the WPE bots are fine. I think it was a low-risk change, though.
(In reply to Michael Catanzaro from comment #8) > A patch would work too, but I have a suspicion that openwebrtc would not be > complaining about the missing element if it were not important for WebRTC. If it's the code I wrote and I think it is, the only thing is that some screen video flip won't work. Summing up, its importance is very relative.