gstreamer-vaapi has stopped playing back h/w accelerated video on Wayland 1.2. At this point, it's not known where the regression has occurred-- I assume it's either gstreamer-vaapi or intel-driver. Analysis/bisect will take some time, insights or ideas are always welcome. SETUP: * Build wayland 1.2, libva, intel-driver, gstreamer's 1.0 branch, and gstreamer-vaapi * Test video: - http://www.sintel.org/download - Download the HD 1080 mkv-- for testing, I re-muxed the video stream into an MP4 container without transcode, and has been working fine for months * Kill all Xorg servers, or boot to 'runlevel 3', text mode * Set LIBVA_DRIVERS_PATH if necessary * Set LD_LIBRARY_PATH if necessary * For my setup, /wld/install is the wayland stack sandbox, and is reflected at build time - --prefix=/wld/install * Run `vainfo`, make sure output is sane REPRODUCE: * Launch weston kms - weston-launch -- -i0 - the arguments will prevent display from sleeping * gst-launch-1.0 filesrc location=Sintel.2010.1080p.mp4 ! \ qtdemux ! vaapidecode ! vaapisink EXPECTED: The video plays back in a window-- this pipeline has worked for months. If using a software decode pipeline, it plays back. ACTUAL: gst-launch exits without ever playing the video or displaying a single frame of the video, no errors reported. STDOUT: libva info: VA-API version 0.34.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /wld/install/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_34 libva info: va_openDriver() returns 0 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... /GstPipeline:pipeline0/GstVaapiDecode:vaapidecode0.GstPad:sink: caps = video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)4.1, profile=(string)high, codec_data=(buffer)01640029ffe1001e67640029acc8601e01a7e226a04040280000030008000003018478c18cd001000668e97b132130, width=(int)1920, height=(int)818, framerate=(fraction)500/21, pixel-aspect-ratio=(fraction)1/1 /GstPipeline:pipeline0/GstVaapiDecode:vaapidecode0.GstPad:src: caps = video/x-surface, type=(string)vaapi, opengl=(boolean)true, width=(int)1920, height=(int)832, framerate=(fraction)500/21, pixel-aspect-ratio=(fraction)1/1 /GstPipeline:pipeline0/GstVaapiSink:vaapisink0.GstPad:sink: caps = video/x-surface, type=(string)vaapi, opengl=(boolean)true, width=(int)1920, height=(int)832, framerate=(fraction)500/21, pixel-aspect-ratio=(fraction)1/1 /GstPipeline:pipeline0/GstVaapiDecode:vaapidecode0.GstPad:src: caps = video/x-surface, type=(string)vaapi, opengl=(boolean)true, width=(int)1920, height=(int)832, framerate=(fraction)500/21, pixel-aspect-ratio=(fraction)1/1 /GstPipeline:pipeline0/GstVaapiSink:vaapisink0.GstPad:sink: caps = video/x-surface, type=(string)vaapi, opengl=(boolean)true, width=(int)1920, height=(int)832, framerate=(fraction)500/21, pixel-aspect-ratio=(fraction)1/1 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 83922369 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... SOFTWARE STACK (select): wayland (master) 1.2.0-0-g6ef06ad weston (master) 1.2.0-0-ga684b5a drm (master) heads/master-0-gfea5408 mesa (master) heads/master-0-g1903129 cairo (master) heads/master-0-g03c81d4 libva (master) heads/master-0-gd2dbc3f intel-driver (master) heads/master-0-g8bf8075 gstreamer (1.0) heads/1.0-0-g80431b4 gst-plugins-base (1.0) heads/1.0-0-gd11092d gst-plugins-good (1.0) heads/1.0-0-g82c342f gst-plugins-bad (1.0) heads/1.0-0-gcbd8367 gst-ffmpeg (1.0) heads/1.0-0-g78b1196 gstreamer-vaapi (master) heads/master-0-g0b1a97c KERNEL: Linux 3.9.8-100.fc17.x86_64 #1 SMP Thu Jun 27 19:19:57 UTC 2013 x86_64
Hi Joe, this is likely a gstreamer-vaapi issue. I have not updated yet to work with Wayland 1.2.x, if anything was needed. I will check it out.
Let me know if you need help with debug, gb! ^_^
Any update on this bug? We need this fixed for demos at LinuxCon NA, Plumbers and a GENIVI event in October and our demos rely on this feature. Ulf
Wayland 1.2, libva, intel-driver, gstreamer's 1.0 branch, and gstreamer-vaapi works fine for me with a 1280x720 video, however no video output for Sintel.2010.1080p.mp4. Maybe gstreamer_vaapi doesn't handle video cropping (1920x1088 vs 1920x1080) correctly.
Just a note that the setup and steps to reproduce have been working fine since Wayland 1.0 and 1.1. It is only with 1.2 that this issue appeared.
Is there any update on this issue?
As stated in this bug's description, the following video streams have functioned with gstreamer-vaapi and Wayland < 1.2 for months (I ran them regularly in the course of my daily duties), but *not* with Wayland >= 1.2: * http://www.bigbuckbunny.org/index.php/download/ - The 1920x1080 h264 stream * http://www.sintel.org/download - The HD1080p stream I am able to play the 720p streams from those sources, though.
I am seeing that gst-vaapi no longer works for streams around 1080p regardless of Wayland version-- I've tried 1.2.0 and 1.0.2, and in each case gstreamer-vaapi will not play a 1920x1080-ish h264 stream. For now at least, Weston is excused from investigation. This is given the following stack: libva libva-1.2.1 intel-driver 1.2.0 gstreamer 1.0.9 gst-plugins-[base,good,bad] 1.0.9 gst-ffmpeg 1.0.9 gstreamer-vaapi 0.5.5 Last known good configuration-- where gst-vaapi played 1920x1080-ish h264 streams: libva 1.2.0 intel-driver 1.2.0 gstreamer 1.0.7 gst-plugins-base,good,bad] 1.0.7 gst-ffmpeg 1.0.7 gstreamer-vaapi commit 5fe72d9 (pre-0.5.4)
Regression more severe in X than in Wayland. I cannot play back either the 1080 or 720 video streams of Sintel or Big Buck Bunny with the stack specified in comment 8, using the gst pipeline specified in the bug description. In either X or Wayland, using a pure software gst pipeline allows me to play back any of the streams. This is the "pure software pipeline": gst-launch-1.0 filesrc location=Sintel.2010.1080p.mp4 ! \ qtdemux ! avdec_h264 ! videoconvert ! < ximagesink | waylandsink > Changing the bug title to be more specific. This would appear to be a regression in the gstreamer-vaapi component, given data collected thus far. Therefore it's deceptive to associate "wayland" with this bug at the present time.
Created attachment 83901 [details] gst-launch debug output under wayland
Created attachment 83902 [details] gst-launch debug output under X
Also, for gst-vaapi ext/codecparsers, this is what's checked out: f90de0a codecparsers: h264: fix calculation of the frame cropping rectangle.
(In reply to comment #10) > Created attachment 83901 [details] > gst-launch debug output under wayland In gst-libs/gst/vaapi/gstvaapiwindow_wayland.c:302, around the "XXX: use VPP to support unusual source and destination rectangles" comment, you could #if 0 / #endif the if() block to unlock you temporarily. Though, this is not something I would push, a proper solution is needed, as indicated. :) (and this is what is to be available for the next release BTW). An alternative is to try something in vaapisink too, but this is more involved to validate because there are multiple combinations to consider and that also impact the X11 backend. One solution would be to use the cropped size to guess-estimate the window size. Though, this is also just a workaround because there are situations where vaapisink does not control the allocation (creation) of the window. So, we end up to need a generic solution in GstVaapiWindowWayland::render().
(In reply to comment #11) > Created attachment 83902 [details] > gst-launch debug output under X I believe there is a missing plug-in elements. This looks more like an installation issue on the GStreamer side. It is expected to produce the same issue in Wayland too. If not, this means that you use different GStreamer installations, and one of them has an issue because you definitely don't see that in Wayland, according to the other log. Could you please report the output of GST_DEBUG=vaapi:5,vaapidecode:5,vaapisink:5 for this one? Thanks.
Created attachment 84013 [details] gst-launch additional debug output under X This is in reply to comment #14.
In that attachment, Xorg and mutter are running. (In reply to comment #15) > Created attachment 84013 [details] > gst-launch additional debug output under X > > This is in reply to comment #14.
Hi, I pushed something to the git master branch. It works, though I am not fully satisfied yet. Rationale: - If VPP is not supported, or not available (libva >= 1.2.0, libva-intel-driver >= 1.2.0), then we fallback to displaying the raw surface. This will be wrong in most cases where video cropping or deinterlacing was needed. At least, we now display something and no longer exit. - If VPP is supported, then an intermediate surface is used to receive the outcome of video processing. Currently, the target surface format is arbitrarily set to YUV 4:2:0 (most probably NV12, under the hoods). A future optimization is to use another format that would be more suitable to the compositor, e.g. packed YUV 4:2:2 (YUY2). Though, we need to determine a proper threshold/balance between extra memory bandwidth (YUV 4:2:2 requires more bytes), or extra GPU/EU processing power (shaders are used for YUV 4:2:0, but direct sampling from YUV 4:2:2 is possible on most hardware).
Tested on latest upstream bits and the issue is gone. wayland (master) 1.4.93-0-g8511544 drm (master) heads/master-0-g305478c mesa (master) heads/master-0-g39ae284 libva (master) heads/master-0-g0337703 intel-driver (master) heads/master-0-gb48ba79 cairo (master) heads/master-0-g85b05e8 libinput (master) heads/master-0-g97af5c3 weston (master) heads/master-0-gbe803ad gstreamer (master) heads/master-0-g7e60572 gst-plugins-base (master) heads/master-0-g1ca576c gst-plugins-good (master) heads/master-0-g541a967 gst-plugins-bad (master) heads/master-0-gbd34e62 gst-ffmpeg (master) heads/master-0-g78b64cb gstreamer-vaapi (master) heads/master-0-gc12d80e
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.