- png: alloc size variable is a png type that's always 32-bit
- vpx: alloc size based on existing allocation
- wavpack: alloc size based on existing allocation
- icles: gdkpixbufoverlay: trusted and hard-coded input data
- rtp tests: rtp-payloading, vp8, vp9, h264, h265: trusted and/or static input data
g_memdup() is deprecated since GLib 2.68 and we want to avoid
deprecation warnings with recent versions of GLib.
Also use gst_buffer_new_memdup() instead of _wrapped(g_memdup(),..)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/993>
Add a new property "do-aggregate"* to the H.264 RTP payloader which
enables STAP-A aggregation as per [RFC-6184][1]. With aggregation enabled,
packets are bundled instead of sent immediately, up until the MTU size.
Bundles also end at access unit boundaries or when packets have to be
fragmented.
*: The property-name is kept generic since it might apply more widely,
e.g. STAP-B or MTAP.
[1]: https://tools.ietf.org/html/rfc6184#section-5.7
Closes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/434
When parsing NAL unit type in codec_data, check the 6bits of
NAL_unit_type only and do not require the array_completeness bit to be
0, since the default and mandatory value of array_completeness is 1 for
hvc1.
https://bugzilla.gnome.org/show_bug.cgi?id=768653
Handle sprop-vps, sprop-sps and sprop-pps in caps instead of
sprop-parameter-sets.
rtph265pay works with byte-stream and hvc1 formats but not hev1 yet. It
handles profile-id, tier-flag and level-id in caps query.
https://bugzilla.gnome.org/show_bug.cgi?id=753760
This way we can use -1 as special value, which is nicer than MAXUINT.
This is backwards compatible even with the GValue API, as shown by
a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=757892
Also make it so that the mtu is always set if specified, not
only in case of the rather weird bufferlist test code path.
This allows us to easily make the payloader fragment a payload
across multiple output packets by setting a small MTU on it.
Implementation according to RFC 4587.
Payloader create fragments on MB boundaries in order to match MTU size
the best it can. Some decoders/depayloaders in the wild are very strict
about receiving a continuous bit-stream (e.g. no no-op bits between
frames), so the payloader will shift the compressed bit-stream of a
frame to align with the last significant bit of the previous frame.
Depayloader does not try to be fancy in case of packet loss. It simply
drops all packets for a frame if there is a loss, keeping it simple.
https://bugzilla.gnome.org/show_bug.cgi?id=751886
The previous implementation had the formatting of SDP attributes happen
in each RTP payloader, now instead the constituent values are propagated
as caps fields. This allows for applications to do SDP offer/answer
based on caps negotiation.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=700748
rtph263ppay should accept any input compatible with its sink template
caps if it just outputs to e.g. udpsink or fakesink.
rtph263ppay ! rtph263pdepay should also work with any compatible input.
This would fail before with not-negotiated errors because the get_caps
function would see the encoding-name in the depayloader's template caps
and default to baseline H.263 because there's no profile/level information
in those caps, which is the right thing to do if downstream has filtercaps
from an SDP, but not if those fields are absent because they can be
anything like with the depayloader's template caps. Makes
videotestsrc ! avenc_h263p ! rtph263ppay ! rtph263pdepay ! fakesink
work.
Need to add h263version field to input caps since the
payloader sink get_caps function will contain it in the
the caps, and the stricter caps subset check requires
this to be present in the input caps as well then.
Feed data into the pipeline using appsrc instead of fdsrc and
a pipe. Store unsigned byte values in guint8 instead of char.
Getting rid of the capsfilter also helps to avoid 'format is
not fully specified' warnings when pushing "video/x-h264" data
into rtph264pay with fully specified h264 caps in the sink template.
