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.
The sizing policy allows selecting between the current behavior,
which deforms the texture to fill the width and height of the
pad; and a new 'keep-aspect-ratio' sizing policy, which fits the
texture within the rectangle respecting its original aspect ratio.
The reason for this is that this allows avoiding extra elements
in the pipeline, and reduces the number of buffer passing through
the pipeline.
Most of this code is a direct port of the sizing policy handling
of the compositor element, except it is adapted to operate on GL
texture coordinates through the projection matrix.
<https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3760>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3760>
It's not possible to annotate a in-parameter for a return value array as
the array length. Both are assumed to have the same direction and the
current annotation causes the size parameter to be considered an out
parameter.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3787>
Without this, the plugin cannot be loaded in a devenv because the
RPATH is not added to the plugin dylib. This RPATH will be stripped on
install, which is what we want.
When deploying apps, people are supposed to use `macdeployqt` to
create an AppBundle that bundles Qt for you and sets the RPATHs
correctly to point to that bundled Qt.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3708>
It is really difficult for people to figure out why nvcodec has
0 features. Even the debug log is cryptic. Also make sure the errors
go to the ERROR log level, which is more likely to be enabled by
default.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3776>
