Commit graph

10 commits

Author SHA1 Message Date
Thibault Saunier
5ff769d731 Move files from gst-plugins-good into the "subprojects/gst-plugins-good/" subdir 2021-09-24 16:13:50 -03:00
Stéphane Cerveau
80f8780e92 rtp: allow per feature registration
Split plugin into features including
dynamic types which can be indiviually
registered during a static build.

More details here:

https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/199
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/661

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/876>
2021-03-29 12:45:22 +02:00
Matthew Waters
ea61714c70 rtph26*depay: drop FU's without a corresponding start bit
If we have not received a FU with a start bit set, any subsequent FU
data is not useful at all and would result in an invalid stream.

This case is constructed from multiple requirements in
RFC 3984 Section 5.8 and RFC 7798 Section 4.4.3.  Following are excerpts
from RFC 3984 but RFC 7798 contains similar language.

The FU in a single FU case is forbidden:

   A fragmented NAL unit MUST NOT be transmitted in one FU; i.e., the
   Start bit and End bit MUST NOT both be set to one in the same FU
   header.

and dropping is possible:

   If a fragmentation unit is lost, the receiver SHOULD discard all
   following fragmentation units in transmission order corresponding to
   the same fragmented NAL unit.

The jump in seqnum case is supported by this from the specification
instead of implementing the forbidden_zero_bit mangling:

   If a fragmentation unit is lost, the receiver SHOULD discard all
   following fragmentation units in transmission order corresponding to
   the same fragmented NAL unit.

   A receiver in an endpoint or in a MANE MAY aggregate the first n-1
   fragments of a NAL unit to an (incomplete) NAL unit, even if fragment
   n of that NAL unit is not received.  In this case, the
   forbidden_zero_bit of the NAL unit MUST be set to one to indicate a
   syntax violation.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/730>
2020-09-21 08:08:38 +00:00
Tim-Philipp Müller
8da79ca824 rtph265depay: store negotiated output format as enum
We keep the boolean byte_stream around since it's nicer for
readability and most of the code just cares about byte_stream
or not. This is useful for future-proofing the code for when
we add support for hev1 output as well.
2017-11-23 09:36:15 +01:00
Tim-Philipp Müller
2d0ea4d381 rtph265depay: try to negotiate an allocator with downstream 2017-11-23 09:36:15 +01:00
Tim-Philipp Müller
7f9f3d38b2 rtp: h265: use common meta utility functions
https://bugzilla.gnome.org/show_bug.cgi?id=761606
2016-02-16 00:25:46 +00:00
Tim-Philipp Müller
714d31ce30 rtp: h265: remove codecparser dependency from h265 payloader/depayloader
Looks like it just uses the NAL enums and nothing else from
the codecparsers, and that's the only reason it had to be
moved from -good to -bad when it was originally added. We
can probably keep those NAL enums up to date enough, so let's
remove the codecparser dependency so it can be moved back into
-good.

https://bugzilla.gnome.org/show_bug.cgi?id=761606
2016-02-16 00:25:41 +00:00
Luis de Bethencourt
139108c83a gstrtph265depay: keep consistency with rtph264depay
Use gst_rtp_drop_meta() and the same function prototype for
gst_rtp_copy_meta() to keep consistency with the RTP elements in
gst-plugins-good
2016-02-16 00:24:41 +00:00
Luis de Bethencourt
f1e2849438 rtph265depay: copy metadata in the depayloader, but only the relevant ones
The payloader didn't copy anything so far, the depayloader copied every
possible meta. Let's make it consistent and just copy all metas without
tags or with only the video tag.

https://bugzilla.gnome.org/show_bug.cgi?id=751774
2016-02-16 00:24:40 +00:00
Thijs Vermeir
544c0d75ce rtp: add h265 RTP payloader + depayloader 2016-02-16 00:24:40 +00:00