Sometimes it is useful to know this information on the
server side. Other popular implementations (vlc, ffmpeg, ...)
also send this header on every message.
This includes a new "user-agent" property that the user
can set to use a custom User-Agent string. The default
is "GStreamer/<version>"
https://bugzilla.gnome.org/show_bug.cgi?id=750101
Use constantDuration to calculate the timestamp of non-first AU in the
RTP packet.
If constantDuration is not present in the MIME parameters, its value
must be calculated based on the timing information from two consecutive
RTP packets with AU-Index equal to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=747881
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
This commit adds support for ISOBMFF Common Encryption (cenc), as
defined in ISO/IEC 23001-7. It uses a GstProtection event to
pass the contents of PSSH boxes to downstream decryptor elements
and attached GstProtectionMeta to each sample.
https://bugzilla.gnome.org/show_bug.cgi?id=705991
GstRTSPMedia uses this classification to detect the real payloader
inside a dynpay bin and asserts if it doesn't find it, therefore
it is required
https://bugzilla.gnome.org/show_bug.cgi?id=753325
Initialize the PT to the default value of the codec and check if
it is still the default before declaring the pt to be dynamic or
not when setting the caps.
Also use the PT constants from the rtp lib when possible
https://bugzilla.gnome.org/show_bug.cgi?id=747965
We need a proper caps event from upstream with the full RTP caps as we can't
create caps ourselves from thin air. Fixes usage of rtpstreamdepay after e.g.
a filesrc or any other element that supports pull mode.
https://bugzilla.gnome.org/show_bug.cgi?id=753066
h264parse does the same, let's keep the behaviour consistent. As we now
include the codec_data inside the stream too here, this causes less caps
renegotiation.
The spec says:
When a picture parameter set NAL unit with a particular value of
pic_parameter_set_id is received, its content replaces the content of the
previous picture parameter set NAL unit, in decoding order, with the same
value of pic_parameter_set_id (when a previous picture parameter set NAL unit
with the same value of pic_parameter_set_id was present in the bitstream).
If the GOP is completed, pads have to start gathering for the
next one but it is possible that the the state might go to
COLLECTING_GOP_START and back to WAITING_GOP_COMPLETE before the
thread has a chance to wake up and proceed, leaving it trapped in
the check_completed_gop loop and deadlocking the other threads
waiting for it to advance.
To solve it, this patch also checks that tha input running time
hasn't changed to prevent this scenario.
h264parse does the same and this fixes decoding of some streams with 32 SPS
(or 256 PPS). It is allowed to have SPS ID 0 to 31 (or PPS ID 0 to 255), but
the field in the codec_data for the number of SPS or PPS is only 5 (or 8) bit.
As such, 32 SPS (or 256 PPS) are interpreted as 0 everywhere.
This looks like a mistake in the part of the spec about the codec_data.
In media to caps function, reserved_keys array is being used for variable i,
leading to GLib-CRITICAL **: g_ascii_strcasecmp: assertion 's1 != NULL' failed
changed it to variable j
https://bugzilla.gnome.org/show_bug.cgi?id=753009
Skip keys from the fmtp, which we already use ourselves for the
caps. Some software is adding random things like clock-rate into
the fmtp, and we would otherwise here set a string-typed clock-rate
in the caps... and thus fail to create valid RTP caps
https://bugzilla.gnome.org/show_bug.cgi?id=753009
