- Oct 26, 2020
-
-
Tim-Philipp Müller authored
-
- Oct 16, 2020
-
-
Part-of: <gstreamer/gst-plugins-bad!1704>
-
In preparation for !1670, this will allow the base class from skipping frames that should not be displayed. Previously it would complain about unordered decoding taking place in the driver. Part-of: <gstreamer/gst-plugins-bad!1701>
-
requests are executed in order, so while dequeuing sink buffers for previous request, also mark these request as no longer pending. This will allow reusing the request later. Part-of: <gstreamer/gst-plugins-bad!1701>
-
Pass the pointer instead of NULL in order to find and remove properly any pending request from the queue. This coding error was leading to use after free in error and early exit cases. Part-of: <gstreamer/gst-plugins-bad!1701>
-
- Oct 15, 2020
-
-
SEI messages contain various information which wouldn't be conveyed by using upstream CAPS (HDR, timecode for example). Part-of: <gstreamer/gst-plugins-bad!1694>
-
- Oct 12, 2020
-
-
`delay` should be a GstClockTimeDiff since SRT time is int64_t. All values are in local time so we should never see a srctime that's in the future. If we do, clamp the delay to 0 and warn about it. Part-of: <gstreamer/gst-plugins-bad!1690>
-
A zero srctime is a missing srctime. Apparently this can happen when ["the connection is not between SRT peers or if Timestamp-Based Packet Delivery mode (TSBPDMODE) is not enabled"][1] so it may not apply to us, but it's best to be defensive. [1]: https://github.com/Haivision/srt/blob/v1.4.2/docs/API.md#sending-and-receiving Part-of: <gstreamer/gst-plugins-bad!1690>
-
If we don't have a clock, stop the source instead of asserting in gst_clock_get_time. This can happen when the element is removed from the pipeline while it's playing. Part-of: <gstreamer/gst-plugins-bad!1690>
-
Tim-Philipp Müller authored
Part-of: <!1628>
-
Part-of: <gstreamer/gst-plugins-bad!1628>
-
Part-of: <gstreamer/gst-plugins-bad!1628>
-
Part-of: <gstreamer/gst-plugins-bad!1628>
-
interlace-mode=alternate is a special case of interlace-mode=interleaved where the fields are split using two different buffers. We should use the latter instead of the former to no break compat with elements supporting only 'interleaved'. Decoders producing alternate, such as OMX on the Zynq, should change the interlace-mode on their output caps. Fix gstreamer/gst-plugins-base#825 Part-of: <gstreamer/gst-plugins-bad!1683>
-
Now that SRT no longer needs the family when creating the socket, this code has become useless. Part-of: <gstreamer/gst-plugins-bad!1685>
-
See https://github.com/Haivision/srt/blob/73ee1e1a3e3adc2702a9a5057d101ef80447b38c/docs/API-functions.md#srt_socket `srt_create_socket()` was added in https://github.com/Haivision/srt/commit/4b897ba92d34f1829a1c6e419eeab17f0763a0fc and srt `v1.3.0` is the first release that has it. Part-of: <gstreamer/gst-plugins-bad!1685>
-
Part-of: <gstreamer/gst-plugins-bad!1685>
-
This would provoke error messages from SRT. Part-of: <gstreamer/gst-plugins-bad!1685>
-
`srt_startup` can also return 1 if it was successful. Avoid warning in this case. Avoid a race when checking whether we need to call it at all. Part-of: <gstreamer/gst-plugins-bad!1685>
-
The [SRT documentation][1] specifies exact types for the socket options. Make sure we match these. This reverts the linger workaround in commit 84f8dbd9 and extends srt_constant_params to support other types than int. [1]: https://github.com/Haivision/srt/blob/master/docs/APISocketOptions.md Part-of: <gstreamer/gst-plugins-bad!1685>
-
- Oct 11, 2020
-
-
Some headers include API from it. Part-of: <!1678>
-
SRT provides the original timestamp of a packet (with drift/skew corrected for local clock), which is what should be used for timestamping the outgoing buffers. This ensures that we output the packets with the same timestamp (and by extension rate) as the original feed. Also detect if packets were dropped (by checking the sequence number) and properly set DISCONT flag on the outgoing buffer. Finally answer the latency queries Part-of: <!1677>
-
Instead of leaking it. Part-of: <gstreamer/gst-plugins-bad!1681>
-
OpenSSL shouldn't be making real system calls, so we can safely ignore syscall errors. System interactions should happen through our BIO. So especially don't look at the system's errno, as it should be meaningless. Part-of: <gstreamer/gst-plugins-bad!1684>
-
Part-of: <!1682>
-
Fixes #1422 gstreamer/gst-plugins-bad#1422 Part-of: <gstreamer/gst-plugins-bad!1682>
-
The connection might be broken, which we should detect instead of just aborting the write. Part-of: <gstreamer/gst-plugins-bad!1680>
-
Don't attempt to obtain encoder lock that is already held by gst_x265_enc_encode_frame(). Part-of: <gstreamer/gst-plugins-bad!1679>
-
Non-first video stream might not be working with current implementation. It could be non-video (e.g., photo source) and then ReadSample() might be blocked forever. Part-of: <gstreamer/gst-plugins-bad!1676>
-
Part-of: <gstreamer/gst-plugins-bad!1675>
-
- Oct 05, 2020
-
-
One was forgotten in 309f6187. Part-of: <gstreamer/gst-plugins-bad!1652>
-
An oddness of wasapi loopback feature is that capture client will not produce any data if there's no outputting sound to corresponding render client. In other words, if there's no sound to render, capture task will stall. As an option to solve such issue, we can add timeout to wake up from capture thread if there's no incoming data within given time interval. But it seems to be glitch prone. Another approach is that we can keep pushing silence data into render client so that capture client can keep capturing data (even if it's just silence). This patch will choose the latter one because it's more straightforward way and it's likely produce glitchless sound than former approach. A bonus point of this approach is that loopback capture on Windows7/8 will work with this patch. Note that there's an OS bug prior to Windows10 when loopback capture client is running with event-driven mode. To work around the bug, event signalling should be handled manually for read thread to wake up. Part-of: <gstreamer/gst-plugins-bad!1651>
-
Always chain up to the parent _stop() implementation as it unrefs some caps (among other things). Fixes: gstreamer/gst-plugins-bad#1409 Part-of: <gstreamer/gst-plugins-bad!1650>
-
In live streaming, buffers sent by souphttpsrc are pushed to the live adapter. The buffers in the adapter are sent out of mssdemux when it is greater than 4096 bytes. Occasionally, when seeking in live streams, if seek occurs just after the last data chunk was received, and if this data chunk is smaller than 4096 bytes, it will be kept in the live adapter. This remaining data in the live adapter will be erroneously prepended to the new data that is downloaded after seek and pushed out. When qtdemux receives this data, since it does not start with a moof box, it is impossible to demux the fragment, and bogus size error will occur. Clear out the live adapter on seek so that no unnecessary remaining data is pushed out together with the new fragment after seeking. Part-of: <!1649>
-
- Oct 04, 2020
-
-
Fixes a debug assertion with i(Pad)OS 14: 'IOSurface textures must use MTLStorageModeShared' Part-of: <gstreamer/gst-plugins-bad!1648>
-
Handled events don't go through the default pad event handler, so they need to be unreffed in this case. Part-of: <gstreamer/gst-plugins-bad!1647>
-
On creating a 2nd wpesrc in a new pipeline in an app that already has a runnig wpesrc, WPE sometimes doesn't return a buffer on request, leading to a crash. This commit fixes the crash, but not the underlying failure - a 2nd wpesrc can still error out instead. Partially fixes gstreamer/gst-plugins-bad#1386 Part-of: <gstreamer/gst-plugins-bad!1647>
-
Fixes #1409 Part-of: <gstreamer/gst-plugins-bad!1647>
-
As waiting for the load to be finished is specific to the WebView, it should be done from our WPEView, not from the WPEContextThread. This fixes issues where multiple wpesrc elements are created in sequence. Without this patch the first view might receive erroneous buffer notifications. Fixes #1386 Part-of: <!1647>
-