h264parse, h265parse: ITU-T conformance issues (regression)
Several h264 and h265 ITU-T conformance bitstreams (https://www.itu.int/net/ITU-T/sigdb/spevideo/Hseries-s.htm) no longer produce the expected decoded output when using h264parse and h265parse and decode element (e.g. vaapih264dec, vaapih265dec, msdkh264dec and msdkh265dec) since commits a194a87b and e88d8480. The MD5 (of decoded output) before and after these commits are different.
For example:
gst-launch-1.0 -vf filesrc location=AVCv1/CAMP_MOT_MBAFF_L30.26l \
! h264parse ! vaapih264dec ! video/x-raw,format=I420 \
! testsink expected-md5=`md5sum AVCv1/CAMP_MOT_MBAFF_L30_rec.yuv | cut -f1 -d" "`
test md5 returned value "10b7dd8b39f4de8d7d0b471840aefcb8" and not expected value "b360d7c05677d545fea9f35862aca50c"
Some of the conformance bitstreams known to be regressed are (may not be full list):
H.264
CAMP_MOT_MBAFF_L30CAMP_MOT_MBAFF_L31CAPCM1_Sand_E- CAPCMNL1_Sand_E
CVPCMNL1_SVA_CCVPCMNL2_SVA_C- CVWP5_TOSHIBA_E
- FRExt1_Panasonic_D
FRExt2_Panasonic_C- FRExt3_Panasonic_E
- FRExt4_Panasonic_B
HCAFR4_HHI_AHCHP3_HHI_A- HPCADQ_BRCM_B
- HPCAFLNL_BRCM_C
- HPCALQ_BRCM_B
- HPCAQ2LQ_BRCM_B
- HPCVNL_BRCM_A
- Sharp_MP_Field_2_B
- Sharp_MP_Field_3_B
- brcm_freh3
- brcm_freh4
- brcm_freh10
- brcm_freh11
H.265
AMP_B_Samsung_7- DELTAQP_A_BRCM_4
ENTP_A_QUALCOMM_1ENTP_B_Qualcomm_1IPRED_C_Mitsubishi_3LS_B_Orange_4MAXBINS_A_TI_5SAO_C_Samsung_5SAO_D_Samsung_5SDH_A_Orange_4TUSIZE_A_Samsung_1
commit a194a87b2600a21f1b47b8c89b1c930d5f30de42
Author: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Date: Tue Sep 25 16:10:13 2018 -0400
h264parse: Don't wait for next NAL if input is aligned
Waiting for the next NAL increases the latency. If alignment=nal/au
has been negotiated, assumes that the buffer contains a complete
NAL and don't expect a second start-code. This way, nal -> nal,
au -> au and au -> nal no longer introduce latency.
As a side effect, the collect_pad() function was not able to poke at the
following NAL. This call is now moved before processing the NAL, so
it's looking at the current NAL before it's ingested into the parser
state in order to dermin if the end of an AU has been reached. The AUD
injection state as been adapted to support this.
This change will break pipelines if alignment=nal is used without respecting the
alignment. Effectively, the parser will no longer fix the broken aligment
which will result in parser error and the termination of the pipeline. Such
issue existed in tsdemux element and might exist in any forks of that code.
Related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1193
commit e88d8480709581a2e54b7954c47193b729b23c79
Author: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Date: Tue Oct 9 16:01:08 2018 -0400
h265parse: Don't wait for next NAL if input is aligned
Waiting for the next NAL increases the latency. If alignment=nal/au
has been negotiated, assumes the the buffer contains a complete
NAL and don't expect a second start-code. This way, nal -> nal,
au -> au and au -> nal no longer introduce latency.
As a side effect, the collect_pad() function was not able to poke at the
following NAL. This call is now moved before processing the NAL, so
it's looking at the current NAL before it's ingested into the parser
state in order to dermin if the end of an AU has been reached. The AUD
injection state as been adapted to support this.
This change will break pipelines if alignment=nal is used without respecting the
alignment. Effectively, the parser will no longer fix the broken aligment
which will result in parser error and the termination of the pipeline. Such
issue existed in tsdemux element and might exist in any forks of that code.
Related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1193
Edited by Tim-Philipp Müller