GNOME Bugzilla – Bug 744713
decoding errors on media encoded using CBR vaapi
Last modified: 2018-05-04 13:52:52 UTC
Hi When playing back content generated using videotestsrc pattern 1 (snow), there seems to be keyframe loss (green frames probably related to decoding error concealing by libav h264 decoder). Frame 1 displays properly, but frame 2 isn't properly decoded (see attachments) mpv / mplayer / ffprobe etc... reports "Truncated VUI" warnings, not sure if that's really related. Video has been generated using: gst-launch-1.0 videotestsrc pattern=1 num-buffers=60 ! timeoverlay ! "video/x-raw,format=(string)I420,width=(int)1920,height=(int)1080,framerate=(fraction)30/1" ! vaapiencode_h264 rate-control=cbr bitrate=40000 ! mp4mux ! filesink location=test.mp4 GST_DEBUG=3 gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! avdec_h264 ! xvimagesink -v ... 0:00:00.019065136 29849 0x7ffbe0001900 ERROR libav :0:: SEI type 191 truncated at 96 And vaapi fails to decode: GST_DEBUG=3 gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! vaapidecode ! vaapisink 0:00:00.091122654 30055 0x1eab230 WARN codecparsers_h264 gsth264parser.c:1216:gst_h264_parser_parse_sei_message: Bit non equal to one. 0:00:00.091192751 30055 0x1eab230 WARN codecparsers_h264 gsth264parser.c:1229:gst_h264_parser_parse_sei_message: error parsing "Sei message" 0:00:00.091200918 30055 0x1eab230 WARN vaapi gstvaapidecoder_h264.c:1605:parse_sei: failed to parse SEI messages 0:00:00.091213060 30055 0x1eab230 ERROR vaapidecode gstvaapidecode.c:795:gst_vaapidecode_parse_frame: parse error 8
Created attachment 297098 [details] frame 1 (correct)
Created attachment 297099 [details] frame2 (incorrect)
*** Bug 744712 has been marked as a duplicate of this bug. ***
I believe this is an issue in the encoder side, especially with/without packed headers.
Florent, Could you please try once more? I recently added the SEI header generation for CBR mode encoding in the h264 encoder. Also please use the parser element before the muxer in encoding pipeline. gst-launch-1.0 videotestsrc pattern=1 num-buffers=60 ! timeoverlay ! "video/x-raw,format=(string)I420,width=(int)1920,height=(int)1080,framerate=(fraction)30/1" ! vaapiencode_h264 rate-control=cbr bitrate=40000 ! vaapiparse_h264 ! mp4mux ! filesink location=test.mp4 gst-play-1.0 test.mp4
Hi To me the error is still here with gst (see below) and mpv/mplayer, even with the vaapiparse_h264 above: (GST_DEBUG=3 gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! avdec_h264 ! xvimagesink -v) Am i supposed to upgrade to a git release (did you ask me to try once more with newer code or with the parser)? My environment : gstreamer-vaapi 0.6.0 libva 1.6.1 libva-intel-driver 1.6.1 libdrm 2.4.65
I ran the test using gstreamer-vaapi master / libva and driver 1.6.2 / HSW / gstreamer master gst-launch-1.0 -ev videotestsrc pattern=1 num-buffers=60 ! timeoverlay ! \ video/x-raw,format=I420,width=1920,height=1080,framerate=30/1 ! \ vaapiencode_h264 rate-control=cbr bitrate=40000 ! h264parse ! \ mp4mux ! filesink location=test.mp4 When playing the video with vaapidecode, I can't see the green artifacts, though I see compression artifacts at the beginning, then it looks OK. But playing with avdec_h264 I see the green artifacts as in attached frame.
(In reply to Víctor Manuel Jáquez Leal from comment #7) > I ran the test using > > gstreamer-vaapi master / libva and driver 1.6.2 / HSW / gstreamer master > > gst-launch-1.0 -ev videotestsrc pattern=1 num-buffers=60 ! timeoverlay ! \ > video/x-raw,format=I420,width=1920,height=1080,framerate=30/1 ! \ > vaapiencode_h264 rate-control=cbr bitrate=40000 ! h264parse ! \ > mp4mux ! filesink location=test.mp4 > > > > When playing the video with vaapidecode, I can't see the green artifacts, > though I see compression artifacts at the beginning, then it looks OK. > > But playing with avdec_h264 I see the green artifacts as in attached frame. Strange !... We have to test it with avcenc in libva, Just to check whether the issue is related with PACKED SEI headers...
Moving to Product:GStreamer, Component:gstreamer-vaapi
Tried the same with ffmpeg + vaapi, but same result. So it should be investigated from driver side IMHO. Better file a bug against vaapi driver and provide the link to this bug report.
intel-vaapi-driver has evolved a lot since 2015. Please reopen if the problem persists.