- Feb 04, 2023
-
-
Sebastian Dröge authored
Fixes gstreamer/gstreamer#1259
-
- Feb 03, 2023
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
This is based on d5e1e2a586020854733f6b0806064d0c900c88d2 from https://gitlab.com/AOMediaCodec/SVT-AV1.
-
libgstnet depends on GIO already anyway so we can as well make use of it instead of a half-baked Windows implementation that doesn't actually work. As a next step, the helper process also needs to be made usable on Windows. See gstreamer/gstreamer#1259 Part-of: <gstreamer/gstreamer!3887>
-
g_new0() will never return NULL but just abort if it can't allocate memory (same for g_slice_new). Part-of: <gstreamer/gstreamer!3784>
-
Part-of: <gstreamer/gstreamer!3784>
-
Part-of: <gstreamer/gstreamer!3784>
-
Gets rid of GSlice allocation that's never freed. Part-of: <gstreamer/gstreamer!3784>
-
Part-of: <gstreamer/gstreamer!3784>
-
Part-of: <gstreamer/gstreamer!3784>
-
Part-of: <!3784>
-
Part-of: <gstreamer/gstreamer!3784>
-
Part-of: <gstreamer/gstreamer!3784>
-
Part-of: <!3784>
-
Part-of: <gstreamer/gstreamer!3784>
-
Part-of: <!3784>
-
This was only used for testing purposes Part-of: <gstreamer/gstreamer!3883>
-
Part-of: <gstreamer/gstreamer!3883>
-
Clarify the ownership in the documentation Part-of: <gstreamer/gstreamer!3883>
-
The tags are fully transfered to this function Part-of: <gstreamer/gstreamer!3883>
-
When completing, log how long a HTTP request took into the debug output. Part-of: <gstreamer/gstreamer!3883>
-
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: <gstreamer/gstreamer!3883>
-
When falling back to using the regular last segment, use that duration as the identical-playlist reload interval (and not the playlist target duration which could be much larger) Part-of: <gstreamer/gstreamer!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: <gstreamer/gstreamer!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: <gstreamer/gstreamer!3883>
-
* The checks for smaller values were wrong * Properly initialize the stream default recommended buffering threshold so that a default (10s) value is used until the subclass can provide a proper value Part-of: <gstreamer/gstreamer!3883>
-
By setting/propagating stream time initially Part-of: <gstreamer/gstreamer!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: <gstreamer/gstreamer!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: <gstreamer/gstreamer!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: <gstreamer/gstreamer!3883>
-
When the stream switches to a new playlist / variant while the loader is waiting on a timer to refresh the old playlist, cancel the timer and submit the request for the new URI. Part-of: <gstreamer/gstreamer!3883>
-
fallback variant URLs get accumulated into a list in the variant now. If there's one available, switch to it after a variant update failure (failure to load the variant 3 times) Part-of: <gstreamer/gstreamer!3883>
-
Don't complain loudly about replacing the current pending playlist, just log it at debug level Part-of: <gstreamer/gstreamer!3883>
-
Check in update_fragment_info() if the playlist we want has actually been loaded yet, and return BUSY if not. Part-of: <gstreamer/gstreamer!3883>
-
Add failed variant playlists to a list and failover to other variants until there is none left Part-of: <gstreamer/gstreamer!3883>
-
When switching to/from an iframe variant to do seeking, wait for the target playlist to load before handling the seek. Part-of: <gstreamer/gstreamer!3883>
-
Implement limited retries on download errors before reporting it, and remember permanent redirects, with LL-HLS directives removed. Part-of: <gstreamer/gstreamer!3883>
-
