7787 2015-05-18 22:38:35 +0000 media player (gtk-play) doesn't work with any QEMU target 2015-10-27 11:44:10 +0000 1 1 7 Build System, Metadata & Runtime OE-Core multimedia unspecified x86 Multiple VERIFIED FIXED Medium+ normal 2.0 1 gary alex.kanavin bogdanx.a.voiculescu meta.mr.watcher meta.watcher randy.macleod ross.burton bogdanx.a.voiculescu --- --- Don't know oldest_to_newest 51107 0 gary 2015-05-18 22:38:35 +0000 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 51109 1 gary 2015-05-18 22:41:58 +0000 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 52551 2 ross.burton 2015-07-23 10:56:12 +0000 GStreamer probably thinks "I'll use GL" and that just fails miserably as it's old-school software GL. Can we make this M3? 52621 3 ross.burton 2015-07-27 12:39:25 +0000 Presumably this is just video and audio plays? 52622 4 gary 2015-07-27 12:46:32 +0000 (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. 54543 5 alex.kanavin 2015-09-23 14:38:06 +0000 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? 54546 6 ross.burton 2015-09-23 14:47:10 +0000 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. 54547 7 gary 2015-09-23 14:50:58 +0000 (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 54548 8 alex.kanavin 2015-09-23 15:02:21 +0000 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? 54554 9 alex.kanavin 2015-09-23 15:28:53 +0000 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. 54555 10 ross.burton 2015-09-23 15:30:38 +0000 I wonder if there's any virtual graphics drivers that support xv... 54556 11 alex.kanavin 2015-09-23 15:34:37 +0000 So is it possible to remove opengl from gstreamer's PACKAGECONFIG, but on qemu images only? 54559 12 ross.burton 2015-09-23 15:43:23 +0000 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. 54561 13 alex.kanavin 2015-09-23 15:53:00 +0000 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. 54570 14 alex.kanavin 2015-09-23 16:45:55 +0000 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. 54572 15 gary 2015-09-23 16:51:28 +0000 (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? 54577 16 ross.burton 2015-09-23 19:04:21 +0000 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. 54603 17 alex.kanavin 2015-09-24 11:00:59 +0000 Yeah, but I had in mind those who use hardware GL. They will be affected too, no? 54604 18 ross.burton 2015-09-24 11:06:21 +0000 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. 54618 19 alex.kanavin 2015-09-24 14:12:30 +0000 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. 54647 20 alex.kanavin 2015-09-24 17:42:56 +0000 Patch submitted: http://lists.openembedded.org/pipermail/openembedded-core/2015-September/110947.html 54783 21 ross.burton 2015-09-29 12:23:53 +0000 Merged in oe-core ab1bb8db62df4246c2ed3a3135d6d71003ee9386. 55812 22 bogdanx.a.voiculescu 2015-10-27 11:44:10 +0000 Verified on master 8a0d8eee432924433c3e70198aaeab3161476c5f. Player barely works with the provided 1080p video - but it works. So there are performance issues with default settings.