summaryrefslogtreecommitdiff
path: root/gst-libs/gst/adaptivedemux/gstadaptivedemux.c
Commit message (Collapse)AuthorAgeFilesLines
* adaptivedemux: Fix leak of pad probes in GstAdaptiveDemuxStreamTom Bailey2017-08-081-1/+1
| | | | | | | | | 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
* adaptivedemux: Stop prepared streams as well as running streamsdavecraig@unbalancedaudio.com2017-08-081-25/+40
| | | | | | | | | | | | 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
* adaptivedemux: Workaround for live seek ranges when advancingEdward Hervey2017-07-131-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a workaround for a regression introduced by f4190a49c04f1d5d174cebba0bc9a03a7ec721c2 ( 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
* adaptivedemux: small refactor to avoid repeated codeThiago Santos2017-07-121-56/+38
| | | | | | Move segment event update to a function https://bugzilla.gnome.org/show_bug.cgi?id=773159
* adaptivedemux: Handle prepared streams on seeksEdward Hervey2017-07-121-0/+29
| | | | | | | | | | | | | | | | 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
* Revert "adaptivedemux: Allow application to force EOS"Nicolas Dufresne2017-07-071-57/+7
| | | | This reverts commit 8a070cf9aff8a122b1a52597441bab61c0476ef9.
* adaptivedemux: Allow application to force EOSNicolas Dufresne2017-07-071-7/+57
| | | | | | | | | | 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
* adaptivedemux: Clear "cancelled" on uridownloader before processing manifestSeungha Yang2017-06-061-0/+3
| | | | | | | | | | | | 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
* adaptivedemux: release the manifest lock ...Mathieu Duponchelle2017-06-011-0/+2
| | | | | | | | | | | | | | | 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
* adaptivedemux: do not erase data while updates-loop is runningThiago Santos2017-06-011-11/+10
| | | | | | | | 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
* adaptivedemux: make sure to free all "old streams"Mathieu Duponchelle2017-06-011-0/+6
| | | | | | | | | 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
* adaptivedemux: Don't be too aggressive with seek rangesEdward Hervey2017-05-311-20/+21
| | | | | | | | 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
* adaptivedemux: Fix debugging messageEdward Hervey2017-05-261-2/+2
| | | | | | GstSegment position is a guint64 and not a gint64 CID #1409910
* adaptivedemux: Check live seeking range more oftenEdward Hervey2017-05-261-2/+30
| | | | | | | | | | | | 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
* adaptivedemux: Don't create invalid eventEdward Hervey2017-05-261-1/+2
| | | | tags could potentially be NULL
* adaptivedemux: retry download MAX_DOWNLOAD_RETRY_COUNT times before erroringMatthew Waters2017-05-251-1/+1
| | | | | | | | | | 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
* adaptivedemux: fix debug message printf formatGraham Leggett2017-05-201-1/+1
| | | | | | Match gsize to G_GSIZE_FORMAT in the debug message. https://bugzilla.gnome.org/show_bug.cgi?id=782873
* adaptivedemux: Add various comments to the codeEdward Hervey2017-05-181-8/+90
|
* adaptivedemux: Store QoS timeEdward Hervey2017-05-181-0/+26
| | | | | Allows subclasses to know where downstream is and make decisions based upon that
* adaptivedemux: Handle stop_type:SET, stop:NONEEdward Hervey2017-05-151-4/+21
| | | | | 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)
* adaptivedemux: Handle more live seeking use-casesEdward Hervey2017-05-091-10/+27
| | | | | | | | | | | | | | | 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
* adaptivedemux: Implement GST_SEEK_TYPE_END usage for liveEdward Hervey2017-05-091-0/+22
| | | | | | | | | | | | | | 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
* adaptivedemux: Allow live seeking range to go back to "now"Edward Hervey2017-05-051-1/+1
| | | | | | | | 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
* adaptivedemux: separate manifest update task from download tasksMatthew Waters2017-04-251-34/+48
| | | | | | | | | | | 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.
* adaptivedemux: Don't hold locks when pushing FLUSH_STARTEdward Hervey2017-04-151-0/+2
| | | | | | | | | | | | | 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
* adaptivedemux: Fix segment creation/adaptation some moreEdward Hervey2017-04-141-12/+39
| | | | | | Take into account the segment stop and the negative rates https://bugzilla.gnome.org/show_bug.cgi?id=781267
* adaptivedemux: Retry downloading a fragment immediately if any in live streamingSeungha Yang2017-04-091-1/+2
| | | | | | | | | | 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
* adaptivedemux: add some reasons on warning reportingMatthew Waters2017-04-071-3/+8
|
* adaptivedemux: set uridownloader's parentThiago Santos2017-04-031-0/+1
| | | | | | Allows internal http source to request contexts and share cookies with the pipeline in case the server imposes any restriction based on cookies.
* adaptivedemux: Don't send EOS on pads when there's a pending switchJan Schmidt2017-03-231-6/+19
| | | | | | | | | | When there are new pads pending for a bitrate switch, don't allow EOS through from the old streams. It will be sent when the new pads are ready, just before the old streams are removed. This fixes racy bitrate switching with hlsdemux in urisourcebin where old pads EOS before new pads appear and the entire pipeline can EOS if those propagate fast enough
* Revert "adaptivedemux: answer duration queries for live streams"Matthew Waters2017-03-141-6/+6
| | | | | | | | Completely disabling duration reporting with live streams is not cool. This reverts commit e1b68d9a65ba512a52c3a2b298fa830a445eb451. https://bugzilla.gnome.org/show_bug.cgi?id=753879
* adaptivedemux: answer duration queries for live streamsAlex Ashley2017-03-021-6/+6
| | | | | | | | | | | For duration queries on live streams, adaptivedemux ignores the query. The problem then is that the query is answered by the downstream qtdemux element, with the duration of the currently passing fragment. This commit changes the behaviour of adaptivedemux to answer the duration queries for live streams, returning GST_CLOCK_TIME_NONE. https://bugzilla.gnome.org/show_bug.cgi?id=753879
* adaptivemutex: Fix double mutex unlockThomas Bluemel2017-03-021-5/+5
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=779480
* adaptivedemux: Convert premature EOS on non-exposed pads to ERRORJan Schmidt2017-02-091-1/+7
| | | | | | | | If we need to send EOS on a pad that hasn't prerolled, generate an error on the bus instead, otherwise the app will have no idea. Fixes the HLS testFragmentNotFound test, which is waiting for either EOS or an error.
* adaptivedemux: Handle errors from prepared_streams tooJan Schmidt2017-02-091-26/+43
| | | | | | Check both active and prepared_streams when we receive an error on the bus, so we post errors for streams that are still pre-rolling
* adaptivedemux: Fix bitrate printed in debugJan Schmidt2017-02-071-2/+1
| | | | | | The download bitrate is already in bits per second, no need to multiply it by 8 again when printing it for debug.
* adaptivedemux: Preroll streams before exposing themJan Schmidt2017-02-071-31/+177
| | | | | | | | | | | | | To ensure that pads have caps when they are exposed, do the exposing when all pending streams have prerolled an output buffer, and only then EOS and remove any old pads. Improves the switching sequence by making caps available as soon as a pad appears. With fixes from Seungha Yang <sh.yang@lge.com> https://bugzilla.gnome.org/show_bug.cgi?id=758257
* adaptivedemux: Handle SEEK event only onceSeungha Yang2017-01-311-0/+7
| | | | | | | | send_event() of parent class (i.e., GstBinClass) iterates srcpads to send SEEK event. And performing it per srcpad is inefficient. So, let's drop duplicated SEEK event by checking seqnum https://bugzilla.gnome.org/show_bug.cgi?id=776612
* adaptivedemux: Use a simple queue instead of queue2Edward Hervey2017-01-101-3/+3
| | | | | | The reason we previously used queue2 was to calculate the download rate, but that wasn't entirely correct and we therefore calculate it before queue2. We therefore now just need a simple queue.
* adaptivedemux: Remove unneeded variablesEdward Hervey2017-01-101-10/+2
| | | | We now have properly non-blocking download time calculation
* adaptivedemux: Avoid using unset GErrorEdward Hervey2016-12-121-1/+1
| | | | | gst_uri_handler_set_uri() doesn't guarantee the GError will be set if it returns FALSE.
* mssdemux: improved live playback supportPhilippe Normand2016-11-291-2/+25
| | | | | | | | | | | When a MSS server hosts a live stream the fragments listed in the manifest usually don't have accurate timestamps and duration, except for the first fragment, which additionally stores timing information for the few upcoming fragments. In this scenario it is useless to periodically fetch and update the manifest and the fragments list can be incrementally built by parsing the first/current fragment. https://bugzilla.gnome.org/show_bug.cgi?id=755036
* adaptivedemux: Fix startup SEGMENT seeking and setting for liveSeungha Yang2016-11-151-5/+11
| | | | | | | Because fragment.timestamp is relative value to period_start, startup SEGMENT seeking should be pointed to "fragment.timestamp + period_start" https://bugzilla.gnome.org/show_bug.cgi?id=774196
* adaptivedemux: reset the manifest failure count after a successful retrievalMatthew Waters2016-11-111-0/+1
| | | | | | | | | This changes the failure case to require a consecutive number of failures rather than being spread out over the entire stream. Fixes the case where fetching the manifest was intermittent. https://bugzilla.gnome.org/show_bug.cgi?id=774177
* adaptivedemux: call the subclass for duration queries for live sourcesMatthew Waters2016-11-111-2/+1
| | | | | | Otherwise, the duration query was failing for live sources https://bugzilla.gnome.org/show_bug.cgi?id=774177
* adaptivedemux: restart the manifest update task after a seekMatthew Waters2016-11-111-0/+7
| | | | | | | | For formats that need to update the manifest to know about new fragments as they're being written by the server would never receive an updated fragment list after a seek event https://bugzilla.gnome.org/show_bug.cgi?id=774177
* Explicitly define float constants as floatNirbheek Chauhan2016-10-271-1/+1
| | | | | | | | | | With MSVC, this gives the following warning: warning C4305: 'function': truncation from 'double' to 'gfloat' Apparently, MSVC does not figure out what type to use for constants based on the assignment. This warning is very spammy, so let's try to fix it.
* adaptivedemux: fix buffer size print formatArnaud Vrac2016-10-111-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=772706
* adaptivedemux: Calculate values before queue2Edward Hervey2016-10-081-2/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to calculate the *actual* bitrate for downloading a fragment we need to take into account the time since we requested the fragment. Without this, the bitrate calculations (previously reported by queue2) would be biased since they wouldn't take into account the request latency (that is the time between the moment we request a specific URI and the moment we receive the first byte of that request). Such examples were it would be biased would be high-bandwith but high-latency networks. If you download 5MB in 500ms, but it takes 200ms to get the first byte, queue2 would report 80Mbit/s (5Mb in 500ms) , but taking the request into account it is only 57Mbit/s (5Mb in 700ms). While this would not cause too much issues if the above fragment represented a much longer duration (5s of content), it would cause issues with short ones (say 1s, or when doing keyframe-only requests which are even shorter) where the code would expect to be able to download up to 80Mbit/s ... whereas if we take the request time into account it's much lower (and we would therefore end up doing late requests). Also calculate the request latency for debugging purposes and further usage (it could allow us to figure out the maximum request rate for example). https://bugzilla.gnome.org/show_bug.cgi?id=733959 https://bugzilla.gnome.org/show_bug.cgi?id=772330
* adaptivedemux: Also never have the SINK flag set on adaptivedemuxSebastian Dröge2016-09-121-1/+2
|
View Lorry Controller Status