It is really easy to break the API and insert a new video format in the
middle of the enum instead of at the end. This minimal test should catch
the most obvious errors. Ideally, this test should be updated after new
format have been added, so that it won't allow further modification to
the enumeration API.
rtpbasedepayload.c:126:5: error: unknown conversion type character 'z' in format [-Werror=format]
profile.c:688:10: error: unused variable 'gst_dir' [-Werror=unused-variable]
Allow fallback to orc subproject if any.
Additionally 'dependencies' keyword is removed from find_library,
because it's invalid keyword for find_library.
Binding the vertex array to 0 will unbind everything else already.
In the previous order older versions of the Intel GL driver caused
errors to be printed for every single call when disabling the vertex
attrib arrays after binding the vertex array to 0.
ISO 14496-3 defines that audioObjectType 5 is a special case that
indicates SBR is present and that an additional field has to be
parsed to find the true audioObjectType.
There are two ways of signaling SBR within an AAC stream - implicit
and explicit (see [1] section 4.2). When explicit signaling is used,
the presence of SBR data is signaled by means of the SBR
audioObjectType in the AudioSpecificConfig data.
Normally the sample rate is specified by an index into a
table of common sample rates. However index 0x0f is a special case
that indicates that the next 24 bits contain the real sample rate.
[1] https://www.telosalliance.com/support/A-closer-look-into-MPEG-4-High-Efficiency-AACFixes#39
The old API would only assert or return an invalid timecode, the new API
returns a boolean or NULL. We can't change the existing API
unfortunately but can at least deprecate it.
... instead of hardcoded ':', since G_SEARCHPATH_SEPARATOR_S
varies depending on OS (e.g., ':' for *nix and ';' for Windows).
Note that, when the seperator is not specified explicitly, Meson
will use ';' for Windows and ':' for *nix respectively.
According to RFC3611, the extended report blocks in XR packet can
have variable length. To visit each block, the iterator should look
into block header. Once XR type is extracted, users can parse the
detailed information by given functions.
Loss/Duplicate RLE
The Loss RLE and the Duplicate RLE have same format so
they can share parsers. For unit test, randomly generated
pseudo packet is used.
Packet Receipt Times
The packet receipt times report block has a list of receipt
times which are in [begin_seq, end_seq).
Receiver Reference Time paser for XR packet
The receiver reference time has ntptime which is 64 bit type.
DLRR
The DLRR report block consists of sub-blocks which has ssrc, last RR,
and delay since last RR. The number of sub-blocks should be calculated
from block length.
Statistics Summary
The Statistics Summary report block provides fixed length
information.
VoIP Metrics
VoIP Metrics consists of several metrics even though they are in
a report block. Data retrieving functions are added per metrics.
https://bugzilla.gnome.org/show_bug.cgi?id=789822
The unit test makes mixed usage of ret value. Sometimes its does
stores an enum and at other moment a boolean. Also fix test
using boolean instead of the correct enum value.
https://bugzilla.gnome.org/show_bug.cgi?id=783521
This removes the crossfade-ratio property and replaces it with an
operator property. Currently this implements the following operators:
- SOURCE: Copy over the source and don't look at the destination
- OVER: Default blending of the source over the destination
- ADD: Like OVER but simply adding the alpha instead
See the example for how to implement crossfading with this.
https://bugzilla.gnome.org/show_bug.cgi?id=797169
The previous failure was a timeout which was due to the sending pipeline
pushing test buffer *before* the remote client was accepted. We would
therefore never get the buffer on the other side.
While the client socket would indeed appear as "connected", this doesn't
mean that the remote server side did "accept" it (which is where we then
add it to the list of remote parties to which data will be sent).
The problem isn't with the element implementation, but to the nature of
TCP 3-way handshake.
In order to make the test reliable, wait for the sink to have accepted
the remote client (by checking the number of handles) before sending out
test buffers.
Add a source-info property that will read/write meta to the buffers
about RTP source information. The GstRTPSourceMeta can be used to
transport information about the origin of a buffer, e.g. the sources
that is included in a mixed audio buffer.
A new function gst_rtp_base_payload_allocate_output_buffer() is added
for payloaders to use to allocate the output RTP buffer with the correct
number of CSRCs according to the meta and fill it.
RTPSourceMeta does not make sense on RTP buffers since the information
is in the RTP header. So the payloader will strip the meta from the
output buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=761947
