Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • gstreamer-vaapi gstreamer-vaapi
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 148
    • Issues 148
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 8
    • Merge requests 8
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.

  • GStreamerGStreamer
  • gstreamer-vaapigstreamer-vaapi
  • Issues
  • #158
Closed
Open
Issue created May 02, 2019 by Wolfgang Grandegger@greywolf

Pipeline not working with gdkpixbufoverlay and vaapi using JPEG 4:2:2 streams

The following pipeline does not work with a JPEG 4:2:2 stream and gdkpixbufoverlay:

$ gst-launch-1.0 filesrc location=qt.img ! qtdemux name=demux demux.video_0 \
       vaapijpegdec ! gdkpixbufoverlay location=gstreamer-logo.png ! vaapisink

To demonstrate the problem, I stored the problematic stream to the QuickTime Video qt.img.

The above commands reports with GST_DEBUG=3 the following warnings:

0:00:00.031914850   510       0x7aa720 WARN               vaapisink gstvaapisink.c:1483:gst_vaapisink_show_frame_unlocked:<vaapisink0> could not get surface
0:00:00.031944593   510       0x7aa720 WARN                 qtdemux qtdemux.c:6073:gst_qtdemux_loop:<demux> error: Internal data stream error.
0:00:00.031949748   510       0x7aa720 WARN                 qtdemux qtdemux.c:6073:gst_qtdemux_loop:<demux> error: streaming stopped, reason error (-5)
ERROR: from element /GstPipeline:pipeline0/GstQTDemux:demux: Internal data stream error.
Additional debug info:
qtdemux.c(6073): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstQTDemux:demux:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

The above pileline works fine if I:

  • use a 4:2:0 JPEG stream instead
  • use jpegdec instead of vaapijpegdec
  • use clockoverlay instead of gdkpixbufoverlay
  • add ! vaapipostproc format=i420 after vaapijpegdec

Looks to me like an issue of with 4:2:2 frames with gdkpixbufoverlay or VAAAPI. Does VAAPI not support this format properly? Converting to "i420" seems not to be a good option.

Some more information and observation can be found in the mail thread with the subject "gdkpixbufoverlay breaks vaapi pipeline" on the "gstreamer-devel" ML:

  • https://lists.freedesktop.org/archives/gstreamer-devel/2019-April/071228.html
  • https://lists.freedesktop.org/archives/gstreamer-devel/2019-May/071233.html

For testing I use:

  • GStreamer v1.4.2 and v1.6.0
  • libva 2.3.0 and 2.4.0
  • Buildroot 2018.11 and 2019.02
  • Linux 4.14.87
  • ASRock-IMB190 with Intel Core i7-6700TE CPU @ 2.40GHz
  • HDMI display

I have provided the following files to reproduce the issue:

$ tar ft bug-report.tar.xz
bug-report/
bug-report/pipeline-gst-debug-5.log   Debug output with GST_DEBUG=5
bug-report/pipeline-gst-debug-3.log   Debug output with GST_DEBUG=3
bug-report/qt.img                     The QuickTime image mentioned above
bug-report/gstreamer-logo.png         Logo used for the gdkpixbufoverlay

bug-report.tar.xz

Assignee
Assign to
Time tracking