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).
