GNOME Bugzilla – Bug 772457
Delayed linking fails when requesting non NV12 colorspaces from decodebin
Last modified: 2018-11-03 15:48:26 UTC
The following pipeline crashes (Internal data stream error): gst-launch-1.0 filesrc location=bbb-1920-1080-30.mp4 num-buffers=180 ! decodebin ! videoscale ! video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\ framerate\=\(fraction\)30/1 ! filesink location=samples/tmp.raw WARNING: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0: Delayed linking failed. ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0: Internal data stream error. Sample: http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_1080p_30fps_normal.mp4 This didn't fail on 1.8.3, and i checked that it does not happen when vaapi is not present.
The following pipeline is cleaner and reproduces the problem (sorry for the bogus one in my initial report): gst-launch-1.0 filesrc location=bbb-1920-1080-30.mp4 ! decodebin ! video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\ framerate\=\(fraction\)30/1 ! fakesink This is equivalent to: gst-launch-1.0 filesrc location=bbb-1920-1080-30.mp4 ! decodebin ! xvimagesink ximagesink, xvimagesink, glimagesink fails; fakesink and vaapisink are the only working sinks, so it. Apparently, it is the NV12 to I420 conversion requested by downstream caps from decodebin that seems to fail. Adding videoconvert after decodebin fixes it. Interestingly, vaapih264dec succeeds in providing I420 data: gst-launch-1.0 filesrc location=bbb-1920-1080-30.mp4 ! qtdemux ! vaapih264dec ! video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\ framerate\=\(fraction\)30/1 ! fakesink -v Using vaapidecodebin does work partially (it seems to add vaapipostproc after the decoder), but this freezes my machine heavily, which you can replicate using: gst-launch-1.0 filesrc location=bbb-1920-1080-30.mp4 ! qtdemux ! vaapih264dec ! vaapipostproc ! video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\ framerate\=\(fraction\)30/1 ! fakesink -v NB: this is on haswell
Also happens with skylake
Using glimagesink works for me *but* exporting the envvar LIBGL_DRI3_DISABLE=1 because a bug in DRI3 (already fixed in upstream). So, it only happens when mapping to system memory. Strangely enough, when using this pipeline gst-launch-1.0 filesrc location=bbb-1920-1080-30.mp4 ! decodebin ! vaapipostproc ! xvimagesink also works fine. But, I cannot see the machine freeze that you mentioned (I'm testing on haswell) In my understanding, decodebin is not doing what it did in before when negotiating memory:system feature caps.
This may be related to bug 758212 and in a similar vein, bug 767429. Theoretically, playbin3 is meant to fix these kinds of issues :)
I just checked and decodebin3 indeed fixes this: gst-launch-1.0 filesrc location=bbb_sunflower_1080p_30fps_normal.mp4 ! decodebin3 name=dec ! video/x-raw\,\ format\=\(string\)I420\,\ width\=\(int\)1920\,\ height\=\(int\)1080\,\ framerate\=\(fraction\)30/1 ! fakesink -v Should we wait for decodebin3 to get promoted to close this ?
-- 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/45.