GNOME Bugzilla – Bug 796179
Setting keyframe-period for the vaapih265enc element higher than 1024 causes decoder parse errors
Last modified: 2018-06-04 17:23:34 UTC
I am creating several bitstreams to evaluate the encoder quality of the Apollo Lake. I ran some tests with GStreamer 1.12 but needed to increase the keyframe-period parameter to a large number so only one I-Frame is used in the output stream. The 1.14.0 release has the required change to set the keyframe-period parameter higher than the previous 300. I set the keyframe-period to more frames than my filesrc and created a bitstream. When I put that bitstream through our Video Quality Measurement Tool it complained about missing references and the PSNR score dropped in half. I tried running a pipeline on the board that would encode and decode the video and it froze with a h265 parse error codes 8. Running the following pipeline: GST_DEBUG=3,"*vaapi*" gst-launch-1.0 filesrc location=Torture_Test_512x288.m4v ! decodebin3 ! vaapih265enc rate-control=2 bitrate=1024 keyframe-period=1025 max-bframes=0 ! vaapih265dec ! "video/x-raw,format=I420,width=512,height=288,framerate=30/1" ! vaapisink I get the following errors from the decoder: 0:00:10.181935933 14105 0x7efe4c004720 WARN codecparsers_h265 gsth265parser.c:807:gst_h265_parser_parse_short_term_ref_pic_sets: value greater than max. value: -1024, max 32767 0:00:10.181969187 14105 0x7efe4c004720 WARN codecparsers_h265 gsth265parser.c:845:gst_h265_parser_parse_short_term_ref_pic_sets: error parsing "ShortTermRefPicSet Parameters" 0:00:10.181986382 14105 0x7efe4c004720 WARN codecparsers_h265 gsth265parser.c:2181:gst_h265_parser_parse_slice_hdr: error parsing "Slice header" 0:00:10.182002670 14105 0x7efe4c004720 ERROR vaapidecode gstvaapidecode.c:1178:gst_vaapidecode_parse_frame: parse error 8 Hardware: Apollo Lake N3350 OS: Yocto Rocko 2.4.2 Build Configuration: BB_VERSION = "1.36.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal-4.8" TARGET_SYS = "x86_64-poky-linux" MACHINE = "intel-corei7-64" DISTRO = "poky" DISTRO_VERSION = "2.4.2" TUNE_FEATURES = "m64 corei7" TARGET_FPU = "" meta meta-poky meta-yocto-bsp = "rocko:342fbd6a3e57021c8e28b124b3adb241936f3d9d" meta-intel = "meta-intel-rocko-2.4.2:92d66730fba1fdc71d2548332c8ff57160e31b05" meta-qt5 = "rocko:7a52f924a0298857db99be20aca1484bb2b4e163" meta-sorenson = "master:35e3d0317fa829aac68c66c98140f1e7514544ea" Note: meta-sorenson updates GStreamer from 1.12 to 1.14
Reproducible simply as the following: gst-launch-1.0 videotestsrc ! vaapih265enc rate-control=2 bitrate=1024 keyframe-period=1025 max-bframes=0 ! vaapih265dec ! fakesink
Created attachment 372504 [details] [review] libs: encoder: h265: increase a range of log2_max_pic_order_cnt according to the spec The specification says, "log2_max_pic_order_cnt_lsb_minus4 shall be in the range of 0 to 12, inclusive."
(In reply to Hyunjun Ko from comment #2) > Created attachment 372504 [details] [review] [review] > libs: encoder: h265: increase a range of log2_max_pic_order_cnt according > to the spec > > The specification says, > "log2_max_pic_order_cnt_lsb_minus4 shall be in the range of 0 to 12, > inclusive." Which specification did you quote? Can I get a copy of the specification?
(In reply to Brent Giles from comment #3) > (In reply to Hyunjun Ko from comment #2) > > Created attachment 372504 [details] [review] [review] [review] > > libs: encoder: h265: increase a range of log2_max_pic_order_cnt according > > to the spec > > > > The specification says, > > "log2_max_pic_order_cnt_lsb_minus4 shall be in the range of 0 to 12, > > inclusive." > > Which specification did you quote? Can I get a copy of the specification? Rec. ITU-T H.265 v3 (04/2015) you can google it.
Comment on attachment 372504 [details] [review] libs: encoder: h265: increase a range of log2_max_pic_order_cnt according to the spec nice!
Regardless the patch, which looks right on its own, I cannot replicate the bug anymore, using 1.14 branches, and I don't understand why, since nothing have changed in the h265 parser or vaapi :/
There was bug fix and enhancement in the profile parsing, does that count?
Comment on attachment 372504 [details] [review] libs: encoder: h265: increase a range of log2_max_pic_order_cnt according to the spec In master: Attachment 372504 [details] pushed as 676e5583 - libs: encoder: h265: increase log2_max_pic_order_cnt range according to spec
in branch 1.14 * 7b0375a4 libs: encoder: h265: increase log2_max_pic_order_cnt range according to spec
branch 1.12 * f3b297c4 libs: encoder: h265: increase log2_max_pic_order_cnt range according to spec
Though I couldn't reproduce it, I'm going to close this bug assuming Hyunjun's patch fixes the issue. @Brent, if the issue is not fixed, please reopen the issue.