h264_mp4toannexb: Try to avoid four byte startcodes
authorAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
Sat, 14 Dec 2019 22:19:20 +0000 (23:19 +0100)
committerMichael Niedermayer <michael@niedermayer.cc>
Thu, 5 Mar 2020 23:58:31 +0000 (00:58 +0100)
commit518bbe9eac0da3bdf259e007e7031a7bccacbe8e
tree06847bfe754f96080f87e627ccb44259c527017b
parentaa486b4b66ee3e1f835230856087c5436a522e40
h264_mp4toannexb: Try to avoid four byte startcodes

According to the H.264 specifications, the only NAL units that need to
have four byte startcodes in H.264 Annex B format are SPS/PPS units and
units that start a new access unit. Before af7e953a, the first of these
conditions wasn't upheld as already existing in-band parameter sets
would not automatically be written with a four byte startcode, but only
when they already were at the beginning of their input packets. But it
made four byte startcodes be used too often as every unit that is written
together with a parameter set that is inserted from extradata received a
four byte startcode although a three byte start code would suffice
unless the unit itself were a parameter set.

FATE has been updated to reflect the changes. Although the patch leaves
the extradata unchanged, the size of the extradata according to the FATE
reports changes. This is due to a quirk in ff_h2645_packet_split which
is used by extract_extradata: If the input is Annex B, the first zero of
a four byte startcode is considered a part of the last unit (if any).

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
libavcodec/h264_mp4toannexb_bsf.c
tests/ref/fate/h264-bsf-mp4toannexb
tests/ref/fate/h264_mp4toannexb_ticket2991
tests/ref/fate/h264_mp4toannexb_ticket5927
tests/ref/fate/h264_mp4toannexb_ticket5927_2
tests/ref/fate/segment-mp4-to-ts