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)
SRT[0] is an open source transport technology[1] that optimizes
streaming performance across unpredictable networks.
Although SRT is based on UDP, it works like connection-oriented
protocol. However, it doesn't mean that the SRT server or client
is necessarily to link to a receiver or a sender so, here, the
pairs of source and sink elements are introduced.
- srtserversink: SRT server to feed SRT stream
- srtclientsrc: SRT client to get SRT stream from srtserversink
- srtclientsink: SRT client to send SRT stream
- srtserversrc: SRT server to listen from srtclientsink
[0] https://github.com/Haivision/srt
[1] http://www.srtalliance.org/https://bugzilla.gnome.org/show_bug.cgi?id=785730
OpenJPEG 2.3 installs its headers to /usr/include/openjpeg-2.3. However,
since libopenjp2.pc seems to provide the right includedir CFLAGS at
least since version 2.1, instead of adding yet another version check,
just remove the subdir and the check for 2.2.
https://bugzilla.gnome.org/show_bug.cgi?id=788703
It is legal for a stream to reuse segments (marking discontinuities as
needed). Uplynk delivers such playlists for their placeholder loops.
Leave the URI scanning in place for playlists which have no
EXT-X-MEDIA-SEQUENCE tag. This should be harmless since the spec
requires these playlists to not be missing segments (RFC8216 6.2.2),
so we should be always matching on the first segment.
https://bugzilla.gnome.org/show_bug.cgi?id=788417
The function was basically one big if-else. Move the branch to the
one caller.
Currently, it's never called with previous_files == NULL. Assert that
this continues.
https://bugzilla.gnome.org/show_bug.cgi?id=788417
This simplifies the code a lot without any functional changes apart from
not closing the display connection. Closing the display connection is
not safe to do as it is shared between all other code in the same
process and no reference counting or anything happens at the platform
layer.
Ensure that region backgrounds are always show when tts:showBackground
is not explicitly set, in accordance with the default behavour given in
the TTML spec.
https://bugzilla.gnome.org/show_bug.cgi?id=787942
when using internal window, window resize should work
when pause state, but expose only do redisplay when
window_id is valid. So expose should do redisplay all
the time.
https://bugzilla.gnome.org/show_bug.cgi?id=787394
Move the package defines for GST_PLUGIN_DEFINE from the
command line into the source file to avoid quoting issues
(-DPACKAGE_NAME="foo" means the quotes won't actually make
it to the compiler and then it no longer gets a string constant).
1. Propagate the GstGLDisplay we create
2. Add the created GstGLContext to the propagated GstGLDisplay
Otherwise with multi-branch GL pipelines involving gtkglsink, things
will fall apart and errors will be genarated somewhere.
Except for gst/gl/gstglfuncs.h
It is up to the client app to include these headers.
It is coherent with the fact that gstreamer-gl.pc does not
require any egl.pc/gles.pc. I.e. it is the responsability
of the app to search these headers within its build setup.
For example gstreamer-vaapi includes explicitly EGL/egl.h
and search for it in its configure.ac.
For example with this patch, if an app includes the headers
gst/gl/egl/gstglcontext_egl.h
gst/gl/egl/gstgldisplay_egl.h
gst/gl/egl/gstglmemoryegl.h
it will *no longer* automatically include EGL/egl.h and GLES2/gl2.h.
Which is good because the app might want to use the gstgl api only
without the need to bother about gl headers.
Also added a test: cd tests/check && make libs/gstglheaders.check
https://bugzilla.gnome.org/show_bug.cgi?id=784779
This is useful for autoplay for example. With autoplay, it is necessary to
wait until the scene graph is fully set up. This signal is emitted once the
QML item node is ready. So, inside a connected slot, the pipeline's state
can be set to PLAYING to automatically start playback as soon as the QML
script is loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=786246
OpenJPEG 2.2 has some API changes and thus ships its headers in a new
include path. Add a configure check (to both meson and autoconf) to
detect the newer version of OpenJPEG and add conditional includes.
Fix the autoconf test for OpenJPEG 2.1, which checked for HAVE_OPENJPEG,
which was always set even for 2.0.
https://bugzilla.gnome.org/show_bug.cgi?id=786250
Otherwise we will get it again later for output, however this frame will
never actually be output so we will shift timestamps.
This is especially bad if we're handling a live stream where the first
frames are not keyframes. We would output the keyframe with the
timestamp of the first frame, and everything would be too late when
arriving in the sink.
If the version of the curl library is recent enough to allow support
for HTTP2 (i.e. CURL_VERSION_HTTP2 is defined) but does not actually
have that feature enabled, the call to
g_object_class_install_property() uses an incorrect default value for
the "http-version" property. The default should be 1.1 if HTTP2 is
not supported by libcurl or if not enabled by libcurl.
https://bugzilla.gnome.org/show_bug.cgi?id=786049
Previously this was broken, because a flushing seek causes unlock()
to be called and in the implementation of unlock() we close the
socket, so the seek errors out.
This patch fixes it by re-connecting before the seek.
Unfortunately, a seek does not work properly right after
re-connecting, so a small hack is also in place: we read 1 buffer
before seeking to allow librtmp to do its processing in RTMP_Read()
https://bugzilla.gnome.org/show_bug.cgi?id=785941
In some cases, it is possible that we need to update the manifest before
pads have been exposed at all. If there are no current pads, just expose
the next prepared streams. This doesn't handle the case where a manifest
update would happen while a live streams is changing periods, which is a
type of use case that we're unaware of real usages yet.
https://bugzilla.gnome.org/show_bug.cgi?id=783028
QML can destroy the video widget at any time, leaving
us with a dangling pointer. Use a lock and a proxy
object to cope with that, and block in the widget
destructor if there are ongoing calls into the widget.
Add a function to install the default RGBA pad templates,
but don't make them required so that there can be
GstGLFilter sub-classes with different input/output
caps if they want. Remove the hard-coded RGBA restriction in
the set_caps_features call, as it will be taken care
of by intersecting with the pad templates.
Update all the sub-classes to match
Build fails in ext/vulkan/xcb and ext/vulkan/wayland when:
* building from tarball
* building out-of-tree
* Only one WSI integration (xcb or wayland) is enabled by configure.ac
This is because vkconfig.h from source directory gets used instead
of the generated one.
Add the correct build directory to "-I". Use angle bracket
include in vkapi.h so that it actually looks in the include search
path instead of defaulting to the same (source tree) directory.
https://bugzilla.gnome.org/show_bug.cgi?id=784539
This reverts commit 1883ac26b7.
This breaks the build on older versions of openjpeg:
gstopenjpegdec.c:752:30: error: ‘opj_image_comp_t {aka struct opj_image_comp}’ has no member named ‘alpha’
https://bugzilla.gnome.org/show_bug.cgi?id=783591
This is wrong because:
* If the rate is negative we should check for the *previous* period
* adaptivedemux already does the proper checks before calling this
method
This ensures smoother playback. It looks weird if we first do a big
jump, then play a couple of consecutive frames, just to again skip ahead
quite a bit because we ran late again.
Far enough here means more than 500ms or 4 times the average keyframe
download time. There is no need to jump ahead by one average keyframe
download time in this case.
This makes playback smooth if the network is fast enough.
When dealing with key-unit trick mode downloads, the goal is to
provide the best "Quality of Experience". This is achieved by:
1) maximizing the number of frames displayed per second
2) avoiding "stalling" as much as possible (i.e. not downloading and
decoding frames fast enough)
This implementation achives this by:
1) Knowing very precisely the current keyframe being download (i.e
more accurate than at the fragment level which might contain more
than one keyfram). This is the new "actual_position" variable
introduced by this commit
2) Knowing the position of downstream (provided by QoS and stored
in the adaptivedemuxstream qos_earliest_time variable)
3) Knowing how long it takes to request and fully download a keyframe
(the average_download_time variable)
Taking those 3 variables into account, whenever a keyframe has been
pushed downstream we calculate a "target time" (target_time variable)
which is the ideal next keyframe time to request so that:
1) It will be requested/downloaded/demuxed/decoded in time to be
displayed without being too late
2) It will not be too far ahead that it would cause too few frames
per second to be displayed.
How far ahead we will request is inversily proportional to how close
the actual position (actual_position) is from the downstream
position (qos_earliest_time). The more is buffered between the source
and the sink, the "closer" the target time will be, and therefore
the more frames per seconds will be displayed (up to the limit
of keyframes_per_second * absolute_rate).
If a manifest has non-zero presentation time offset
(i.e., earliest presentation time specified by sidx box is not zero),
the initial sidx position shouldn't be zero. Since we cannot define
exact sidx position until parsing sidx box, set the value to unknown.
https://bugzilla.gnome.org/show_bug.cgi?id=782693
This embeds the muxer inside the sink and accepts elementary streams
while the old HLS sink required the muxer outside. Apart from that the
interface is the same as before.
Currently only mpegtsmux is supported, but support for other muxers is
just a matter of adding a property.
The advantage of the new sink is that it reduces complexity a lot and
properly handles pre-encoded streams with appropriately spaced
keyframes.
https://bugzilla.gnome.org/show_bug.cgi?id=781496
This patch bumps the required meson to 0.40.1 as gstreamer core just
did, and cleanup some code to use a feature from 0.37 that allow
specifying version range when checking dependency.
https://bugzilla.gnome.org/show_bug.cgi?id=780654
A common subtitling use case is live-generated subtitles, in which each
new word is contained in its own span, and the spans are displayed
sequentially, with the effect that lines of displayed subtitles are
built up word-by-word.
This can, however, cause problems when the number of words in a block is
greater than the number of allowed GstMemorys in a GstBuffer.
Since in this use case each span will have the same styling as adjacent
spans, we can join adjacent spans (and other inline elements, such as
breaks) into a single element containing the concatenated text of each,
thus avoiding the limit of GstMemorys in a GstBuffer and also reducing
the amount of styling/layout metadata that is attached to each buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=781725
The parser stores the text from each inline element of a scene in its
own GstMemory, which is inserted in the GstBuffer containing the scene
data. However, GstBuffers can contain only a limited number of
GstMemorys. Therefore, don't add more than the maximum number of
GstMemorys to each buffer, and warn if this is attempted.
https://bugzilla.gnome.org/show_bug.cgi?id=781725
When parsing <br> elements, store an actual newline in the text field of
the created TtmlElement. They then don't need to be treated as a
separate case from anon-span elements when being processed.
https://bugzilla.gnome.org/show_bug.cgi?id=781725
Encapsulates in a function the code that warns of an illegally
positioned element, rather than repeating the same code multiple times.
Also frees a string allocated by ttml_get_element_type_string, which was
previously being leaked.
https://bugzilla.gnome.org/show_bug.cgi?id=781725
../subprojects/gst-plugins-bad/ext/smoothstreaming/gstmssdemux.c: In function ‘gst_mss_demux_requires_periodical_playlist_update’:
../subprojects/gst-plugins-bad/ext/smoothstreaming/gstmssdemux.c:729:16: error: unused variable ‘mssdemux’ [-Werror=unused-variable]
GstMssDemux *mssdemux = GST_MSS_DEMUX_CAST (demux);
^~~~~~~~
cc1: all warnings being treated as errors
Without this, for streams where the content is stored indefinitely and
can be seeked on, the duration would never increase when in paused or,
until we reached near the end of the currently advertised stream (where
the internal fragment parser would see descriptions of new fragments).
The TTML spec has an issue in which tab (U+0009) characters that are
first in a sequence of whitespace characters are not suppressed at the
start and end of line areas. This issue was reported in [1] and the
editor of the TTML specs confirmed that this was not the intention
behind the spec.
The editor has created an issue to fix this in both the TTML1 and TTML2
specs [2], giving a proposal of what the spec should say. This patch
updates ttmlparse to implement the intended behaviour as proposed, in
which tabs in the input are converted to spaces before processing.
[1] https://github.com/w3c/imsc/issues/224
[2] https://github.com/w3c/ttml1/issues/235https://bugzilla.gnome.org/show_bug.cgi?id=781539
If multiple styles/regions with the same ID are present in the input
(which is not allowed in TTML), use the last and give a warning.
Fixes CID #1405134.
Clang's static analyser found potential code paths in which variables
were being used in comparisons when uninitialised. Fix by properly
handling out-of-range value returned by gst_ttml_get_element_index.
