- Dec 03, 2019
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Dec 02, 2019
-
-
Since macOS Mojave (10.14), video permissions have to be explicitly granted by a user in order to open a video device such as a camera. This commit adds a check for the current permission status, and tries to request for permission if applicable.
-
commit 6adfb120 added this flag to fix builds with `-Werror`, and afterwards it was changed to use a version check when newer versions of openexr moved over to C++11. However, some distros have backported patches to older openexr versions which make it require C++11, which makes the version check incorrect and causes an error because we passed `-Werror -std=c++98`. Instead, directly check when usage of the header requires `-std=c++98` with `-Werror` and override the `cpp_std` setting on the target. Fixes #1117
-
- Nov 28, 2019
-
-
We need to ignore the data we get from WASAPI in this case and write out silence (zeroes). Initially reported at gstreamer/gst-plugins-bad#808
-
The whole `src_read()` function is a hot loop since the ringbuffer thread is waiting on us, and printing to the console from inside it can easily cause us to miss our deadline. F.ex., if you had GST_DEBUG=3 and we accidentally missed a device period, we'd trigger the "reported glitch" warning, which would cause us to miss another device period, and so on. Let's reduce the log level so that GST_DEBUG=3 is more usable, and only print buffer flag info when it's actually relevant.
-
Some audio drivers return varying amounts of data per ::GetBuffer call, instead of following the device period that they've told us about in `src_prepare()`. Previously, we would just drop those extra buffers hoping that the extra buffers were temporary (f.ex., a startup 'burst' of audio data). However, it seems that some audio drivers, particularly on older Windows versions (such as Windows 10 1703 and older) consistently return varying amounts of data. Use GstAdapter to smooth that out, and hope that the audio driver is locally varying but globally periodic. Initially reported in gstreamer/gst-plugins-bad#808
-
bpf = bytes per frame.
-
We were miscalculating the device period, i.e. the number of frames we'll get from WASAPI in each IAudioClient::GetBuffer call, due to a calculation mistake (truncate instead of round). For example, on my machine when the aux input is set to 44.1KHz, the reported device period is 101587, which comes out to 447.998 frames per ::GetBuffer call. In reality we will, of course, get 448 frames per call, but we were truncating, so we expected 447 and were discarding one frame every time. This led to glitching, and skew over time. Interestingly, I can only see this with 44.1Khz. 48Khz/96Khz are fine, because the device period is a more 'even' number. Fixes gstreamer/gst-plugins-bad#806
-
- Nov 26, 2019
-
-
CoInitialize is not allowed when targeting UWP and causes a Windows Application Certification Kit (WACK) error.
-
We should commit the parent to activate new subsurface, this is documented in the protocol. Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
-
- Nov 20, 2019
-
-
Can be reproduced with: videotestsrc ! x264enc key-int-max=$N ! \ h264parse ! msdkh264dec ! fakesink sync=1 It happens with any gop size but the smaller is the distance N between key frames, the quicker it is leaking. Fixes #1023
-
- Nov 18, 2019
-
-
-
Packets of a given PID are meant to have sequential continuity counters (modulo 16). If there are not sequential, this is the sign of a broken stream, which we then consider as a discontinuity. But if that new packet is a frame start (PUSI is true), then we can resume from that packet without any damage.
-
- Nov 14, 2019
-
-
Currently tsdemux timestamps only the PTS, and only issues the DTS if it's different. In that case, parsers tend to estimate the next DTS based on the previous DTS and the duration, which can accumulate rounding errors.
-
- Nov 11, 2019
-
-
Tim-Philipp Müller authored
Only pass -std=c++98 for openexr 2.3.x.
-
- Nov 04, 2019
-
-
It uses modern C++; adding -std=c++98 breaks the build.
-
- Oct 29, 2019
-
-
-
And only update the caps and stream-start event accordingly. This ensures that we'll always forward sticky events that arrive after the caption pad was created, and especially updates to existing sticky events like the segment event. Also create a proper stream id based on the upstream stream id for the stream-start event, and make sure that all the sticky events we know are already on the caption pad at the time it is added to the element.
-
- Oct 24, 2019
-
-
Otherwise we'd be working with a NULL buffer and cause various critical warnings along the way. Fixes gstreamer/gst-plugins-bad#1104
-
- Oct 17, 2019
-
-
gstwasapiutil.c(173) : warning C4715: 'gst_wasapi_device_role_to_erole': not all control paths return a value gstwasapiutil.c(188) : warning C4715: 'gst_wasapi_erole_to_device_role': not all control paths return a value
-
The GstDeviceProvider isn't subclass of GstElement. (gst-device-monitor-1.0:49356): GLib-GObject-WARNING **: 20:21:18.651: invalid cast from 'GstWasapiDeviceProvider' to 'GstElement'
-
- Oct 06, 2019
-
-
A classic case of not updating the next item to iterate after deleting it from the singly linked list. Only ever hit with a text buffer with GST_CLOCK_TIME_NONE for either the timestamp or duration.
-
- Oct 01, 2019
-
-
In Debian, soundfonts in SF3 format (i.e. the same as SF2 format but with Ogg/Vorbis-compressed samples) are installed into /usr/share/sounds/sf3. Soundfonts in SF3 format are supported since FluidSynth 1.1.7 (released in Feb 2018).
-
- Sep 23, 2019
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Sep 09, 2019
-
-
crypto libraries are not required for hlssink and hlssink2. Also, hlsdemux with nonencrypted stream can work without crpyto. Make an error only when users set "hls-crpyto" with non-auto option explicitly, but no crpyto library was found.
-
- Sep 06, 2019
-
-
Fix gst_event_new_seek call in gst-libs/gst/player/gstplayer.c If rate >= 0.0, then previous code doesn't set end of segment. So, the end of segment will be in place where previous seek put it. This is not neccesary end of media file (in case of reverse playback). So if we play video backward for some time and then switched to forward playing, we will get EOS somewhere in the middle of media file. This commit always sets end of segment, thus fixing this bug
-
- Sep 02, 2019
-
-
Asking decklink to render audio data seems to be based entirely on the sample counts which completely disregards the timestamps we pass to decklink. As a result, we need to explicitly check for late buffers and drop them ourselves.
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
Instead of using the information we stored ourselves for the video frame itself. Which was also the wrong one: it was the mode from the property, not the autodetected one. This fixes vanc extraction with mode=auto
-
- Aug 31, 2019
-
-
-
-
Just use srt's blocking epoll function and fix locking while we're at it.
-
- Aug 23, 2019
-
-
Do not take device_name if a device has been specified. Do not take device_index into account if a device or a device name has been specified.
-
- Aug 21, 2019
-
-
PES packets with size 0 are unbounded, and could therefore overflow the 32-bit size accumulator. Add a 32MB limit, which is larger than any PES packet should ever get. If one does, then output a 32MB chunk and continue.
-
-