rtph264depay: simplify buffer accumulation control flow
authorTim-Philipp Müller <tim@centricular.com>
Fri, 26 May 2017 15:30:06 +0000 (16:30 +0100)
committerTim-Philipp Müller <tim@centricular.com>
Thu, 1 Jun 2017 16:32:17 +0000 (17:32 +0100)
commita68a7fb65d0d43bf032b494d23f5ab73154b3507
tree0ef70d848768423795e61942aed6a43382a3b722
parent72d2afda1876a3c0a263a125a965b32240e0a806
rtph264depay: simplify buffer accumulation control flow

There is no difference between pushing out a buffer directly
with gst_rtp_base_depayload_push() and returning it from the
process function. The base class will just call _depayload_push()
on the returned buffer as well.

So instead of marshalling buffers through three layers and back,
just push them from one place in handle_nal() and always return
NULL from the process vfunc. This simplifies the code a little.

Also rename _push_fragmentation_unit() to _finish_fragmentation_unit()
for clarity. Push sounds like it means being pushed out, whereas
it might just be pushed into an adapter.

This change has the side-effect that multiple NALs in a single STAP
(such as SPS/PPS) may no longer be pushed out as a single buffer if
we output NALs in byte-stream format (i.e. not aggregate AUs), but
that shouldn't really make any difference to anyone.
gst/rtp/gstrtph264depay.c