Commit graph

203 commits

Author SHA1 Message Date
Sebastian Dröge
2f3e245426 adaptivedemux: Don't log with non-GObject objects
Instead of using the streams, log with the pad of the streams.

https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1457

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1844>
2020-12-02 12:03:36 +00:00
Edward Hervey
7b2368b6df adaptivedemux: Don't calculate bitrate for header/index fragments
They are generally substantially smaller than regular fragments, and therefore
we end up pushing totally wrong bitrates downstream.

Fixes erratic buffering issues with DASH introduced by
66f5e87435

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1021>
2020-11-11 20:18:11 +00:00
Edward Hervey
dd425fe0fd adaptivedemux: Store QoS values on the element
Storing it per-stream requires taking the manifest lock which can apparenly be
hold for aeons. And since the QoS event comes from the video rendering thread
we *really* do not want to do that.

Storing it as-is in the element is fine, the important part is knowing the
earliest time downstream.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1021>
2020-11-11 20:18:11 +00:00
Edward Hervey
e700a21993 adaptivedemux: Don't calculate bitrate for header/index fragments
They are generally substantially smaller than regular fragments, and therefore
we end up pushing totally wrong bitrates downstream.

Fixes erratic buffering issues with DASH introduced by
66f5e87435

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1786>
2020-11-11 19:46:16 +00:00
Edward Hervey
66f5e87435 adaptivedemux: Add another nominal bitrate fallback calculation
Some HTTP servers don't provide fragment sizes (with the Content-Length HTTP
header). In order to still figure out a nominal bitrate (for usage by queue2),
calculate on when we're done downloading a fragment.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1544>
2020-09-09 11:19:17 +02:00
Edward Hervey
298eedad8b adaptivedemux: Handle invalid HTTP duration
The default BYTE DURATION basesrc query handler will return `-1` and TRUE. In
order to properly handle cases where upstream http servers didn't return a valid
Content-Length we also need to check whether it was valid when calculating
bitrates.

Avoids returning completely bogus bitrates with gogol's video streaming services

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1544>
2020-09-09 11:18:22 +02:00
Edward Hervey
9a335105f8 adaptivedemux: Handle live duration queries
Handle it the same way live sources would, that it by handling the query and
return an unknown duration.

Fixes #566

Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1279>
2020-06-08 08:44:27 +00:00
Jan Schmidt
46f994871f adaptivedemux: Handle instant rate change requests directly
Downstream demuxers will first send seek events upstream to us.
Do the right thing with instant rate change requests by handling them
immediately.
2020-04-02 11:26:46 +00:00
Jan Schmidt
1c79b39896 adaptivedemux: Don't ignore gst_segment_do_seek() return result
gst_segment_do_seek() can fail, so don't ignore the return result
2020-04-02 11:26:46 +00:00
Thiago Santos
3c5e5f8b85 adaptivedemux: fix 'utc now' gdatetime creation
It broke after removal of usage of GTimeVal that was deprecated,
it requires seconds in this unix-based creation instead of microseconds.

The downside here is that it will create an extra object just to be
discarded in order to add the microsecond part to it.

It would end up segfaulting as it would return a NULL value
2019-11-20 22:16:15 +00:00
Edward Hervey
7bceb6c3ff bad: Avoid using deprecated API
GTimeval is deprecated
2019-11-08 10:43:08 +00:00
Aaron Boxer
6d3429af34 documentation: fixed a heap o' typos 2019-11-05 09:11:25 -05:00
Charlie Turner
659d76a633 adaptivedemux: remove some deadlocks using webkitwebsrc.
WebKit's websrc depends on the main-thread for download completion
rendezvous. This exposed a number of deadlocks in adaptivedemux due to
it holding the MANIFEST_LOCK during network requests, and also needing
to hold it to change_state and resolve queries, which frequently occur
during these download windows.

Make demux->running MT-safe so that it can be accessed without using the
MANIFEST_LOCK. In case a source is downloading and requires a MT-thread
notification for completion of the fragment download, a state change
during this download window will deadlock unless we cancel the downloads
and ensure they are not restarted before we finish the state-change.

Also make demux->priv->have_manifest MT-safe. A duration query happening
in the window described above can deadlock for the same reason. Other
src queries (like SEEKING) that happen in this window also could
deadlock, but I haven't hit this scenario.

Increase granularity of API_LOCK'ing in change_state as well. We need to
cancel downloads before trying to take this lock, since sink events
(EOS) will hold it before starting a fragment download.
2019-07-29 13:19:41 +01:00
Thibault Saunier
7fe3f36ac8 Minor documentation fixes 2019-05-13 11:36:27 -04:00
Tim-Philipp Müller
86c1a7b4ad libs: Update for g_type_class_add_private() deprecation in recent GLib 2018-06-24 12:19:17 +02:00
Hosang Lee
9992564102 adaptivedemux: Set connection-speed value as current download rate if set
If connection-speed property is in use, this value should be used as the
current download rate since subclasses might read it to figure out
which playlist variant they will use.

https://bugzilla.gnome.org/show_bug.cgi?id=784592
2018-05-28 16:02:45 +02:00
Seungha Yang
a8cb7662d7 adaptivedemux: Support period change in live playlist
Regardless of LIVE or VOD, "a manifest has next period but
currently EOSed" state is meaning that it's time to advance period.

Previous behavior of adpativedemux, however, was able to period
advancing only for VOD case, since the adaptivedemux tried to
update and wait new manifest without respecting existence of the next period.

https://bugzilla.gnome.org/show_bug.cgi?id=781183
2018-05-12 09:27:46 +02:00
Mathieu Duponchelle
ce98e7b87b adaptivedemux: reject segment seeks
While #782140 can stay open for actually handling these,
the fact is currently adaptivedemux does not handle segment
seeks, and as such should not accept them.

https://bugzilla.gnome.org/show_bug.cgi?id=784655
2018-02-02 16:59:54 +01:00
Jun Xie
26cd1f108e adaptivedemux: fix pending_segment log
pending_segment shall be logged as GST_PTR_FORMAT, it's an event

https://bugzilla.gnome.org/show_bug.cgi?id=791813
2017-12-20 14:20:55 +02:00
Jun Xie
f995bcf85a adaptivedemux: fix log integer format
range_start/range_end shall be logged as G_GINT64_FORMAT

https://bugzilla.gnome.org/show_bug.cgi?id=791735
2017-12-18 14:09:36 +01:00
Thiago Santos
c2d34d1e44 adaptivedemux: add replaced flag to not error out on bitrate change
When switching bitrates we set the old streams as cancelled, but it
could also be confused with a cancel due to other reasons (as an error)
and it would lead the element to stop the pipeline mistankely. This
would happen when the stream being replaced was waiting for a manifest
update on live. Ss make it sure that we are stopping for switching
bitrates to avoid erroring out.

https://bugzilla.gnome.org/show_bug.cgi?id=789457
2017-10-26 01:03:21 -07:00
Reynaldo H. Verdejo Pinochet
88fcf303c5 adaptivedemux: fix typos 2017-10-03 14:35:48 -07:00
Matthew Waters
cbf4a44426 adaptivedemux: start/stop the manifest update loop on liveness or periodic update changes
Scenario:
A manifest starts out in live mode but then the recording is finalized
and a subsequent update changes the state to a non-live manifest when
the server has finished recording/transcoding/whatever with the full
list of fragments.

Without this patch, the manifest update task is never stopped on the
live->non-live transition and will busy loop, burning through one CPU
core.

https://bugzilla.gnome.org/show_bug.cgi?id=786275
2017-08-15 15:19:32 +10:00
Tom Bailey
4064683d36 adaptivedemux: Fix leak of pad probes in GstAdaptiveDemuxStream
This commit ensures that the idle probe which GstAdaptiveDemuxStream
adds to the upstream source pad is removed after use. Previously a new
probe was added to the pad whenever a fragment was downloaded, meaning
the number of pad probe callbacks being executed increased continually.

https://bugzilla.gnome.org/show_bug.cgi?id=785957
2017-08-08 16:04:42 +01:00
davecraig@unbalancedaudio.com
2ebcfcbc43 adaptivedemux: Stop prepared streams as well as running streams
There can be twice as many stream tasks running as there are output
pads for playback of variant HLS playlists. Half of them are the
current pads, and the other half are the pads that are about to be
switched to due to a bitrate change.
The old code only stopped the current streams which could result
in a deadlock on stopping the pipeline. The changes force stopping
and joining of any prepared streams too.

https://bugzilla.gnome.org/show_bug.cgi?id=785987
2017-08-08 12:24:21 +03:00
Edward Hervey
50f92fab89 adaptivedemux: Workaround for live seek ranges when advancing
This is a workaround for a regression introduced by
f4190a49c0
 ( adaptivedemux: Check live seeking range more often )

The goal of the previous commit was to be able to cope with non-1.0
rates on live streams which have a "seeking window" (i.e. the server
keeps around quite a bit of the live stream so you can seek back into
it).

Without that commit, two different kind of issues would happen:
* When doing reverse playback, you would never check whether you
  are outside of the seekable region. And would then continuously
  try to download fragments that are no longer present.
* When doing fast forward, you would end up requesting fragments
  which are not present yet.

In order to determine whether one was *really* outside of the seekable
window, we check whether the current stream position is still
within the seekable region.

The *problem* though with that commit is that it assumes that subclasses
will return continuously updated seeking ranges (i.e. dependent on the
current time), which is *NOT* the case.

For example:
* dashdemux does use the current UTC to determine the seekable region
* hlsdemux uses the values from the last updated manifest

Therefore if one downloads fragments faster than realtime, for HLS
we would end up at the end of the last manifest seekable range, and
the previous commit would consider the stream as being ended... which
is not the case.

In the long run, we need to figure out a way to cope with non-1.0
rates on live streams for all types of stream (including HLS).

https://bugzilla.gnome.org/show_bug.cgi?id=783075
2017-07-13 14:44:11 +02:00
Thiago Santos
33afa6bd18 adaptivedemux: small refactor to avoid repeated code
Move segment event update to a function

https://bugzilla.gnome.org/show_bug.cgi?id=773159
2017-07-12 10:13:39 +02:00
Edward Hervey
1df725e5cd adaptivedemux: Handle prepared streams on seeks
This is a race that was exposed by the {hls|dash}.scrub_forward_seeking
validate test.

The "race" is that a subclass might want to change format, causing
a new stream to be created (but not exposed/switched yet) and put on the
prepared_streams list. That stream will have values (including pending
segment) from the pre-seek state.

Before the stream is exposed/switched, a new seek comes in and the stream
values get updated ... but the ones that will be changed don't get updated
causing them to push out wrong segments once they are exposed.

https://bugzilla.gnome.org/show_bug.cgi?id=773159
2017-07-12 10:13:39 +02:00
Nicolas Dufresne
2f8980d70d Revert "adaptivedemux: Allow application to force EOS"
This reverts commit 8a070cf9af.
2017-07-07 17:20:38 -04:00
Nicolas Dufresne
8a070cf9af adaptivedemux: Allow application to force EOS
Adaptive demuxers are special demuxers that runs their own sources
internally. In this patch we flag the demuxer as being a source in order
to receive the downstream events. We then handle the EOS event by
resetting the internal state and pushing EOS on all pads. This handling
is done asynchronously to avoid blocking user thread.

https://bugzilla.gnome.org/show_bug.cgi?id=723868
2017-07-07 14:36:38 -04:00
Seungha Yang
87cb9fa49e adaptivedemux: Clear "cancelled" on uridownloader before processing manifest
Previous commit let demux call gst_uri_downloader_cancel() on _demux_reset().
Note that, _demux_reset() called during PAUSED_TO_READY and READY_TO_PAUSED.
And, it will set "cancelled" on uridownloader which blocks the use of
uridownloader. The issue is that, subclass can use the uridownloader not only
live streaming for manifest update, but also for fetching another manifests
such as variant and rendition m3u8 of hls streaming. So to unblock it,
demux should clear "cancelled" before processing initial manifest.

https://bugzilla.gnome.org/show_bug.cgi?id=783401
2017-06-06 19:21:56 -07:00
Mathieu Duponchelle
694da006e0 adaptivedemux: release the manifest lock ...
before broadcasting preroll.

The deadlock was as follows:

-> The subclass pushes a buffer on a newly-created stream in T1
-> We take the preroll lock in T1, to handle_preroll
-> The demuxer is stopped in T2, we take the MANIFEST_LOCK
-> T1 starts blocking because it received a reconfigure event
   and needs to take the MANIFEST_LOCK
-> T2 deadlocks because it now wants the preroll_lock.

https://bugzilla.gnome.org/show_bug.cgi?id=783255
2017-06-01 15:27:07 +02:00
Thiago Santos
5a693fdd9d adaptivedemux: do not erase data while updates-loop is running
Make sure the manifest update loop is stopped before proceeding with the
resetting of the manifest data. Otherwise, the updates loop will try to
use it and it leads to a segfault

https://bugzilla.gnome.org/show_bug.cgi?id=783028
2017-06-01 15:27:07 +02:00
Mathieu Duponchelle
c88125045f adaptivedemux: make sure to free all "old streams"
As we release the MANIFEST_LOCK in stop_tasks,
demux->priv->old_streams can be set, we need to free these
otherwise we may end up trying to dispose elements in the
READY state.

https://bugzilla.gnome.org/show_bug.cgi?id=783256
2017-06-01 11:13:46 +02:00
Edward Hervey
b104fb203a adaptivedemux: Don't be too aggressive with seek ranges
When an accurate seek is requested on a live stream, only requests the
exact value for the "starting position" (i.e. start in forward playback
and stop in reverse playback).

https://bugzilla.gnome.org/show_bug.cgi?id=782698
2017-05-31 11:34:41 +02:00
Edward Hervey
cf362be9ff adaptivedemux: Fix debugging message
GstSegment position is a guint64 and not a gint64

CID #1409910
2017-05-26 17:30:34 +02:00
Edward Hervey
f4190a49c0 adaptivedemux: Check live seeking range more often
The live seeking range was only checked when doing actual seeks. This was
assuming that the rate would always be 1.0 (i.e. the playback would
advance in realtime, and therefore fragments would always be available
since the seeking window moves at the same rate).

With non-1.0 rates, this no longer becomes valid, and therefore we need
to check whether we are still within the live seeking range when advancing.

https://bugzilla.gnome.org/show_bug.cgi?id=783075
2017-05-26 11:51:14 +02:00
Edward Hervey
2cf4ece73b adaptivedemux: Don't create invalid event
tags could potentially be NULL
2017-05-26 09:55:42 +02:00
Matthew Waters
430a90df20 adaptivedemux: retry download MAX_DOWNLOAD_RETRY_COUNT times before erroring
What we want is to retry downloading the fragment on 4xx/5xx errors
however returning EOS will cause waiting for a manifest update for live
(which may be a really long time) or stop everything for non-live.

Change that to only return EOS/ERROR once we've reached the error limit.

https://bugzilla.gnome.org/show_bug.cgi?id=776609
2017-05-25 13:33:35 +03:00
Graham Leggett
711b006cb9 adaptivedemux: fix debug message printf format
Match gsize to G_GSIZE_FORMAT in the debug message.

https://bugzilla.gnome.org/show_bug.cgi?id=782873
2017-05-20 18:20:34 +01:00
Edward Hervey
be6465fc35 adaptivedemux: Add various comments to the code 2017-05-18 19:04:57 +02:00
Edward Hervey
3f42783857 adaptivedemux: Store QoS time
Allows subclasses to know where downstream is and make decisions
based upon that
2017-05-18 19:04:57 +02:00
Edward Hervey
6a6ddb26b4 adaptivedemux: Handle stop_type:SET, stop:NONE
Seek values of type GST_SEEK_TYPE_SET with values of GST_CLOCK_TIME_NONE
are perfectly valid (we essentially don't modify the existing position)
2017-05-15 18:11:35 +02:00
Edward Hervey
ea6e58d27f adaptivedemux: Handle more live seeking use-cases
This commit fixes the following assumptions with live seeking:
1) start was always valid and of type GST_SEEK_TYPE_SET
2) direction was always forward
3) stop should be offsetted when handling non-accurate seeks before
   the range start position.

In order to handle more live seeking use-cases (including reverse playback),
only do non-accurate start/stop value clamping for GST_SEEK_TYPE_SET values.

Also add a bit more debugging lines for issues

https://bugzilla.gnome.org/show_bug.cgi?id=782330
2017-05-09 09:02:07 +02:00
Edward Hervey
df60e12203 adaptivedemux: Implement GST_SEEK_TYPE_END usage for live
When dealing with live streams, we can't rely on GstSegment calculation
since it uses the segment duration to calculate the absolute values.

But since we are dealing with live *and* we know the ranges, we can
compute the absolute seeking values using the range stop (i.e. "now")
as the END position.

Allows seeking back to "live" by using start_type:GST_SEEK_TYPE_END
and start:0

https://bugzilla.gnome.org/show_bug.cgi?id=782228
2017-05-09 09:02:07 +02:00
Edward Hervey
6772981668 adaptivedemux: Allow live seeking range to go back to "now"
The allowed live seek ranges returned by subclasses are "inclusive", that is
to say that the "range_stop" value they return is the highest acceptable position
one can seek to (i.e. "now").

Allow seeking to exactly that value
2017-05-05 18:28:33 +02:00
Matthew Waters
0886160123 adaptivedemux: separate manifest update task from download tasks
Rationale is to allow the manifest update task to continue running while
seeks are occurring.  Otherwise, if the user reliably performs a seek
before the manifest is updated, then as the manifest task is reset on
seeks (and thus the time to wait between manifest updates), the manifest
would never be updated.

This fix makes the manifest update task free-running and continously
update even during seeks.
2017-04-25 14:16:15 +10:00
Edward Hervey
e00be27585 adaptivedemux: Don't hold locks when pushing FLUSH_START
Some actions (Qos, reconfigure, ...) might take place before we finish pushing out flush_start.

One problem would be that:
1) The QOS handling in adaptivedemux takes the MANIFEST LOCK
  That QOS event comes from basesink with its PREROLL_LOCK taken
2) FLUSH_START is sent from adaptivedemux with the MANIFEST_LOCK taken and the basesink flushing handler needs to take the PREROLL_LOCK

 => deadlock

https://bugzilla.gnome.org/show_bug.cgi?id=781320
2017-04-15 08:18:39 +02:00
Edward Hervey
44ec6bb2f3 adaptivedemux: Fix segment creation/adaptation some more
Take into account the segment stop and the negative rates

https://bugzilla.gnome.org/show_bug.cgi?id=781267
2017-04-14 08:02:29 +02:00
Seungha Yang
ea588ae0e0 adaptivedemux: Retry downloading a fragment immediately if any in live streaming
At the moment that demux is waiting manifest update, the target sequence
of fragment was advanced already. So, checking stream_has_next_fragment()
means looking for the next fragment of target fragment.
This might cause unexpected buffering if each fragment has
large duration and manifest is listing only limited number of fragments.

https://bugzilla.gnome.org/show_bug.cgi?id=780494
2017-04-09 10:56:32 +03:00