[Bug 762500] New: jpeg decoder: gen75_mfd.c:2203:

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762500

Bug ID: 762500
Summary: jpeg decoder: gen75_mfd.c:2203:
gen75_mfd_jpeg_decode_init: Assertion `0' failed
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gstreamer-vaapi
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@zen.co.uk
QA Contact: gstreamer-***@lists.freedesktop.org
CC: ***@gmail.com, ***@igalia.com
GNOME version: ---

Created attachment 321907
--> https://bugzilla.gnome.org/attachment.cgi?id=321907&action=edit
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)

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762500

--- Comment #1 from Víctor Manuel Jáquez Leal <***@igalia.com> ---
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

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762500

--- Comment #2 from Tim-Philipp Müller <***@zen.co.uk> ---
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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762500

Víctor Manuel Jáquez Leal <***@igalia.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.freedesktop.or
| |g/show_bug.cgi?id=67150

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762500

--- Comment #3 from sreerenj <***@gmail.com> ---
Why does this stream not decodable with software decoders too?!
But ffmpeg is decoding correctly.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762500

--- Comment #4 from sreerenj <***@gmail.com> ---
This is a similar case:
https://bugzilla.gnome.org/show_bug.cgi?id=763321

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762500

--- Comment #5 from sreerenj <***@gmail.com> ---
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.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762500

--- Comment #6 from sreerenj <***@gmail.com> ---
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 :)

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762500

--- Comment #7 from sreerenj <***@gmail.com> ---
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....

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762500

Víctor Manuel Jáquez Leal <***@igalia.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@intel.com

--- Comment #8 from Víctor Manuel Jáquez Leal <***@igalia.com> ---
*** Bug 763321 has been marked as a duplicate of this bug. ***

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=762500

GStreamer system administrator <***@gstreamer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #9 from GStreamer system administrator <***@gstreamer.net> ---
-- 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.