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_L30
• CAMP_MOT_MBAFF_L31
• CAPCM1_Sand_E
• CAPCMNL1_Sand_E
• CVPCMNL1_SVA_C
• CVPCMNL2_SVA_C
• CVWP5_TOSHIBA_E
• FRExt1_Panasonic_D
• FRExt2_Panasonic_C
• FRExt3_Panasonic_E
• FRExt4_Panasonic_B
• HCAFR4_HHI_A
• HCHP3_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_1
• ENTP_B_Qualcomm_1
• IPRED_C_Mitsubishi_3
• LS_B_Orange_4
• MAXBINS_A_TI_5
• SAO_C_Samsung_5
• SAO_D_Samsung_5
• SDH_A_Orange_4
• TUSIZE_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