GNOME Bugzilla – Bug 762500
jpeg decoder: gen75_mfd.c:2203: gen75_mfd_jpeg_decode_init: Assertion `0' failed
Last modified: 2018-11-03 15:47:23 UTC
Created attachment 321907 [details] vaapi-assert.jpg Not sure if this is an issue with the jepg parser / vaapi or lower levels in the stack: $ gst-play-1.0 vaapi-assert.jpg libva info: VA-API version 0.38.1 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_38 libva info: va_openDriver() returns 0 Redistribute latency... lt-gst-play-1.0: gen75_mfd.c:2203: gen75_mfd_jpeg_decode_init: Assertion `0' failed. Aborted (core dumped)
The culprit is libva-intel-driver. I hate that libva-intel-driver handles its no-valid-states with asserts: https://cgit.freedesktop.org/vaapi/intel-driver/tree/src/gen75_mfd.c#n2150 This jpeg file has 4 components and libva-intel-driver only supports 1 and 3 components for subsampling
Ah I see, why do error handling if you can just assert :P I think we need to be stricter in general about the JPEGs we pass to vaapi, I have other jpg files which will cause an error at runtime because the vaapi decoder can't handle the profile.
Why does this stream not decodable with software decoders too?! But ffmpeg is decoding correctly.
This is a similar case: https://bugzilla.gnome.org/show_bug.cgi?id=763321
Similar to what SiewHoon did in #763321, we can check for the number of components in gstvaapidecoder_jpeg and error out if it is greater than four to get rid of the driver assert. But this will not help to fallback to software decoder since we already reached the parsing state.
Ideally we should have something similar to VAEncode config attribute VAConfigAttribValEncJPEG { .... .... unsigned int max_num_components : 3; ... } , and query the config attribute to check whether specific features are supported or not. But this requires change in driver and va_header :)
I curious about few other things related with this: In gstreamer-vaapi git master, we negotiate src caps from vaapidecode only after getting the first decoded frame ready to be pushed. So in theory, if there is any issue in hardware decode, playbin can still fallback to software decoder (assuming we will have patch in gstreamer-vaapi to return FALSE/FLOW_ERROR before driver asserts) I think this is beneficial for all codecs, playbin will try to autoplug the vaapidecode first, if any error occurred while doing the first frame decode (may be due to un-maintained driver), it switchback to software decoder....
*** Bug 763321 has been marked as a duplicate of this bug. ***
-- 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/35.