GNOME Bugzilla – Bug 739291
gstreamer-vaapi stops decoding H.264 in a UK DVB-T2 stream
Last modified: 2014-11-14 14:38:08 UTC
A live UDP stream of BBC ONE HD fails to decode with gstreamer-vaapi running under gstreamer 1.4.3. A pcap of the stream is at http://90.155.96.198/sfarnsworth/bbcone-hd.pcap My problem pipeline is: gst-launch-1.0 -v udpsrc uri=udp://239.192.1.229:5000 ! queue ! tsdemux name=demux ! queue ! vaapiparse_h264 disable-passthrough=true ! vaapidecode ! queue ! vaapisink You can reproduce the failure with: gst-launch-1.0 -v filesrc location=/data/data/bbcone-hd.pcap ! pcapparse ! queue ! tsdemux name=demux ! queue ! vaapiparse_h264 disable-passthrough=true ! vaapidecode ! queue ! vaapisink I'll attach the full failure log. The last messages I get before video decode locks up completely are: 0:00:17.209290562 7468 0x152f2d0 ERROR vaapidecode gstvaapidecode.c:898:gst_vaapidecode_parse_frame: parse error 8 0:00:17.209697851 7468 0x152f2d0 ERROR vaapidecode gstvaapidecode.c:898:gst_vaapidecode_parse_frame: parse error 8 I have temporary access to a source of off-air DVB-T2, which I can use to reproduce this fault or generate more pcaps upon request.
Created attachment 289515 [details] Full failure log, with GST_DEBUG=tsdemux:4,vaapi*:4
Based on your logs, this looks like a parser error, where possible failure points are: (i) AUD NAL unit without an initial SPS NAL parsed so far, (ii) PPS or SEI NAL without a parent SPS NAL. I think it would even fail without vaapidecode. e.g. generating an mp4 file from that.
avdec_h264 copes fine with it, as do consumer STBs. vaapidecode, in contrast, stops decoding the video stream permanently upon hitting that parse error.
Hi Simon, (In reply to comment #3) > avdec_h264 copes fine with it, as do consumer STBs. > > vaapidecode, in contrast, stops decoding the video stream permanently upon > hitting that parse error. Could you please try current git master branch? I have synced with upstream git master branch for codecparsers and videoparsers/h264parse. However, I currently get this (unrelated) error with your pipeline: ERROR: from element /GstPipeline:pipeline0/GstPcapParse:pcapparse0: The stream is of a different type than handled by this element.
(oops, nevermind, wrong gstreamer prefix :)).
I still don't have happiness with git master as of: commit eeb43989c1cf92aa3bd88e330ecea95bb8ab3319 Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Wed Oct 29 17:30:30 2014 +0100 vaapipostproc: allow user defined scaling mode. Add new "scale-method" property to expose the scaling mode to use during video processing. Note that this is only a hint, and the actual behaviour may differ from implementation (VA driver) to implementation. avdec_h264 works fine, vaapidecode locks up as before (same error). The working pipeline is: gst-launch-1.0 udpsrc uri=udp://239.192.1.229:5000 ! queue ! tsdemux name=demux ! queue ! h264parse disable-passthrough=true ! avdec_h264 ! videoconvert ! video/x-raw,format=NV12 ! queue ! vaapisink This plays perfectly with no errors. If I change it to: gst-launch-1.0 udpsrc uri=udp://239.192.1.229:5000 ! queue ! tsdemux name=demux ! queue ! vaapiparse_h264 disable-passthrough=true ! vaapidecode ! queue ! vaapisink I get the "vaapidecode gstvaapidecode.c:898:gst_vaapidecode_parse_frame: parse error 8" error, and VA-API stops decoding video. The same error occurs if I replace vaapiparse_h264 with h264parse.
Created attachment 290310 [details] [review] codecparsers: h264: fix derivation of MaxPicNum variable Please try the attached patch. This should work for you, but I have not run the full conformance suite yet. Thanks.
That patch improves things; I can now play fine as long as I don't ask vaapipostproc to use advanced deinterlacing. With advanced deinterlacing enabled, I have problems; it goes juddery. If I invert tff in vaapipostproc, the streams get deinterlaced properly, but MPEG-2 now goes wrong. I suspect H.264 decoding doesn't set TFF correctly.
(In reply to comment #8) > That patch improves things; I can now play fine as long as I don't ask > vaapipostproc to use advanced deinterlacing. > > With advanced deinterlacing enabled, I have problems; it goes juddery. If I > invert tff in vaapipostproc, the streams get deinterlaced properly, but MPEG-2 > now goes wrong. > > I suspect H.264 decoding doesn't set TFF correctly. What platform and driver version (git hash) do you use for advanced deinterlacing?
This is on HSW i3-4350T. The driver in use is git ad3f8b5e of https://github.com/gbeauchesne/libva-intel-driver.git branch 17.vpp.vebox
Hi Simon, (In reply to comment #8) > That patch improves things; I can now play fine as long as I don't ask > vaapipostproc to use advanced deinterlacing. > > With advanced deinterlacing enabled, I have problems; it goes juddery. If I > invert tff in vaapipostproc, the streams get deinterlaced properly, but MPEG-2 > now goes wrong. > > I suspect H.264 decoding doesn't set TFF correctly. I have analyzed your stream further and I can confirm what you suspected. TFF was not set when it should. Besides, your stream further exposes SEI messages (pic_timing) with additional information that we need to cope with, e.g. pic_struct == 3. I will cook a couple of patches.
Created attachment 290636 [details] [review] decoder: h264: fix detection of top-field-first (TFF) flag Please try the attached patch in addition to the codecparsers/h264 one. This is the essential patch. A couple more patches deal with other issues or features.
Created attachment 290637 [details] [review] decoder: h264: fix picture ordering count type 0 with previous MMCO5
Created attachment 290638 [details] [review] decoder: h264: add initial support for repeat-first-field (RFF) flag
(In reply to comment #12) > Created an attachment (id=290636) [details] [review] > decoder: h264: add initial support for repeat-first-field (RFF) flag > > Please try the attached patch in addition to the codecparsers/h264 one. This is > the essential patch. A couple more patches deal with other issues or features. This should help, but is not fully correct. I will update it.
(In reply to comment #15) > (In reply to comment #12) > > Created an attachment (id=290636) [details] [review] [details] [review] > > decoder: h264: add initial support for repeat-first-field (RFF) flag > > > > Please try the attached patch in addition to the codecparsers/h264 one. This is > > the essential patch. A couple more patches deal with other issues or features. > > This should help, but is not fully correct. I will update it. forget about this comment, the TFF flag is propagated down to other fields correctly. Everything should be in order now, I will push the patches shortly. :)
Created attachment 290697 [details] [review] decoder: h264: fix detection of top-field-first (TFF) flag Changes: - Fixed split_fields() to set top or bottom field for the first field and TFF.
commit 8f71f74c5d67079c5addc3ecd99278bd413248f1 Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Thu Nov 13 15:13:24 2014 +0100 decoder: h264: add initial support for repeat-first-field (RFF) flag. Use the SEI pic_timing() message to track and propagate down the repeat first field (RFF) flag. This is only initial support as there is one other condition that could induce the RFF flag, which is not handled yet. commit a4048a9d6bc689f50b4b940782aa6a7c7740f772 Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Thu Nov 13 15:05:19 2014 +0100 decoder: h264: fix picture ordering count type 0 with previous MMCO5. Fix the decoding process for picture order count type 0 when the previous picture had a memory_management_control_operation = 5. In particular, fix the actual variable type for prev_pic_structure to hold the full bits of the picture structure. In practice, this used to work though, due to the underlying type used to express a gboolean. commit 415d5df7ee716fc5d8b652b359dc16187ab0e905 Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Thu Nov 13 15:00:21 2014 +0100 decoder: h264: fix detection of top-field-first (TFF) flag. Use the SEI pic_timing() message to track the pic_struct variable when present, or infer it from the regular slice header flags field_pic_flag and bottom_field_flag. This fixes temporal sequence ordering when the output pictures are to be displayed. https://bugzilla.gnome.org/show_bug.cgi?id=739291 commit c4f42114b41bd5ae78b79d529fc617e2906e4a96 Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Fri Nov 14 09:54:02 2014 +0100 codecparsers: update to gst-vaapi-branch commit 3d05d9f. 1241840 h264: fix derivation of MaxPicNum variable 3bd718e h264: fix GstH264ParserResult documentation typo b021609 h264parse: set the HEADER flag on buffers containing SPS or PPS b08e4be h264parse: don't unnecesarily set src_caps