GNOME Bugzilla – Bug 794161
HEVC Decode: ERROR: pipeline doesn't want to preroll
Last modified: 2018-03-08 09:17:30 UTC
Unable to decode HEVC (tested on SKL): $ gst-launch-1.0 --gst-debug-level=1 -f -q filesrc location=<hevc file> ! h265parse ! vaapih265dec ! vaapipostproc format=i420 ! vaapisink ERROR: from element /GstPipeline:pipeline0/GstH265Parse:h265parse0: Internal data stream error. Additional debug info: gstbaseparse.c(3611): gst_base_parse_loop (): /GstPipeline:pipeline0/GstH265Parse:h265parse0: streaming stopped, reason not-negotiated (-4) ERROR: pipeline doesn't want to preroll. First bad commit is in gst-plugins-bad: commit d252f503fc2cd9e373e1467cdf3f0de34345359a (HEAD -> master) Author: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk> Date: Thu Mar 1 11:08:44 2018 +0100 h265parser: decouple GstH265Profile and GstH265ProfileIDC We used to have the same enum to represent H265 profiles and idc values. Those are no longer the same with extension profiles defined from version 2 of the spec. Split those enums so the semantic of each is clearer and we'll be able to add extension profiles to GstH265Profile. Also add gst_h265_profile_tier_level_get_profile() to retrieve the GstH265Profile from the GstH265ProfileTierLevel. It will be used to implement the detection of extension profiles. https://bugzilla.gnome.org/show_bug.cgi?id=793876 Software Stack: libva (master) heads/master-0-g20a301bf6cc0 intel-vaapi-driver (master) heads/master-0-gbb92421bdb3f gstreamer (master) heads/master-0-gf204b57fa544 gst-plugins-base (master) 1.13.90-0-g7d18a9727379 gst-plugins-good (master) 1.13.90-0-g0da4d409b9fa gst-plugins-bad (master) heads/master-0-gd252f503fc2c gstreamer-vaapi (master) 1.13.90-0-gf6f981e371ba
Did you recompile gstreamer-vaapi after updating gst-plugins-bad ?
(There was a structure size change after 1.13.90 which breaks ABI and means gstreamer-vaapi needs to be rebuilt).
(In reply to Tim-Philipp Müller from comment #1) > Did you recompile gstreamer-vaapi after updating gst-plugins-bad ? Yes, I did a clean recompile of all components.
Ok, could you attach a xz -9 compressed GST_DEBUG=*:6 log then please?
Created attachment 369414 [details] GST_DEBUG=*:6 output
Could you also attach a log from before the problematic commit, when it worked? I see this in the log: __gst_video_element_proxy_getcaps:<vaapidecode_h265-0> template caps ...; video/x-h265, profile=(string)main; ... and then: gst_video_element_proxy_getcaps:<vaapidecode_h265-0> intersecting with video/x-h265, width=(int)2560, height=(int)1600, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, stream-format=(string)hvc1, alignment=(string)au, profile=(string)main-10, tier=(string)main, level=(string)5.1, codec_data=(buffer)... So vaapidecode_h265 supports only "main" profile, but we now detect "main-10" profile. What did we detect before?
Created attachment 369416 [details] debug log before bug
Ok, so before h265parse detect main profile. Can you make the/a file available somewhere by any chance? What does "vainfo" output for you?
(In reply to Tim-Philipp Müller from comment #8) > Ok, so before h265parse detect main profile. > > Can you make the/a file available somewhere by any chance? > Unfortunately I'm not at liberty to share the input file. However, Sree has access to the files and may be able to help debug. Sree, can you help debug this? > What does "vainfo" output for you? libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /home/uaeoff/Work/workspace/media/install/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.1 (libva 2.1.1.pre1) vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 2.1.1.pre1 (2.1.1.pre1) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Simple : VAEntrypointEncSlice VAProfileMPEG2Main : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP VAProfileH264ConstrainedBaseline: VAEntrypointFEI VAProfileH264ConstrainedBaseline: VAEntrypointStats VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264Main : VAEntrypointEncSliceLP VAProfileH264Main : VAEntrypointFEI VAProfileH264Main : VAEntrypointStats VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264High : VAEntrypointEncSliceLP VAProfileH264High : VAEntrypointFEI VAProfileH264High : VAEntrypointStats VAProfileH264MultiviewHigh : VAEntrypointVLD VAProfileH264MultiviewHigh : VAEntrypointEncSlice VAProfileH264StereoHigh : VAEntrypointVLD VAProfileH264StereoHigh : VAEntrypointEncSlice VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc VAProfileJPEGBaseline : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointEncPicture VAProfileVP8Version0_3 : VAEntrypointVLD VAProfileVP8Version0_3 : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice
Note: This does not fail on KBL platform. KBL has VAProfileHEVCMain10:VAEntrypointEncSlice profile:entrypoint.
(In reply to Tim-Philipp Müller from comment #8) > Can you make the/a file available somewhere by any chance? I found a file online the will reproduce this on platform <= SKL: http://fate-suite.ffmpeg.org/hevc-conformance/AMP_A_Samsung_6.bit
(In reply to U. Artie Eoff from comment #11) > (In reply to Tim-Philipp Müller from comment #8) > > Can you make the/a file available somewhere by any chance? > > I found a file online the will reproduce this on platform <= SKL: > http://fate-suite.ffmpeg.org/hevc-conformance/AMP_A_Samsung_6.bit I'll have a look. I can see that that stream is main-10: shouldn't be decodable with skl and should be decodable with kbl. But it seems there is some mess-up in KBL and it decodes the stream as main profile.
(In reply to sreerenj from comment #12) > (In reply to U. Artie Eoff from comment #11) > > (In reply to Tim-Philipp Müller from comment #8) > > > Can you make the/a file available somewhere by any chance? > > > > I found a file online the will reproduce this on platform <= SKL: > > http://fate-suite.ffmpeg.org/hevc-conformance/AMP_A_Samsung_6.bit > > I'll have a look. > I can see that that stream is main-10: shouldn't be decodable with skl and > should be decodable with kbl. > But it seems there is some mess-up in KBL and it decodes the stream as main > profile. The input file is main 8bit, SKL tries to use main-10. $ mediainfo AMP_A_Samsung_6.bit General Complete name : AMP_A_Samsung_6.bit Format : HEVC Format/Info : High Efficiency Video Coding File size : 2.00 MiB FileExtension_Invalid : hevc h265 265 Video Format : HEVC Format/Info : High Efficiency Video Coding Format profile : L5.1@Main Width : 2 560 pixels Height : 1 600 pixels Display aspect ratio : 16:10 Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits
K, So this stream has: profile_idc = 0 (so we can't recognize the profile here) profile_compatibility_flag[2] is 1: which means this is a main-10 profile. So; Skylake is not supposed to try decoding this stream. (no hardware support) But Kabylake should decode this stream. So everything looks good to me :)
(In reply to U. Artie Eoff from comment #13) > (In reply to sreerenj from comment #12) > > (In reply to U. Artie Eoff from comment #11) > > > (In reply to Tim-Philipp Müller from comment #8) > > > > Can you make the/a file available somewhere by any chance? > > > > > > I found a file online the will reproduce this on platform <= SKL: > > > http://fate-suite.ffmpeg.org/hevc-conformance/AMP_A_Samsung_6.bit > > > > I'll have a look. > > I can see that that stream is main-10: shouldn't be decodable with skl and > > should be decodable with kbl. > > But it seems there is some mess-up in KBL and it decodes the stream as main > > profile. > > The input file is main 8bit, SKL tries to use main-10. > > $ mediainfo AMP_A_Samsung_6.bit > General > Complete name : AMP_A_Samsung_6.bit > Format : HEVC > Format/Info : High Efficiency Video Coding > File size : 2.00 MiB > FileExtension_Invalid : hevc h265 265 > > Video > Format : HEVC > Format/Info : High Efficiency Video Coding > Format profile : L5.1@Main > Width : 2 560 pixels > Height : 1 600 pixels > Display aspect ratio : 16:10 > Color space : YUV > Chroma subsampling : 4:2:0 > Bit depth : 8 bits It is 8-bit stream, but encoded as main-10. Main-10 streams can be 8 bit or 10 bit. A main-10 compatible decoder should be able to decode all main profile streams.
Hmm, SKL was able to decode this stream successfully before the hevc parser changes.
(In reply to U. Artie Eoff from comment #16) > Hmm, SKL was able to decode this stream successfully before the hevc parser > changes. It can happen if you fool the driver by telling it as main profile. And it will work as long as the encoded stream is not using any main-10 specific tools(algorithmic features).
Thanks.
If the only difference between HEVC main-10 and main profile is the bit-depth (which I'm not 100% sure), then we can do the workaround by setting profile as "main". But do we really need to do this?
> If the only difference between HEVC main-10 and main profile is the > bit-depth (which I'm not 100% sure), then we can do the workaround by > setting profile as "main". > > But do we really need to do this? The caps also have chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8 so you could advertise support for main-10 profile with 8-bit depth, but I don't know if that will always be ok for the hw decoder, if there are additional features that could be used.