Try to run gtk-play on any QEMU target - result is a blank window. Obviously the player thinks something is happening as the "progress bar" moves, but there is no video. To duplicate, build core-image-sato for any QEMU target with these [additional] settings: CORE_IMAGE_EXTRA_INSTALL = "rsync gstreamer1.0-libav" LICENSE_FLAGS_WHITELIST ?= "commercial_gstreamer1.0-libav \ commercial_libav \ " Tested against Poky/Yocto master rev fab7da4f8030a4067db0522f77eaa6d3b501c68f
Note: the extra settings allow easy import of video files, along with settings to be able to play .mp4 files such as: https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
GStreamer probably thinks "I'll use GL" and that just fails miserably as it's old-school software GL. Can we make this M3?
Presumably this is just video and audio plays?
(In reply to comment #3) > Presumably this is just video and audio plays? Correct, just trying to play any audio+video (mostly interested in video as audio may not be available in qemu). Any video file would do, the setup above is just to allow use of .mp4 video files.
Gstreamer defaults to GL sink - if you use a different sink, e.g. this: gst-play-1.0 --videosink ximagesink sintel_trailer-1080p.mp4 then video displays fine. Is GL sink supposed to work in QEMU, or should we find out how to make something else the default?
GL is *meant* to work in qemu using the software renderer, but we don't use the LLVM-based software renderer yet so we need a way of forcing it to use something else.
(In reply to comment #6) > GL is *meant* to work in qemu using the software renderer, but we don't use > the LLVM-based software renderer yet so we need a way of forcing it to use > something else. The point of the bug is that a user who tries to use gtk-play via the GUI won't have this kind of control and he's left with no video whatsoever. So I would say that yes you either need to change the default or I would think it better to have the current default be functional in QEMU
At build time, gstreamer1.0-plugins-bad.inc enables or disables opengl depending on whether opengl is in DISTRO_FEATURES. At run time, I don't think you can disable a gstreamer plugin that is already installed on the target (through a config file or environment variable), but not 100% certain here. Ideas?
A related issue is that typically gstreamer installations use xvimagesink for rendering video (because it has a higher rank than other video sinks), but in qemu sato image it doesn't work: "No Xv port available". Still unsure how to proceed.
I wonder if there's any virtual graphics drivers that support xv...
So is it possible to remove opengl from gstreamer's PACKAGECONFIG, but on qemu images only?
Not without making gstreamer machine-specific. https://bugzilla.gnome.org/show_bug.cgi?id=751684 is relevant and has a draft (doesn't compile) patch that makes glsink refuse to work on software renderers.
Until that patch shows up in upstream, we can unconditionally downrank glimagesink so that ximagesink always comes up first. If someone wants GL rendering, they would have to hardcode the sink name into where the pipeline is formed.
I'm a bit reluctant to fix it that way, because there may be OE users out there who rely on GL being the default without being explicit about it (when Xv is not available), and things will suddenly break/change for them.
(In reply to comment #14) > I'm a bit reluctant to fix it that way, because there may be OE users out > there who rely on GL being the default without being explicit about it (when > Xv is not available), and things will suddenly break/change for them. Why not make such a change QEMU [target] dependent, then it won't affect those users?
Nobody in their right mind is relying the software renderer in Mesa, as this bug demonstrates it's utterly broken. Clutter can't start up against it either, pretty much the only app that works fine is glxgears.
Yeah, but I had in mind those who use hardware GL. They will be affected too, no?
The gstreamer patch checked that the GL implementation didn't declare itself a software renderer, so if you have proper drivers the gl sink still works.
Yeah, but that patch is incomplete and doesn't compile, and work on it seems to have stalled. Let's just downgrade the GL sink unconditionally, I'll be submitting that to ML shortly.
Patch submitted: http://lists.openembedded.org/pipermail/openembedded-core/2015-September/110947.html
Merged in oe-core ab1bb8db62df4246c2ed3a3135d6d71003ee9386.
Verified on master 8a0d8eee432924433c3e70198aaeab3161476c5f. Player barely works with the provided 1080p video - but it works. So there are performance issues with default settings.