h264parse: Don't wait for next NAL if input is aligned
authorNicolas Dufresne <nicolas.dufresne@collabora.com>
Tue, 25 Sep 2018 20:10:13 +0000 (16:10 -0400)
committerNicolas Dufresne <nicolas@ndufresne.ca>
Wed, 15 Apr 2020 14:10:15 +0000 (14:10 +0000)
commita194a87b2600a21f1b47b8c89b1c930d5f30de42
treee8b317a07a17f63758c3f74a6b321441dcd5bf7c
parentea99aee8814cf1c6b59edf2a95b888af5bf0d2c4
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
gst/videoparsers/gsth264parse.c