GNOME Bugzilla – Bug 719671
[High][ILK gst-master] GPU hang when decoding FM1_FT_E.264
Last modified: 2014-01-10 06:51:22 UTC
Environment: -------------- Platform: ilk Libva(git://anongit.freedesktop.org/libva): staging 1264cd81fd8728f18bd2feedf6e9c1a232663890 Libva_intel_driver(git://anongit.freedesktop.org/vaapi/intel-driver): staging 34627c96f331f7a344270c3d51b634f5f166073e Gstreamer10(git://anongit.freedesktop.org/gstreamer/gstreamer): 1.0 4e880d4d1e151ea64f83c28b5c3e1bbc06c57903 Gst_plugins_base10(git://anongit.freedesktop.org/gstreamer/gst-plugins-base): 1.0 2dd3f028c1e6dea799d7496639f53220818b20b1 Gst_plugins_good10(git://anongit.freedesktop.org/gstreamer/gst-plugins-good): 1.0 643d425f51f81b56deec16c01162637546708ee5 Gst_plugins_bad10(git://anongit.freedesktop.org/gstreamer/gst-plugins-bad): 1.0 0587ab41b4f9979e9cfc11011ed5c970569ee3d3 Gst_plugins_ugly10(git://anongit.freedesktop.org/gstreamer/gst-plugins-ugly): 1.0 c7c911b8320576429e4a4234a1e29ec7436e6814 Cmdline: -------------- gst-launch-1.0 filesrc location=/root/media_tools/decoder/Base_Ext_Main_profile/FM1_FT_E.264 '!' h264parse '!' vaapidecode '!' vaapisink sync=false og info: -------------- [ 529.205714] [drm:i915_set_reset_status] *ERROR* bsd ring hung inside bo (0xda3000 ctx 0) at 0xda33bc [ 535.207384] [drm] stuck on bsd ring [ 541.223057] [drm] stuck on bsd ring [ 547.222831] [drm] stuck on bsd ring
Hi, please try the following: 1. git master branch for libva and libva-intel-driver. If this works, then please report the issue against libva-intel-driver. If this still fails, go to step 2. 2. Try to regression test against the released gstreamer-vaapi versions, available at: <http://www.freedesktop.org/software/vaapi/releases/gstreamer-vaapi/>. If none works back to 0.4.3, go to step 3, otherwise please mention the latest version of gstreamer-vaapi where this worked. Thanks.
Hi. This bug reproduced when using master branch. I tried to bisect intel-driver and gstreamer-vaapi, it still exists when applying the branches several months before, commit ae5e5be80b9da5c39b55a646728ca89f2b767f13 Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Fri Oct 4 15:37:24 2013 +0200 vaapipostproc: add support for raw YUV video source buffers. Allow video processing from raw YUV buffers coming from the sink pad, while still producing a VA surface for the downstream elements. Then I tried to use your another earlier branch: commit d75d70d395d48eb02ef31b5656131b85c8221a97 Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Mon Feb 6 15:54:09 2012 +0100 mpeg2: fix crash when there is no free surface to decode into. With the latest gstreamer/base.. 1.0 branch, it failed to build.So I haven't got the first bad commit til now. Thanks
Using mplayer to play this stream on ILK, mplayer crashed Error while decoding frame! [h264 @ 0x7f853b5aa260]non-existing PPS 0 referenced [h264 @ 0x7f853b5aa260]decode_slice_header error [h264 @ 0x7f853b5aa260]Invalid mix of idr and non-idr slices Error while decoding frame! [VD_FFMPEG] Trying pixfmt=0. [VD_FFMPEG] XVMC-accelerated MPEG-2. Movie-Aspect is undefined - no prescaling applied. VO: [vaapi] 176x144 => 176x144 H.264 VA-API Acceleration [VD_FFMPEG] XVMC-accelerated MPEG-2. [VD_FFMPEG] Trying pixfmt=0. [VD_FFMPEG] XVMC-accelerated MPEG-2. [h264 @ 0x7f853b5aa260]Missing reference picture, default is 0 [h264 @ 0x7f853b5aa260]decode_slice_header error WARNING: Invalid reference frame!!! mplayer: i965_decoder_utils.c:286: gen5_fill_avc_ref_idx_state: Assertion `frame_idx < 16' failed. MPlayer interrupted by signal 6 in module: decode video - MPlayer crashed. This shouldn't happen.
This clip is baseline profile. after driver upgrade. baseline was not supported anymore. gst-vaapi is hard to check whether a clip has Arbitrary slice ordering (ASO) in baseline by from codec_data. that means even a baseline clip without ASO, gst-vaapi pipeline still would fail it. This is not only for ILK but all GEN platform which only support constrained-baseline, main, high profiles. suggest mark as [won't fix]. Thanks, Wind
(In reply to comment #4) > This clip is baseline profile. after driver upgrade. baseline was not supported > anymore. gst-vaapi is hard to check whether a clip has Arbitrary slice ordering > (ASO) in baseline by from codec_data. that means even a baseline clip without > ASO, gst-vaapi pipeline still would fail it. > This is not only for ILK but all GEN platform which only support > constrained-baseline, main, high profiles. > > suggest mark as [won't fix]. We indeed cannot support Baseline profile in the general case on Intel HD Graphics hardware (and many others actually). However, it is not correct to cause a crash. So, if this still crashes with the latest release of the VA intel-driver, then an additional fix is needed on the gstreamer-vaapi side. Having said that, it should be somewhat simple to support Baseline profile streams with ASO. However, the Flexible Macroblock Ordering (FMO) and Redundant Slices (RS) features shall not be present. And, checking for those conditions is not simple, and not deterministic either, since there is no appropriate SPS level information for that. Only PPS level. So, with VA intel-driver 1.2.2 where Baseline profile is no longer exposed, gstreamer-vaapi should not crash and correctly stop. In this case, we can close as [WONTFIX].
Or [NOTABUG] for what it worth. :)
Adding this to 0.5.9, if needed.
(In reply to comment #5) > (In reply to comment #4) > > This clip is baseline profile. after driver upgrade. baseline was not supported > > anymore. gst-vaapi is hard to check whether a clip has Arbitrary slice ordering > > (ASO) in baseline by from codec_data. that means even a baseline clip without > > ASO, gst-vaapi pipeline still would fail it. > > This is not only for ILK but all GEN platform which only support > > constrained-baseline, main, high profiles. > > > > suggest mark as [won't fix]. > > We indeed cannot support Baseline profile in the general case on Intel HD > Graphics hardware (and many others actually). However, it is not correct to > cause a crash. So, if this still crashes with the latest release of the VA > intel-driver, then an additional fix is needed on the gstreamer-vaapi side. > > Having said that, it should be somewhat simple to support Baseline profile > streams with ASO. However, the Flexible Macroblock Ordering (FMO) and Redundant > Slices (RS) features shall not be present. And, checking for those conditions > is not simple, and not deterministic either, since there is no appropriate SPS > level information for that. Only PPS level. FMO can checked from num_of_slice_group in PPS. RS only from slice_data which not parsed by gst-vaapi. Is it possible to work around of Baseline to Main since conformance tests failed lots. and later consider check ASO/FMO > > So, with VA intel-driver 1.2.2 where Baseline profile is no longer exposed, > gstreamer-vaapi should not crash and correctly stop. In this case, we can close > as [WONTFIX].
(In reply to comment #8) > (In reply to comment #5) > > (In reply to comment #4) > > > This clip is baseline profile. after driver upgrade. baseline was not supported > > > anymore. gst-vaapi is hard to check whether a clip has Arbitrary slice ordering > > > (ASO) in baseline by from codec_data. that means even a baseline clip without > > > ASO, gst-vaapi pipeline still would fail it. > > > This is not only for ILK but all GEN platform which only support > > > constrained-baseline, main, high profiles. > > > > > > suggest mark as [won't fix]. > > > > We indeed cannot support Baseline profile in the general case on Intel HD > > Graphics hardware (and many others actually). However, it is not correct to > > cause a crash. So, if this still crashes with the latest release of the VA > > intel-driver, then an additional fix is needed on the gstreamer-vaapi side. > > > > Having said that, it should be somewhat simple to support Baseline profile > > streams with ASO. However, the Flexible Macroblock Ordering (FMO) and Redundant > > Slices (RS) features shall not be present. And, checking for those conditions > > is not simple, and not deterministic either, since there is no appropriate SPS > > level information for that. Only PPS level. > FMO can checked from num_of_slice_group in PPS. RS only from slice_data which > not parsed by gst-vaapi. > Is it possible to work around of Baseline to Main since conformance tests > failed lots. and later consider check ASO/FMO Only if SPS centains constraint_set1_flag iirc and this is what we do already. Doing anything else is wrong in the general case. You'd need to make the driver more robust and recoverable from GPU hang.
(In reply to comment #9) > Only if SPS centains constraint_set1_flag iirc and this is what we do already. > Doing anything else is wrong in the general case. You'd need to make the driver > more robust and recoverable from GPU hang. Then we have to tell QA to remove all baseline clips from their conformance tests, correct?
(In reply to comment #10) > (In reply to comment #9) > > Only if SPS centains constraint_set1_flag iirc and this is what we do already. > > Doing anything else is wrong in the general case. You'd need to make the driver > > more robust and recoverable from GPU hang. > Then we have to tell QA to remove all baseline clips from their conformance > tests, correct? Not necessarily remove, mark them as "expected to fail". There is an option for that IIRC. BTW, there are video tests that are correctly marked with "Baseline Profile" but with constraint_set1_flag set so that we can decode them with "Main Profile". So, the check for baseline profile specific coding tools should include profile_idc == 66 and constraint_set1_flag not set (= 0).
(In reply to comment #11) > Not necessarily remove, mark them as "expected to fail". There is an option for > that IIRC. > > BTW, there are video tests that are correctly marked with "Baseline Profile" > but with constraint_set1_flag set so that we can decode them with "Main > Profile". So, the check for baseline profile specific coding tools should > include profile_idc == 66 and constraint_set1_flag not set (= 0). This is constrained baseline. There are still many clips marked with profile_idc=66 and constraint_set1_flag=1 but doesn't have any FMO/ASO/RS would be failed.
(In reply to comment #12) > (In reply to comment #11) > > Not necessarily remove, mark them as "expected to fail". There is an option for > > that IIRC. > > > > BTW, there are video tests that are correctly marked with "Baseline Profile" > > but with constraint_set1_flag set so that we can decode them with "Main > > Profile". So, the check for baseline profile specific coding tools should > > include profile_idc == 66 and constraint_set1_flag not set (= 0). > This is constrained baseline. There are still many clips marked with > profile_idc=66 and constraint_set1_flag=1 but doesn't have any FMO/ASO/RS would > be failed. Again, you have zero deterministic way to know this beforehand. So, the better thing to do first is to fix the validation suite as mentioned before.
Thanks. Zhenxiang, please mark QA validation suite of baseline but not constrained-baseline profile as Gwenole's suggestion "expected to fail".
Mark as won't fix.