GNOME Bugzilla – Bug 797312
vaapih265dec: [radeon] GStreamer fails to play HEVC video
Last modified: 2018-11-03 15:56:18 UTC
Created attachment 373979 [details] Matroska file with x265 video where gst-launch-1.0 fails The attached 1s video plays fine with other players. $ gst-launch-1.0 playbin uri=file:///data/scratch/das_boot.mkv Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Got context from element 'vaapisink0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0"; Redistribute latency... Got context from element 'playsink': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)"\(GstVaapiDisplayGLX\)\ vaapidisplayglx0"; Redistribute latency... ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0: Internal data stream error. Additional debug info: gstmultiqueue.c(2069): gst_multi_queue_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstMultiQueue:multiqueue0: streaming stopped, reason error (-5) ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ...
I have tested this file withough vaapi support, and it works, so I'm moving the ticket component to gstreamer-vaapi. Then I have tested on 1.14.1 as shipped by Fedora (Intel i965 driver for Intel(R) Skylake - 2.1.0) and it also worked. Then I tested on HW without HEVC support (Intel i965 driver for Intel(R) Ivybridge Mobile - 2.1.0) and the software fallback (FFMPEG) did work as expected. Which means I cannot reproduce the error you are seeing. Please provide additional information such as VAAPI support details, as reported by vainfo utility, and confirm which version of GStreamer you are testing. Ideally, test against newer libva and vaapi driver, as the issue may already been resolved.
(In reply to Nicolas Dufresne (ndufresne) from comment #1) > Please provide additional information such as VAAPI support details, as > reported by vainfo utility, and confirm which version of GStreamer you are > testing. Ideally, test against newer libva and vaapi driver, as the issue > may already been resolved. This is libva-2.3.0 and GStreamer 1.14.4, both from Debian/testing: $ gst-launch-1.0 --version gst-launch-1.0 version 1.14.4 GStreamer 1.14.4 http://packages.qa.debian.org/gstreamer1.0 $ vainfo libva info: VA-API version 1.3.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_2 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.3 (libva 2.2.0) vainfo: Driver version: Mesa Gallium driver 18.1.7 for Radeon RX 560 Series (POLARIS11, DRM 3.26.0, 4.18.0-2-amd64, LLVM 6.0.1) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc
As Nicolas said, the stream plays with my kabylake using intel-vaapi-driver and this is the first time I heard of someone playing HEVC with the gallium state tracker for radeon. Please upload the log with GST_DEBUG=*:4,vaapi*:5
Created attachment 373980 [details] gst-launch debug output with GST_DEBUG=*:4,vaapi*:5
Comment on attachment 373980 [details] gst-launch debug output with GST_DEBUG=*:4,vaapi*:5 vaapi logs didn't show up. I guess the correct debug format is GST_DEBUG="vaapi*:5,*:4"
(In reply to Víctor Manuel Jáquez Leal from comment #5) > vaapi logs didn't show up. I guess the correct debug format is > GST_DEBUG="vaapi*:5,*:4" Uhm, that didn't change the log. I'm going to upload the log with GST_DEBUG="*:5" now.
Created attachment 373982 [details] gst-launch debug output with GST_DEBUG=*:5
Can you try with GST_DEBUG=*vaapi*:6 ?
Created attachment 374014 [details] gst-launch debug output with GST_DEBUG=*vaapi*:6 Setting GST_DEBUG to *vaapi*:6 doesn't produce more lines of debug output.
Looks like a problem with gstvaapisink which does not restrict the caps to what it really supports. Try playbin video-sink="videoconvert ! xvimagesink" Try also try gst-launch-1.0 filesrc location=file:///data/scratch/das_boot.mkv ! matroskademux ! h265parse ! vaapidecode ! vaapipostproc ! "video/x-raw(memory:VASurface), format=(string)RGBA" ! vaapisink
0:00:00.456349780 [335m28462[00m 0x7fe30803ea30 [37mDEBUG [00m [00m vaapi gstvaapisurface.c:376:gst_vaapi_surface_new_full:[00m size 992x574, format NV12, flags 0x00000000 0:00:00.456630547 [335m28462[00m 0x7fe30803ea30 [37mDEBUG [00m [00m vaapi gstvaapisurface.c:213:gst_vaapi_surface_create_full:[00m surface 0xe 0:00:00.456646808 [335m28462[00m 0x7fe30803ea30 [37mDEBUG [00m [00m vaapi gstvaapiutils.c:130:vaapi_check_status:[00m vaRenderPicture(): invalid VASurfaceID 0:00:00.456653059 [335m28462[00m 0x7fe30803ea30 [31;01mERROR [00m [00m vaapipostproc gstvaapipostproc.c:872:gst_vaapipostproc_process_vpp:<vaapipostproc0>[00m failed to apply VPP filters (error 2) IIUC the problem is in vaapipostroc: it is unable to apply a filter in a surface. Another test would be to export the environment variable GST_VAAPI_DISABLE_VPP=1
(In reply to Julien Isorce from comment #10) > Try also try gst-launch-1.0 filesrc > location=file:///data/scratch/das_boot.mkv ! matroskademux ! h265parse ! > vaapidecode ! vaapipostproc ! "video/x-raw(memory:VASurface), > format=(string)RGBA" ! vaapisink No success. WARNING: erroneous pipeline: no element "vaapidecode"
Created attachment 374034 [details] gst-launch playbin video-sink="videoconvert ! xvimagesink" debug output with GST_DEBUG=vaapi*:5,*:4 That didn't work either.
(In reply to Víctor Manuel Jáquez Leal from comment #11) > Another test would be to export the environment variabl GST_VAAPI_DISABLE_VPP=1 Success: That does play it!
We would need to debug what's happening with the posprocessor. One last log (without GST_VAAPI_DISABLE_VPP!) exporting the variable LIBVA_TRACE=~/vpp-failure With it we would get the logs from VAAPI (but not for the driver, sadly) And post it here :) Thanks!
Created attachment 374037 [details] vpp-failure.174006.thd-0x00001980
Created attachment 374038 [details] /home/rbk/vpp-failure.174006.thd-0x00001983
Created attachment 374039 [details] vpp-failure.174006.thd-0x00001984
Created attachment 374040 [details] vpp-failure.174006.thd-0x0000199b
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/110.