This crept in several years ago sadly :(
The usage of accurate seeking should be reserved to use-cases where it is
essential that we seek to that position. This should not be the default.
There is a new option `--acurate-seeks/-a` to be able to force that.
Furthermore, if accurate seeks aren't required, a player should be using the
GST_SEEK_FLAG_KEY_UNIT flag to seek to the closest keyframe and provide the most
reactive experience.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3926>
This was causing incorrect output when seeking, especially
when used with a multithreaded source like `videotestsrc n-threads=2`.
It should now correctly wait for frames still being processed by VT
while vtdec is flushing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3922>
We are using std::isspace() with one parameter. That function is defined
in the cctype header.
```
win32ipcutils.cpp(34): error C2672: 'std::isspace': no matching overloaded function found
win32ipcutils.cpp(34): error C2780: 'bool std::isspace(_Elem,const std::locale &)': expects 2 arguments - 1 provided
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3933>
When the task already exists, we forgot to free the passed `user_data`.
This wasn't an issue for most C code, which doesn't pass a
`GDestroyNotify`, but bindings such as gstreamer-rs do!
That said, allocating a trampoline in gstreamer-rs just for it to get
thrown away again is awkward. Maybe we need a `gst_pad_resume_task`?
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3920>
The av1C box is optional so dropping parsing does not break anything
fundamentally, and there seems to be no historical record how version 0
even looks like while the comments and the parsing disagreed with each
other.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3882>
Since b76d336549
pads are deactivated when going to READY but in `uridecodebin(3)`, the
sources source pads are activated while in NULL state (when PULL mode is
supported), meaning that we are ending up deactivating those pads in
NULL_TO_READY, breaking the pipeline.
The intent of the commit mentioned above is to ensure that the pads are
deactivated either in PAUSED_TO_READY or READY_TO_READY, so it should
be safe to avoid deactivating in NULL_TO_READY.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3849>
Generating the source element is done when uridecodebin is doing the
READY to PAUSED state change, so it is reasonable to set the new source
element to that state.
This also allows detecting early failures with backing libraries or
hardware (checks done in NULL->READY).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3857>
Do not store cached EGL images in GstMemory QData. Instead, use a
per-DmabufUpload GHashTable to store cache entries with a weak
reference to the GstMemory.
This allows two glupload elements on separate tee branches to have
their own EGL image cache. For this pipeline:
gst-launch-1.0 v4l2src ! tee name=t \
t. ! queue ! glupload ! fakesink
t. ! queue ! glupload ! fakesink
this gets rid of the occasional critical error message:
GStreamer-CRITICAL **: 08:26:33.194: gst_mini_object_unref: assertion 'GST_MINI_OBJECT_REFCOUNT_VALUE (mini_object) > 0' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3880>
When using qtdemux in a pipeline that should only work as a pure demuxer (not
for actual playback), qtdemux shouldn't emit new GstSegments to correct
the start time (jump to the future) to ensure that the user experiences no
playback delay. By doing so, it's generating the wrong segments when an append
of data from the past happens. When that happens, downstream elements such as
parsers (eg: aacparse) may clip those buffers laying before the GstSegment and
create problems on the GStreamer client app (eg: WebKit).
Getting buffers clipped out because of the wrong GstSegments started becoming
a problen when this commit was introduced:
ab6e49e9cc audioparsers: add back segment clipping to parsers that have lost it
This clipping makes test DASH shaka 35 from MVT tests[1] to fail in
WebKitGTK/WPE (at least) and can potentially cause a number of other problems
in the WebKit Media Source Extensions (MSE) code.
Note that this new behaviour of not emitting new GstSegments only makes sense
when qtdemux is being used as a pure demuxer and not as part of a regular
pipeline. This is why the variant field has been added. When equal to
VARIANT_MSE_BYTESTREAM, it will make qtdemux behave differently in push mode,
taking decisions that meet the expectations for an MSE-like processing mode.
This kind of tweaks have been done in the past for MSS streams, for instance.
That code has been refactored to use VARIANT_MSS_FRAGMENTED now, instead of
its own dedicated boolean flag.
Co-authored by: Alicia Boya García <ntrrgc@gmail.com>
...who suggested to use "variant: mse-bytestream" in the caps to identify that
mode, as proposed in her unmerged patch:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/467
[1] https://github.com/rdkcentral/mvt
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3867>
The live playlists should be updated at a defined interval. The problem is that
this interval was used *after* the playlist was finally received and processed,
which resulted in a gradual shift happening in playlist updates.
Instead store and use the time at which playlists were requested to determine
when the next one should be downloaded.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
The scanning is done in a reverse order, the proper full checks to do are
therefore:
* If the position is beyond half a "segment duration", it's in the following
segment
* If the position is within the first half of a segment, it's in that one
* If the segment is the first one and the position is within half a duration
backwards, we consider the position as being within that first segment
Also handle the case where a "partial only" segment doesn't have a reliable
duration, and therefore use the playlist target duration instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
The implementation wouldn't work with regular HLS streams (i.e. the final
fallback).
Now that the implementation uses time to search for the starting
segment (instead of just the n-th from the end), we can specify the correct
hold_back fallback value from the RFC
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Avoid a deadlock if a downstream seeking query happens while the scheduler
thread is holding the manifest lock (for example during a seek back to live).
Instead, do a more elaborate fix where the external calls that need access to a
'manifest' access a copy that's updated during a manually triggered manifest
update callback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Rename track_dequeue_data_locked() to
gst_adaptive_demux_track_dequeue_data_locked(), since it's non-static.
Make find_stream_for_track_locked() static since it's only used in the main
gstadaptivedemux.c file.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
gst_adaptive_demux2_stream_finish_download() will already schedule another
fragment download if it can so don't fall through to the retry code that will
also try and schedule a download (triggering an assert).
Fix the logic in general to retry advancing into the live seek range once.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
When calculating the seek range for a live stream, use the same hold-back logic
as when choosing a starting segment, including low-latency segments if
enabled. Permits seeking closer to the live edge when re-synching or catching
up.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
When playing at the live edge of a live playlist, and a download fails, we don't
expect there to be a next fragment. That case is handled lower down anyway, so
don't retry infinitely on spurious http errors at the live edge.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
gst_hls_demux_stream_has_next_fragment() can be called with a NULL
current_segment if we're past the end of the current playlist. In that case,
just return FALSE instead of hitting a critical in the playlist code.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
When playing LL-HLS playlists in LL-HLS mode, update the playlist more often (on
the partial segment interval) or else we end up downloading them in bursts and
playing further from the live edge than intended.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
When playing a live stream, make the recommended buffering threshold at most the
hold-back distance from live. If we start 3 seconds from the live edge, there's
no point trying to buffer more - we'll just hit the live edge and have to wait
for more data to be available anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Add a field to the DownloadRequest that reports the most recent time at which
data arrived. Update it in the DownloadHelper.
Add a method to retrieve the GST_BUFFER_OFFSET() for the DownloadRequest's data
buffer (if any).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
After cancelling a DownloadRequest, the download helper may not do so
immediately, so we can't assert on the in_use flag. Also, since there's no
refcount on the preload hint struct in the download request callback data, make
sure no callbacks will be dispatched when we're going to free the preload hint
struct.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Implement fulfilment of HTTP requests from the active preload downloads by
finding any preload request that can provide the requested data and feeding
bytes from the internal DownloadRequest to the caller provided target
DownloadRequest.
Doesn't yet calculate timestamps to make the target request have a sensible
apparent bitrate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Add download_request_take_buffer_range() and
download_request_get_bytes_available() methods.
download_request_take_buffer_range() takes bytes from the front of the request
that satisfy the requested start/end byterange, and puts any remaining bytes
back into the DownloadRequest
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Add a helper that submits and handles blocking preload requests for future
PART/MAP data from live playlists. Add handling in the hlsdemux stream to submit
preload requests when hitting the end of the available segments in a live
playlist.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Add a flag to hlsdemux to enable or disable LL-HLS handling.
When LL-HLS is enabled and an LL-HLS playlist is loaded, use the part-hold-back
threshold to choose a starting segment.
For live streams that aren't LL-HLS, use the provided hold-back attribute, or
fall back to landing 3 segments from the end.
Make the gst_hls_media_playlist_seek() method able to choose a partial segment
within 2 target durations of the end of the playlist when requested.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Fix an off-by-one in gst_hls_media_playlist_sync_to_playlist() that would ignore
the first fragment in the reference playlist. The error was harmless, since we
expect the reference playlist to be older than the playlist we're
synchronising (so the first/oldest segment in the reference playlist will likely
not exist in the new playlist), so this is just for correctness.
Also fix a segment leak in gst_hls_media_playlist_advance_fragment() when
ignoring the partial_only segment.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Add a function for synchronising current position with the contents of a
playlist that is specifically for that and can handle synchronising to a partial
segment.
gst_hls_media_playlist_seek() will be used only when performing external seek
requests, to find the best segment or partial segment at which to resume
playback.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
Fixes for stream_time recalculation and handling in partial segments.
Disallow bitrate switching when in the middle of partial segments - only at a
full segment (or right before the first partial segment of a segment).
It's possible but more difficult to switch bitrates in the middle of a partial
segment group, since they are less likely to have aligned keyframes. In any
case, the seek code can't do that right now.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3883>
This will be used for CUDA stream sharing.
* Adding GstCudaPoolAllocator object. The pool allocator will
control synchronization of allocated memory objects.
* Modify gst_cuda_allocator_alloc() API so that caller can specify/set
GstCudaStream object for the newly allocated memory.
* GST_CUDA_MEMORY_TRANSFER_NEED_SYNC flag is added in addition to
existing GST_CUDA_MEMORY_TRANSFER_NEED_{UPLOAD,DOWNLOAD}.
The flag indicates that any GPU command queued in the CUDA stream
may not be finished yet, and caller should take care of the
synchronization.
The flag is controlled by GstCudaMemory object if the memory holds
GstCudaStream. (Otherwise, GstCudaMemory will do synchronization
as before this commit). Specifically, GstCudaMemory object will set
the new flag automatically when memory is mapped with
(GST_MAP_CUDA | GST_MAP_WRITE) flags. Caller will need to unset
the flag via GST_MEMORY_FLAG_UNSET() if it's already synchronized
by client code.
* gst_cuda_memory_sync() helper function is added to perform synchronization
* Why not use CUevent object to keep track of synchronization status?
CUDA provides fence-like interface already via CUevent object,
but cuEventRecord/cuEventQuery APIs are not zero-cost operations.
Instead, in this version, the status is tracked by using map and
object flags.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3629>
Usually gst-plugin-scanner.exe will be located under libexec/gstreamer-1.0
or even somewhere user specified location via GST_PLUGIN_SCANNER
environment. So, in order for child process to be able to load
GStreamer DLLs, parent process will need to update PATH env
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3886>
And also keep the default encoder settings but simply override them with
our own values that we care about.
This mirrors the encoder configuration behaviour from ffmpeg.
Add AVTP Raw Video Format de-payload support. The element supports only
GRAY16_LE output format, so:
- active pixels (no vertical blanking),
- progressive mode,
- 8 and 16-bit pixel depth,
- mono pixel format,
- grayscale colorspace.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1335>
Add AVTP Raw Video Format payload support. The element supports only GRAY16_LE
input format, so:
- active pixels (no vertical blanking),
- progressive mode,
- 8 and 16-bit pixel depth,
- mono pixel format,
- grayscale colorspace.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1335>
Due to a bug in the VT API, attempting to encode interlaced content
with ProRes results in an error, halting the pipeline instead of
gracefully falling back to software encoding.
Should be removed in the future if Apple ever fixes this issue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3222>
The VA API has not defined the scaling list entries for U/V planes
for the 4:4:4 stream. In fact, we do not meet the 4:4:4 format output
for H264 so far, and scaling list is not used frequently, so we just
print out some warning and ignore these scaling list values.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3749>
We already have functions to generate a stream-id from pads but in the
end those pads are not even used in most cases. This adds functions to
generate a stream-id even before creating the source pads for the
element that is going to use it. For example a demuxer that is properly
implements the GstStream/GstStreamCollection API will not have a Pad but
already needs to generate a stream-id.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3160>
The gst-devtools project generates gstreamer-validate-1.0.pc, this
must match the dependency in gst-editing-services for detection
to work properly.
Fixes:
Run-time dependency gst-validate-1.0 found: NO (tried pkgconfig and cmake)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3859>
All the RTP src pads were sharing the same stream-id while each actually
carry a different stream.
This was causing problem for example when funneling the streams together
and then trying to split them using 'streamiddemux'.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3855>
In theory, `dispose()` functions should be idempotent and should be
prepared not to crash or cause a double-free if an unref done from
inside caused a recursive call to `dispose()` of the same object.
https://developer.gnome.org/gobject/stable/howto-gobject-destruction.html
This patch modifies the `dispose()` method to honor these constraints.
Since the double `dispose()` call won't actually occur in qtdemux (there
is no cycle detection mechanism that could invoke it to work that way),
this is more of a code cleanup than a user-facing problem fix.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3822>
* Extend protocol so that client can notify of releasing shared memory
* Server will hold shared memory object until it's released by client
* Add allocator/buffer pool to reuse shared memory objects and buffers
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3765>
With the addition of the 'keep-aspect-ratio' sizing policy, content
that doesn't fit the target size is downscaled according to its own
aspect ratio to fit that target size, and centered.
Centering might not always be the desired behaviour, however;
consumers of this API might want to align the resulting picture to
the left or to the right.
To account for any of these cases, add two new properties to the
glvideomixer pad: xalign, and yalign. They operate on normalized
coordinates (0.0 for start, 1.0 for end), and default to 0.5 which
centers content.
<https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3762>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3762>
If we know there's only one stream we care about and we
don't have to synchronise audio and video, or send RRs,
we might just as well not hook up all the RTCP bits and
use fewer threads and sockets and simplify the pipeline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3531>
Spec 7.1.3:
If a memory object does not have the VK_MEMORY_PROPERTY_HOST_COHERENT_BIT
property, then vkFlushMappedMemoryRanges must be called in order to guarantee
that writes to the memory object from the host are made available to the host
domain, where they can be further made available to the device domain via a
domain operation. Similarly, vkInvalidateMappedMemoryRanges must be called to
guarantee that writes which are available to the host domain are made visible to
host operations.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3723>
There is no byte-stream/au format for AV1 but only for H264, and the
encoder actually outputs obu-stream/tu instead of the annexb
stream-format that is similar to H264 byte-stream format.
Without this the encoder can't be used with elements that require a
specific AV1 stream-format, e.g. the MP4 or Matroska/WebM muxer.
