Bug 67190

Summary: [gst-vaapi] H264 video playback regression between 5fe72d9 and 0.5.5
Product: libva Reporter: Joe Konno <joe.konno>
Component: gst-vaapiAssignee: Weichangzhi <changzhix.wei>
Status: RESOLVED FIXED QA Contact: Sean V Kelley <seanvk>
Severity: normal    
Priority: medium CC: brian.j.lovin, gb.devel, krh, rob, ulf.hofemeier, ullysses.a.eoff, wayland-bugs
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: gst-launch debug output under wayland
gst-launch debug output under X
gst-launch additional debug output under X

Description Joe Konno 2013-07-22 20:26:17 UTC
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
Comment 1 Gwenole Beauchesne 2013-07-24 17:07:33 UTC
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.
Comment 2 Joe Konno 2013-07-26 15:21:15 UTC
Let me know if you need help with debug, gb! ^_^
Comment 3 Ulf Hofemeier 2013-08-02 15:41:20 UTC
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
Comment 4 haihao 2013-08-05 05:23:00 UTC
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.
Comment 5 Joe Konno 2013-08-05 15:53:04 UTC
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.
Comment 6 Joe Konno 2013-08-08 13:57:06 UTC
Is there any update on this issue?
Comment 7 Joe Konno 2013-08-08 14:19:33 UTC
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.
Comment 8 Joe Konno 2013-08-09 15:38:11 UTC
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)
Comment 9 Joe Konno 2013-08-09 15:53:39 UTC
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.
Comment 10 Joe Konno 2013-08-09 17:26:34 UTC
Created attachment 83901 [details]
gst-launch debug output under wayland
Comment 11 Joe Konno 2013-08-09 17:26:54 UTC
Created attachment 83902 [details]
gst-launch debug output under X
Comment 12 Joe Konno 2013-08-09 17:42:11 UTC
Also, for gst-vaapi ext/codecparsers, this is what's checked out:

f90de0a codecparsers: h264: fix calculation of the frame cropping rectangle.
Comment 13 Gwenole Beauchesne 2013-08-13 04:18:00 UTC
(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().
Comment 14 Gwenole Beauchesne 2013-08-13 04:21:28 UTC
(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.
Comment 15 Joe Konno 2013-08-13 13:52:48 UTC
Created attachment 84013 [details]
gst-launch additional debug output under X

This is in reply to comment #14.
Comment 16 Joe Konno 2013-08-13 13:54:31 UTC
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.
Comment 17 Gwenole Beauchesne 2013-08-27 16:36:58 UTC
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).
Comment 18 U. Artie Eoff 2014-05-15 18:59:53 UTC
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.