Fixes ffeb09e4ab
if (sscanf(...)) { // != 0
error;
}
Is not correct where != 0 indicates some kind of success.
Check instead that the correct number of elements were slurped.
SDP's are generated and consumed according to the W3C PeerConnection API
available from https://www.w3.org/TR/webrtc/
The SDP is either created initially from the connected
sink pads/attached transceivers as in the case of generating an offer or
intersected with the connected sink pads/attached transceivers as in
the case for creating an answer. In both cases, the rtp payloaded streams
sent by the peer are exposed as separate src pads.
The implementation supports trickle ICE, RTCP muxing, reduced size RTCP.
With contributions from:
Nirbheek Chauhan <nirbheek@centricular.com>
Mathieu Duponchelle <mathieu@centricular.com>
Edward Hervey <edward@centricular.com>
https://bugzilla.gnome.org/show_bug.cgi?id=792523
By removing the indirection to the main loop completely when receiving
the peer certificate. For reference, the on-decoder-key signal does not
have a redirection.
We call the base class first as this will remove the pad from
the aggregator, thus stopping misc callbacks from being called,
one of which (process_textures) will recreate the vertex_buffer
if it is destroyed
https://bugzilla.gnome.org/show_bug.cgi?id=760873
For libsrtp 1, add defines that translate the new namespaced identifiers
to the old unnamespaced ones. Also move the code for setting and getting
a stream's ROC into two compat functions that match libsrtp2's API.
It seems that libsrtp2 properly supports changing the ROC without having
to touch the sequence numbers afterwards, given that srtp_set_stream_roc
sets a pending_roc field, so the entire roc_changed dance should not be
needed anymore. The compat functions for libsrtp 1 just contain our
preexisting hacks, however, so it's still needed there.
libsrtp2 has no means of discovering the streams in the session, so to
create the stats structure we need to iterate over our own set of SSRCs.
For this we also need to re-add the previously removed ssrcs_set to the
encoder.
https://bugzilla.gnome.org/show_bug.cgi?id=776901
Fix regression when used in combination with new flvmux which was
ported to GstAggregator, and which sends plain video/x-flv caps
before sending full caps that include streamheaders.
Instead of a massive if/else/if/else/if/else/...:
* Use a common cleanup path for allocated items just before leaving
the function (which will be free-d only if we're not dealing with
a delayed SPU).
* "goto" that cleanup path wherever needed
CID #1427096
CID #1427114
In file included from ../../../gst-plugins-bad/ext/gl/gstopengl.c:47:0:
../../../gst-plugins-bad/ext/gl/gstglmixerbin.h:25:29: fatal error: gst/video/video.h: No such file or directory
This is to mimic LV2 and what is commonly documented over the
web. We also completely track these directories when updating
the cache now. Unlike LV2, the plugins are flat in the plugin
directories, so no need for the recursive lookup. This also fixes
support for Fedora and other architecture using lib64 as a libdir.
While keeping it simple, this patch tries and mimic lilv default path.
It does not matter if some path are duplicated due to symlink because in
the end it's lilv that will walk these paths. The worst case is that we
update our cache more often then strictly needed.
https://bugzilla.gnome.org/show_bug.cgi?id=791717
The AVERAGE-BANDWIDTH attribute in the EXT-X-STREAM-INF tag represents
the average segment bit rate of the Variant Stream, while the BANDWIDTH
attribute represents the peak segment bit rate of the Variant Stream.
(https://tools.ietf.org/html/draft-pantos-http-live-streaming-23#section-4.3.4.2)
Using the average bit rate instead of the peak bit rate for variant switching
is more efficient and appropriate. Sometimes due to VBR encoding,
the BANDWIDTH may represent a value way above the average bit rate,
which could result to players not switching to that variant stream
although network bandwidth is sufficiently available.
https://bugzilla.gnome.org/show_bug.cgi?id=790821
gstsrt.c: In function ‘gst_srt_client_connect_full’:
gstsrt.c:151:6: error: ‘sock’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (sock != SRT_INVALID_SOCK) {
https://bugzilla.gnome.org/show_bug.cgi?id=791302
When compiling with clang, an enum conversion error is triggered
since GstVideoFrameFlags are not GstVideoFlags.
This patch sets GST_VIDEO_FRAME_FLAG_NONE to the added video meta.
https://bugzilla.gnome.org/show_bug.cgi?id=791251
This patch adds code to gldownload to export the image as a
dmabuf if requested. The element now exposes memory:DMABuf as
a cap feature, and if it is selected, the element exports the
texture to an EGL image and then a dmabuf. It also implements a
fallback to system memory download in case the exportation failed.
https://bugzilla.gnome.org/show_bug.cgi?id=776927
We change the video info base on the received buffer. We need to
rollback these changes whenever we want to copy into our internal
pool of buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=790057
The SHM interface does not allow passing arbitrary strides and offsets,
for this reason, we simply disable this feature from the proposed pool.
This fixes video artifact seen when using the FFMPEG based video
decoder.
https://bugzilla.gnome.org/show_bug.cgi?id=790057
This reverts commit 47fd4d391e.
This patch is incorrect. It doesn't actually compile, and causes a crash
because the viv-fb window implementation needs a native EGL handle
to pass to fbCreateWindow, but the GstGLDisplayEGL handleis actually
an EGLDisplay now (and gets cast to the wrong type)
