- Sep 18, 2017
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Sep 16, 2017
-
-
this incidentally fixes a missing g_source_destroy() call in _main() https://bugzilla.gnome.org/show_bug.cgi?id=787727
- Sep 08, 2017
-
-
If bo allocation failed we destroy the buffer and return GST_FLOW_ERROR, but the @buffer pointer was still pointing to the address of the destroyed buffer. gst_kms_sink_copy_to_dumb_buffer() was then trying to unref it when bailing out causing a crash. Leave @buffer untouched if allocation failed to fix the crash. Also remove the check on *buffer being not NULL as gst_buffer_new() will abort if it failed. https://bugzilla.gnome.org/show_bug.cgi?id=787442
-
- Sep 07, 2017
-
-
This was already added and tested in autoconf.
-
OpenSSL 1.1.0 no longer allows stack-allocated structures; it hides the implementation behind typedefs https://bugzilla.gnome.org/show_bug.cgi?id=787309
-
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).
- Aug 25, 2017
-
-
Philippe Normand authored
The media-info-updated signal is now emitted before duration-changed since commit 8a29da80. https://bugzilla.gnome.org/show_bug.cgi?id=786201
-
- Aug 17, 2017
-
-
Tim-Philipp Müller authored
From 48a5d85 to dd9d403
-
2.2 implies HAVE_2_1
-
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
-
- Aug 16, 2017
-
-
Otherwise we have problems with the new gtk-doc ported to python. But it's a good thing to do anyway. https://bugzilla.gnome.org/show_bug.cgi?id=786364
-
- Aug 15, 2017
-
-
Philippe Normand authored
This is a follow-up of 98b0802a https://bugzilla.gnome.org/show_bug.cgi?id=786201
-
- Aug 14, 2017
-
-
- Aug 11, 2017
-
-
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
-
There can be twice as many stream tasks running as there are output pads for playback of variant HLS playlists. Half of them are the current pads, and the other half are the pads that are about to be switched to due to a bitrate change. The old code only stopped the current streams which could result in a deadlock on stopping the pipeline. The changes force stopping and joining of any prepared streams too. https://bugzilla.gnome.org/show_bug.cgi?id=785987
-
Sebastian Dröge authored
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.
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
This is better than reporting no latency at all and then later failing in live pipelines. https://bugzilla.gnome.org/show_bug.cgi?id=786036
-
Sebastian Dröge authored
This structure is only ever read from.
-
- Aug 08, 2017
-
-
This commit ensures that the idle probe which GstAdaptiveDemuxStream adds to the upstream source pad is removed after use. Previously a new probe was added to the pad whenever a fragment was downloaded, meaning the number of pad probe callbacks being executed increased continually. https://bugzilla.gnome.org/show_bug.cgi?id=785957
-
- Jul 25, 2017
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
This allows us to know exactly where in the material track we are, and how to convert from a PTS for a source track to the actual PTS of the material track (i.e. by adding the component start position). https://bugzilla.gnome.org/show_bug.cgi?id=785119
-
Sebastian Dröge authored
While the size in the packet is only 16 bits, we need to handle bigger sizes without overflowing. For video streams this can happen, 0 is written to the stream instead. This fixes muxing of buffers >= 2**16.
-
- Jul 17, 2017
-
-
On systems without pkg-config, we have the the library present but not the headers https://bugzilla.gnome.org/show_bug.cgi?id=785010
- Jul 16, 2017
-
-
Philippe Normand authored
Make sure the window handle is configured after the NSWindow was created. https://bugzilla.gnome.org/show_bug.cgi?id=767462
-
Matthew Waters authored
Avoids dereferencing dead objects What happens in the autovideosink case is that context 1 is created and destroyed before all the async operations hae executed on the associated window. When the delayed operations execute, they then reference dead objects and crash. We fix this by keeping refs over all async operations so the object cannot be deleted while async operations are in flight. https://bugzilla.gnome.org/show_bug.cgi?id=782379
-
- Jul 14, 2017
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Jul 13, 2017
-
-
This is a workaround for a regression introduced by f4190a49 ( adaptivedemux: Check live seeking range more often ) The goal of the previous commit was to be able to cope with non-1.0 rates on live streams which have a "seeking window" (i.e. the server keeps around quite a bit of the live stream so you can seek back into it). Without that commit, two different kind of issues would happen: * When doing reverse playback, you would never check whether you are outside of the seekable region. And would then continuously try to download fragments that are no longer present. * When doing fast forward, you would end up requesting fragments which are not present yet. In order to determine whether one was *really* outside of the seekable window, we check whether the current stream position is still within the seekable region. The *problem* though with that commit is that it assumes that subclasses will return continuously updated seeking ranges (i.e. dependent on the current time), which is *NOT* the case. For example: * dashdemux does use the current UTC to determine the seekable region * hlsdemux uses the values from the last updated manifest Therefore if one downloads fragments faster than realtime, for HLS we would end up at the end of the last manifest seekable range, and the previous commit would consider the stream as being ended... which is not the case. In the long run, we need to figure out a way to cope with non-1.0 rates on live streams for all types of stream (including HLS). https://bugzilla.gnome.org/show_bug.cgi?id=783075
-
Move segment event update to a function https://bugzilla.gnome.org/show_bug.cgi?id=773159
-
This is a race that was exposed by the {hls|dash}.scrub_forward_seeking validate test. The "race" is that a subclass might want to change format, causing a new stream to be created (but not exposed/switched yet) and put on the prepared_streams list. That stream will have values (including pending segment) from the pre-seek state. Before the stream is exposed/switched, a new seek comes in and the stream values get updated ... but the ones that will be changed don't get updated causing them to push out wrong segments once they are exposed. https://bugzilla.gnome.org/show_bug.cgi?id=773159
-
Sebastian Dröge authored
-
Sebastian Dröge authored
When seeking backwards into a previously unseen location, we wouldn't fully initialize them and playback would fail later.
-