mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-07-27 08:48:19 +00:00
Code Issues 1 Projects Releases Wiki Activity
gstreamer/ext/dash/gstdashdemux.c

3268 lines
113 KiB
C
Raw Normal View History

Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
/*
* DASH demux plugin for GStreamer
*
* gstdashdemux.c
*
* Copyright (C) 2012 Orange
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
* Authors:
* David Corvoysier <david.corvoysier@orange.com>
* Hamid Zakari <hamid.zakari@gmail.com>
*
dashdemux: Remove timing code that delays pushing of fragments Fragments should be pushed ASAP as downstream should be responsible for doing the syncrhonization and proper buffering. This has the great side effect of fixing most of the seeking A/V sync issues.
2013-01-25 15:45:18 +00:00
* Copyright (C) 2013 Smart TV Alliance
* Author: Thiago Sousa Santos <thiago.sousa.santos@collabora.com>, Collabora Ltd.
*
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License for more details.
*
* You should have received a copy of the GNU Library General Public
Renamed LICENSE into COPYING
2012-09-28 10:55:27 +00:00
* License along with this library (COPYING); if not, write to the
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
* Free Software Foundation, Inc., 59 Temple Place - Suite 330,
* Boston, MA 02111-1307, USA.
*/
/**
* SECTION:element-dashdemux
*
* DASH demuxer element.
* <title>Example launch line</title>
* |[
dashdemux: fix outdated example launch line https://bugzilla.gnome.org/show_bug.cgi?id=749809
2015-05-25 01:30:55 +00:00
* gst-launch-1.0 playbin uri="http://www-itec.uni-klu.ac.at/ftp/datasets/mmsys12/RedBullPlayStreets/redbull_4s/RedBullPlayStreets_4s_isoffmain_DIS_23009_1_v_2_1c2_2011_08_30.mpd"
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
* ]|
*/
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
/* Implementation notes:
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
* The following section describes how dashdemux works internally.
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Added introduction and general design notes
2012-10-15 12:14:53 +00:00
* Introduction:
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Added introduction and general design notes
2012-10-15 12:14:53 +00:00
* dashdemux is a "fake" demux, as unlike traditional demux elements, it
* doesn't split data streams contained in an enveloppe to expose them
* to downstream decoding elements.
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Added introduction and general design notes
2012-10-15 12:14:53 +00:00
* Instead, it parses an XML file called a manifest to identify a set of
* individual stream fragments it needs to fetch and expose to the actual
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
* demux elements that will handle them (this behavior is sometimes
Added introduction and general design notes
2012-10-15 12:14:53 +00:00
* referred as the "demux after a demux" scenario).
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Added introduction and general design notes
2012-10-15 12:14:53 +00:00
* For a given section of content, several representations corresponding
* to different bitrates may be available: dashdemux will select the most
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
* appropriate representation based on local conditions (typically the
Added introduction and general design notes
2012-10-15 12:14:53 +00:00
* available bandwidth and the amount of buffering available, capped by
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
* a maximum allowed bitrate).
*
Added introduction and general design notes
2012-10-15 12:14:53 +00:00
* The representation selection algorithm can be configured using
* specific properties: max bitrate, min/max buffering, bandwidth ratio.
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
*
Added introduction and general design notes
2012-10-15 12:14:53 +00:00
* General Design:
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
* dashdemux has a single sink pad that accepts the data corresponding
Added introduction and general design notes
2012-10-15 12:14:53 +00:00
* to the manifest, typically fetched from an HTTP or file source.
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Added introduction and general design notes
2012-10-15 12:14:53 +00:00
* dashdemux exposes the streams it recreates based on the fragments it
* fetches through dedicated src pads corresponding to the caps of the
* fragments container (ISOBMFF/MP4 or MPEG2TS).
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Added introduction and general design notes
2012-10-15 12:14:53 +00:00
* During playback, new representations will typically be exposed as a
* new set of pads (see 'Switching between representations' below).
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Added introduction and general design notes
2012-10-15 12:14:53 +00:00
* Fragments downloading is performed using a dedicated task that fills
* an internal queue. Another task is in charge of popping fragments
* from the queue and pushing them downstream.
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
* Switching between representations:
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
* Decodebin supports scenarios allowing to seamlessly switch from one
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
* stream to another inside the same "decoding chain".
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
* To achieve that, it combines the elements it autoplugged in chains
* and groups, allowing only one decoding group to be active at a given
* time for a given chain.
*
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
* A chain can signal decodebin that it is complete by sending a
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
* no-more-pads event, but even after that new pads can be added to
* create new subgroups, providing that a new no-more-pads event is sent.
*
* We take advantage of that to dynamically create a new decoding group
* in order to select a different representation during playback.
*
* Typically, assuming that each fragment contains both audio and video,
* the following tree would be created:
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
* chain "DASH Demux"
Comments: We don't select a single representation, but a representation for each stream Code: cleanup of gst_get_next_fragment (also renamed in gst_get_next_fragment_set)
2012-10-15 13:08:53 +00:00
* |_ group "Representation set 1"
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
* | |_ chain "Qt Demux 0"
* | |_ group "Stream 0"
* | |_ chain "H264"
* | |_ chain "AAC"
Comments: We don't select a single representation, but a representation for each stream Code: cleanup of gst_get_next_fragment (also renamed in gst_get_next_fragment_set)
2012-10-15 13:08:53 +00:00
* |_ group "Representation set 2"
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
* |_ chain "Qt Demux 1"
* |_ group "Stream 1"
* |_ chain "H264"
* |_ chain "AAC"
*
* Or, if audio and video are contained in separate fragments:
*
* chain "DASH Demux"
Comments: We don't select a single representation, but a representation for each stream Code: cleanup of gst_get_next_fragment (also renamed in gst_get_next_fragment_set)
2012-10-15 13:08:53 +00:00
* |_ group "Representation set 1"
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
* | |_ chain "Qt Demux 0"
* | | |_ group "Stream 0"
* | | |_ chain "H264"
* | |_ chain "Qt Demux 1"
* | |_ group "Stream 1"
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
* | |_ chain "AAC"
Comments: We don't select a single representation, but a representation for each stream Code: cleanup of gst_get_next_fragment (also renamed in gst_get_next_fragment_set)
2012-10-15 13:08:53 +00:00
* |_ group "Representation set 2"
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
* |_ chain "Qt Demux 3"
* | |_ group "Stream 2"
* | |_ chain "H264"
* |_ chain "Qt Demux 4"
* |_ group "Stream 3"
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
* |_ chain "AAC"
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
*
Comments: We don't select a single representation, but a representation for each stream Code: cleanup of gst_get_next_fragment (also renamed in gst_get_next_fragment_set)
2012-10-15 13:08:53 +00:00
* In both cases, when switching from Set 1 to Set 2 an EOS is sent on
* each end pad corresponding to Rep 0, triggering the "drain" state to
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
* propagate upstream.
Comments: We don't select a single representation, but a representation for each stream Code: cleanup of gst_get_next_fragment (also renamed in gst_get_next_fragment_set)
2012-10-15 13:08:53 +00:00
* Once both EOS have been processed, the "Set 1" group is completely
* drained, and decodebin2 will switch to the "Set 2" group.
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
* Note: nothing can be pushed to the new decoding group before the
* old one has been drained, which means that in order to be able to
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
* adapt quickly to bandwidth changes, we will not be able to rely
* on downstream buffering, and will instead manage an internal queue.
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
*
Documented the representation switch mechanism
2012-10-15 11:09:49 +00:00
*/
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif
#include <string.h>
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
#include <stdio.h>
dashdemux: provide a default suggestedPresentationDelay If MPD@suggestedPresentationDelay is not present in the manifest, dashdemux selects the fragment closest to the most recently generated fragment. This causes a playback issue because this choice does not allow the DASH client to build up any buffer of downloaded fragments without pausing playback. This is because by definition new fragments appear on the server in real-time (e.g. if segment duration is 4 seconds, a new fragment will appear on the server every 4 seconds). If the starting playback position was n*segmentDuration seconds behind "now", the DASH client could download up to 'n' fragments faster than realtime before it reached the point where it needed to wait for fragments to appear on the server. The MPD@suggestedPresentationDelay attribute allows a content publisher to provide a suggested starting position that is behind the current "live" position. If the MPD@suggestedPresentationDelay attribute is not present, provide a suitable default value as a property of the dashdemux element. To allow the default presentation delay to be specified either using fragments or seconds, the property is a string that contains a number and a unit (e.g. "10 seconds", "4 fragments", "2500ms").
2015-07-07 14:38:08 +00:00
#include <stdlib.h>
dashdemux: fix printing buffering time and download rate/size This was broken on armv7.
2012-10-25 15:15:09 +00:00
#include <inttypes.h>
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
#include <gio/gio.h>
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
#include <gst/base/gsttypefindhelper.h>
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
#include <gst/tag/tag.h>
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
#include <gst/net/gstnet.h>
dashdemux: remove stream loop thread Download and push from the same task, makes code a lot simpler to maintain. Also pushing from separate threads avoids deadlocking when gst_pad_push blocks due to downstream queues being full.
2013-12-20 13:05:22 +00:00
#include "gst/gst-i18n-plugin.h"
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
#include "gstdashdemux.h"
dash: use same debug category for dashdemux and the mpd parser Makes debugging easier
2013-06-25 21:34:13 +00:00
#include "gstdash_debug.h"
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
dashdemux: use audio_%02u and video_%02u names for pads Instead of using the default ghostpad%u naming. The audio_/video_ names are more common in demuxers
2015-01-26 20:51:22 +00:00
static GstStaticPadTemplate gst_dash_demux_videosrc_template =
GST_STATIC_PAD_TEMPLATE ("video_%02u",
GST_PAD_SRC,
GST_PAD_SOMETIMES,
GST_STATIC_CAPS_ANY);
static GstStaticPadTemplate gst_dash_demux_audiosrc_template =
GST_STATIC_PAD_TEMPLATE ("audio_%02u",
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
GST_PAD_SRC,
GST_PAD_SOMETIMES,
GST_STATIC_CAPS_ANY);
dashdemux: create src pads for subtitle streams. Create src pads for Representations that contain timed-text subtitles, both when the subtitles are encapsulated in ISO BMFF (i.e., the Representation has mimeType "application/mp4") and when they are unencapsulated (i.e., the Representation has mimeType "application/ttml+xml"). https://bugzilla.gnome.org/show_bug.cgi?id=747774
2015-08-18 13:16:11 +00:00
static GstStaticPadTemplate gst_dash_demux_subtitlesrc_template =
GST_STATIC_PAD_TEMPLATE ("subtitle_%02u",
GST_PAD_SRC,
GST_PAD_SOMETIMES,
GST_STATIC_CAPS_ANY);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
static GstStaticPadTemplate sinktemplate = GST_STATIC_PAD_TEMPLATE ("sink",
GST_PAD_SINK,
GST_PAD_ALWAYS,
We now only accept actual manifest files, and not any XML file
2012-10-17 13:52:19 +00:00
GST_STATIC_CAPS ("application/dash+xml"));
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
dash: use same debug category for dashdemux and the mpd parser Makes debugging easier
2013-06-25 21:34:13 +00:00
GST_DEBUG_CATEGORY (gst_dash_demux_debug);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
#define GST_CAT_DEFAULT gst_dash_demux_debug
enum
{
PROP_0,
PROP_MAX_BUFFERING_TIME,
PROP_BANDWIDTH_USAGE,
PROP_MAX_BITRATE,
dashdemux: Add properties to select maximum allowed width/height and framerate https://bugzilla.gnome.org/show_bug.cgi?id=770408
2016-08-25 17:50:11 +00:00
PROP_MAX_VIDEO_WIDTH,
PROP_MAX_VIDEO_HEIGHT,
PROP_MAX_VIDEO_FRAMERATE,
dashdemux: provide a default suggestedPresentationDelay If MPD@suggestedPresentationDelay is not present in the manifest, dashdemux selects the fragment closest to the most recently generated fragment. This causes a playback issue because this choice does not allow the DASH client to build up any buffer of downloaded fragments without pausing playback. This is because by definition new fragments appear on the server in real-time (e.g. if segment duration is 4 seconds, a new fragment will appear on the server every 4 seconds). If the starting playback position was n*segmentDuration seconds behind "now", the DASH client could download up to 'n' fragments faster than realtime before it reached the point where it needed to wait for fragments to appear on the server. The MPD@suggestedPresentationDelay attribute allows a content publisher to provide a suggested starting position that is behind the current "live" position. If the MPD@suggestedPresentationDelay attribute is not present, provide a suitable default value as a property of the dashdemux element. To allow the default presentation delay to be specified either using fragments or seconds, the property is a string that contains a number and a unit (e.g. "10 seconds", "4 fragments", "2500ms").
2015-07-07 14:38:08 +00:00
PROP_PRESENTATION_DELAY,
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
PROP_LAST
};
/* Default values for properties */
Applied gst-indent
2012-11-21 13:14:34 +00:00
#define DEFAULT_MAX_BUFFERING_TIME 30 /* in seconds */
Explicitly define float constants as float 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.
2016-10-27 03:41:26 +00:00
#define DEFAULT_BANDWIDTH_USAGE 0.8f /* 0 to 1 */
dashdemux: Add properties to select maximum allowed width/height and framerate https://bugzilla.gnome.org/show_bug.cgi?id=770408
2016-08-25 17:50:11 +00:00
#define DEFAULT_MAX_BITRATE 0 /* in bit/s */
#define DEFAULT_MAX_VIDEO_WIDTH 0
#define DEFAULT_MAX_VIDEO_HEIGHT 0
#define DEFAULT_MAX_VIDEO_FRAMERATE_N 0
#define DEFAULT_MAX_VIDEO_FRAMERATE_D 1
dashdemux: provide a default suggestedPresentationDelay If MPD@suggestedPresentationDelay is not present in the manifest, dashdemux selects the fragment closest to the most recently generated fragment. This causes a playback issue because this choice does not allow the DASH client to build up any buffer of downloaded fragments without pausing playback. This is because by definition new fragments appear on the server in real-time (e.g. if segment duration is 4 seconds, a new fragment will appear on the server every 4 seconds). If the starting playback position was n*segmentDuration seconds behind "now", the DASH client could download up to 'n' fragments faster than realtime before it reached the point where it needed to wait for fragments to appear on the server. The MPD@suggestedPresentationDelay attribute allows a content publisher to provide a suggested starting position that is behind the current "live" position. If the MPD@suggestedPresentationDelay attribute is not present, provide a suitable default value as a property of the dashdemux element. To allow the default presentation delay to be specified either using fragments or seconds, the property is a string that contains a number and a unit (e.g. "10 seconds", "4 fragments", "2500ms").
2015-07-07 14:38:08 +00:00
#define DEFAULT_PRESENTATION_DELAY NULL /* zero */
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
/* Clock drift compensation for live streams */
#define SLOW_CLOCK_UPDATE_INTERVAL (1000000 * 30 * 60) /* 30 minutes */
#define FAST_CLOCK_UPDATE_INTERVAL (1000000 * 30) /* 30 seconds */
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
#define SUPPORTED_CLOCK_FORMATS (GST_MPD_UTCTIMING_TYPE_NTP | GST_MPD_UTCTIMING_TYPE_HTTP_HEAD | GST_MPD_UTCTIMING_TYPE_HTTP_XSDATE | GST_MPD_UTCTIMING_TYPE_HTTP_ISO | GST_MPD_UTCTIMING_TYPE_HTTP_NTP)
dashdemux: post-review fixup of UTCTiming element This commit addresses the following items from the code review: use a portable way to define NTP_TO_UNIX_EPOCH, fix memory leak on error, and add documentation to UTCTiming parse functions Using LL is not portable, so the G_GUINT64_CONSTANT needs to be instead. If an error occurs during DNS resolution, the GError was not being released, causing a memory leak. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-13 17:21:29 +00:00
#define NTP_TO_UNIX_EPOCH G_GUINT64_CONSTANT(2208988800) /* difference (in seconds) between NTP epoch and Unix epoch */
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
struct _GstDashDemuxClockDrift
{
GMutex clock_lock; /* used to protect access to struct */
guint selected_url;
gint64 next_update;
/* @clock_compensation: amount (in usecs) to add to client's idea of
now to map it to the server's idea of now */
GTimeSpan clock_compensation;
GstClock *ntp_clock;
};
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
typedef struct
{
guint64 start_offset, end_offset;
/* TODO: Timestamp and duration */
} GstDashStreamSyncSample;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
/* GObject */
static void gst_dash_demux_set_property (GObject * object, guint prop_id,
const GValue * value, GParamSpec * pspec);
static void gst_dash_demux_get_property (GObject * object, guint prop_id,
GValue * value, GParamSpec * pspec);
static void gst_dash_demux_dispose (GObject * obj);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* GstAdaptiveDemux */
static GstClockTime gst_dash_demux_get_duration (GstAdaptiveDemux * ademux);
static gboolean gst_dash_demux_is_live (GstAdaptiveDemux * ademux);
static void gst_dash_demux_reset (GstAdaptiveDemux * ademux);
static gboolean gst_dash_demux_process_manifest (GstAdaptiveDemux * ademux,
GstBuffer * buf);
static gboolean gst_dash_demux_seek (GstAdaptiveDemux * demux, GstEvent * seek);
static GstFlowReturn
gst_dash_demux_stream_update_fragment_info (GstAdaptiveDemuxStream * stream);
static GstFlowReturn gst_dash_demux_stream_seek (GstAdaptiveDemuxStream *
adaptivedemux: handle snap seeks Adaptive demuxers need to start downloading from specific positions (fragments) for every stream, this means that all streams can snap-seek to a different position when requested. Snap seeking in this case will be done in 2 steps: 1) do the snap seeking on the pad that received the seek event and get the final position 2) use this position to do a regular seek on the other streams to make sure they all start from the same position More arguments were added to the stream_seek function, allowing better control of how seeking is done. Knowing the flags and the playback direction allows subclasses to handle snap-seeking. And also adds a new return parameter to inform of the final selected seeking position that is used to align the other streams. https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-01-27 16:31:10 +00:00
stream, gboolean forward, GstSeekFlags flags, GstClockTime ts,
GstClockTime * final_ts);
static gboolean gst_dash_demux_stream_has_next_fragment (GstAdaptiveDemuxStream
* stream);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static GstFlowReturn
gst_dash_demux_stream_advance_fragment (GstAdaptiveDemuxStream * stream);
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
static gboolean
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
gst_dash_demux_stream_advance_subfragment (GstAdaptiveDemuxStream * stream);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static gboolean gst_dash_demux_stream_select_bitrate (GstAdaptiveDemuxStream *
stream, guint64 bitrate);
adaptivedemux: handle snap seeks Adaptive demuxers need to start downloading from specific positions (fragments) for every stream, this means that all streams can snap-seek to a different position when requested. Snap seeking in this case will be done in 2 steps: 1) do the snap seeking on the pad that received the seek event and get the final position 2) use this position to do a regular seek on the other streams to make sure they all start from the same position More arguments were added to the stream_seek function, allowing better control of how seeking is done. Knowing the flags and the playback direction allows subclasses to handle snap-seeking. And also adds a new return parameter to inform of the final selected seeking position that is used to align the other streams. https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-01-27 16:31:10 +00:00
static gint64 gst_dash_demux_get_manifest_update_interval (GstAdaptiveDemux *
demux);
static GstFlowReturn gst_dash_demux_update_manifest_data (GstAdaptiveDemux *
demux, GstBuffer * buf);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static gint64
gst_dash_demux_stream_get_fragment_waiting_time (GstAdaptiveDemuxStream *
stream);
static void gst_dash_demux_advance_period (GstAdaptiveDemux * demux);
static gboolean gst_dash_demux_has_next_period (GstAdaptiveDemux * demux);
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
static GstFlowReturn gst_dash_demux_data_received (GstAdaptiveDemux * demux,
adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-28 10:45:36 +00:00
GstAdaptiveDemuxStream * stream, GstBuffer * buffer);
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
static gboolean
gst_dash_demux_stream_fragment_start (GstAdaptiveDemux * demux,
GstAdaptiveDemuxStream * stream);
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
static GstFlowReturn
gst_dash_demux_stream_fragment_finished (GstAdaptiveDemux * demux,
GstAdaptiveDemuxStream * stream);
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
static gboolean gst_dash_demux_need_another_chunk (GstAdaptiveDemuxStream *
stream);
dashdemux: handle error messages from the sources Set up a message handling function to be able to catch errors from the source element and signal the cond to allow the download loop to retry the download.
2014-05-02 21:30:05 +00:00
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
/* GstDashDemux */
Applied gst-indent
2012-12-20 08:04:28 +00:00
static gboolean gst_dash_demux_setup_all_streams (GstDashDemux * demux);
dashdemux: parse the sidx index from isobmff streams Allows dashdemux to identify the subsegments in the stream and switch bitrates when needed
2015-01-12 14:57:02 +00:00
static void gst_dash_demux_stream_free (GstAdaptiveDemuxStream * stream);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
all: Fix for GST_DISABLE_GST_DEBUG Where applicable, remove methods that don't do anything different than the default implementation.
2013-07-29 07:35:08 +00:00
static GstCaps *gst_dash_demux_get_input_caps (GstDashDemux * demux,
GstActiveStream * stream);
dashdemux: use audio_%02u and video_%02u names for pads Instead of using the default ghostpad%u naming. The audio_/video_ names are more common in demuxers
2015-01-26 20:51:22 +00:00
static GstPad *gst_dash_demux_create_pad (GstDashDemux * demux,
GstActiveStream * stream);
adaptivedemux: use GstSystemClock to all real-time calculations A realtime clock is used in many places, such as deciding which fragment to select at start up and deciding how long to sleep before a fragment becomes available. For example dashdemux needs sample the client's estimate of UTC when selecting where to start in a live DASH stream. The problem with dashdemux calculating the client's idea of UTC is that it makes it difficult to create unit tests, because the passage of time is a factor in the test. This commit changes dashdemux and adaptivedemux to use the GstSystemClock, so that a unit test can replace the system clock when it needs to be able to control the clock. This commit makes no change to the behaviour under normal usage, as GstSystemClock is based upon the system time. https://bugzilla.gnome.org/show_bug.cgi?id=762147
2016-02-16 14:44:10 +00:00
static GstDashDemuxClockDrift *gst_dash_demux_clock_drift_new (GstDashDemux *
demux);
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
static void gst_dash_demux_clock_drift_free (GstDashDemuxClockDrift *);
static gboolean gst_dash_demux_poll_clock_drift (GstDashDemux * demux);
static GTimeSpan gst_dash_demux_get_clock_compensation (GstDashDemux * demux);
static GDateTime *gst_dash_demux_get_server_now_utc (GstDashDemux * demux);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
#define SIDX(s) (&(s)->sidx_parser.sidx)
dashdemux: Add assertion for preventing of access after the end of the sidx entries array Better crash cleanly here than reading some random numbers from memory.
2017-03-14 17:27:45 +00:00
static inline GstSidxBoxEntry *
SIDX_ENTRY (GstDashDemuxStream * s, gint i)
{
g_assert (i < SIDX (s)->entries_count);
return &(SIDX (s)->entries[(i)]);
}
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
#define SIDX_CURRENT_ENTRY(s) SIDX_ENTRY(s, SIDX(s)->entry_index)
dashdemux: add support for generating Protection events from ContentProtection elements If a ContentProtection element is present in an AdaptationSet element, send Protection events on the source pad, so that qtdemux can use this information to correctly generate its source caps for DASH CENC encrypted streams. This allows qtdemux to support CENC encrypted DASH streams where the content protection specific information is carried in the MPD file rather than in pssh boxes in the initialisation segments. This commit adds a new function to the adaptivedemux base class to allow a GstEvent to be queued for a stream. The queue of events are sent the next time a buffer is pushed for that stream. https://bugzilla.gnome.org/show_bug.cgi?id=705991
2015-02-06 13:22:14 +00:00
static void gst_dash_demux_send_content_protection_event (gpointer cp_data,
gpointer stream);
dashdemux: port to 1.0
2013-04-18 10:41:09 +00:00
#define gst_dash_demux_parent_class parent_class
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
G_DEFINE_TYPE_WITH_CODE (GstDashDemux, gst_dash_demux, GST_TYPE_ADAPTIVE_DEMUX,
dashdemux: port to 1.0
2013-04-18 10:41:09 +00:00
GST_DEBUG_CATEGORY_INIT (gst_dash_demux_debug, "dashdemux", 0,
dashdemux: remove unnecessary semicolon https://bugzilla.gnome.org/show_bug.cgi?id=749691
2015-05-21 17:40:37 +00:00
"dashdemux element")
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
static void
gst_dash_demux_dispose (GObject * obj)
{
GstDashDemux *demux = GST_DASH_DEMUX (obj);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_dash_demux_reset (GST_ADAPTIVE_DEMUX_CAST (demux));
dashdemux: Properly stop download and stream tasks where appropriate.
2013-02-05 00:58:32 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (demux->client) {
gst_mpd_client_free (demux->client);
demux->client = NULL;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
dashdemux: handle multiple languages Handle multiple languages by using the not-linked return to stop the download task for that stream. It can be reactivated when a reconfigure event is received. Stopping the unused streams is relevant to save network bandwidth
2013-12-04 14:30:22 +00:00
g_mutex_clear (&demux->client_lock);
dashdemux: plug some leaks Add some missing free/unrefs spotted by valgrind
2013-02-18 17:02:48 +00:00
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
gst_dash_demux_clock_drift_free (demux->clock_drift);
demux->clock_drift = NULL;
dashdemux: provide a default suggestedPresentationDelay If MPD@suggestedPresentationDelay is not present in the manifest, dashdemux selects the fragment closest to the most recently generated fragment. This causes a playback issue because this choice does not allow the DASH client to build up any buffer of downloaded fragments without pausing playback. This is because by definition new fragments appear on the server in real-time (e.g. if segment duration is 4 seconds, a new fragment will appear on the server every 4 seconds). If the starting playback position was n*segmentDuration seconds behind "now", the DASH client could download up to 'n' fragments faster than realtime before it reached the point where it needed to wait for fragments to appear on the server. The MPD@suggestedPresentationDelay attribute allows a content publisher to provide a suggested starting position that is behind the current "live" position. If the MPD@suggestedPresentationDelay attribute is not present, provide a suitable default value as a property of the dashdemux element. To allow the default presentation delay to be specified either using fragments or seconds, the property is a string that contains a number and a unit (e.g. "10 seconds", "4 fragments", "2500ms").
2015-07-07 14:38:08 +00:00
g_free (demux->default_presentation_delay);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
G_OBJECT_CLASS (parent_class)->dispose (obj);
}
dashdemux: Fix handling of live streams with timeshift buffers. By implementing get_live_seek_range. As shown by : gst-validate-1.0 playbin \ uri=http://dev-iplatforms.kw.bbc.co.uk/dash/news24-avc3/news24.php This patch handles live seeking, by setting a live seek range comprised between now - timeShiftBufferDepth and now. The inteersting thing with this stream is that one can actually ask fragments up to availabilityStartTime, but it seems quite clear in the spec that content is only guaranteed to exist up to timeShiftBufferDepth. One can test live seeking this way : gst-validate-1.0 playbin \ uri=http://dev-iplatforms.kw.bbc.co.uk/dash/news24-avc3/news24.php \ --set-scenario seek_back.scenario with scenario being: description, seek=true seek, playback-time=position+5.0, start="position-600.0", flags=accurate+flush This example will play the stream, wait for five seconds, then seek back to a position 10 minutes earlier. https://bugzilla.gnome.org/show_bug.cgi?id=744362
2015-02-12 21:06:17 +00:00
static gboolean
gst_dash_demux_get_live_seek_range (GstAdaptiveDemux * demux, gint64 * start,
gint64 * stop)
{
GstDashDemux *self = GST_DASH_DEMUX (demux);
dashdemux: gst_dash_demux_get_live_seek_range returns positive values https://bugzilla.gnome.org/show_bug.cgi?id=752374
2015-11-20 19:38:03 +00:00
GDateTime *now;
GDateTime *mstart;
dashdemux: Fix handling of live streams with timeshift buffers. By implementing get_live_seek_range. As shown by : gst-validate-1.0 playbin \ uri=http://dev-iplatforms.kw.bbc.co.uk/dash/news24-avc3/news24.php This patch handles live seeking, by setting a live seek range comprised between now - timeShiftBufferDepth and now. The inteersting thing with this stream is that one can actually ask fragments up to availabilityStartTime, but it seems quite clear in the spec that content is only guaranteed to exist up to timeShiftBufferDepth. One can test live seeking this way : gst-validate-1.0 playbin \ uri=http://dev-iplatforms.kw.bbc.co.uk/dash/news24-avc3/news24.php \ --set-scenario seek_back.scenario with scenario being: description, seek=true seek, playback-time=position+5.0, start="position-600.0", flags=accurate+flush This example will play the stream, wait for five seconds, then seek back to a position 10 minutes earlier. https://bugzilla.gnome.org/show_bug.cgi?id=744362
2015-02-12 21:06:17 +00:00
GTimeSpan stream_now;
dashdemux: include segment duration when calculating seek range The gst_dash_demux_get_live_seek_range () function returns a stop value that is beyond the available range. The functions gst_mpd_client_check_time_position() and gst_mpd_client_get_next_segment_availability_end_time() in gstmpdparser.c include the segment duration when checking if a segment is available. The gst_dash_demux_get_live_seek_range() function in gstdashdemux.c ignores the segment duration. According to the DASH specification, if maxSegmentDuration is not present, then the maximum Segment duration is the maximum duration of any Segment documented in the MPD. https://bugzilla.gnome.org/show_bug.cgi?id=753751
2016-02-24 15:54:54 +00:00
GstClockTime seg_duration;
dashdemux: Fix handling of live streams with timeshift buffers. By implementing get_live_seek_range. As shown by : gst-validate-1.0 playbin \ uri=http://dev-iplatforms.kw.bbc.co.uk/dash/news24-avc3/news24.php This patch handles live seeking, by setting a live seek range comprised between now - timeShiftBufferDepth and now. The inteersting thing with this stream is that one can actually ask fragments up to availabilityStartTime, but it seems quite clear in the spec that content is only guaranteed to exist up to timeShiftBufferDepth. One can test live seeking this way : gst-validate-1.0 playbin \ uri=http://dev-iplatforms.kw.bbc.co.uk/dash/news24-avc3/news24.php \ --set-scenario seek_back.scenario with scenario being: description, seek=true seek, playback-time=position+5.0, start="position-600.0", flags=accurate+flush This example will play the stream, wait for five seconds, then seek back to a position 10 minutes earlier. https://bugzilla.gnome.org/show_bug.cgi?id=744362
2015-02-12 21:06:17 +00:00
dashdemux: gst_dash_demux_get_live_seek_range returns positive values https://bugzilla.gnome.org/show_bug.cgi?id=752374
2015-11-20 19:38:03 +00:00
if (self->client->mpd_node->availabilityStartTime == NULL)
return FALSE;
dashdemux: include segment duration when calculating seek range The gst_dash_demux_get_live_seek_range () function returns a stop value that is beyond the available range. The functions gst_mpd_client_check_time_position() and gst_mpd_client_get_next_segment_availability_end_time() in gstmpdparser.c include the segment duration when checking if a segment is available. The gst_dash_demux_get_live_seek_range() function in gstdashdemux.c ignores the segment duration. According to the DASH specification, if maxSegmentDuration is not present, then the maximum Segment duration is the maximum duration of any Segment documented in the MPD. https://bugzilla.gnome.org/show_bug.cgi?id=753751
2016-02-24 15:54:54 +00:00
seg_duration = gst_mpd_client_get_maximum_segment_duration (self->client);
dashdemux: gst_dash_demux_get_live_seek_range returns positive values https://bugzilla.gnome.org/show_bug.cgi?id=752374
2015-11-20 19:38:03 +00:00
now = gst_dash_demux_get_server_now_utc (self);
mstart =
gst_date_time_to_g_date_time (self->client->
mpd_node->availabilityStartTime);
dashdemux: Fix handling of live streams with timeshift buffers. By implementing get_live_seek_range. As shown by : gst-validate-1.0 playbin \ uri=http://dev-iplatforms.kw.bbc.co.uk/dash/news24-avc3/news24.php This patch handles live seeking, by setting a live seek range comprised between now - timeShiftBufferDepth and now. The inteersting thing with this stream is that one can actually ask fragments up to availabilityStartTime, but it seems quite clear in the spec that content is only guaranteed to exist up to timeShiftBufferDepth. One can test live seeking this way : gst-validate-1.0 playbin \ uri=http://dev-iplatforms.kw.bbc.co.uk/dash/news24-avc3/news24.php \ --set-scenario seek_back.scenario with scenario being: description, seek=true seek, playback-time=position+5.0, start="position-600.0", flags=accurate+flush This example will play the stream, wait for five seconds, then seek back to a position 10 minutes earlier. https://bugzilla.gnome.org/show_bug.cgi?id=744362
2015-02-12 21:06:17 +00:00
stream_now = g_date_time_difference (now, mstart);
g_date_time_unref (now);
g_date_time_unref (mstart);
dashdemux: gst_dash_demux_get_live_seek_range returns positive values https://bugzilla.gnome.org/show_bug.cgi?id=752374
2015-11-20 19:38:03 +00:00
if (stream_now <= 0)
return FALSE;
*stop = stream_now * GST_USECOND;
if (self->client->mpd_node->timeShiftBufferDepth == GST_MPD_DURATION_NONE) {
*start = 0;
} else {
*start =
*stop - (self->client->mpd_node->timeShiftBufferDepth * GST_MSECOND);
if (*start < 0)
*start = 0;
}
dashdemux: include segment duration when calculating seek range The gst_dash_demux_get_live_seek_range () function returns a stop value that is beyond the available range. The functions gst_mpd_client_check_time_position() and gst_mpd_client_get_next_segment_availability_end_time() in gstmpdparser.c include the segment duration when checking if a segment is available. The gst_dash_demux_get_live_seek_range() function in gstdashdemux.c ignores the segment duration. According to the DASH specification, if maxSegmentDuration is not present, then the maximum Segment duration is the maximum duration of any Segment documented in the MPD. https://bugzilla.gnome.org/show_bug.cgi?id=753751
2016-02-24 15:54:54 +00:00
/* As defined in 5.3.9.5.3 of the DASH specification, a segment does
not become available until the sum of:
* the value of the MPD@availabilityStartTime,
* the PeriodStart time of the containing Period
* the MPD start time of the Media Segment, and
* the MPD duration of the Media Segment.
Therefore we need to subtract the media segment duration from the stop
time.
*/
*stop -= seg_duration;
dashdemux: Fix handling of live streams with timeshift buffers. By implementing get_live_seek_range. As shown by : gst-validate-1.0 playbin \ uri=http://dev-iplatforms.kw.bbc.co.uk/dash/news24-avc3/news24.php This patch handles live seeking, by setting a live seek range comprised between now - timeShiftBufferDepth and now. The inteersting thing with this stream is that one can actually ask fragments up to availabilityStartTime, but it seems quite clear in the spec that content is only guaranteed to exist up to timeShiftBufferDepth. One can test live seeking this way : gst-validate-1.0 playbin \ uri=http://dev-iplatforms.kw.bbc.co.uk/dash/news24-avc3/news24.php \ --set-scenario seek_back.scenario with scenario being: description, seek=true seek, playback-time=position+5.0, start="position-600.0", flags=accurate+flush This example will play the stream, wait for five seconds, then seek back to a position 10 minutes earlier. https://bugzilla.gnome.org/show_bug.cgi?id=744362
2015-02-12 21:06:17 +00:00
return TRUE;
}
dashdemux: implement get_presentation_offset. To account for presentationTimeOffset as per section 7.2.1 . https://bugzilla.gnome.org/show_bug.cgi?id=745455
2015-03-02 13:00:03 +00:00
static GstClockTime
gst_dash_demux_get_presentation_offset (GstAdaptiveDemux * demux,
GstAdaptiveDemuxStream * stream)
{
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
return gst_mpd_parser_get_stream_presentation_offset (dashdemux->client,
dashstream->index);
}
dashdemux: Export the period start time to the base class https://bugzilla.gnome.org/show_bug.cgi?id=754222
2015-09-02 15:33:51 +00:00
static GstClockTime
gst_dash_demux_get_period_start_time (GstAdaptiveDemux * demux)
{
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
return gst_mpd_parser_get_period_start_time (dashdemux->client);
}
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
static void
gst_dash_demux_class_init (GstDashDemuxClass * klass)
{
GObjectClass *gobject_class;
GstElementClass *gstelement_class;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstAdaptiveDemuxClass *gstadaptivedemux_class;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
gobject_class = (GObjectClass *) klass;
gstelement_class = (GstElementClass *) klass;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gstadaptivedemux_class = (GstAdaptiveDemuxClass *) klass;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
gobject_class->set_property = gst_dash_demux_set_property;
gobject_class->get_property = gst_dash_demux_get_property;
gobject_class->dispose = gst_dash_demux_dispose;
Sprinkle some G_PARAM_DEPRECATED and #ifndef GST_REMOVE_DEPRECATED
2014-11-02 17:18:12 +00:00
#ifndef GST_REMOVE_DEPRECATED
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
g_object_class_install_property (gobject_class, PROP_MAX_BUFFERING_TIME,
g_param_spec_uint ("max-buffering-time", "Maximum buffering time",
dashdemux: deprecate max-buffering-time property It is not used as dashdemux doesn't have a internal buffer for fragments anymore
2014-05-06 11:52:27 +00:00
"Maximum number of seconds of buffer accumulated during playback"
"(deprecated)",
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
2, G_MAXUINT, DEFAULT_MAX_BUFFERING_TIME,
Sprinkle some G_PARAM_DEPRECATED and #ifndef GST_REMOVE_DEPRECATED
2014-11-02 17:18:12 +00:00
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS | G_PARAM_DEPRECATED));
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
g_object_class_install_property (gobject_class, PROP_BANDWIDTH_USAGE,
g_param_spec_float ("bandwidth-usage",
"Bandwidth usage [0..1]",
dashdemux: depracate bandwidth-usage in favor of bitrate-limit Bitrate-limit is already available in the baseclass and, even though the bandwidth-usage name is better, hls and mss already used bitrate-limit. This patch deprecates the bandwidth-usage and maps it to the baseclass bitrate-limite.
2015-02-17 13:50:59 +00:00
"Percentage of the available bandwidth to use when "
"selecting representations (deprecated)",
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
0, 1, DEFAULT_BANDWIDTH_USAGE,
dashdemux: marked PROP_BANDWIDTH_USAGE property as deprecated https://bugzilla.gnome.org/show_bug.cgi?id=753890
2015-08-20 17:14:36 +00:00
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS | G_PARAM_DEPRECATED));
dashdemux: depracate bandwidth-usage in favor of bitrate-limit Bitrate-limit is already available in the baseclass and, even though the bandwidth-usage name is better, hls and mss already used bitrate-limit. This patch deprecates the bandwidth-usage and maps it to the baseclass bitrate-limite.
2015-02-17 13:50:59 +00:00
#endif
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
g_object_class_install_property (gobject_class, PROP_MAX_BITRATE,
g_param_spec_uint ("max-bitrate", "Max bitrate",
dashdemux: Add properties to select maximum allowed width/height and framerate https://bugzilla.gnome.org/show_bug.cgi?id=770408
2016-08-25 17:50:11 +00:00
"Max of bitrate supported by target video decoder (0 = no maximum)",
0, G_MAXUINT, DEFAULT_MAX_BITRATE,
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));
g_object_class_install_property (gobject_class, PROP_MAX_VIDEO_WIDTH,
g_param_spec_uint ("max-video-width", "Max video width",
"Max video width to select (0 = no maximum)",
0, G_MAXUINT, DEFAULT_MAX_VIDEO_WIDTH,
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));
g_object_class_install_property (gobject_class, PROP_MAX_VIDEO_HEIGHT,
g_param_spec_uint ("max-video-height", "Max video height",
"Max video height to select (0 = no maximum)",
0, G_MAXUINT, DEFAULT_MAX_VIDEO_HEIGHT,
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));
g_object_class_install_property (gobject_class, PROP_MAX_VIDEO_FRAMERATE,
gst_param_spec_fraction ("max-video-framerate", "Max video framerate",
"Max video framerate to select (0/1 = no maximum)",
0, 1, G_MAXINT, 1, DEFAULT_MAX_VIDEO_FRAMERATE_N,
DEFAULT_MAX_VIDEO_FRAMERATE_D,
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));
dashdemux: provide a default suggestedPresentationDelay If MPD@suggestedPresentationDelay is not present in the manifest, dashdemux selects the fragment closest to the most recently generated fragment. This causes a playback issue because this choice does not allow the DASH client to build up any buffer of downloaded fragments without pausing playback. This is because by definition new fragments appear on the server in real-time (e.g. if segment duration is 4 seconds, a new fragment will appear on the server every 4 seconds). If the starting playback position was n*segmentDuration seconds behind "now", the DASH client could download up to 'n' fragments faster than realtime before it reached the point where it needed to wait for fragments to appear on the server. The MPD@suggestedPresentationDelay attribute allows a content publisher to provide a suggested starting position that is behind the current "live" position. If the MPD@suggestedPresentationDelay attribute is not present, provide a suitable default value as a property of the dashdemux element. To allow the default presentation delay to be specified either using fragments or seconds, the property is a string that contains a number and a unit (e.g. "10 seconds", "4 fragments", "2500ms").
2015-07-07 14:38:08 +00:00
g_object_class_install_property (gobject_class, PROP_PRESENTATION_DELAY,
g_param_spec_string ("presentation-delay", "Presentation delay",
"Default presentation delay (in seconds, milliseconds or fragments) (e.g. 12s, 2500ms, 3f)",
DEFAULT_PRESENTATION_DELAY,
G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));
bad: use new gst_element_class_add_static_pad_template() https://bugzilla.gnome.org/show_bug.cgi?id=763081
2016-03-04 06:50:26 +00:00
gst_element_class_add_static_pad_template (gstelement_class,
&gst_dash_demux_audiosrc_template);
gst_element_class_add_static_pad_template (gstelement_class,
&gst_dash_demux_videosrc_template);
gst_element_class_add_static_pad_template (gstelement_class,
&gst_dash_demux_subtitlesrc_template);
gst_element_class_add_static_pad_template (gstelement_class, &sinktemplate);
dashdemux: port to 1.0
2013-04-18 10:41:09 +00:00
gst_element_class_set_static_metadata (gstelement_class,
"DASH Demuxer",
ext: Use Codec/Demuxer/Adaptive for the adaptive streaming demuxers
2014-02-20 14:09:36 +00:00
"Codec/Demuxer/Adaptive",
dashdemux: port to 1.0
2013-04-18 10:41:09 +00:00
"Dynamic Adaptive Streaming over HTTP demuxer",
"David Corvoysier <david.corvoysier@orange.com>\n\
Hamid Zakari <hamid.zakari@gmail.com>\n\
Gianluca Gennari <gennarone@gmail.com>");
dashdemux: handle error messages from the sources Set up a message handling function to be able to catch errors from the source element and signal the cond to allow the download loop to retry the download.
2014-05-02 21:30:05 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gstadaptivedemux_class->get_duration = gst_dash_demux_get_duration;
gstadaptivedemux_class->is_live = gst_dash_demux_is_live;
gstadaptivedemux_class->reset = gst_dash_demux_reset;
gstadaptivedemux_class->seek = gst_dash_demux_seek;
gstadaptivedemux_class->process_manifest = gst_dash_demux_process_manifest;
adaptivedemux: Allow subclasses to override how a new manifest would be downloaded
2015-04-23 15:22:11 +00:00
gstadaptivedemux_class->update_manifest_data =
gst_dash_demux_update_manifest_data;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gstadaptivedemux_class->get_manifest_update_interval =
gst_dash_demux_get_manifest_update_interval;
gstadaptivedemux_class->has_next_period = gst_dash_demux_has_next_period;
gstadaptivedemux_class->advance_period = gst_dash_demux_advance_period;
dashdemux: avoid busy-looping when waiting for new fragment When all fragments have already been downloaded on a live stream dashdemux would busy loop as the default implementation of has_next_fragment would return TRUE. Implement it to correctly signal if adaptivedemux should wait for the manifest update before trying to get new fragments.
2015-05-12 16:41:19 +00:00
gstadaptivedemux_class->stream_has_next_fragment =
gst_dash_demux_stream_has_next_fragment;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gstadaptivedemux_class->stream_advance_fragment =
gst_dash_demux_stream_advance_fragment;
gstadaptivedemux_class->stream_get_fragment_waiting_time =
gst_dash_demux_stream_get_fragment_waiting_time;
gstadaptivedemux_class->stream_seek = gst_dash_demux_stream_seek;
gstadaptivedemux_class->stream_select_bitrate =
gst_dash_demux_stream_select_bitrate;
gstadaptivedemux_class->stream_update_fragment_info =
gst_dash_demux_stream_update_fragment_info;
dashdemux: parse the sidx index from isobmff streams Allows dashdemux to identify the subsegments in the stream and switch bitrates when needed
2015-01-12 14:57:02 +00:00
gstadaptivedemux_class->stream_free = gst_dash_demux_stream_free;
dashdemux: protect against malformed isombff format Be more careful around malformed mpds that announce using isombff profile but actually are regular mpds
2015-02-16 02:16:52 +00:00
gstadaptivedemux_class->get_live_seek_range =
gst_dash_demux_get_live_seek_range;
dashdemux: implement get_presentation_offset. To account for presentationTimeOffset as per section 7.2.1 . https://bugzilla.gnome.org/show_bug.cgi?id=745455
2015-03-02 13:00:03 +00:00
gstadaptivedemux_class->get_presentation_offset =
gst_dash_demux_get_presentation_offset;
dashdemux: Export the period start time to the base class https://bugzilla.gnome.org/show_bug.cgi?id=754222
2015-09-02 15:33:51 +00:00
gstadaptivedemux_class->get_period_start_time =
gst_dash_demux_get_period_start_time;
dashdemux: don't meddle with the class struct from an instance Fix some very dubious code. The class methods should always be set, and the instance-specific check should then be done inside the method. For data_received that's there already, for finish_fragment we need to add it. https://bugzilla.gnome.org/show_bug.cgi?id=753937
2015-08-21 15:13:43 +00:00
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
gstadaptivedemux_class->start_fragment = gst_dash_demux_stream_fragment_start;
dashdemux: don't meddle with the class struct from an instance Fix some very dubious code. The class methods should always be set, and the instance-specific check should then be done inside the method. For data_received that's there already, for finish_fragment we need to add it. https://bugzilla.gnome.org/show_bug.cgi?id=753937
2015-08-21 15:13:43 +00:00
gstadaptivedemux_class->finish_fragment =
gst_dash_demux_stream_fragment_finished;
gstadaptivedemux_class->data_received = gst_dash_demux_data_received;
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
gstadaptivedemux_class->need_another_chunk =
gst_dash_demux_need_another_chunk;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
static void
dashdemux: port to 1.0
2013-04-18 10:41:09 +00:00
gst_dash_demux_init (GstDashDemux * demux)
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
{
/* Properties */
demux->max_buffering_time = DEFAULT_MAX_BUFFERING_TIME * GST_SECOND;
demux->max_bitrate = DEFAULT_MAX_BITRATE;
dashdemux: Add properties to select maximum allowed width/height and framerate https://bugzilla.gnome.org/show_bug.cgi?id=770408
2016-08-25 17:50:11 +00:00
demux->max_video_width = DEFAULT_MAX_VIDEO_WIDTH;
demux->max_video_height = DEFAULT_MAX_VIDEO_HEIGHT;
demux->max_video_framerate_n = DEFAULT_MAX_VIDEO_FRAMERATE_N;
demux->max_video_framerate_d = DEFAULT_MAX_VIDEO_FRAMERATE_D;
dashdemux: provide a default suggestedPresentationDelay If MPD@suggestedPresentationDelay is not present in the manifest, dashdemux selects the fragment closest to the most recently generated fragment. This causes a playback issue because this choice does not allow the DASH client to build up any buffer of downloaded fragments without pausing playback. This is because by definition new fragments appear on the server in real-time (e.g. if segment duration is 4 seconds, a new fragment will appear on the server every 4 seconds). If the starting playback position was n*segmentDuration seconds behind "now", the DASH client could download up to 'n' fragments faster than realtime before it reached the point where it needed to wait for fragments to appear on the server. The MPD@suggestedPresentationDelay attribute allows a content publisher to provide a suggested starting position that is behind the current "live" position. If the MPD@suggestedPresentationDelay attribute is not present, provide a suitable default value as a property of the dashdemux element. To allow the default presentation delay to be specified either using fragments or seconds, the property is a string that contains a number and a unit (e.g. "10 seconds", "4 fragments", "2500ms").
2015-07-07 14:38:08 +00:00
demux->default_presentation_delay = DEFAULT_PRESENTATION_DELAY;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
dashdemux: handle multiple languages Handle multiple languages by using the not-linked return to stop the download task for that stream. It can be reactivated when a reconfigure event is received. Stopping the unused streams is relevant to save network bandwidth
2013-12-04 14:30:22 +00:00
g_mutex_init (&demux->client_lock);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_adaptive_demux_set_stream_struct_size (GST_ADAPTIVE_DEMUX_CAST (demux),
sizeof (GstDashDemuxStream));
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
static void
gst_dash_demux_set_property (GObject * object, guint prop_id,
const GValue * value, GParamSpec * pspec)
{
dashdemux: depracate bandwidth-usage in favor of bitrate-limit Bitrate-limit is already available in the baseclass and, even though the bandwidth-usage name is better, hls and mss already used bitrate-limit. This patch deprecates the bandwidth-usage and maps it to the baseclass bitrate-limite.
2015-02-17 13:50:59 +00:00
GstAdaptiveDemux *adaptivedemux = GST_ADAPTIVE_DEMUX_CAST (object);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
GstDashDemux *demux = GST_DASH_DEMUX (object);
switch (prop_id) {
case PROP_MAX_BUFFERING_TIME:
demux->max_buffering_time = g_value_get_uint (value) * GST_SECOND;
break;
case PROP_BANDWIDTH_USAGE:
dashdemux: depracate bandwidth-usage in favor of bitrate-limit Bitrate-limit is already available in the baseclass and, even though the bandwidth-usage name is better, hls and mss already used bitrate-limit. This patch deprecates the bandwidth-usage and maps it to the baseclass bitrate-limite.
2015-02-17 13:50:59 +00:00
adaptivedemux->bitrate_limit = g_value_get_float (value);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
break;
case PROP_MAX_BITRATE:
demux->max_bitrate = g_value_get_uint (value);
break;
dashdemux: Add properties to select maximum allowed width/height and framerate https://bugzilla.gnome.org/show_bug.cgi?id=770408
2016-08-25 17:50:11 +00:00
case PROP_MAX_VIDEO_WIDTH:
demux->max_video_width = g_value_get_uint (value);
break;
case PROP_MAX_VIDEO_HEIGHT:
demux->max_video_height = g_value_get_uint (value);
break;
case PROP_MAX_VIDEO_FRAMERATE:
demux->max_video_framerate_n = gst_value_get_fraction_numerator (value);
demux->max_video_framerate_d = gst_value_get_fraction_denominator (value);
break;
dashdemux: provide a default suggestedPresentationDelay If MPD@suggestedPresentationDelay is not present in the manifest, dashdemux selects the fragment closest to the most recently generated fragment. This causes a playback issue because this choice does not allow the DASH client to build up any buffer of downloaded fragments without pausing playback. This is because by definition new fragments appear on the server in real-time (e.g. if segment duration is 4 seconds, a new fragment will appear on the server every 4 seconds). If the starting playback position was n*segmentDuration seconds behind "now", the DASH client could download up to 'n' fragments faster than realtime before it reached the point where it needed to wait for fragments to appear on the server. The MPD@suggestedPresentationDelay attribute allows a content publisher to provide a suggested starting position that is behind the current "live" position. If the MPD@suggestedPresentationDelay attribute is not present, provide a suitable default value as a property of the dashdemux element. To allow the default presentation delay to be specified either using fragments or seconds, the property is a string that contains a number and a unit (e.g. "10 seconds", "4 fragments", "2500ms").
2015-07-07 14:38:08 +00:00
case PROP_PRESENTATION_DELAY:
g_free (demux->default_presentation_delay);
demux->default_presentation_delay = g_value_dup_string (value);
break;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
}
static void
gst_dash_demux_get_property (GObject * object, guint prop_id, GValue * value,
GParamSpec * pspec)
{
dashdemux: depracate bandwidth-usage in favor of bitrate-limit Bitrate-limit is already available in the baseclass and, even though the bandwidth-usage name is better, hls and mss already used bitrate-limit. This patch deprecates the bandwidth-usage and maps it to the baseclass bitrate-limite.
2015-02-17 13:50:59 +00:00
GstAdaptiveDemux *adaptivedemux = GST_ADAPTIVE_DEMUX_CAST (object);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
GstDashDemux *demux = GST_DASH_DEMUX (object);
switch (prop_id) {
case PROP_MAX_BUFFERING_TIME:
dashdemux: Fix issue with get returning a value for max-buffering-time It was not properly divided by GST_SECONDS. Also fix issue with max-buffering-time being multiplied by GST_SECONDS every time the property is retrieved. https://bugzilla.gnome.org/show_bug.cgi?id=700487
2013-05-06 20:56:01 +00:00
g_value_set_uint (value, demux->max_buffering_time / GST_SECOND);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
break;
case PROP_BANDWIDTH_USAGE:
dashdemux: depracate bandwidth-usage in favor of bitrate-limit Bitrate-limit is already available in the baseclass and, even though the bandwidth-usage name is better, hls and mss already used bitrate-limit. This patch deprecates the bandwidth-usage and maps it to the baseclass bitrate-limite.
2015-02-17 13:50:59 +00:00
g_value_set_float (value, adaptivedemux->bitrate_limit);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
break;
case PROP_MAX_BITRATE:
g_value_set_uint (value, demux->max_bitrate);
break;
dashdemux: Add properties to select maximum allowed width/height and framerate https://bugzilla.gnome.org/show_bug.cgi?id=770408
2016-08-25 17:50:11 +00:00
case PROP_MAX_VIDEO_WIDTH:
g_value_set_uint (value, demux->max_video_width);
break;
case PROP_MAX_VIDEO_HEIGHT:
g_value_set_uint (value, demux->max_video_height);
break;
case PROP_MAX_VIDEO_FRAMERATE:
gst_value_set_fraction (value, demux->max_video_framerate_n,
demux->max_video_framerate_d);
break;
dashdemux: provide a default suggestedPresentationDelay If MPD@suggestedPresentationDelay is not present in the manifest, dashdemux selects the fragment closest to the most recently generated fragment. This causes a playback issue because this choice does not allow the DASH client to build up any buffer of downloaded fragments without pausing playback. This is because by definition new fragments appear on the server in real-time (e.g. if segment duration is 4 seconds, a new fragment will appear on the server every 4 seconds). If the starting playback position was n*segmentDuration seconds behind "now", the DASH client could download up to 'n' fragments faster than realtime before it reached the point where it needed to wait for fragments to appear on the server. The MPD@suggestedPresentationDelay attribute allows a content publisher to provide a suggested starting position that is behind the current "live" position. If the MPD@suggestedPresentationDelay attribute is not present, provide a suitable default value as a property of the dashdemux element. To allow the default presentation delay to be specified either using fragments or seconds, the property is a string that contains a number and a unit (e.g. "10 seconds", "4 fragments", "2500ms").
2015-07-07 14:38:08 +00:00
case PROP_PRESENTATION_DELAY:
if (demux->default_presentation_delay == NULL)
g_value_set_static_string (value, "");
else
g_value_set_string (value, demux->default_presentation_delay);
break;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
}
dashdemux: properly error out when manifest has no streams Post an error message when the manifest is parsed and no valid streams are found be activated and used. Fixes #704308
2013-07-31 01:06:38 +00:00
static gboolean
dashdemux: reimplementing live streams manifest updates Manifest updates should be done periodically for live streams, this patch makes the demuxer create a new manifest client for the new version and transfers the stream position to the new one, discarding the old one afterwards.
2013-02-22 19:40:36 +00:00
gst_dash_demux_setup_mpdparser_streams (GstDashDemux * demux,
GstMpdClient * client)
dashdemux: complete support for Media Presentations with several Periods - Periods are played in sequence, from PeriodStart to PeriodEnd - seamless switching from one Period to the next one works fine; - the 'new-segment' generation is broken, so if we need to switch pads for a new Period there is a crash;
2012-10-24 09:49:51 +00:00
{
dashdemux: properly error out when manifest has no streams Post an error message when the manifest is parsed and no valid streams are found be activated and used. Fixes #704308
2013-07-31 01:06:38 +00:00
gboolean has_streams = FALSE;
dashdemux: expose all streams always expose all streams instead of only exposing one of each type. This is more aligned with gstreamer's way of working. Allows the user to select the stream that it wants to use by linking its pad and leaving the unused ones as unlinked.
2013-12-02 20:31:41 +00:00
GList *adapt_sets, *iter;
dashdemux: complete support for Media Presentations with several Periods - Periods are played in sequence, from PeriodStart to PeriodEnd - seamless switching from one Period to the next one works fine; - the 'new-segment' generation is broken, so if we need to switch pads for a new Period there is a crash;
2012-10-24 09:49:51 +00:00
dashdemux: expose all streams always expose all streams instead of only exposing one of each type. This is more aligned with gstreamer's way of working. Allows the user to select the stream that it wants to use by linking its pad and leaving the unused ones as unlinked.
2013-12-02 20:31:41 +00:00
adapt_sets = gst_mpd_client_get_adaptation_sets (client);
for (iter = adapt_sets; iter; iter = g_list_next (iter)) {
GstAdaptationSetNode *adapt_set_node = iter->data;
dashdemux: complete support for Media Presentations with several Periods - Periods are played in sequence, from PeriodStart to PeriodEnd - seamless switching from one Period to the next one works fine; - the 'new-segment' generation is broken, so if we need to switch pads for a new Period there is a crash;
2012-10-24 09:49:51 +00:00
dashdemux: expose all streams always expose all streams instead of only exposing one of each type. This is more aligned with gstreamer's way of working. Allows the user to select the stream that it wants to use by linking its pad and leaving the unused ones as unlinked.
2013-12-02 20:31:41 +00:00
gst_mpd_client_setup_streaming (client, adapt_set_node);
has_streams = TRUE;
dashdemux: properly error out when manifest has no streams Post an error message when the manifest is parsed and no valid streams are found be activated and used. Fixes #704308
2013-07-31 01:06:38 +00:00
}
dashdemux: expose all streams always expose all streams instead of only exposing one of each type. This is more aligned with gstreamer's way of working. Allows the user to select the stream that it wants to use by linking its pad and leaving the unused ones as unlinked.
2013-12-02 20:31:41 +00:00
dashdemux: properly error out when manifest has no streams Post an error message when the manifest is parsed and no valid streams are found be activated and used. Fixes #704308
2013-07-31 01:06:38 +00:00
if (!has_streams) {
GST_ELEMENT_ERROR (demux, STREAM, DEMUX, ("Manifest has no playable "
dashdemux: expose all streams always expose all streams instead of only exposing one of each type. This is more aligned with gstreamer's way of working. Allows the user to select the stream that it wants to use by linking its pad and leaving the unused ones as unlinked.
2013-12-02 20:31:41 +00:00
"streams"), ("No streams could be activated from the manifest"));
dashdemux: complete support for Media Presentations with several Periods - Periods are played in sequence, from PeriodStart to PeriodEnd - seamless switching from one Period to the next one works fine; - the 'new-segment' generation is broken, so if we need to switch pads for a new Period there is a crash;
2012-10-24 09:49:51 +00:00
}
dashdemux: properly error out when manifest has no streams Post an error message when the manifest is parsed and no valid streams are found be activated and used. Fixes #704308
2013-07-31 01:06:38 +00:00
return has_streams;
dashdemux: reimplementing live streams manifest updates Manifest updates should be done periodically for live streams, this patch makes the demuxer create a new manifest client for the new version and transfers the stream position to the new one, discarding the old one afterwards.
2013-02-22 19:40:36 +00:00
}
static gboolean
gst_dash_demux_setup_all_streams (GstDashDemux * demux)
{
guint i;
dashdemux: fix multiple period mpd playback Make dash playlists with multiple periods work again by waiting to switch the periods when all streams have reached the end of the current period. The stream_loop is responsible for advancing the period, but the download loops will already start downloading data for the next period as soon as possible.
2013-12-09 14:28:25 +00:00
GST_DEBUG_OBJECT (demux, "Setting up streams for period %d",
gst_mpd_client_get_period_index (demux->client));
dashdemux: reimplementing live streams manifest updates Manifest updates should be done periodically for live streams, this patch makes the demuxer create a new manifest client for the new version and transfers the stream position to the new one, discarding the old one afterwards.
2013-02-22 19:40:36 +00:00
/* clean old active stream list, if any */
gst_active_streams_free (demux->client);
dashdemux: refactor streams data to its own struct Keeps code more organized and similar to what other demuxers usually do
2013-01-28 13:46:27 +00:00
dashdemux: properly error out when manifest has no streams Post an error message when the manifest is parsed and no valid streams are found be activated and used. Fixes #704308
2013-07-31 01:06:38 +00:00
if (!gst_dash_demux_setup_mpdparser_streams (demux, demux->client)) {
return FALSE;
}
dashdemux: refactor streams data to its own struct Keeps code more organized and similar to what other demuxers usually do
2013-01-28 13:46:27 +00:00
GST_DEBUG_OBJECT (demux, "Creating stream objects");
for (i = 0; i < gst_mpdparser_get_nb_active_stream (demux->client); i++) {
GstDashDemuxStream *stream;
GstActiveStream *active_stream;
GstCaps *caps;
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
GstStructure *s;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstPad *srcpad;
dashdemux: push language code tag Language code tag is retrieved from the AdaptationSet language property. https://bugzilla.gnome.org/show_bug.cgi?id=732237
2014-06-25 13:55:32 +00:00
gchar *lang = NULL;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstTagList *tags = NULL;
dashdemux: refactor streams data to its own struct Keeps code more organized and similar to what other demuxers usually do
2013-01-28 13:46:27 +00:00
active_stream = gst_mpdparser_get_active_stream_by_index (demux->client, i);
if (active_stream == NULL)
continue;
dashdemux: Skip audio streams if TRICKMODE_NO_AUDIO is given in the seek event We just don't expose pads for audio streams, or even download them.
2016-07-28 08:27:29 +00:00
if (demux->trickmode_no_audio
&& active_stream->mimeType == GST_STREAM_AUDIO) {
GST_DEBUG_OBJECT (demux,
"Skipping audio stream %d because of TRICKMODE_NO_AUDIO flag", i);
continue;
}
dashdemux: use audio_%02u and video_%02u names for pads Instead of using the default ghostpad%u naming. The audio_/video_ names are more common in demuxers
2015-01-26 20:51:22 +00:00
srcpad = gst_dash_demux_create_pad (demux, active_stream);
dashdemux: create src pads for subtitle streams. Create src pads for Representations that contain timed-text subtitles, both when the subtitles are encapsulated in ISO BMFF (i.e., the Representation has mimeType "application/mp4") and when they are unencapsulated (i.e., the Representation has mimeType "application/ttml+xml"). https://bugzilla.gnome.org/show_bug.cgi?id=747774
2015-08-18 13:16:11 +00:00
if (srcpad == NULL)
continue;
dashdemux: refactor streams data to its own struct Keeps code more organized and similar to what other demuxers usually do
2013-01-28 13:46:27 +00:00
caps = gst_dash_demux_get_input_caps (demux, active_stream);
GST_LOG_OBJECT (demux, "Creating stream %d %" GST_PTR_FORMAT, i, caps);
dashdemux: push language code tag Language code tag is retrieved from the AdaptationSet language property. https://bugzilla.gnome.org/show_bug.cgi?id=732237
2014-06-25 13:55:32 +00:00
if (active_stream->cur_adapt_set) {
dashdemux: read language from ContentComponent node as a fallback If the language is not specified in the AdaptationSet, use the ContentComponent node to get it. We only get it if there is only a single ContentComponent as it doesn't seem clear on what to do if there are multiple entries https://bugzilla.gnome.org/show_bug.cgi?id=732237
2014-08-19 19:01:58 +00:00
GstAdaptationSetNode *adp_set = active_stream->cur_adapt_set;
lang = adp_set->lang;
/* Fallback to the language in ContentComponent node */
dashdemux: improve detection of stream language Improved the detection of stream's language if the AdaptationSet contains more than 1 ContentComponent https://bugzilla.gnome.org/show_bug.cgi?id=752367
2015-09-09 13:09:43 +00:00
if (lang == NULL) {
GList *it;
for (it = adp_set->ContentComponents; it; it = it->next) {
GstContentComponentNode *cc_node = it->data;
if (cc_node->lang) {
lang = cc_node->lang;
break;
}
}
dashdemux: read language from ContentComponent node as a fallback If the language is not specified in the AdaptationSet, use the ContentComponent node to get it. We only get it if there is only a single ContentComponent as it doesn't seem clear on what to do if there are multiple entries https://bugzilla.gnome.org/show_bug.cgi?id=732237
2014-08-19 19:01:58 +00:00
}
dashdemux: push language code tag Language code tag is retrieved from the AdaptationSet language property. https://bugzilla.gnome.org/show_bug.cgi?id=732237
2014-06-25 13:55:32 +00:00
}
if (lang) {
if (gst_tag_check_language_code (lang))
tags = gst_tag_list_new (GST_TAG_LANGUAGE_CODE, lang, NULL);
else
tags = gst_tag_list_new (GST_TAG_LANGUAGE_NAME, lang, NULL);
}
dashdemux: switch bitrates without switching pads
2013-02-07 23:58:37 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
stream = (GstDashDemuxStream *)
gst_adaptive_demux_stream_new (GST_ADAPTIVE_DEMUX_CAST (demux), srcpad);
stream->active_stream = active_stream;
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
s = gst_caps_get_structure (caps, 0);
dashdemux: Always parsing sidx for On-Demand profile The indexRange attribute is optional and if it's not present, we should extract the sidx box from incoming buffers. https://bugzilla.gnome.org/show_bug.cgi?id=776200
2016-12-20 02:16:11 +00:00
stream->is_isobmff =
gst_structure_has_name (s, "video/quicktime") ||
gst_structure_has_name (s, "audio/x-m4a");
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
stream->first_sync_sample_always_after_moof = TRUE;
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
if (stream->is_isobmff)
stream->isobmff_adapter = gst_adapter_new ();
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_adaptive_demux_stream_set_caps (GST_ADAPTIVE_DEMUX_STREAM_CAST (stream),
caps);
if (tags)
gst_adaptive_demux_stream_set_tags (GST_ADAPTIVE_DEMUX_STREAM_CAST
(stream), tags);
stream->index = i;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
stream->pending_seek_ts = GST_CLOCK_TIME_NONE;
dashdemux: Fix issue when manifest update sets slow start without passing necessary header & caps changes downstream https://bugzilla.gnome.org/show_bug.cgi?id=777206
2017-01-17 02:33:03 +00:00
stream->last_representation_id = NULL;
dashdemux: add support for generating Protection events from ContentProtection elements If a ContentProtection element is present in an AdaptationSet element, send Protection events on the source pad, so that qtdemux can use this information to correctly generate its source caps for DASH CENC encrypted streams. This allows qtdemux to support CENC encrypted DASH streams where the content protection specific information is carried in the MPD file rather than in pssh boxes in the initialisation segments. This commit adds a new function to the adaptivedemux base class to allow a GstEvent to be queued for a stream. The queue of events are sent the next time a buffer is pushed for that stream. https://bugzilla.gnome.org/show_bug.cgi?id=705991
2015-02-06 13:22:14 +00:00
if (active_stream->cur_adapt_set &&
active_stream->cur_adapt_set->RepresentationBase &&
active_stream->cur_adapt_set->RepresentationBase->ContentProtection) {
GST_DEBUG_OBJECT (demux, "Adding ContentProtection events to source pad");
dashdemux: Add binary search for stream_sidx_seek Add binary search to optimize in stream_sidx_seek. https://bugzilla.gnome.org/show_bug.cgi?id=749653
2015-07-29 13:31:30 +00:00
g_list_foreach (active_stream->cur_adapt_set->RepresentationBase->
ContentProtection, gst_dash_demux_send_content_protection_event,
stream);
dashdemux: add support for generating Protection events from ContentProtection elements If a ContentProtection element is present in an AdaptationSet element, send Protection events on the source pad, so that qtdemux can use this information to correctly generate its source caps for DASH CENC encrypted streams. This allows qtdemux to support CENC encrypted DASH streams where the content protection specific information is carried in the MPD file rather than in pssh boxes in the initialisation segments. This commit adds a new function to the adaptivedemux base class to allow a GstEvent to be queued for a stream. The queue of events are sent the next time a buffer is pushed for that stream. https://bugzilla.gnome.org/show_bug.cgi?id=705991
2015-02-06 13:22:14 +00:00
}
dashdemux: parse the sidx index from isobmff streams Allows dashdemux to identify the subsegments in the stream and switch bitrates when needed
2015-01-12 14:57:02 +00:00
gst_isoff_sidx_parser_init (&stream->sidx_parser);
adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-28 10:45:36 +00:00
if (gst_mpd_client_has_isoff_ondemand_profile (demux->client))
stream->sidx_adapter = gst_adapter_new ();
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
}
dashdemux: complete support for Media Presentations with several Periods - Periods are played in sequence, from PeriodStart to PeriodEnd - seamless switching from one Period to the next one works fine; - the 'new-segment' generation is broken, so if we need to switch pads for a new Period there is a crash;
2012-10-24 09:49:51 +00:00
return TRUE;
}
dashdemux: add support for generating Protection events from ContentProtection elements If a ContentProtection element is present in an AdaptationSet element, send Protection events on the source pad, so that qtdemux can use this information to correctly generate its source caps for DASH CENC encrypted streams. This allows qtdemux to support CENC encrypted DASH streams where the content protection specific information is carried in the MPD file rather than in pssh boxes in the initialisation segments. This commit adds a new function to the adaptivedemux base class to allow a GstEvent to be queued for a stream. The queue of events are sent the next time a buffer is pushed for that stream. https://bugzilla.gnome.org/show_bug.cgi?id=705991
2015-02-06 13:22:14 +00:00
static void
gst_dash_demux_send_content_protection_event (gpointer data, gpointer userdata)
{
GstDescriptorType *cp = (GstDescriptorType *) data;
GstDashDemuxStream *stream = (GstDashDemuxStream *) userdata;
GstEvent *event;
GstBuffer *pssi;
glong pssi_len;
gchar *schemeIdUri;
if (cp->schemeIdUri == NULL)
return;
GST_TRACE_OBJECT (stream, "check schemeIdUri %s", cp->schemeIdUri);
/* RFC 2141 states: The leading "urn:" sequence is case-insensitive */
schemeIdUri = g_ascii_strdown (cp->schemeIdUri, -1);
if (g_str_has_prefix (schemeIdUri, "urn:uuid:")) {
pssi_len = strlen (cp->value);
pssi = gst_buffer_new_wrapped (g_memdup (cp->value, pssi_len), pssi_len);
GST_LOG_OBJECT (stream, "Queuing Protection event on source pad");
/* RFC 4122 states that the hex part of a UUID is in lower case,
* but some streams seem to ignore this and use upper case for the
* protection system ID */
event = gst_event_new_protection (cp->schemeIdUri + 9, pssi, "dash/mpd");
gst_adaptive_demux_stream_queue_event ((GstAdaptiveDemuxStream *) stream,
event);
gst_buffer_unref (pssi);
}
g_free (schemeIdUri);
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static GstClockTime
gst_dash_demux_get_duration (GstAdaptiveDemux * ademux)
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemux *demux = GST_DASH_DEMUX_CAST (ademux);
dashdemux: new API to load the stream Period with a given index this avoids to fiddle with stream internals in the code
2012-12-17 14:00:52 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
g_return_val_if_fail (demux->client != NULL, GST_CLOCK_TIME_NONE);
dashdemux: Change first fragment selection for live streams When dashdemux selects its first fragment, it always selects the first fragment listed in the manifest. For on-demand content, this is the correct behaviour. However for live content, this behaviour is undesirable because the first fragment listed in the manifest might be some considerable time behind "now". The commit uses the host's idea of UTC and tries to find the oldest fragment that contains samples for this time of day. https://bugzilla.gnome.org/show_bug.cgi?id=701509
2013-06-11 13:28:53 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return gst_mpd_client_get_media_presentation_duration (demux->client);
}
dashdemux: complete support for manifest file updates
2012-12-17 14:19:33 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static gboolean
gst_dash_demux_is_live (GstAdaptiveDemux * ademux)
{
GstDashDemux *demux = GST_DASH_DEMUX_CAST (ademux);
dashdemux: Fix event leak when parsing manifest fails Always remember to unref the event before proceeding, in both success and failure cases
2013-07-03 22:11:11 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
g_return_val_if_fail (demux->client != NULL, FALSE);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return gst_mpd_client_is_live (demux->client);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
static gboolean
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_dash_demux_setup_streams (GstAdaptiveDemux * demux)
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
gboolean ret = TRUE;
dashdemux: Find the current period in a live stream Start from the correct period on a live stream https://bugzilla.gnome.org/show_bug.cgi?id=737421
2014-10-10 10:24:08 +00:00
GstDateTime *now = NULL;
guint period_idx;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
dashdemux: Find the current period in a live stream Start from the correct period on a live stream https://bugzilla.gnome.org/show_bug.cgi?id=737421
2014-10-10 10:24:08 +00:00
/* setup video, audio and subtitle streams, starting from first Period if
* non-live */
period_idx = 0;
if (gst_mpd_client_is_live (dashdemux->client)) {
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
GDateTime *g_now;
dashdemux: added check that availabilityStartTime is present for live streams https://bugzilla.gnome.org/show_bug.cgi?id=757602
2016-01-08 11:04:13 +00:00
if (dashdemux->client->mpd_node->availabilityStartTime == NULL) {
ret = FALSE;
GST_ERROR_OBJECT (demux, "MPD does not have availabilityStartTime");
goto done;
}
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
if (dashdemux->clock_drift == NULL) {
gchar **urls;
urls =
gst_mpd_client_get_utc_timing_sources (dashdemux->client,
SUPPORTED_CLOCK_FORMATS, NULL);
if (urls) {
GST_DEBUG_OBJECT (dashdemux, "Found a supported UTCTiming element");
adaptivedemux: use GstSystemClock to all real-time calculations A realtime clock is used in many places, such as deciding which fragment to select at start up and deciding how long to sleep before a fragment becomes available. For example dashdemux needs sample the client's estimate of UTC when selecting where to start in a live DASH stream. The problem with dashdemux calculating the client's idea of UTC is that it makes it difficult to create unit tests, because the passage of time is a factor in the test. This commit changes dashdemux and adaptivedemux to use the GstSystemClock, so that a unit test can replace the system clock when it needs to be able to control the clock. This commit makes no change to the behaviour under normal usage, as GstSystemClock is based upon the system time. https://bugzilla.gnome.org/show_bug.cgi?id=762147
2016-02-16 14:44:10 +00:00
dashdemux->clock_drift = gst_dash_demux_clock_drift_new (dashdemux);
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
gst_dash_demux_poll_clock_drift (dashdemux);
}
}
dashdemux: Find the current period in a live stream Start from the correct period on a live stream https://bugzilla.gnome.org/show_bug.cgi?id=737421
2014-10-10 10:24:08 +00:00
/* get period index for period encompassing the current time */
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
g_now = gst_dash_demux_get_server_now_utc (dashdemux);
now = gst_date_time_new_from_g_date_time (g_now);
dashdemux: Find the current period in a live stream Start from the correct period on a live stream https://bugzilla.gnome.org/show_bug.cgi?id=737421
2014-10-10 10:24:08 +00:00
if (dashdemux->client->mpd_node->suggestedPresentationDelay != -1) {
GstDateTime *target = gst_mpd_client_add_time_difference (now,
dashdemux->client->mpd_node->suggestedPresentationDelay * -1000);
gst_date_time_unref (now);
now = target;
dashdemux: provide a default suggestedPresentationDelay If MPD@suggestedPresentationDelay is not present in the manifest, dashdemux selects the fragment closest to the most recently generated fragment. This causes a playback issue because this choice does not allow the DASH client to build up any buffer of downloaded fragments without pausing playback. This is because by definition new fragments appear on the server in real-time (e.g. if segment duration is 4 seconds, a new fragment will appear on the server every 4 seconds). If the starting playback position was n*segmentDuration seconds behind "now", the DASH client could download up to 'n' fragments faster than realtime before it reached the point where it needed to wait for fragments to appear on the server. The MPD@suggestedPresentationDelay attribute allows a content publisher to provide a suggested starting position that is behind the current "live" position. If the MPD@suggestedPresentationDelay attribute is not present, provide a suitable default value as a property of the dashdemux element. To allow the default presentation delay to be specified either using fragments or seconds, the property is a string that contains a number and a unit (e.g. "10 seconds", "4 fragments", "2500ms").
2015-07-07 14:38:08 +00:00
} else if (dashdemux->default_presentation_delay) {
gint64 dfp =
gst_mpd_client_parse_default_presentation_delay (dashdemux->client,
dashdemux->default_presentation_delay);
dashdemux: fix default suggestedPresentationDelay When MPD@suggestedPresentationDelay is not present in the MPD, dashdemux can provide default suggestedPresentationDelay. However when applying default value of suggestedPresentationDelay, the value should be subtracted from current time, not added to it. When streams setup is performed and live point is calculated, we have to go to the wall clock (current time) minus suggestedPresentationDelay, if we tried to start with current time plus suggestedPresentationDelay, we would be asking for future stream, which has not yet been recorded. Also the value needs to be converted from ms to us. https://bugzilla.gnome.org/show_bug.cgi?id=764726
2016-04-01 16:42:32 +00:00
GstDateTime *target = gst_mpd_client_add_time_difference (now,
dfp * -1000);
dashdemux: provide a default suggestedPresentationDelay If MPD@suggestedPresentationDelay is not present in the manifest, dashdemux selects the fragment closest to the most recently generated fragment. This causes a playback issue because this choice does not allow the DASH client to build up any buffer of downloaded fragments without pausing playback. This is because by definition new fragments appear on the server in real-time (e.g. if segment duration is 4 seconds, a new fragment will appear on the server every 4 seconds). If the starting playback position was n*segmentDuration seconds behind "now", the DASH client could download up to 'n' fragments faster than realtime before it reached the point where it needed to wait for fragments to appear on the server. The MPD@suggestedPresentationDelay attribute allows a content publisher to provide a suggested starting position that is behind the current "live" position. If the MPD@suggestedPresentationDelay attribute is not present, provide a suitable default value as a property of the dashdemux element. To allow the default presentation delay to be specified either using fragments or seconds, the property is a string that contains a number and a unit (e.g. "10 seconds", "4 fragments", "2500ms").
2015-07-07 14:38:08 +00:00
gst_date_time_unref (now);
now = target;
dashdemux: Find the current period in a live stream Start from the correct period on a live stream https://bugzilla.gnome.org/show_bug.cgi?id=737421
2014-10-10 10:24:08 +00:00
}
period_idx =
gst_mpd_client_get_period_index_at_time (dashdemux->client, now);
if (period_idx == G_MAXUINT) {
#ifndef GST_DISABLE_GST_DEBUG
gchar *date_str = gst_date_time_to_iso8601_string (now);
GST_DEBUG_OBJECT (demux, "Unable to find live period active at %s",
date_str);
g_free (date_str);
#endif
ret = FALSE;
goto done;
}
}
if (!gst_mpd_client_set_period_index (dashdemux->client, period_idx) ||
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
!gst_dash_demux_setup_all_streams (dashdemux)) {
ret = FALSE;
goto done;
}
/* If stream is live, try to find the segment that
* is closest to current time */
if (gst_mpd_client_is_live (dashdemux->client)) {
dashdemux: reuse seeking function to reduce repeated code Instead of writing a seek routine, just use the mpdparser function. Also remove function that is not needed anymore
2015-05-08 19:49:02 +00:00
GDateTime *gnow;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GST_DEBUG_OBJECT (demux, "Seeking to current time of day for live stream ");
dashdemux: answer to latency queries Set live if stream is live and also add to the max latency the max internal buffering
2013-07-04 18:14:00 +00:00
dashdemux: reuse seeking function to reduce repeated code Instead of writing a seek routine, just use the mpdparser function. Also remove function that is not needed anymore
2015-05-08 19:49:02 +00:00
gnow = gst_date_time_to_g_date_time (now);
gst_mpd_client_seek_to_time (dashdemux->client, gnow);
g_date_time_unref (gnow);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
} else {
GST_DEBUG_OBJECT (demux, "Seeking to first segment for on-demand stream ");
dashdemux: answer to latency queries Set live if stream is live and also add to the max latency the max internal buffering
2013-07-04 18:14:00 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* start playing from the first segment */
dashdemux: refactor segment iteration for better performance Segments are now stored with their repeat counts instead of spanding them to multiple segments. This caused advancing to the next segment using a single index to have to iterate over the whole list every time. This commit addresses this by storing both the segment index as well as the repeat index and makes advancing to next segment just an increment of the repeat or the segment index.
2015-05-08 19:31:44 +00:00
gst_mpd_client_seek_to_first_segment (dashdemux->client);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
done:
dashdemux: Find the current period in a live stream Start from the correct period on a live stream https://bugzilla.gnome.org/show_bug.cgi?id=737421
2014-10-10 10:24:08 +00:00
if (now != NULL)
gst_date_time_unref (now);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
return ret;
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static gboolean
gst_dash_demux_process_manifest (GstAdaptiveDemux * demux, GstBuffer * buf)
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
gboolean ret = FALSE;
gchar *manifest;
GstMapInfo mapinfo;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (dashdemux->client)
gst_mpd_client_free (dashdemux->client);
dashdemux->client = gst_mpd_client_new ();
mpdparser: Store an URI downloader in the parser for downloading additional MPD resources if needed https://bugzilla.gnome.org/show_bug.cgi?id=752230
2015-08-21 09:06:07 +00:00
gst_mpd_client_set_uri_downloader (dashdemux->client, demux->downloader);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
dashdemux->client->mpd_uri = g_strdup (demux->manifest_uri);
dashdemux->client->mpd_base_uri = g_strdup (demux->manifest_base_uri);
dashdemux: Replace GQueue by GstDataQueue GstDataQueue has proper locking and provides functions to limit the size of the queue. Also has blocking calls that are useful to our multithread scenario in Dash.
2013-01-28 21:52:04 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GST_DEBUG_OBJECT (demux, "Fetched MPD file at URI: %s (base: %s)",
dashdemux->client->mpd_uri,
GST_STR_NULL (dashdemux->client->mpd_base_uri));
dashdemux: Replace GQueue by GstDataQueue GstDataQueue has proper locking and provides functions to limit the size of the queue. Also has blocking calls that are useful to our multithread scenario in Dash.
2013-01-28 21:52:04 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (gst_buffer_map (buf, &mapinfo, GST_MAP_READ)) {
manifest = (gchar *) mapinfo.data;
if (gst_mpd_parse (dashdemux->client, manifest, mapinfo.size)) {
dashdemux: Implement lazy-loading of external periods https://bugzilla.gnome.org/show_bug.cgi?id=752230
2015-09-22 14:17:38 +00:00
if (gst_mpd_client_setup_media_presentation (dashdemux->client, 0, 0,
NULL)) {
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
ret = TRUE;
} else {
GST_ELEMENT_ERROR (demux, STREAM, DECODE,
("Incompatible manifest file."), (NULL));
}
}
gst_buffer_unmap (buf, &mapinfo);
} else {
GST_WARNING_OBJECT (demux, "Failed to map manifest buffer");
dashdemux: Replace GQueue by GstDataQueue GstDataQueue has proper locking and provides functions to limit the size of the queue. Also has blocking calls that are useful to our multithread scenario in Dash.
2013-01-28 21:52:04 +00:00
}
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (ret)
ret = gst_dash_demux_setup_streams (demux);
return ret;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
dashdemux: keep a list of streams periods Keep a list of streams per period so that the download loop can keep downloading while the stream loop is still pushing old period's data.
2013-02-13 04:13:23 +00:00
static GstPad *
dashdemux: use audio_%02u and video_%02u names for pads Instead of using the default ghostpad%u naming. The audio_/video_ names are more common in demuxers
2015-01-26 20:51:22 +00:00
gst_dash_demux_create_pad (GstDashDemux * demux, GstActiveStream * stream)
dashdemux: keep a list of streams periods Keep a list of streams per period so that the download loop can keep downloading while the stream loop is still pushing old period's data.
2013-02-13 04:13:23 +00:00
{
GstPad *pad;
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
GstPadTemplate *tmpl;
dashdemux: use audio_%02u and video_%02u names for pads Instead of using the default ghostpad%u naming. The audio_/video_ names are more common in demuxers
2015-01-26 20:51:22 +00:00
gchar *name;
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
dashdemux: use audio_%02u and video_%02u names for pads Instead of using the default ghostpad%u naming. The audio_/video_ names are more common in demuxers
2015-01-26 20:51:22 +00:00
switch (stream->mimeType) {
case GST_STREAM_AUDIO:
name = g_strdup_printf ("audio_%02u", demux->n_audio_streams++);
tmpl = gst_static_pad_template_get (&gst_dash_demux_audiosrc_template);
break;
case GST_STREAM_VIDEO:
name = g_strdup_printf ("video_%02u", demux->n_video_streams++);
tmpl = gst_static_pad_template_get (&gst_dash_demux_videosrc_template);
break;
dashdemux: create src pads for subtitle streams. Create src pads for Representations that contain timed-text subtitles, both when the subtitles are encapsulated in ISO BMFF (i.e., the Representation has mimeType "application/mp4") and when they are unencapsulated (i.e., the Representation has mimeType "application/ttml+xml"). https://bugzilla.gnome.org/show_bug.cgi?id=747774
2015-08-18 13:16:11 +00:00
case GST_STREAM_APPLICATION:
if (gst_mpd_client_active_stream_contains_subtitles (stream)) {
name = g_strdup_printf ("subtitle_%02u", demux->n_subtitle_streams++);
tmpl =
gst_static_pad_template_get (&gst_dash_demux_subtitlesrc_template);
} else {
return NULL;
}
break;
dashdemux: use audio_%02u and video_%02u names for pads Instead of using the default ghostpad%u naming. The audio_/video_ names are more common in demuxers
2015-01-26 20:51:22 +00:00
default:
g_assert_not_reached ();
return NULL;
}
dashdemux: keep a list of streams periods Keep a list of streams per period so that the download loop can keep downloading while the stream loop is still pushing old period's data.
2013-02-13 04:13:23 +00:00
/* Create and activate new pads */
adaptivedemux: replace ghostpad with a standard pad Handling the ghostpad and its internal pad was causing more issues than helping because of their coupled activation/deactivation actions. As we have to install custom chain,event and query functions it is better to use a floating sink pad internally in the demuxer and just use those pad functions to push through a standard pad in the demuxer https://bugzilla.gnome.org/show_bug.cgi?id=757951
2016-01-13 12:51:20 +00:00
pad = gst_pad_new_from_template (tmpl, name);
dashdemux: use audio_%02u and video_%02u names for pads Instead of using the default ghostpad%u naming. The audio_/video_ names are more common in demuxers
2015-01-26 20:51:22 +00:00
g_free (name);
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
gst_object_unref (tmpl);
dashdemux: keep a list of streams periods Keep a list of streams per period so that the download loop can keep downloading while the stream loop is still pushing old period's data.
2013-02-13 04:13:23 +00:00
gst_pad_set_active (pad, TRUE);
GST_INFO_OBJECT (demux, "Creating srcpad %s:%s", GST_DEBUG_PAD_NAME (pad));
return pad;
}
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
static void
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_dash_demux_reset (GstAdaptiveDemux * ademux)
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemux *demux = GST_DASH_DEMUX_CAST (ademux);
dashdemux: re-enable and fix adaptive switching It is still unstable, but at least it works when the switches aren't happening after every fragment
2013-01-30 20:27:47 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GST_DEBUG_OBJECT (demux, "Resetting demux");
dashdemux: re-enable and fix adaptive switching It is still unstable, but at least it works when the switches aren't happening after every fragment
2013-01-30 20:27:47 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
demux->end_of_period = FALSE;
demux->end_of_manifest = FALSE;
dashdemux: remove stream loop thread Download and push from the same task, makes code a lot simpler to maintain. Also pushing from separate threads avoids deadlocking when gst_pad_push blocks due to downstream queues being full.
2013-12-20 13:05:22 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (demux->client) {
gst_mpd_client_free (demux->client);
demux->client = NULL;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
gst_dash_demux_clock_drift_free (demux->clock_drift);
demux->clock_drift = NULL;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
demux->client = gst_mpd_client_new ();
mpdparser: Store an URI downloader in the parser for downloading additional MPD resources if needed https://bugzilla.gnome.org/show_bug.cgi?id=752230
2015-08-21 09:06:07 +00:00
gst_mpd_client_set_uri_downloader (demux->client, ademux->downloader);
dashdemux: use audio_%02u and video_%02u names for pads Instead of using the default ghostpad%u naming. The audio_/video_ names are more common in demuxers
2015-01-26 20:51:22 +00:00
demux->n_audio_streams = 0;
demux->n_video_streams = 0;
dashdemux: Reset number of subtitle streams counter on reset() too Otherwise we will continue increasing forever the number of subtitle streams when reusing the element for another DASH manifest.
2016-07-28 08:16:24 +00:00
demux->n_subtitle_streams = 0;
dashdemux: Skip audio streams if TRICKMODE_NO_AUDIO is given in the seek event We just don't expose pads for audio streams, or even download them.
2016-07-28 08:27:29 +00:00
demux->trickmode_no_audio = FALSE;
dashdemux: Remember if for a stream we could do key-units only mode This makes sure we don't even try going into that mode if we previously saw that the stream does not have the suitable metadata. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:32:50 +00:00
demux->allow_trickmode_key_units = TRUE;
dashdemux: keep a list of streams periods Keep a list of streams per period so that the download loop can keep downloading while the stream loop is still pushing old period's data.
2013-02-13 04:13:23 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static GstCaps *
gst_dash_demux_get_video_input_caps (GstDashDemux * demux,
GstActiveStream * stream)
dashdemux: keep a list of streams periods Keep a list of streams per period so that the download loop can keep downloading while the stream loop is still pushing old period's data.
2013-02-13 04:13:23 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
guint width = 0, height = 0;
dashdemux: Suggestion for setting the framerate information. Dashdemux has set the width and height information from MPD manifest. Some embedded devices which are not insufficient H/W resources need more information such as framerate to assign H/W resources. So I suggested that dashdemux also needs to set the framerate information from MDP manifest. https://bugzilla.gnome.org/show_bug.cgi?id=758515
2015-12-08 00:33:39 +00:00
gint fps_num = 0, fps_den = 1;
gboolean have_fps = FALSE;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstCaps *caps = NULL;
dashdemux: keep a list of streams periods Keep a list of streams per period so that the download loop can keep downloading while the stream loop is still pushing old period's data.
2013-02-13 04:13:23 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (stream == NULL)
return NULL;
dashdemux: Fix another wrong assertion Also adds a couple log messages for easier debugging
2013-04-11 12:12:26 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* if bitstreamSwitching is true we dont need to swich pads on resolution change */
if (!gst_mpd_client_get_bitstream_switching_flag (stream)) {
width = gst_mpd_client_get_video_stream_width (stream);
height = gst_mpd_client_get_video_stream_height (stream);
dashdemux: Suggestion for setting the framerate information. Dashdemux has set the width and height information from MPD manifest. Some embedded devices which are not insufficient H/W resources need more information such as framerate to assign H/W resources. So I suggested that dashdemux also needs to set the framerate information from MDP manifest. https://bugzilla.gnome.org/show_bug.cgi?id=758515
2015-12-08 00:33:39 +00:00
have_fps =
gst_mpd_client_get_video_stream_framerate (stream, &fps_num, &fps_den);
dashdemux: keep a list of streams periods Keep a list of streams per period so that the download loop can keep downloading while the stream loop is still pushing old period's data.
2013-02-13 04:13:23 +00:00
}
dashdemux: create src pads for subtitle streams. Create src pads for Representations that contain timed-text subtitles, both when the subtitles are encapsulated in ISO BMFF (i.e., the Representation has mimeType "application/mp4") and when they are unencapsulated (i.e., the Representation has mimeType "application/ttml+xml"). https://bugzilla.gnome.org/show_bug.cgi?id=747774
2015-08-18 13:16:11 +00:00
caps = gst_mpd_client_get_stream_caps (stream);
if (caps == NULL)
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return NULL;
dashdemux: keep a list of streams periods Keep a list of streams per period so that the download loop can keep downloading while the stream loop is still pushing old period's data.
2013-02-13 04:13:23 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (width > 0 && height > 0) {
gst_caps_set_simple (caps, "width", G_TYPE_INT, width, "height",
G_TYPE_INT, height, NULL);
dashdemux: add combine flows function Use a flow combination function to decide the result from the stream_loop
2013-12-05 05:53:18 +00:00
}
dashdemux: Suggestion for setting the framerate information. Dashdemux has set the width and height information from MPD manifest. Some embedded devices which are not insufficient H/W resources need more information such as framerate to assign H/W resources. So I suggested that dashdemux also needs to set the framerate information from MDP manifest. https://bugzilla.gnome.org/show_bug.cgi?id=758515
2015-12-08 00:33:39 +00:00
if (have_fps) {
gst_caps_set_simple (caps, "framerate", GST_TYPE_FRACTION, fps_num,
fps_den, NULL);
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return caps;
dashdemux: remove stream loop thread Download and push from the same task, makes code a lot simpler to maintain. Also pushing from separate threads avoids deadlocking when gst_pad_push blocks due to downstream queues being full.
2013-12-20 13:05:22 +00:00
}
dashdemux: add combine flows function Use a flow combination function to decide the result from the stream_loop
2013-12-05 05:53:18 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static GstCaps *
gst_dash_demux_get_audio_input_caps (GstDashDemux * demux,
GstActiveStream * stream)
dashdemux: move the buffers queues to the streams Store the buffers separately for each stream, this is clearer than having a queue with a list of buffers. It also allows easier selection of buffers to push in later refactors
2013-01-28 15:28:29 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
guint rate = 0, channels = 0;
GstCaps *caps = NULL;
dashdemux: move the buffers queues to the streams Store the buffers separately for each stream, this is clearer than having a queue with a list of buffers. It also allows easier selection of buffers to push in later refactors
2013-01-28 15:28:29 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (stream == NULL)
return NULL;
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* if bitstreamSwitching is true we dont need to swich pads on rate/channels change */
if (!gst_mpd_client_get_bitstream_switching_flag (stream)) {
channels = gst_mpd_client_get_audio_stream_num_channels (stream);
rate = gst_mpd_client_get_audio_stream_rate (stream);
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
}
dashdemux: create src pads for subtitle streams. Create src pads for Representations that contain timed-text subtitles, both when the subtitles are encapsulated in ISO BMFF (i.e., the Representation has mimeType "application/mp4") and when they are unencapsulated (i.e., the Representation has mimeType "application/ttml+xml"). https://bugzilla.gnome.org/show_bug.cgi?id=747774
2015-08-18 13:16:11 +00:00
caps = gst_mpd_client_get_stream_caps (stream);
if (caps == NULL)
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return NULL;
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (rate > 0) {
gst_caps_set_simple (caps, "rate", G_TYPE_INT, rate, NULL);
}
if (channels > 0) {
gst_caps_set_simple (caps, "channels", G_TYPE_INT, channels, NULL);
}
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return caps;
dashdemux: move the buffers queues to the streams Store the buffers separately for each stream, this is clearer than having a queue with a list of buffers. It also allows easier selection of buffers to push in later refactors
2013-01-28 15:28:29 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static GstCaps *
gst_dash_demux_get_application_input_caps (GstDashDemux * demux,
GstActiveStream * stream)
{
GstCaps *caps = NULL;
dashdemux: plug some leaks Add some missing free/unrefs spotted by valgrind
2013-02-18 17:02:48 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (stream == NULL)
return NULL;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
dashdemux: create src pads for subtitle streams. Create src pads for Representations that contain timed-text subtitles, both when the subtitles are encapsulated in ISO BMFF (i.e., the Representation has mimeType "application/mp4") and when they are unencapsulated (i.e., the Representation has mimeType "application/ttml+xml"). https://bugzilla.gnome.org/show_bug.cgi?id=747774
2015-08-18 13:16:11 +00:00
caps = gst_mpd_client_get_stream_caps (stream);
if (caps == NULL)
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return NULL;
dashdemux: plug some leaks Add some missing free/unrefs spotted by valgrind
2013-02-18 17:02:48 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return caps;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static GstCaps *
gst_dash_demux_get_input_caps (GstDashDemux * demux, GstActiveStream * stream)
dashdemux: minor refactor Split one very large function into 2 smaller but still large functions. Also change the if conditions to positive checks to improve readability.
2013-07-09 03:47:07 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
switch (stream->mimeType) {
case GST_STREAM_VIDEO:
return gst_dash_demux_get_video_input_caps (demux, stream);
case GST_STREAM_AUDIO:
return gst_dash_demux_get_audio_input_caps (demux, stream);
case GST_STREAM_APPLICATION:
return gst_dash_demux_get_application_input_caps (demux, stream);
default:
return GST_CAPS_NONE;
dashdemux: minor refactor Split one very large function into 2 smaller but still large functions. Also change the if conditions to positive checks to improve readability.
2013-07-09 03:47:07 +00:00
}
}
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
static void
gst_dash_demux_stream_update_headers_info (GstAdaptiveDemuxStream * stream)
{
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (stream->demux);
gchar *path = NULL;
gst_mpd_client_get_next_header (dashdemux->client,
&path, dashstream->index,
&stream->fragment.header_range_start, &stream->fragment.header_range_end);
dashdemux: Properly handle relative and non-HTTP URIs for the headers/indices gst_uri_join_strings() will return the second parameter if it is an absolute URI. No need to do a (wrong) check if the URI is absolute or not beforehand. https://bugzilla.gnome.org/show_bug.cgi?id=755134
2015-09-16 21:38:24 +00:00
if (path != NULL) {
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
stream->fragment.header_uri =
gst_uri_join_strings (gst_mpdparser_get_baseURL (dashdemux->client,
dashstream->index), path);
g_free (path);
dashdemux: Properly handle relative and non-HTTP URIs for the headers/indices gst_uri_join_strings() will return the second parameter if it is an absolute URI. No need to do a (wrong) check if the URI is absolute or not beforehand. https://bugzilla.gnome.org/show_bug.cgi?id=755134
2015-09-16 21:38:24 +00:00
path = NULL;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
}
gst_mpd_client_get_next_header_index (dashdemux->client,
&path, dashstream->index,
&stream->fragment.index_range_start, &stream->fragment.index_range_end);
dashdemux: Properly handle relative and non-HTTP URIs for the headers/indices gst_uri_join_strings() will return the second parameter if it is an absolute URI. No need to do a (wrong) check if the URI is absolute or not beforehand. https://bugzilla.gnome.org/show_bug.cgi?id=755134
2015-09-16 21:38:24 +00:00
if (path != NULL) {
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
stream->fragment.index_uri =
gst_uri_join_strings (gst_mpdparser_get_baseURL (dashdemux->client,
dashstream->index), path);
g_free (path);
}
}
dashdemux: remove stream loop thread Download and push from the same task, makes code a lot simpler to maintain. Also pushing from separate threads avoids deadlocking when gst_pad_push blocks due to downstream queues being full.
2013-12-20 13:05:22 +00:00
static GstFlowReturn
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_dash_demux_stream_update_fragment_info (GstAdaptiveDemuxStream * stream)
dashdemux: remove stream loop thread Download and push from the same task, makes code a lot simpler to maintain. Also pushing from separate threads avoids deadlocking when gst_pad_push blocks due to downstream queues being full.
2013-12-20 13:05:22 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (stream->demux);
GstClockTime ts;
GstMediaFragmentInfo fragment;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
gboolean isombff;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_adaptive_demux_stream_fragment_clear (&stream->fragment);
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
isombff = gst_mpd_client_has_isoff_ondemand_profile (dashdemux->client);
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
/* Reset chunk size if any */
stream->fragment.chunk_size = 0;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
if (GST_ADAPTIVE_DEMUX_STREAM_NEED_HEADER (stream) && isombff) {
gst_dash_demux_stream_update_headers_info (stream);
dashstream->sidx_base_offset = stream->fragment.index_range_end + 1;
dashdemux: Ensure sidx parsing when updating fragment info Fix seek fail with On-Demand profile mpd which has no indexRange attribute https://bugzilla.gnome.org/show_bug.cgi?id=776431
2016-12-23 06:31:34 +00:00
/* sidx entries may not be available in here */
if (dashstream->sidx_index != 0 && SIDX (dashstream)->entries) {
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
/* request only the index to be downloaded as we need to reposition the
* stream to a subsegment */
return GST_FLOW_OK;
}
}
dashdemux: Only do keyframe-only playback if the corresponding seek flag is given https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-31 12:12:49 +00:00
if (dashstream->moof_sync_samples
&& GST_ADAPTIVE_DEMUX (dashdemux)->
segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS) {
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
GstDashStreamSyncSample *sync_sample =
&g_array_index (dashstream->moof_sync_samples, GstDashStreamSyncSample,
dashstream->current_sync_sample);
gst_mpd_client_get_next_fragment (dashdemux->client, dashstream->index,
&fragment);
stream->fragment.uri = fragment.uri;
stream->fragment.timestamp = GST_CLOCK_TIME_NONE;
stream->fragment.duration = GST_CLOCK_TIME_NONE;
stream->fragment.range_start = sync_sample->start_offset;
stream->fragment.range_end = sync_sample->end_offset;
return GST_FLOW_OK;
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (gst_mpd_client_get_next_fragment_timestamp (dashdemux->client,
dashstream->index, &ts)) {
dashdemux: Fix issue when manifest update sets slow start without passing necessary header & caps changes downstream https://bugzilla.gnome.org/show_bug.cgi?id=777206
2017-01-17 02:33:03 +00:00
if (gst_mpd_client_is_live (dashdemux->client)) {
if (!GST_ADAPTIVE_DEMUX_STREAM_NEED_HEADER (stream)) {
if (dashstream->active_stream
&& dashstream->active_stream->cur_representation) {
/* id specifies an identifier for this Representation. The
* identifier shall be unique within a Period unless the
* Representation is functionally identically to another
* Representation in the same Period. */
if (!g_strcmp0 (dashstream->active_stream->cur_representation->id,
dashstream->last_representation_id)) {
GstCaps *caps;
stream->need_header = TRUE;
GST_INFO_OBJECT (dashdemux, "Switching bitrate to %d",
dashstream->active_stream->cur_representation->bandwidth);
caps =
gst_dash_demux_get_input_caps (dashdemux,
dashstream->active_stream);
gst_adaptive_demux_stream_set_caps (stream, caps);
}
}
}
g_free (dashstream->last_representation_id);
dashdemux: Fix potential NULL pointer dereference CID 1399700
2017-02-28 13:53:10 +00:00
if (dashstream->active_stream
&& dashstream->active_stream->cur_representation) {
dashstream->last_representation_id =
g_strdup (dashstream->active_stream->cur_representation->id);
} else {
dashstream->last_representation_id = NULL;
}
dashdemux: Fix issue when manifest update sets slow start without passing necessary header & caps changes downstream https://bugzilla.gnome.org/show_bug.cgi?id=777206
2017-01-17 02:33:03 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (GST_ADAPTIVE_DEMUX_STREAM_NEED_HEADER (stream)) {
dashdemux: Fix leak in gst_dash_demux_stream_update_fragment_info() The gst_dash_demux_stream_update_fragment_info function could call gst_dash_demux_stream_update_headers_info function twice. The gst_dash_demux_stream_update_headers_info function will set header_uri and index_uri to some newly allocated strings. The values set by the first call of gst_dash_demux_stream_update_headers_info will leak when the function is called for a second time. The solution is to call gst_adaptive_demux_stream_fragment_clear before the second call of gst_dash_demux_stream_update_headers_info https://bugzilla.gnome.org/show_bug.cgi?id=753188
2015-08-03 15:57:31 +00:00
gst_adaptive_demux_stream_fragment_clear (&stream->fragment);
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
gst_dash_demux_stream_update_headers_info (stream);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
}
dashdemux: Use 1 download task per stream Instead of having a single download task for all streams, this commit makes each stream have its own download loop, allowing parallel download of fragments.
2013-12-03 19:16:09 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_mpd_client_get_next_fragment (dashdemux->client, dashstream->index,
&fragment);
Fixed state machine (again)
2012-10-17 08:02:39 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
stream->fragment.uri = fragment.uri;
dashdemux: Always parsing sidx for On-Demand profile The indexRange attribute is optional and if it's not present, we should extract the sidx box from incoming buffers. https://bugzilla.gnome.org/show_bug.cgi?id=776200
2016-12-20 02:16:11 +00:00
/* If mpd does not specify indexRange (i.e., null index_uri),
* sidx entries may not be available until download it */
if (isombff && dashstream->sidx_index != 0 && SIDX (dashstream)->entries) {
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
GstSidxBoxEntry *entry = SIDX_CURRENT_ENTRY (dashstream);
stream->fragment.range_start =
dashstream->sidx_base_offset + entry->offset;
stream->fragment.timestamp = entry->pts;
stream->fragment.duration = entry->duration;
if (stream->demux->segment.rate < 0.0) {
stream->fragment.range_end =
stream->fragment.range_start + entry->size - 1;
} else {
stream->fragment.range_end = fragment.range_end;
}
} else {
stream->fragment.timestamp = fragment.timestamp;
stream->fragment.duration = fragment.duration;
stream->fragment.range_start =
MAX (fragment.range_start, dashstream->sidx_base_offset);
stream->fragment.range_end = fragment.range_end;
}
dashdemux: remove stream loop thread Download and push from the same task, makes code a lot simpler to maintain. Also pushing from separate threads avoids deadlocking when gst_pad_push blocks due to downstream queues being full.
2013-12-20 13:05:22 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return GST_FLOW_OK;
dashdemux: remove stream loop thread Download and push from the same task, makes code a lot simpler to maintain. Also pushing from separate threads avoids deadlocking when gst_pad_push blocks due to downstream queues being full.
2013-12-20 13:05:22 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return GST_FLOW_EOS;
}
Fixed state machine (again)
2012-10-17 08:02:39 +00:00
dashdemux: Add binary search for stream_sidx_seek Add binary search to optimize in stream_sidx_seek. https://bugzilla.gnome.org/show_bug.cgi?id=749653
2015-07-29 13:31:30 +00:00
static gint
gst_dash_demux_index_entry_search (GstSidxBoxEntry * entry, GstClockTime * ts,
gpointer user_data)
{
GstClockTime entry_ts = entry->pts + entry->duration;
if (entry_ts < *ts)
return -1;
else if (entry->pts > *ts)
return 1;
else
return 0;
}
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
static void
gst_dash_demux_stream_sidx_seek (GstDashDemuxStream * dashstream,
dashdemux: implement snap seek handling Handle snap seeking at the stream_seek method and let superclass do the rest to support snap seeking https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-02-01 13:49:23 +00:00
gboolean forward, GstSeekFlags flags, GstClockTime ts,
GstClockTime * final_ts)
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
{
GstSidxBox *sidx = SIDX (dashstream);
dashdemux: Add binary search for stream_sidx_seek Add binary search to optimize in stream_sidx_seek. https://bugzilla.gnome.org/show_bug.cgi?id=749653
2015-07-29 13:31:30 +00:00
GstSidxBoxEntry *entry;
gint idx = sidx->entries_count;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
dashdemux: Add binary search for stream_sidx_seek Add binary search to optimize in stream_sidx_seek. https://bugzilla.gnome.org/show_bug.cgi?id=749653
2015-07-29 13:31:30 +00:00
/* check whether ts is already past the last element or not */
dashdemux: Implement SIDX tracking based on buffer offset This simplifies the code but also removes a bug with tracking of the remaining size for the initial subfragment: we were not considering the size between the index and the start of the first moof here. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-05-27 13:08:09 +00:00
if (sidx->entries[idx - 1].pts + sidx->entries[idx - 1].duration >= ts) {
dashdemux: implement snap seek handling Handle snap seeking at the stream_seek method and let superclass do the rest to support snap seeking https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-02-01 13:49:23 +00:00
GstSearchMode mode = GST_SEARCH_MODE_BEFORE;
if ((flags & GST_SEEK_FLAG_SNAP_NEAREST) == GST_SEEK_FLAG_SNAP_NEAREST) {
mode = GST_SEARCH_MODE_BEFORE;
} else if ((forward && (flags & GST_SEEK_FLAG_SNAP_AFTER)) ||
(!forward && (flags & GST_SEEK_FLAG_SNAP_BEFORE))) {
mode = GST_SEARCH_MODE_AFTER;
} else {
mode = GST_SEARCH_MODE_BEFORE;
}
dashdemux: Add binary search for stream_sidx_seek Add binary search to optimize in stream_sidx_seek. https://bugzilla.gnome.org/show_bug.cgi?id=749653
2015-07-29 13:31:30 +00:00
entry =
gst_util_array_binary_search (sidx->entries, sidx->entries_count,
sizeof (GstSidxBoxEntry),
dashdemux: implement snap seek handling Handle snap seeking at the stream_seek method and let superclass do the rest to support snap seeking https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-02-01 13:49:23 +00:00
(GCompareDataFunc) gst_dash_demux_index_entry_search, mode, &ts, NULL);
dashdemux: Add binary search for stream_sidx_seek Add binary search to optimize in stream_sidx_seek. https://bugzilla.gnome.org/show_bug.cgi?id=749653
2015-07-29 13:31:30 +00:00
dashdemux: Exception handle in _sidx_seek() If target seek position is outside of the range of sidx entries, binary search returns NULL pointer. https://bugzilla.gnome.org/show_bug.cgi?id=776200
2017-03-14 10:41:56 +00:00
if (entry) {
idx = entry - sidx->entries;
} else if (mode == GST_SEARCH_MODE_BEFORE) {
/* target ts is smaller than pts of the first entry */
idx = 0;
} else {
/* target ts is larger than pts + duration of the last entry
* idx = sidx->entries_count */
}
dashdemux: implement snap seek handling Handle snap seeking at the stream_seek method and let superclass do the rest to support snap seeking https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-02-01 13:49:23 +00:00
/* FIXME in reverse mode, if we are exactly at a fragment start it makes more
* sense to start from the end of the previous fragment */
/* FIXME we should have a GST_SEARCH_MODE_NEAREST */
if ((flags & GST_SEEK_FLAG_SNAP_NEAREST) == GST_SEEK_FLAG_SNAP_NEAREST &&
idx + 1 < sidx->entries_count) {
if (ABS (sidx->entries[idx + 1].pts - ts) <
ABS (sidx->entries[idx].pts - ts))
idx += 1;
}
dashdemux: Add binary search for stream_sidx_seek Add binary search to optimize in stream_sidx_seek. https://bugzilla.gnome.org/show_bug.cgi?id=749653
2015-07-29 13:31:30 +00:00
}
sidx->entry_index = idx;
dashstream->sidx_index = idx;
adaptivedemux: handle snap seeks Adaptive demuxers need to start downloading from specific positions (fragments) for every stream, this means that all streams can snap-seek to a different position when requested. Snap seeking in this case will be done in 2 steps: 1) do the snap seeking on the pad that received the seek event and get the final position 2) use this position to do a regular seek on the other streams to make sure they all start from the same position More arguments were added to the stream_seek function, allowing better control of how seeking is done. Knowing the flags and the playback direction allows subclasses to handle snap-seeking. And also adds a new return parameter to inform of the final selected seeking position that is used to align the other streams. https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-01-27 16:31:10 +00:00
if (final_ts) {
if (idx == sidx->entries_count)
*final_ts = sidx->entries[idx].pts + sidx->entries[idx].duration;
else
*final_ts = sidx->entries[idx].pts;
}
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static GstFlowReturn
adaptivedemux: handle snap seeks Adaptive demuxers need to start downloading from specific positions (fragments) for every stream, this means that all streams can snap-seek to a different position when requested. Snap seeking in this case will be done in 2 steps: 1) do the snap seeking on the pad that received the seek event and get the final position 2) use this position to do a regular seek on the other streams to make sure they all start from the same position More arguments were added to the stream_seek function, allowing better control of how seeking is done. Knowing the flags and the playback direction allows subclasses to handle snap-seeking. And also adds a new return parameter to inform of the final selected seeking position that is used to align the other streams. https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-01-27 16:31:10 +00:00
gst_dash_demux_stream_seek (GstAdaptiveDemuxStream * stream, gboolean forward,
GstSeekFlags flags, GstClockTime ts, GstClockTime * final_ts)
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
{
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (stream->demux);
Fixed state machine (again)
2012-10-17 08:02:39 +00:00
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
if (dashstream->moof)
gst_isoff_moof_box_free (dashstream->moof);
dashstream->moof = NULL;
if (dashstream->moof_sync_samples)
g_array_free (dashstream->moof_sync_samples, TRUE);
dashstream->moof_sync_samples = NULL;
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
dashstream->current_sync_sample = -1;
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
if (gst_mpd_client_has_isoff_ondemand_profile (dashdemux->client)) {
if (dashstream->sidx_parser.status == GST_ISOFF_SIDX_PARSER_FINISHED) {
dashdemux: implement snap seek handling Handle snap seeking at the stream_seek method and let superclass do the rest to support snap seeking https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-02-01 13:49:23 +00:00
gst_dash_demux_stream_sidx_seek (dashstream, forward, flags, ts,
final_ts);
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
} else {
/* no index yet, seek when we have it */
adaptivedemux: handle snap seeks Adaptive demuxers need to start downloading from specific positions (fragments) for every stream, this means that all streams can snap-seek to a different position when requested. Snap seeking in this case will be done in 2 steps: 1) do the snap seeking on the pad that received the seek event and get the final position 2) use this position to do a regular seek on the other streams to make sure they all start from the same position More arguments were added to the stream_seek function, allowing better control of how seeking is done. Knowing the flags and the playback direction allows subclasses to handle snap-seeking. And also adds a new return parameter to inform of the final selected seeking position that is used to align the other streams. https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-01-27 16:31:10 +00:00
/* FIXME - the final_ts won't be correct here */
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
dashstream->pending_seek_ts = ts;
}
Revert "Revert "dashdemux: When doing SIDX seeking, return instead of overriding the timestamp with 0 from the MPD seeking method"" This reverts commit aea2c13fc1672a7260679d706d0a084a34ba7531.
2016-08-11 10:11:22 +00:00
return GST_FLOW_OK;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
}
adaptivedemux: handle snap seeks Adaptive demuxers need to start downloading from specific positions (fragments) for every stream, this means that all streams can snap-seek to a different position when requested. Snap seeking in this case will be done in 2 steps: 1) do the snap seeking on the pad that received the seek event and get the final position 2) use this position to do a regular seek on the other streams to make sure they all start from the same position More arguments were added to the stream_seek function, allowing better control of how seeking is done. Knowing the flags and the playback direction allows subclasses to handle snap-seeking. And also adds a new return parameter to inform of the final selected seeking position that is used to align the other streams. https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-01-27 16:31:10 +00:00
gst_mpd_client_stream_seek (dashdemux->client, dashstream->active_stream,
forward, flags, ts, final_ts);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return GST_FLOW_OK;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
static gboolean
gst_dash_demux_stream_has_next_sync_sample (GstAdaptiveDemuxStream * stream)
{
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
dashdemux: Only do keyframe-only playback if the corresponding seek flag is given https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-31 12:12:49 +00:00
if (dashstream->moof_sync_samples
&& GST_ADAPTIVE_DEMUX (stream->demux)->
segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS) {
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
if (stream->demux->segment.rate > 0.0) {
if (dashstream->current_sync_sample + 1 <
dashstream->moof_sync_samples->len)
return TRUE;
} else {
if (dashstream->current_sync_sample >= 1)
return TRUE;
}
}
return FALSE;
}
dashdemux: also check for subfragments on has_next_fragment In dash isombff profile the fragment is split into subframents where bitrate switching is possible. Also take that into consideration when checking if a stream has next fragments.
2015-09-14 16:56:10 +00:00
static gboolean
gst_dash_demux_stream_has_next_subfragment (GstAdaptiveDemuxStream * stream)
{
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
GstSidxBox *sidx = SIDX (dashstream);
if (dashstream->sidx_parser.status == GST_ISOFF_SIDX_PARSER_FINISHED) {
if (stream->demux->segment.rate > 0.0) {
if (sidx->entry_index + 1 < sidx->entries_count)
return TRUE;
} else {
if (sidx->entry_index >= 1)
return TRUE;
}
}
return FALSE;
}
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
static gboolean
gst_dash_demux_stream_advance_sync_sample (GstAdaptiveDemuxStream * stream)
{
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
gboolean fragment_finished = FALSE;
dashdemux: Only do keyframe-only playback if the corresponding seek flag is given https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-31 12:12:49 +00:00
if (dashstream->moof_sync_samples
&& GST_ADAPTIVE_DEMUX (stream->demux)->
segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS) {
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
if (stream->demux->segment.rate > 0.0) {
dashstream->current_sync_sample++;
if (dashstream->current_sync_sample >= dashstream->moof_sync_samples->len) {
fragment_finished = TRUE;
}
} else {
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
if (dashstream->current_sync_sample == -1) {
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
dashstream->current_sync_sample =
dashstream->moof_sync_samples->len - 1;
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
} else if (dashstream->current_sync_sample == 0) {
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
dashstream->current_sync_sample = -1;
fragment_finished = TRUE;
dashdemux: In KEY_UNITS trick mode, download all I-frames and not only IDR
2016-08-18 10:21:54 +00:00
} else {
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
dashstream->current_sync_sample--;
dashdemux: In KEY_UNITS trick mode, download all I-frames and not only IDR
2016-08-18 10:21:54 +00:00
}
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
}
}
GST_DEBUG_OBJECT (stream->pad,
"Advancing sync sample #%d fragment_finished:%d",
dashstream->current_sync_sample, fragment_finished);
if (!fragment_finished)
stream->discont = TRUE;
return !fragment_finished;
}
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
static gboolean
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
gst_dash_demux_stream_advance_subfragment (GstAdaptiveDemuxStream * stream)
{
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
GstSidxBox *sidx = SIDX (dashstream);
gboolean fragment_finished = TRUE;
dashdemux: protect against malformed isombff format Be more careful around malformed mpds that announce using isombff profile but actually are regular mpds
2015-02-16 02:16:52 +00:00
if (dashstream->sidx_parser.status == GST_ISOFF_SIDX_PARSER_FINISHED) {
if (stream->demux->segment.rate > 0.0) {
sidx->entry_index++;
if (sidx->entry_index < sidx->entries_count) {
fragment_finished = FALSE;
}
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
dashstream->sidx_index++;
dashdemux: protect against malformed isombff format Be more careful around malformed mpds that announce using isombff profile but actually are regular mpds
2015-02-16 02:16:52 +00:00
} else {
sidx->entry_index--;
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
dashstream->sidx_index--;
dashdemux: protect against malformed isombff format Be more careful around malformed mpds that announce using isombff profile but actually are regular mpds
2015-02-16 02:16:52 +00:00
if (sidx->entry_index >= 0) {
fragment_finished = FALSE;
}
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
}
}
dashdemux: protect against malformed isombff format Be more careful around malformed mpds that announce using isombff profile but actually are regular mpds
2015-02-16 02:16:52 +00:00
GST_DEBUG_OBJECT (stream->pad, "New sidx index: %d / %d. "
"Finished fragment: %d", sidx->entry_index, sidx->entries_count,
fragment_finished);
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
return !fragment_finished;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
}
dashdemux: avoid busy-looping when waiting for new fragment When all fragments have already been downloaded on a live stream dashdemux would busy loop as the default implementation of has_next_fragment would return TRUE. Implement it to correctly signal if adaptivedemux should wait for the manifest update before trying to get new fragments.
2015-05-12 16:41:19 +00:00
static gboolean
gst_dash_demux_stream_has_next_fragment (GstAdaptiveDemuxStream * stream)
{
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (stream->demux);
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
if (dashstream->moof_sync_samples
dashdemux: Only do keyframe-only playback if the corresponding seek flag is given https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-31 12:12:49 +00:00
&& GST_ADAPTIVE_DEMUX (dashdemux)->
segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS) {
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
if (gst_dash_demux_stream_has_next_sync_sample (stream))
return TRUE;
}
dashdemux: also check for subfragments on has_next_fragment In dash isombff profile the fragment is split into subframents where bitrate switching is possible. Also take that into consideration when checking if a stream has next fragments.
2015-09-14 16:56:10 +00:00
if (gst_mpd_client_has_isoff_ondemand_profile (dashdemux->client)) {
if (gst_dash_demux_stream_has_next_subfragment (stream))
return TRUE;
}
dashdemux: avoid busy-looping when waiting for new fragment When all fragments have already been downloaded on a live stream dashdemux would busy loop as the default implementation of has_next_fragment would return TRUE. Implement it to correctly signal if adaptivedemux should wait for the manifest update before trying to get new fragments.
2015-05-12 16:41:19 +00:00
return gst_mpd_client_has_next_segment (dashdemux->client,
dashstream->active_stream, stream->demux->segment.rate > 0.0);
}
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
static void
gst_dash_demux_clear_pending_stream_data (GstDashDemux * dashdemux,
GstDashDemuxStream * dashstream)
{
gst_isoff_sidx_parser_clear (&dashstream->sidx_parser);
gst_isoff_sidx_parser_init (&dashstream->sidx_parser);
if (dashstream->sidx_adapter)
gst_adapter_clear (dashstream->sidx_adapter);
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
/* Reset ISOBMFF box parsing state */
if (dashstream->isobmff_adapter)
gst_adapter_clear (dashstream->isobmff_adapter);
dashstream->isobmff_parser.current_fourcc = 0;
dashstream->isobmff_parser.current_start_offset = 0;
dashstream->isobmff_parser.current_offset = 0;
dashstream->isobmff_parser.current_size = 0;
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
if (dashstream->moof)
gst_isoff_moof_box_free (dashstream->moof);
dashstream->moof = NULL;
if (dashstream->moof_sync_samples)
g_array_free (dashstream->moof_sync_samples, TRUE);
dashstream->moof_sync_samples = NULL;
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
dashstream->current_sync_sample = -1;
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static GstFlowReturn
gst_dash_demux_stream_advance_fragment (GstAdaptiveDemuxStream * stream)
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (stream->demux);
dashdemux: Use 1 download task per stream Instead of having a single download task for all streams, this commit makes each stream have its own download loop, allowing parallel download of fragments.
2013-12-03 19:16:09 +00:00
dashdemux: protect against malformed isombff format Be more careful around malformed mpds that announce using isombff profile but actually are regular mpds
2015-02-16 02:16:52 +00:00
GST_DEBUG_OBJECT (stream->pad, "Advance fragment");
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
/* If downloading only keyframes, switch to the next one or fall through */
if (dashstream->moof_sync_samples
dashdemux: Only do keyframe-only playback if the corresponding seek flag is given https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-31 12:12:49 +00:00
&& GST_ADAPTIVE_DEMUX (dashdemux)->
segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS) {
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
if (gst_dash_demux_stream_advance_sync_sample (stream))
return GST_FLOW_OK;
}
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
if (dashstream->isobmff_adapter)
gst_adapter_clear (dashstream->isobmff_adapter);
dashstream->isobmff_parser.current_fourcc = 0;
dashstream->isobmff_parser.current_start_offset = 0;
dashstream->isobmff_parser.current_offset = 0;
dashstream->isobmff_parser.current_size = 0;
if (dashstream->moof)
gst_isoff_moof_box_free (dashstream->moof);
dashstream->moof = NULL;
if (dashstream->moof_sync_samples)
g_array_free (dashstream->moof_sync_samples, TRUE);
dashstream->moof_sync_samples = NULL;
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
dashstream->current_sync_sample = -1;
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
if (gst_mpd_client_has_isoff_ondemand_profile (dashdemux->client)) {
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
if (gst_dash_demux_stream_advance_subfragment (stream))
return GST_FLOW_OK;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
}
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
gst_isoff_sidx_parser_clear (&dashstream->sidx_parser);
gst_isoff_sidx_parser_init (&dashstream->sidx_parser);
if (dashstream->sidx_adapter)
gst_adapter_clear (dashstream->sidx_adapter);
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return gst_mpd_client_advance_segment (dashdemux->client,
dashstream->active_stream, stream->demux->segment.rate > 0.0);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static gboolean
gst_dash_demux_stream_select_bitrate (GstAdaptiveDemuxStream * stream,
guint64 bitrate)
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
{
dashdemux: re-enable and fix adaptive switching It is still unstable, but at least it works when the switches aren't happening after every fragment
2013-01-30 20:27:47 +00:00
GstActiveStream *active_stream = NULL;
mpdparser: fixed parsing of SegmentList syntax element, and eliminated Represention node list from Period node SegmentList nodes are allowed into Period, AdaptationSet or Representation nodes and there is at most 1 element, so no need to keep a list; Period nodes cannot have any Represention elements, as AdaptationSet nodes are mandatory; this breaks compatibility with some legacy DASH test sequences.
2012-10-08 09:16:09 +00:00
GList *rep_list = NULL;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
gint new_index;
adaptivedemux: Enable bitrate selection for trick mode streaming again And scale the bitrate with the absolute rate (if it's bigger than 1.0) to get to the real bitrate due to faster playback. This allowed in my tests to play a stream with 10x speed without buffering as the lowest bitrate is chosen, instead of staying/selecting the highest bitrate and then buffering all the time. It was previously disabled for not very well specified reasons, which seem to be not valid anymore nowadays.
2016-08-25 16:35:13 +00:00
GstAdaptiveDemux *base_demux = stream->demux;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemux *demux = GST_DASH_DEMUX_CAST (stream->demux);
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
gboolean ret = FALSE;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
active_stream = dashstream->active_stream;
if (active_stream == NULL) {
goto end;
}
dashdemux: re-enable and fix adaptive switching It is still unstable, but at least it works when the switches aren't happening after every fragment
2013-01-30 20:27:47 +00:00
dashdemux: Use 1 download task per stream Instead of having a single download task for all streams, this commit makes each stream have its own download loop, allowing parallel download of fragments.
2013-12-03 19:16:09 +00:00
/* retrieve representation list */
if (active_stream->cur_adapt_set)
rep_list = active_stream->cur_adapt_set->Representations;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (!rep_list) {
goto end;
}
dashdemux: measure download rate just like hlsdemux new bitrate = (old bitrate + (last fragment bitrate * 3)) / 4
2014-05-01 15:04:51 +00:00
GST_DEBUG_OBJECT (stream->pad,
"Trying to change to bitrate: %" G_GUINT64_FORMAT, bitrate);
dashdemux: Use 1 download task per stream Instead of having a single download task for all streams, this commit makes each stream have its own download loop, allowing parallel download of fragments.
2013-12-03 19:16:09 +00:00
dashdemux: Add properties to select maximum allowed width/height and framerate https://bugzilla.gnome.org/show_bug.cgi?id=770408
2016-08-25 17:50:11 +00:00
if (active_stream->mimeType == GST_STREAM_VIDEO && demux->max_bitrate) {
bitrate = MIN (demux->max_bitrate, bitrate);
}
dashdemux: Use 1 download task per stream Instead of having a single download task for all streams, this commit makes each stream have its own download loop, allowing parallel download of fragments.
2013-12-03 19:16:09 +00:00
/* get representation index with current max_bandwidth */
adaptivedemux: Enable bitrate selection for trick mode streaming again And scale the bitrate with the absolute rate (if it's bigger than 1.0) to get to the real bitrate due to faster playback. This allowed in my tests to play a stream with 10x speed without buffering as the lowest bitrate is chosen, instead of staying/selecting the highest bitrate and then buffering all the time. It was previously disabled for not very well specified reasons, which seem to be not valid anymore nowadays.
2016-08-25 16:35:13 +00:00
if ((base_demux->segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS) ||
ABS (base_demux->segment.rate) <= 1.0) {
new_index =
dashdemux: Add properties to select maximum allowed width/height and framerate https://bugzilla.gnome.org/show_bug.cgi?id=770408
2016-08-25 17:50:11 +00:00
gst_mpdparser_get_rep_idx_with_max_bandwidth (rep_list, bitrate,
demux->max_video_width, demux->max_video_height,
demux->max_video_framerate_n, demux->max_video_framerate_d);
adaptivedemux: Enable bitrate selection for trick mode streaming again And scale the bitrate with the absolute rate (if it's bigger than 1.0) to get to the real bitrate due to faster playback. This allowed in my tests to play a stream with 10x speed without buffering as the lowest bitrate is chosen, instead of staying/selecting the highest bitrate and then buffering all the time. It was previously disabled for not very well specified reasons, which seem to be not valid anymore nowadays.
2016-08-25 16:35:13 +00:00
} else {
new_index =
gst_mpdparser_get_rep_idx_with_max_bandwidth (rep_list,
dashdemux: Add properties to select maximum allowed width/height and framerate https://bugzilla.gnome.org/show_bug.cgi?id=770408
2016-08-25 17:50:11 +00:00
bitrate / ABS (base_demux->segment.rate), demux->max_video_width,
demux->max_video_height, demux->max_video_framerate_n,
demux->max_video_framerate_d);
adaptivedemux: Enable bitrate selection for trick mode streaming again And scale the bitrate with the absolute rate (if it's bigger than 1.0) to get to the real bitrate due to faster playback. This allowed in my tests to play a stream with 10x speed without buffering as the lowest bitrate is chosen, instead of staying/selecting the highest bitrate and then buffering all the time. It was previously disabled for not very well specified reasons, which seem to be not valid anymore nowadays.
2016-08-25 16:35:13 +00:00
}
dashdemux: Use 1 download task per stream Instead of having a single download task for all streams, this commit makes each stream have its own download loop, allowing parallel download of fragments.
2013-12-03 19:16:09 +00:00
/* if no representation has the required bandwidth, take the lowest one */
if (new_index == -1)
new_index = gst_mpdparser_get_rep_idx_with_min_bandwidth (rep_list);
if (new_index != active_stream->representation_idx) {
GstRepresentationNode *rep = g_list_nth_data (rep_list, new_index);
GST_INFO_OBJECT (demux, "Changing representation idx: %d %d %u",
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
dashstream->index, new_index, rep->bandwidth);
dashdemux: Use 1 download task per stream Instead of having a single download task for all streams, this commit makes each stream have its own download loop, allowing parallel download of fragments.
2013-12-03 19:16:09 +00:00
if (gst_mpd_client_setup_representation (demux->client, active_stream, rep)) {
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstCaps *caps;
dashdemux: Use 1 download task per stream Instead of having a single download task for all streams, this commit makes each stream have its own download loop, allowing parallel download of fragments.
2013-12-03 19:16:09 +00:00
GST_INFO_OBJECT (demux, "Switching bitrate to %d",
active_stream->cur_representation->bandwidth);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
caps = gst_dash_demux_get_input_caps (demux, active_stream);
gst_adaptive_demux_stream_set_caps (stream, caps);
ret = TRUE;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
dashdemux: Use 1 download task per stream Instead of having a single download task for all streams, this commit makes each stream have its own download loop, allowing parallel download of fragments.
2013-12-03 19:16:09 +00:00
} else {
GST_WARNING_OBJECT (demux, "Can not switch representation, aborting...");
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
}
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
if (ret) {
gst_dash_demux_clear_pending_stream_data (demux, dashstream);
if (gst_mpd_client_has_isoff_ondemand_profile (demux->client)) {
/* store our current position to change to the same one in a different
* representation if needed */
dashstream->sidx_index = SIDX (dashstream)->entry_index;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
}
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
end:
dashdemux: synchronize with the download loop thread to signal it to continue If EOS or ERROR happens before the download loop thread has reached its g_cond_wait() call, then the g_cond_signal doesn't have any effect and the download loop thread stucks later. https://bugzilla.gnome.org/show_bug.cgi?id=735663
2014-08-29 10:38:12 +00:00
return ret;
dashdemux: handle top-level index urls Parse and provide access to top-level index segments if available. dashdemux should push those whenever a header is pushed. Fixes #700489
2013-07-01 16:19:15 +00:00
}
dashdemux: fix memory leak in gst_dash_demux_get_next_header()
2012-10-17 16:40:02 +00:00
dashdemux: only update current reading position when needed If the seek doesn't set the start/stop position, no need to reposition the download index.
2016-02-01 12:48:33 +00:00
#define SEEK_UPDATES_PLAY_POSITION(r, start_type, stop_type) \
((r >= 0 && start_type != GST_SEEK_TYPE_NONE) || \
(r < 0 && stop_type != GST_SEEK_TYPE_NONE))
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static gboolean
gst_dash_demux_seek (GstAdaptiveDemux * demux, GstEvent * seek)
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gdouble rate;
GstFormat format;
GstSeekFlags flags;
GstSeekType start_type, stop_type;
gint64 start, stop;
GList *list;
GstClockTime current_pos, target_pos;
guint current_period;
GstStreamPeriod *period;
dashdemux: Skip audio streams if TRICKMODE_NO_AUDIO is given in the seek event We just don't expose pads for audio streams, or even download them.
2016-07-28 08:27:29 +00:00
GList *iter, *streams = NULL;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
dashdemux: Skip audio streams if TRICKMODE_NO_AUDIO is given in the seek event We just don't expose pads for audio streams, or even download them.
2016-07-28 08:27:29 +00:00
gboolean trickmode_no_audio;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_event_parse_seek (seek, &rate, &format, &flags, &start_type, &start,
&stop_type, &stop);
dashdemux: only update current reading position when needed If the seek doesn't set the start/stop position, no need to reposition the download index.
2016-02-01 12:48:33 +00:00
if (!SEEK_UPDATES_PLAY_POSITION (rate, start_type, stop_type)) {
/* nothing to do if we don't have to update the current position */
return TRUE;
}
if (demux->segment.rate > 0.0) {
dashdemux: respect seeking parameter Instead of using the segment values, use the parameter requested in the seeking argument
2016-01-29 23:34:42 +00:00
target_pos = (GstClockTime) start;
dashdemux: only update current reading position when needed If the seek doesn't set the start/stop position, no need to reposition the download index.
2016-02-01 12:48:33 +00:00
} else {
dashdemux: respect seeking parameter Instead of using the segment values, use the parameter requested in the seeking argument
2016-01-29 23:34:42 +00:00
target_pos = (GstClockTime) stop;
dashdemux: only update current reading position when needed If the seek doesn't set the start/stop position, no need to reposition the download index.
2016-02-01 12:48:33 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* select the requested Period in the Media Presentation */
dashdemux: Implement lazy-loading of external periods https://bugzilla.gnome.org/show_bug.cgi?id=752230
2015-09-22 14:17:38 +00:00
if (!gst_mpd_client_setup_media_presentation (dashdemux->client, target_pos,
-1, NULL))
return FALSE;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
current_period = 0;
for (list = g_list_first (dashdemux->client->periods); list;
list = g_list_next (list)) {
period = list->data;
current_pos = period->start;
current_period = period->number;
dashdemux: fix off by one seeking issue When seeking to the last second of a mpd it would reject the seek because the comparison was < instead of <= This fails the important use case of seeking to the end of a file to play it back in reverse from the end
2015-08-16 11:49:35 +00:00
GST_DEBUG_OBJECT (demux, "Looking at period %u) start:%"
GST_TIME_FORMAT " - duration:%"
GST_TIME_FORMAT ") for position %" GST_TIME_FORMAT,
current_period, GST_TIME_ARGS (current_pos),
GST_TIME_ARGS (period->duration), GST_TIME_ARGS (target_pos));
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (current_pos <= target_pos
dashdemux: fix off by one seeking issue When seeking to the last second of a mpd it would reject the seek because the comparison was < instead of <= This fails the important use case of seeking to the end of a file to play it back in reverse from the end
2015-08-16 11:49:35 +00:00
&& target_pos <= current_pos + period->duration) {
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
break;
}
mpdparser: do not switch pads when bitstreamSwitching = true
2012-12-17 14:39:10 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (list == NULL) {
GST_WARNING_OBJECT (demux, "Could not find seeked Period");
return FALSE;
dashdemux: reworked caps detection also reworked the API to extract audio/video parameters from the manifest file (mimeType, width, height, rate, num channels)
2012-10-19 18:12:09 +00:00
}
dashdemux: Skip audio streams if TRICKMODE_NO_AUDIO is given in the seek event We just don't expose pads for audio streams, or even download them.
2016-07-28 08:27:29 +00:00
trickmode_no_audio = ! !(flags & GST_SEEK_FLAG_TRICKMODE_NO_AUDIO);
streams = demux->streams;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (current_period != gst_mpd_client_get_period_index (dashdemux->client)) {
GST_DEBUG_OBJECT (demux, "Seeking to Period %d", current_period);
dashdemux: reworked caps detection also reworked the API to extract audio/video parameters from the manifest file (mimeType, width, height, rate, num channels)
2012-10-19 18:12:09 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* clean old active stream list, if any */
gst_active_streams_free (dashdemux->client);
dashdemux: Skip audio streams if TRICKMODE_NO_AUDIO is given in the seek event We just don't expose pads for audio streams, or even download them.
2016-07-28 08:27:29 +00:00
dashdemux->trickmode_no_audio = trickmode_no_audio;
dashdemux: reworked caps detection also reworked the API to extract audio/video parameters from the manifest file (mimeType, width, height, rate, num channels)
2012-10-19 18:12:09 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* setup video, audio and subtitle streams, starting from the new Period */
if (!gst_mpd_client_set_period_index (dashdemux->client, current_period)
|| !gst_dash_demux_setup_all_streams (dashdemux))
return FALSE;
dashdemux: Skip audio streams if TRICKMODE_NO_AUDIO is given in the seek event We just don't expose pads for audio streams, or even download them.
2016-07-28 08:27:29 +00:00
streams = demux->next_streams;
} else if (dashdemux->trickmode_no_audio != trickmode_no_audio) {
/* clean old active stream list, if any */
gst_active_streams_free (dashdemux->client);
dashdemux->trickmode_no_audio = trickmode_no_audio;
/* setup video, audio and subtitle streams, starting from the new Period */
if (!gst_dash_demux_setup_all_streams (dashdemux))
return FALSE;
streams = demux->next_streams;
mpdparser: do not switch pads when bitstreamSwitching = true
2012-12-17 14:39:10 +00:00
}
mpdparser/dashdemux: fixed get_width, get_height, get_audio_rate, get_num_audio_channels API functions the actual values now can be extracted also from the AdaptationSet element; checking NULL structs for better robustness;
2012-10-08 15:43:14 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* Update the current sequence on all streams */
dashdemux: Skip audio streams if TRICKMODE_NO_AUDIO is given in the seek event We just don't expose pads for audio streams, or even download them.
2016-07-28 08:27:29 +00:00
for (iter = streams; iter; iter = g_list_next (iter)) {
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemuxStream *dashstream = iter->data;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
if (flags & GST_SEEK_FLAG_FLUSH) {
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
gst_dash_demux_clear_pending_stream_data (dashdemux, dashstream);
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
}
adaptivedemux: handle snap seeks Adaptive demuxers need to start downloading from specific positions (fragments) for every stream, this means that all streams can snap-seek to a different position when requested. Snap seeking in this case will be done in 2 steps: 1) do the snap seeking on the pad that received the seek event and get the final position 2) use this position to do a regular seek on the other streams to make sure they all start from the same position More arguments were added to the stream_seek function, allowing better control of how seeking is done. Knowing the flags and the playback direction allows subclasses to handle snap-seeking. And also adds a new return parameter to inform of the final selected seeking position that is used to align the other streams. https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-01-27 16:31:10 +00:00
gst_dash_demux_stream_seek (iter->data, rate >= 0, 0, target_pos, NULL);
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return TRUE;
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static gint64
gst_dash_demux_get_manifest_update_interval (GstAdaptiveDemux * demux)
dashdemux: refactor fragment fetching into smaller functions Makes it easier to maintain and extend. This is a first step into adding multi language support to dashdemux
2013-12-03 03:12:08 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
return MIN (dashdemux->client->mpd_node->minimumUpdatePeriod * 1000,
SLOW_CLOCK_UPDATE_INTERVAL);
dashdemux: refactor fragment fetching into smaller functions Makes it easier to maintain and extend. This is a first step into adding multi language support to dashdemux
2013-12-03 03:12:08 +00:00
}
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
static GstFlowReturn
adaptivedemux: Allow subclasses to override how a new manifest would be downloaded
2015-04-23 15:22:11 +00:00
gst_dash_demux_update_manifest_data (GstAdaptiveDemux * demux,
GstBuffer * buffer)
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
GstMpdClient *new_client = NULL;
GstMapInfo mapinfo;
dashdemux: Only set timestamp to the first buffer of fragments Setting it to the other parts of the fragment is slightly wrong and misleading as it isn't accurate enough.
2014-05-02 21:32:56 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GST_DEBUG_OBJECT (demux, "Updating manifest file from URL");
dashdemux: Only set timestamp to the first buffer of fragments Setting it to the other parts of the fragment is slightly wrong and misleading as it isn't accurate enough.
2014-05-02 21:32:56 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* parse the manifest file */
new_client = gst_mpd_client_new ();
mpdparser: Store an URI downloader in the parser for downloading additional MPD resources if needed https://bugzilla.gnome.org/show_bug.cgi?id=752230
2015-08-21 09:06:07 +00:00
gst_mpd_client_set_uri_downloader (new_client, demux->downloader);
dashdemux: when updating the manifest, set the uri This will allow dashdemux to create the correct full path URIs to continue downloading fragments
2014-11-29 13:25:45 +00:00
new_client->mpd_uri = g_strdup (demux->manifest_uri);
new_client->mpd_base_uri = g_strdup (demux->manifest_base_uri);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_buffer_map (buffer, &mapinfo, GST_MAP_READ);
dashdemux: Only set timestamp to the first buffer of fragments Setting it to the other parts of the fragment is slightly wrong and misleading as it isn't accurate enough.
2014-05-02 21:32:56 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (gst_mpd_parse (new_client, (gchar *) mapinfo.data, mapinfo.size)) {
const gchar *period_id;
guint period_idx;
GList *iter;
dashdemux: replace the streams with the new mpd client's streams Otherwise it won't update with the new segment info from the playlist update
2014-11-29 13:26:31 +00:00
GList *streams_iter;
dashdemux: Only set timestamp to the first buffer of fragments Setting it to the other parts of the fragment is slightly wrong and misleading as it isn't accurate enough.
2014-05-02 21:32:56 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* prepare the new manifest and try to transfer the stream position
* status from the old manifest client */
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GST_DEBUG_OBJECT (demux, "Updating manifest");
dashdemux: mark first buffer as discont after restarting a download task Mark first buffer as discont after restarting a download task, so downstream can reset its state to properly handle the new fragment. Related issue: https://bugzilla.gnome.org/show_bug.cgi?id=736318 https://bugzilla.gnome.org/show_bug.cgi?id=736319
2014-09-09 11:12:31 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
period_id = gst_mpd_client_get_period_id (dashdemux->client);
period_idx = gst_mpd_client_get_period_index (dashdemux->client);
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* setup video, audio and subtitle streams, starting from current Period */
dashdemux: Implement lazy-loading of external periods https://bugzilla.gnome.org/show_bug.cgi?id=752230
2015-09-22 14:17:38 +00:00
if (!gst_mpd_client_setup_media_presentation (new_client, -1,
(period_id ? -1 : period_idx), period_id)) {
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* TODO */
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
}
dashdemux: Fix period selection for live streams Fix period selection and properly error out when update cannot be done https://bugzilla.gnome.org/show_bug.cgi?id=725298
2014-12-02 10:06:00 +00:00
if (period_id) {
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (!gst_mpd_client_set_period_id (new_client, period_id)) {
GST_DEBUG_OBJECT (demux, "Error setting up the updated manifest file");
dashdemux: fix memory leak in gst_dash_demux_update_manifest_data new_client local variable was not freed in case of errors. Also, the buffer is not unmapped. https://bugzilla.gnome.org/show_bug.cgi?id=760120
2016-01-04 12:12:45 +00:00
gst_mpd_client_free (new_client);
gst_buffer_unmap (buffer, &mapinfo);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return GST_FLOW_EOS;
}
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
} else {
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (!gst_mpd_client_set_period_index (new_client, period_idx)) {
GST_DEBUG_OBJECT (demux, "Error setting up the updated manifest file");
dashdemux: fix memory leak in gst_dash_demux_update_manifest_data new_client local variable was not freed in case of errors. Also, the buffer is not unmapped. https://bugzilla.gnome.org/show_bug.cgi?id=760120
2016-01-04 12:12:45 +00:00
gst_mpd_client_free (new_client);
gst_buffer_unmap (buffer, &mapinfo);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return GST_FLOW_EOS;
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
}
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (!gst_dash_demux_setup_mpdparser_streams (dashdemux, new_client)) {
GST_ERROR_OBJECT (demux, "Failed to setup streams on manifest " "update");
dashdemux: fix memory leak in gst_dash_demux_update_manifest_data new_client local variable was not freed in case of errors. Also, the buffer is not unmapped. https://bugzilla.gnome.org/show_bug.cgi?id=760120
2016-01-04 12:12:45 +00:00
gst_mpd_client_free (new_client);
gst_buffer_unmap (buffer, &mapinfo);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return GST_FLOW_ERROR;
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* update the streams to play from the next segment */
dashdemux: replace the streams with the new mpd client's streams Otherwise it won't update with the new segment info from the playlist update
2014-11-29 13:26:31 +00:00
for (iter = demux->streams, streams_iter = new_client->active_streams;
iter && streams_iter;
iter = g_list_next (iter), streams_iter = g_list_next (streams_iter)) {
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemuxStream *demux_stream = iter->data;
dashdemux: replace the streams with the new mpd client's streams Otherwise it won't update with the new segment info from the playlist update
2014-11-29 13:26:31 +00:00
GstActiveStream *new_stream = streams_iter->data;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstClockTime ts;
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (!new_stream) {
GST_DEBUG_OBJECT (demux,
"Stream of index %d is missing from manifest update",
demux_stream->index);
dashdemux: fix memory leak in gst_dash_demux_update_manifest_data new_client local variable was not freed in case of errors. Also, the buffer is not unmapped. https://bugzilla.gnome.org/show_bug.cgi?id=760120
2016-01-04 12:12:45 +00:00
gst_mpd_client_free (new_client);
gst_buffer_unmap (buffer, &mapinfo);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return GST_FLOW_EOS;
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (gst_mpd_client_get_next_fragment_timestamp (dashdemux->client,
dashdemux: Improve live stream manifest update repositioning When updating the manifest the timestamps on it might have changed a little due to rounding and timescale conversions. If the change makes the timestamp of the current segment to go up it makes dashdemux reposition to the previous one causing one extra unnecessary download. So when repositioning add an extra 10 microseconds to cover for that rounding issues and increase the chance of falling in the same segment. Additionally, also improve the time used when the client is already after the last segment. Instead of using the last segment starting timestamp use the final timestamp to make it reposition to the next one and not to the one that has already been downloaded.
2015-05-11 17:19:20 +00:00
demux_stream->index, &ts)
|| gst_mpd_client_get_last_fragment_timestamp_end (dashdemux->client,
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
demux_stream->index, &ts)) {
dashdemux: Improve live stream manifest update repositioning When updating the manifest the timestamps on it might have changed a little due to rounding and timescale conversions. If the change makes the timestamp of the current segment to go up it makes dashdemux reposition to the previous one causing one extra unnecessary download. So when repositioning add an extra 10 microseconds to cover for that rounding issues and increase the chance of falling in the same segment. Additionally, also improve the time used when the client is already after the last segment. Instead of using the last segment starting timestamp use the final timestamp to make it reposition to the next one and not to the one that has already been downloaded.
2015-05-11 17:19:20 +00:00
/* Due to rounding when doing the timescale conversions it might happen
* that the ts falls back to a previous segment, leading the same data
* to be downloaded twice. We try to work around this by always adding
* 10 microseconds to get back to the correct segment. The errors are
* usually on the order of nanoseconds so it should be enough.
*/
GST_DEBUG_OBJECT (GST_ADAPTIVE_DEMUX_STREAM_PAD (demux_stream),
"Current position: %" GST_TIME_FORMAT ", updating to %"
GST_TIME_FORMAT, GST_TIME_ARGS (ts),
GST_TIME_ARGS (ts + (10 * GST_USECOND)));
ts += 10 * GST_USECOND;
adaptivedemux: handle snap seeks Adaptive demuxers need to start downloading from specific positions (fragments) for every stream, this means that all streams can snap-seek to a different position when requested. Snap seeking in this case will be done in 2 steps: 1) do the snap seeking on the pad that received the seek event and get the final position 2) use this position to do a regular seek on the other streams to make sure they all start from the same position More arguments were added to the stream_seek function, allowing better control of how seeking is done. Knowing the flags and the playback direction allows subclasses to handle snap-seeking. And also adds a new return parameter to inform of the final selected seeking position that is used to align the other streams. https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-01-27 16:31:10 +00:00
gst_mpd_client_stream_seek (new_client, new_stream,
demux->segment.rate >= 0, 0, ts, NULL);
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
}
dashdemux: Improve live stream manifest update repositioning When updating the manifest the timestamps on it might have changed a little due to rounding and timescale conversions. If the change makes the timestamp of the current segment to go up it makes dashdemux reposition to the previous one causing one extra unnecessary download. So when repositioning add an extra 10 microseconds to cover for that rounding issues and increase the chance of falling in the same segment. Additionally, also improve the time used when the client is already after the last segment. Instead of using the last segment starting timestamp use the final timestamp to make it reposition to the next one and not to the one that has already been downloaded.
2015-05-11 17:19:20 +00:00
dashdemux: replace the streams with the new mpd client's streams Otherwise it won't update with the new segment info from the playlist update
2014-11-29 13:26:31 +00:00
demux_stream->active_stream = new_stream;
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_mpd_client_free (dashdemux->client);
dashdemux->client = new_client;
dashdemux: synchronize with the download loop thread to signal it to continue If EOS or ERROR happens before the download loop thread has reached its g_cond_wait() call, then the g_cond_signal doesn't have any effect and the download loop thread stucks later. https://bugzilla.gnome.org/show_bug.cgi?id=735663
2014-08-29 10:38:12 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GST_DEBUG_OBJECT (demux, "Manifest file successfully updated");
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
if (dashdemux->clock_drift) {
gst_dash_demux_poll_clock_drift (dashdemux);
}
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
} else {
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
/* In most cases, this will happen if we set a wrong url in the
* source element and we have received the 404 HTML response instead of
* the manifest */
GST_WARNING_OBJECT (demux, "Error parsing the manifest.");
dashdemux: plug mpd client leak On parsing error, free the mpd client object https://bugzilla.gnome.org/show_bug.cgi?id=760120
2016-02-09 20:24:50 +00:00
gst_mpd_client_free (new_client);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_buffer_unmap (buffer, &mapinfo);
dashdemux: Fix period selection for live streams Fix period selection and properly error out when update cannot be done https://bugzilla.gnome.org/show_bug.cgi?id=725298
2014-12-02 10:06:00 +00:00
return GST_FLOW_ERROR;
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_buffer_unmap (buffer, &mapinfo);
dashdemux: synchronize with the download loop thread to signal it to continue If EOS or ERROR happens before the download loop thread has reached its g_cond_wait() call, then the g_cond_signal doesn't have any effect and the download loop thread stucks later. https://bugzilla.gnome.org/show_bug.cgi?id=735663
2014-08-29 10:38:12 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return GST_FLOW_OK;
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static gint64
gst_dash_demux_stream_get_fragment_waiting_time (GstAdaptiveDemuxStream *
stream)
dashdemux: refactor fragment fetching into smaller functions Makes it easier to maintain and extend. This is a first step into adding multi language support to dashdemux
2013-12-03 03:12:08 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (stream->demux);
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
mpdparser: renamed gst_mpd_client_get_next_segment_availability_end_time to gst_mpd_client_get_next_segment_availability_start_time The function actually returns the segment availability start time (as defined by the standard). That is at the end of the segment, but it is called availability start time. Availability end time is something else (the time when the segment is no longer available on the server). The function name was misleading. https://bugzilla.gnome.org/show_bug.cgi?id=757655
2015-11-10 22:01:38 +00:00
GstDateTime *segmentAvailability;
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstActiveStream *active_stream = dashstream->active_stream;
dashdemux: refactor fragment fetching into smaller functions Makes it easier to maintain and extend. This is a first step into adding multi language support to dashdemux
2013-12-03 03:12:08 +00:00
mpdparser: renamed gst_mpd_client_get_next_segment_availability_end_time to gst_mpd_client_get_next_segment_availability_start_time The function actually returns the segment availability start time (as defined by the standard). That is at the end of the segment, but it is called availability start time. Availability end time is something else (the time when the segment is no longer available on the server). The function name was misleading. https://bugzilla.gnome.org/show_bug.cgi?id=757655
2015-11-10 22:01:38 +00:00
segmentAvailability =
gst_mpd_client_get_next_segment_availability_start_time
(dashdemux->client, active_stream);
dashdemux: refactor fragment fetching into smaller functions Makes it easier to maintain and extend. This is a first step into adding multi language support to dashdemux
2013-12-03 03:12:08 +00:00
mpdparser: renamed gst_mpd_client_get_next_segment_availability_end_time to gst_mpd_client_get_next_segment_availability_start_time The function actually returns the segment availability start time (as defined by the standard). That is at the end of the segment, but it is called availability start time. Availability end time is something else (the time when the segment is no longer available on the server). The function name was misleading. https://bugzilla.gnome.org/show_bug.cgi?id=757655
2015-11-10 22:01:38 +00:00
if (segmentAvailability) {
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gint64 diff;
GstDateTime *cur_time;
dashdemux: refactor fragment fetching into smaller functions Makes it easier to maintain and extend. This is a first step into adding multi language support to dashdemux
2013-12-03 03:12:08 +00:00
adaptivedemux: use GstSystemClock to all real-time calculations A realtime clock is used in many places, such as deciding which fragment to select at start up and deciding how long to sleep before a fragment becomes available. For example dashdemux needs sample the client's estimate of UTC when selecting where to start in a live DASH stream. The problem with dashdemux calculating the client's idea of UTC is that it makes it difficult to create unit tests, because the passage of time is a factor in the test. This commit changes dashdemux and adaptivedemux to use the GstSystemClock, so that a unit test can replace the system clock when it needs to be able to control the clock. This commit makes no change to the behaviour under normal usage, as GstSystemClock is based upon the system time. https://bugzilla.gnome.org/show_bug.cgi?id=762147
2016-02-16 14:44:10 +00:00
cur_time =
gst_date_time_new_from_g_date_time
(gst_adaptive_demux_get_client_now_utc (GST_ADAPTIVE_DEMUX_CAST
(dashdemux)));
diff =
gst_mpd_client_calculate_time_difference (cur_time,
mpdparser: renamed gst_mpd_client_get_next_segment_availability_end_time to gst_mpd_client_get_next_segment_availability_start_time The function actually returns the segment availability start time (as defined by the standard). That is at the end of the segment, but it is called availability start time. Availability end time is something else (the time when the segment is no longer available on the server). The function name was misleading. https://bugzilla.gnome.org/show_bug.cgi?id=757655
2015-11-10 22:01:38 +00:00
segmentAvailability);
gst_date_time_unref (segmentAvailability);
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_date_time_unref (cur_time);
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
/* subtract the server's clock drift, so that if the server's
time is behind our idea of UTC, we need to sleep for longer
before requesting a fragment */
adaptivedemux: fixed clock compensation in get_fragment_waiting_time Clock compensation is calculated in usec but is added to a GstClockTime value. https://bugzilla.gnome.org/show_bug.cgi?id=759534
2015-12-16 10:23:23 +00:00
return diff -
gst_dash_demux_get_clock_compensation (dashdemux) * GST_USECOND;
dashdemux: refactor fragment fetching into smaller functions Makes it easier to maintain and extend. This is a first step into adding multi language support to dashdemux
2013-12-03 03:12:08 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return 0;
}
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static gboolean
gst_dash_demux_has_next_period (GstAdaptiveDemux * demux)
{
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
dashdemux: remove uridownloader from fragments download Instead, use a source element linked to a ghostpad to provide smaller buffers and more granular control for downstream buffering elements while also reducing startup latency
2014-04-25 11:50:18 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (demux->segment.rate >= 0)
return gst_mpd_client_has_next_period (dashdemux->client);
dashdemux: handle a few more error cases related to missing plugins, bad URI and a lockup on dealing with errors from the source.
2014-05-02 21:34:04 +00:00
else
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
return gst_mpd_client_has_previous_period (dashdemux->client);
dashdemux: refactor fragment fetching into smaller functions Makes it easier to maintain and extend. This is a first step into adding multi language support to dashdemux
2013-12-03 03:12:08 +00:00
}
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
static void
gst_dash_demux_advance_period (GstAdaptiveDemux * demux)
Initial import of gstdashdemux sources
2013-05-08 14:13:32 +00:00
{
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
dashdemux: correctly signal EOS on manifest end Put EOS on the streams queues after the last fragment from the last period for each stream. This way we keep it serialized with the buffers and it will work when streams have different ending times
2013-01-29 18:58:50 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
g_return_if_fail (gst_mpd_client_has_next_period (dashdemux->client));
dashdemux: reimplementing live streams manifest updates Manifest updates should be done periodically for live streams, this patch makes the demuxer create a new manifest client for the new version and transfers the stream position to the new one, discarding the old one afterwards.
2013-02-22 19:40:36 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
if (demux->segment.rate >= 0) {
if (!gst_mpd_client_set_period_index (dashdemux->client,
gst_mpd_client_get_period_index (dashdemux->client) + 1)) {
/* TODO error */
return;
}
} else {
if (!gst_mpd_client_set_period_index (dashdemux->client,
gst_mpd_client_get_period_index (dashdemux->client) - 1)) {
/* TODO error */
return;
dashdemux: Use 1 download task per stream Instead of having a single download task for all streams, this commit makes each stream have its own download loop, allowing parallel download of fragments.
2013-12-03 19:16:09 +00:00
}
dashdemux: remove stream loop thread Download and push from the same task, makes code a lot simpler to maintain. Also pushing from separate threads avoids deadlocking when gst_pad_push blocks due to downstream queues being full.
2013-12-20 13:05:22 +00:00
}
dashdemux: handle live playback resync During a live stream it is possible for dashdemux to lag behind on a slow connection or to rush ahead of the connection os too fast. For the first case it is necessary to jump some segments ahead to be able to continue playback as old segments are usually deleted from the server. For the later, dashdemux should wait a little before attempting another download do give time to the server to produce a new segment
2013-07-09 02:24:28 +00:00
dashdemux: port to adaptive demux
2014-08-26 19:45:46 +00:00
gst_dash_demux_setup_all_streams (dashdemux);
dashdemux: refactor segment iteration for better performance Segments are now stored with their repeat counts instead of spanding them to multiple segments. This caused advancing to the next segment using a single index to have to iterate over the whole list every time. This commit addresses this by storing both the segment index as well as the repeat index and makes advancing to next segment just an increment of the repeat or the segment index.
2015-05-08 19:31:44 +00:00
gst_mpd_client_seek_to_first_segment (dashdemux->client);
dashdemux: handle live playback resync During a live stream it is possible for dashdemux to lag behind on a slow connection or to rush ahead of the connection os too fast. For the first case it is necessary to jump some segments ahead to be able to continue playback as old segments are usually deleted from the server. For the later, dashdemux should wait a little before attempting another download do give time to the server to produce a new segment
2013-07-09 02:24:28 +00:00
}
dashdemux: parse the sidx index from isobmff streams Allows dashdemux to identify the subsegments in the stream and switch bitrates when needed
2015-01-12 14:57:02 +00:00
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
static GstBuffer *
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
_gst_buffer_split (GstBuffer * buffer, gint offset, gsize size)
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
{
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
GstBuffer *newbuf = gst_buffer_copy_region (buffer,
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
GST_BUFFER_COPY_FLAGS | GST_BUFFER_COPY_TIMESTAMPS | GST_BUFFER_COPY_META
dashdemux: avoid assertion when splitting buffer Pass size=-1 as is if that is the case instead of subtracting the offset. Otherwise we have an invalid size passed for that buffer.
2015-05-29 12:01:29 +00:00
| GST_BUFFER_COPY_MEMORY, offset, size == -1 ? size : size - offset);
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
gst_buffer_resize (buffer, 0, offset);
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
return newbuf;
}
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
static gboolean
gst_dash_demux_stream_fragment_start (GstAdaptiveDemux * demux,
GstAdaptiveDemuxStream * stream)
{
dashdemux: Mark every first buffer of moov, sidx, moof and mdat as DISCONT in keyframe-only mode We need to mark every first buffer of a key unit as discont, and also every first buffer of a moov and moof. This ensures that qtdemux takes note of our buffer offsets for each of those buffers instead of keeping track of them itself from the first buffer. We need offsets to be consistent between moof and mdat https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-06-01 11:02:11 +00:00
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
dashstream->sidx_index_header_or_data = 0;
dashstream->sidx_current_offset = -1;
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dashstream->isobmff_parser.index_header_or_data = 0;
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
dashstream->isobmff_parser.current_offset = -1;
dashdemux: Mark every first buffer of moov, sidx, moof and mdat as DISCONT in keyframe-only mode We need to mark every first buffer of a key unit as discont, and also every first buffer of a moov and moof. This ensures that qtdemux takes note of our buffer offsets for each of those buffers instead of keeping track of them itself from the first buffer. We need offsets to be consistent between moof and mdat https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-06-01 11:02:11 +00:00
/* We need to mark every first buffer of a key unit as discont,
* and also every first buffer of a moov and moof. This ensures
* that qtdemux takes note of our buffer offsets for each of those
* buffers instead of keeping track of them itself from the first
* buffer. We need offsets to be consistent between moof and mdat
*/
if (dashstream->is_isobmff && dashdemux->allow_trickmode_key_units
&& (demux->segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS)
&& dashstream->active_stream->mimeType == GST_STREAM_VIDEO)
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
stream->discont = TRUE;
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
return TRUE;
}
dashdemux: parse the sidx index from isobmff streams Allows dashdemux to identify the subsegments in the stream and switch bitrates when needed
2015-01-12 14:57:02 +00:00
static GstFlowReturn
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
gst_dash_demux_stream_fragment_finished (GstAdaptiveDemux * demux,
GstAdaptiveDemuxStream * stream)
dashdemux: parse the sidx index from isobmff streams Allows dashdemux to identify the subsegments in the stream and switch bitrates when needed
2015-01-12 14:57:02 +00:00
{
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
dashdemux: protect against malformed isombff format Be more careful around malformed mpds that announce using isombff profile but actually are regular mpds
2015-02-16 02:16:52 +00:00
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
dashdemux: Mark every first buffer of moov, sidx, moof and mdat as DISCONT in keyframe-only mode We need to mark every first buffer of a key unit as discont, and also every first buffer of a moov and moof. This ensures that qtdemux takes note of our buffer offsets for each of those buffers instead of keeping track of them itself from the first buffer. We need offsets to be consistent between moof and mdat https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-06-01 11:02:11 +00:00
/* We need to mark every first buffer of a key unit as discont,
* and also every first buffer of a moov and moof. This ensures
* that qtdemux takes note of our buffer offsets for each of those
* buffers instead of keeping track of them itself from the first
* buffer. We need offsets to be consistent between moof and mdat
*/
if (dashstream->is_isobmff && dashdemux->allow_trickmode_key_units
&& (demux->segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS)
&& dashstream->active_stream->mimeType == GST_STREAM_VIDEO)
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
stream->discont = TRUE;
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
/* Only handle fragment advancing specifically for SIDX if we're not
* in key unit mode */
if (!(dashstream->moof_sync_samples
&& GST_ADAPTIVE_DEMUX (dashdemux)->
segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS)
&& gst_mpd_client_has_isoff_ondemand_profile (dashdemux->client)
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
&& dashstream->sidx_parser.status == GST_ISOFF_SIDX_PARSER_FINISHED) {
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
/* fragment is advanced on data_received when byte limits are reached */
dashdemux: Advance subfragment only if any exist SIDX based playback is not restricted to SegmentBase, but it possible with SegmentList/SegmentTemplate. In the latter case, each fragment has its own SIDX box and might be subdivided into subfragment. So, demux should not assume that the end of subfragment is the end of stream. Moreover, should try advance subfragment only if there are remaining subfragments. With additional fixes by Sebastian Dröge <sebastian@centricular.com> https://bugzilla.gnome.org/show_bug.cgi?id=776200
2017-03-07 12:56:03 +00:00
if (gst_dash_demux_stream_has_next_subfragment (stream)) {
dashdemux: fix return when trying to advance in subfragmented stream Even if it doesn't actually advance the subfragment in the default way for streams that have subfragments, it can help the base class to return EOS when there is no more fragments instead of signaling it that it should continue downloading. https://bugzilla.gnome.org/show_bug.cgi?id=755042
2015-09-15 12:58:20 +00:00
return GST_FLOW_OK;
dashdemux: Advance subfragment only if any exist SIDX based playback is not restricted to SegmentBase, but it possible with SegmentList/SegmentTemplate. In the latter case, each fragment has its own SIDX box and might be subdivided into subfragment. So, demux should not assume that the end of subfragment is the end of stream. Moreover, should try advance subfragment only if there are remaining subfragments. With additional fixes by Sebastian Dröge <sebastian@centricular.com> https://bugzilla.gnome.org/show_bug.cgi?id=776200
2017-03-07 12:56:03 +00:00
}
dashdemux: fix return when trying to advance in subfragmented stream Even if it doesn't actually advance the subfragment in the default way for streams that have subfragments, it can help the base class to return EOS when there is no more fragments instead of signaling it that it should continue downloading. https://bugzilla.gnome.org/show_bug.cgi?id=755042
2015-09-15 12:58:20 +00:00
}
dashdemux: don't meddle with the class struct from an instance Fix some very dubious code. The class methods should always be set, and the instance-specific check should then be done inside the method. For data_received that's there already, for finish_fragment we need to add it. https://bugzilla.gnome.org/show_bug.cgi?id=753937
2015-08-21 15:13:43 +00:00
dashdemux: remove redundant else statement Else statement is redundant when the if block finishes with an return.
2015-07-08 10:32:58 +00:00
if (G_UNLIKELY (stream->downloading_header || stream->downloading_index))
return GST_FLOW_OK;
return gst_adaptive_demux_stream_advance_fragment (demux, stream,
stream->fragment.duration);
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
}
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
static gboolean
gst_dash_demux_need_another_chunk (GstAdaptiveDemuxStream * stream)
{
dashdemux: Remember if for a stream we could do key-units only mode This makes sure we don't even try going into that mode if we previously saw that the stream does not have the suitable metadata. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:32:50 +00:00
GstDashDemux *dashdemux = (GstDashDemux *) stream->demux;
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
GstDashDemuxStream *dashstream = (GstDashDemuxStream *) stream;
/* We're chunked downloading for ISOBMFF in KEY_UNITS mode for the actual
* fragment until we parsed the moof and arrived at the mdat. 8192 is a
* random guess for the moof size
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
*/
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
if (dashstream->is_isobmff
&& (GST_ADAPTIVE_DEMUX (stream->demux)->
segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS)
&& dashstream->active_stream->mimeType == GST_STREAM_VIDEO
dashdemux: Remember if for a stream we could do key-units only mode This makes sure we don't even try going into that mode if we previously saw that the stream does not have the suitable metadata. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:32:50 +00:00
&& !stream->downloading_header && !stream->downloading_index
&& dashdemux->allow_trickmode_key_units) {
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
if (dashstream->isobmff_parser.current_fourcc != GST_ISOFF_FOURCC_MDAT) {
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
/* Need to download the moof first to know anything */
dashdemux: Collect average moof and first sync sample sizes And always request those in the beginning so that ideally we get the moof and the first sync sample all together with the first HTTP request. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:47:55 +00:00
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
stream->fragment.chunk_size = 8192;
dashdemux: Collect average moof and first sync sample sizes And always request those in the beginning so that ideally we get the moof and the first sync sample all together with the first HTTP request. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:47:55 +00:00
/* Do we have the first fourcc already or are we in the middle */
if (dashstream->isobmff_parser.current_fourcc == 0) {
stream->fragment.chunk_size += dashstream->moof_average_size;
if (dashstream->first_sync_sample_always_after_moof)
stream->fragment.chunk_size +=
dashstream->first_sync_sample_average_size;
}
dashdemux: When doing chunked downloading on SIDX, clip requests on the SIDX entry boundaries https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-04 11:47:41 +00:00
if (gst_mpd_client_has_isoff_ondemand_profile (dashdemux->client) &&
dashstream->sidx_parser.sidx.entries) {
guint64 sidx_end_offset =
dashstream->sidx_base_offset +
SIDX_CURRENT_ENTRY (dashstream)->offset +
SIDX_CURRENT_ENTRY (dashstream)->size;
if (stream->fragment.chunk_size +
dashstream->isobmff_parser.current_offset > sidx_end_offset) {
stream->fragment.chunk_size =
sidx_end_offset - dashstream->isobmff_parser.current_offset;
}
}
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
} else if (dashstream->moof && dashstream->moof_sync_samples) {
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
/* Have the moof, either we're done now or we want to download the
* directly following sync sample */
if (dashstream->first_sync_sample_after_moof
&& dashstream->current_sync_sample == 0) {
GstDashStreamSyncSample *sync_sample =
&g_array_index (dashstream->moof_sync_samples,
GstDashStreamSyncSample, 0);
dashdemux: When doing chunked downloading on SIDX, clip requests on the SIDX entry boundaries https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-04 11:47:41 +00:00
guint64 end_offset = sync_sample->end_offset + 1;
if (gst_mpd_client_has_isoff_ondemand_profile (dashdemux->client) &&
dashstream->sidx_parser.sidx.entries) {
guint64 sidx_end_offset =
dashstream->sidx_base_offset +
SIDX_CURRENT_ENTRY (dashstream)->offset +
SIDX_CURRENT_ENTRY (dashstream)->size;
if (end_offset > sidx_end_offset) {
end_offset = sidx_end_offset;
}
}
if (dashstream->isobmff_parser.current_offset < end_offset) {
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
stream->fragment.chunk_size =
dashdemux: When doing chunked downloading on SIDX, clip requests on the SIDX entry boundaries https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-04 11:47:41 +00:00
end_offset - dashstream->isobmff_parser.current_offset;
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
} else {
stream->fragment.chunk_size = 0;
}
} else {
stream->fragment.chunk_size = 0;
}
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
} else {
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
/* Have moof but can't do key-units mode, just download until the end */
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
stream->fragment.chunk_size = -1;
}
dashdemux: Remember if for a stream we could do key-units only mode This makes sure we don't even try going into that mode if we previously saw that the stream does not have the suitable metadata. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:32:50 +00:00
} else {
/* We might've decided that we can't allow key-unit only
* trickmodes while doing chunked downloading. In that case
* just download from here to the end now */
dashdemux: Collect average moof and first sync sample sizes And always request those in the beginning so that ideally we get the moof and the first sync sample all together with the first HTTP request. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:47:55 +00:00
if (dashstream->moof
&& (GST_ADAPTIVE_DEMUX (stream->demux)->
segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS))
dashdemux: Remember if for a stream we could do key-units only mode This makes sure we don't even try going into that mode if we previously saw that the stream does not have the suitable metadata. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:32:50 +00:00
stream->fragment.chunk_size = -1;
else
stream->fragment.chunk_size = 0;
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
}
dashdemux: Remember if for a stream we could do key-units only mode This makes sure we don't even try going into that mode if we previously saw that the stream does not have the suitable metadata. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:32:50 +00:00
return stream->fragment.chunk_size != 0;
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
}
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
static GstBuffer *
gst_dash_demux_parse_isobmff (GstAdaptiveDemux * demux,
GstDashDemuxStream * dash_stream, GstBuffer * buffer)
{
GstAdaptiveDemuxStream *stream = (GstAdaptiveDemuxStream *) dash_stream;
dashdemux: Always parsing sidx for On-Demand profile The indexRange attribute is optional and if it's not present, we should extract the sidx box from incoming buffers. https://bugzilla.gnome.org/show_bug.cgi?id=776200
2016-12-20 02:16:11 +00:00
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
gsize available;
guint index_header_or_data;
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
GstMapInfo map;
GstByteReader reader;
guint32 fourcc;
guint header_size;
guint64 size, buffer_offset;
/* This must not be called when we're in the mdat. We only look at the mdat
* header and then stop parsing the boxes as we're only interested in the
* metadata! Handling mdat is the job of the surrounding code, as well as
* stopping or starting the next fragment when mdat is over (=> sidx)
*/
g_assert (dash_stream->isobmff_parser.current_fourcc !=
GST_ISOFF_FOURCC_MDAT);
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
if (stream->downloading_index)
index_header_or_data = 1;
else if (stream->downloading_header)
index_header_or_data = 2;
else
index_header_or_data = 3;
if (dash_stream->isobmff_parser.index_header_or_data != index_header_or_data) {
/* Clear pending data */
if (gst_adapter_available (dash_stream->isobmff_adapter) != 0)
GST_ERROR_OBJECT (stream->pad,
"Had pending ISOBMFF data after switch between index/header/data");
gst_adapter_clear (dash_stream->isobmff_adapter);
dash_stream->isobmff_parser.current_fourcc = 0;
dash_stream->isobmff_parser.current_start_offset = 0;
dash_stream->isobmff_parser.current_offset = -1;
dash_stream->isobmff_parser.current_size = 0;
dash_stream->isobmff_parser.index_header_or_data = index_header_or_data;
}
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
if (dash_stream->isobmff_parser.current_offset == -1) {
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dash_stream->isobmff_parser.current_offset =
GST_BUFFER_OFFSET_IS_VALID (buffer) ? GST_BUFFER_OFFSET (buffer) : 0;
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
}
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
gst_adapter_push (dash_stream->isobmff_adapter, buffer);
available = gst_adapter_available (dash_stream->isobmff_adapter);
buffer = gst_adapter_take_buffer (dash_stream->isobmff_adapter, available);
buffer_offset = dash_stream->isobmff_parser.current_offset;
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
/* Always at the start of a box here */
g_assert (dash_stream->isobmff_parser.current_size == 0);
/* At the start of a box => Parse it */
gst_buffer_map (buffer, &map, GST_MAP_READ);
gst_byte_reader_init (&reader, map.data, map.size);
/* While there are more boxes left to parse ... */
dash_stream->isobmff_parser.current_start_offset =
dash_stream->isobmff_parser.current_offset;
do {
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dash_stream->isobmff_parser.current_fourcc = 0;
dash_stream->isobmff_parser.current_size = 0;
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
if (!gst_isoff_parse_box_header (&reader, &fourcc, NULL, &header_size,
&size)) {
break;
}
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
dash_stream->isobmff_parser.current_fourcc = fourcc;
if (size == 0) {
/* We assume this is mdat, anything else with "size until end"
* does not seem to make sense */
g_assert (dash_stream->isobmff_parser.current_fourcc ==
GST_ISOFF_FOURCC_MDAT);
dash_stream->isobmff_parser.current_size = -1;
break;
}
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
dash_stream->isobmff_parser.current_size = size;
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
/* Do we have the complete box or are at MDAT */
if (gst_byte_reader_get_remaining (&reader) < size - header_size ||
dash_stream->isobmff_parser.current_fourcc == GST_ISOFF_FOURCC_MDAT) {
/* Reset byte reader to the beginning of the box */
gst_byte_reader_set_pos (&reader,
gst_byte_reader_get_pos (&reader) - header_size);
break;
}
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
GST_LOG_OBJECT (stream->pad,
"box %" GST_FOURCC_FORMAT " at offset %" G_GUINT64_FORMAT " size %"
G_GUINT64_FORMAT, GST_FOURCC_ARGS (fourcc),
dash_stream->isobmff_parser.current_offset +
gst_byte_reader_get_pos (&reader) - header_size, size);
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
if (dash_stream->isobmff_parser.current_fourcc == GST_ISOFF_FOURCC_MOOF) {
GstByteReader sub_reader;
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
g_assert (dash_stream->moof == NULL);
g_assert (dash_stream->moof_sync_samples == NULL);
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
gst_byte_reader_get_sub_reader (&reader, &sub_reader, size - header_size);
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
dash_stream->moof = gst_isoff_moof_box_parse (&sub_reader);
dash_stream->moof_offset =
dash_stream->isobmff_parser.current_start_offset;
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
dash_stream->moof_size = size;
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
dash_stream->current_sync_sample = -1;
dashdemux: Collect average moof and first sync sample sizes And always request those in the beginning so that ideally we get the moof and the first sync sample all together with the first HTTP request. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:47:55 +00:00
if (dash_stream->moof_average_size) {
if (dash_stream->moof_average_size < size)
dash_stream->moof_average_size =
(size * 3 + dash_stream->moof_average_size) / 4;
else
dash_stream->moof_average_size =
(size + dash_stream->moof_average_size + 3) / 4;
} else {
dash_stream->moof_average_size = size;
}
dashdemux: Always parsing sidx for On-Demand profile The indexRange attribute is optional and if it's not present, we should extract the sidx box from incoming buffers. https://bugzilla.gnome.org/show_bug.cgi?id=776200
2016-12-20 02:16:11 +00:00
} else if (dash_stream->isobmff_parser.current_fourcc ==
GST_ISOFF_FOURCC_SIDX &&
gst_mpd_client_has_isoff_ondemand_profile (dashdemux->client)) {
GstByteReader sub_reader;
GstIsoffParserResult res;
guint dummy;
dash_stream->sidx_base_offset = buffer_offset +
gst_byte_reader_get_pos (&reader) - header_size + size;
gst_byte_reader_get_sub_reader (&reader, &sub_reader, size - header_size);
res =
gst_isoff_sidx_parser_parse (&dash_stream->sidx_parser, &sub_reader,
&dummy);
if (res == GST_ISOFF_PARSER_DONE) {
dashdemux: Add first_offset of sidx box to base offset sidx has "first_offset" syntax which represents the distance in bytes from anchor point to media fragment. If present, we should adjust sidx_base_offset. https://bugzilla.gnome.org/show_bug.cgi?id=776431
2016-12-23 06:41:57 +00:00
guint64 first_offset = dash_stream->sidx_parser.sidx.first_offset;
if (first_offset) {
GST_LOG_OBJECT (stream->pad,
"non-zero sidx first offset %" G_GUINT64_FORMAT, first_offset);
dash_stream->sidx_base_offset += first_offset;
}
dashdemux: Always parsing sidx for On-Demand profile The indexRange attribute is optional and if it's not present, we should extract the sidx box from incoming buffers. https://bugzilla.gnome.org/show_bug.cgi?id=776200
2016-12-20 02:16:11 +00:00
if (GST_CLOCK_TIME_IS_VALID (dash_stream->pending_seek_ts)) {
/* FIXME, preserve seek flags */
gst_dash_demux_stream_sidx_seek (dash_stream,
demux->segment.rate >= 0, 0, dash_stream->pending_seek_ts, NULL);
dashdemux: Do pending seek when SIDX is found Parsing SIDX box was allowed even if "indexRange" attribute does not appear for On-Demand profile. However, actual seeking using SIDX index did not happen since download loop keep working on. To use SIDX index in that case, demux should try it in the next download loop. https://bugzilla.gnome.org/show_bug.cgi?id=777394
2017-01-17 13:27:46 +00:00
/* push buffer up to sidx box, and do pending stream seek */
break;
dashdemux: Always parsing sidx for On-Demand profile The indexRange attribute is optional and if it's not present, we should extract the sidx box from incoming buffers. https://bugzilla.gnome.org/show_bug.cgi?id=776200
2016-12-20 02:16:11 +00:00
} else {
SIDX (dash_stream)->entry_index = dash_stream->sidx_index;
}
}
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
} else {
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
gst_byte_reader_skip (&reader, size - header_size);
}
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
dash_stream->isobmff_parser.current_fourcc = 0;
dash_stream->isobmff_parser.current_start_offset += size;
dash_stream->isobmff_parser.current_size = 0;
} while (gst_byte_reader_get_remaining (&reader) > 0);
gst_buffer_unmap (buffer, &map);
/* mdat? Push all we have and wait for it to be over */
if (dash_stream->isobmff_parser.current_fourcc == GST_ISOFF_FOURCC_MDAT) {
GstBuffer *pending;
GST_LOG_OBJECT (stream->pad,
"box %" GST_FOURCC_FORMAT " at offset %" G_GUINT64_FORMAT " size %"
G_GUINT64_FORMAT, GST_FOURCC_ARGS (fourcc),
dash_stream->isobmff_parser.current_offset +
gst_byte_reader_get_pos (&reader) - header_size,
dash_stream->isobmff_parser.current_size);
/* At mdat. Move the start of the mdat to the adapter and have everything
* else be pushed. We parsed all header boxes at this point and are not
* supposed to be called again until the next moof */
pending = _gst_buffer_split (buffer, gst_byte_reader_get_pos (&reader), -1);
gst_adapter_push (dash_stream->isobmff_adapter, pending);
dash_stream->isobmff_parser.current_offset +=
gst_byte_reader_get_pos (&reader);
dash_stream->isobmff_parser.current_size = 0;
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
GST_BUFFER_OFFSET (buffer) = buffer_offset;
GST_BUFFER_OFFSET_END (buffer) =
buffer_offset + gst_buffer_get_size (buffer);
return buffer;
} else if (gst_byte_reader_get_pos (&reader) != 0) {
GstBuffer *pending;
/* Multiple complete boxes and no mdat? Push them and keep the remainder,
* which is the start of the next box if any remainder */
pending = _gst_buffer_split (buffer, gst_byte_reader_get_pos (&reader), -1);
gst_adapter_push (dash_stream->isobmff_adapter, pending);
dash_stream->isobmff_parser.current_offset +=
gst_byte_reader_get_pos (&reader);
dash_stream->isobmff_parser.current_size = 0;
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
GST_BUFFER_OFFSET (buffer) = buffer_offset;
GST_BUFFER_OFFSET_END (buffer) =
buffer_offset + gst_buffer_get_size (buffer);
return buffer;
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
}
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
/* Not even a single complete, non-mdat box, wait */
dash_stream->isobmff_parser.current_size = 0;
gst_adapter_push (dash_stream->isobmff_adapter, buffer);
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
return NULL;
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
}
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
static gboolean
gst_dash_demux_find_sync_samples (GstAdaptiveDemux * demux,
GstAdaptiveDemuxStream * stream)
{
dashdemux: Remember if for a stream we could do key-units only mode This makes sure we don't even try going into that mode if we previously saw that the stream does not have the suitable metadata. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:32:50 +00:00
GstDashDemux *dashdemux = (GstDashDemux *) stream->demux;
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
GstDashDemuxStream *dash_stream = (GstDashDemuxStream *) stream;
guint i;
guint32 track_id = 0;
guint64 prev_traf_end;
dashdemux: Also allow key-unit only mode if (some) sample flags are given by trex but we can still find sync frames https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 08:54:21 +00:00
gboolean trex_sample_flags = FALSE;
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
dashdemux: Remember if for a stream we could do key-units only mode This makes sure we don't even try going into that mode if we previously saw that the stream does not have the suitable metadata. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:32:50 +00:00
if (!dash_stream->moof) {
dashdemux->allow_trickmode_key_units = FALSE;
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
return FALSE;
dashdemux: Remember if for a stream we could do key-units only mode This makes sure we don't even try going into that mode if we previously saw that the stream does not have the suitable metadata. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:32:50 +00:00
}
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
dash_stream->current_sync_sample = -1;
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
dash_stream->moof_sync_samples =
g_array_new (FALSE, FALSE, sizeof (GstDashStreamSyncSample));
prev_traf_end = dash_stream->moof_offset;
/* generate table of keyframes and offsets */
for (i = 0; i < dash_stream->moof->traf->len; i++) {
GstTrafBox *traf = &g_array_index (dash_stream->moof->traf, GstTrafBox, i);
guint64 traf_offset = 0, prev_trun_end;
guint j;
if (i == 0) {
track_id = traf->tfhd.track_id;
} else if (track_id != traf->tfhd.track_id) {
GST_ERROR_OBJECT (stream->pad,
"moof with trafs of different track ids (%u != %u)", track_id,
traf->tfhd.track_id);
g_array_free (dash_stream->moof_sync_samples, TRUE);
dash_stream->moof_sync_samples = NULL;
dashdemux: Remember if for a stream we could do key-units only mode This makes sure we don't even try going into that mode if we previously saw that the stream does not have the suitable metadata. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:32:50 +00:00
dashdemux->allow_trickmode_key_units = FALSE;
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
return FALSE;
}
if (traf->tfhd.flags & GST_TFHD_FLAGS_BASE_DATA_OFFSET_PRESENT) {
traf_offset = traf->tfhd.base_data_offset;
} else if (traf->tfhd.flags & GST_TFHD_FLAGS_DEFAULT_BASE_IS_MOOF) {
traf_offset = dash_stream->moof_offset;
} else {
traf_offset = prev_traf_end;
}
prev_trun_end = traf_offset;
for (j = 0; j < traf->trun->len; j++) {
GstTrunBox *trun = &g_array_index (traf->trun, GstTrunBox, j);
guint64 trun_offset, prev_sample_end;
guint k;
if (trun->flags & GST_TRUN_FLAGS_DATA_OFFSET_PRESENT) {
trun_offset = traf_offset + trun->data_offset;
} else {
trun_offset = prev_trun_end;
}
prev_sample_end = trun_offset;
for (k = 0; k < trun->samples->len; k++) {
GstTrunSample *sample =
&g_array_index (trun->samples, GstTrunSample, k);
guint64 sample_offset;
guint32 sample_flags;
#if 0
guint32 sample_duration;
#endif
sample_offset = prev_sample_end;
if (trun->flags & GST_TRUN_FLAGS_SAMPLE_FLAGS_PRESENT) {
sample_flags = sample->sample_flags;
} else if ((trun->flags & GST_TRUN_FLAGS_FIRST_SAMPLE_FLAGS_PRESENT)
&& k == 0) {
sample_flags = trun->first_sample_flags;
} else if (traf->
tfhd.flags & GST_TFHD_FLAGS_DEFAULT_SAMPLE_FLAGS_PRESENT) {
sample_flags = traf->tfhd.default_sample_flags;
} else {
dashdemux: Also allow key-unit only mode if (some) sample flags are given by trex but we can still find sync frames https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 08:54:21 +00:00
trex_sample_flags = TRUE;
continue;
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
}
#if 0
if (trun->flags & GST_TRUN_FLAGS_SAMPLE_DURATION_PRESENT) {
sample_duration = sample->sample_duration;
} else if (traf->
tfhd.flags & GST_TFHD_FLAGS_DEFAULT_SAMPLE_DURATION_PRESENT) {
sample_duration = traf->tfhd.default_sample_duration;
} else {
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
GST_FIXME_OBJECT (stream->pad,
"Sample duration given by trex - can't download only keyframes");
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
g_array_free (dash_stream->moof_sync_samples, TRUE);
dash_stream->moof_sync_samples = NULL;
return FALSE;
}
#endif
if (trun->flags & GST_TRUN_FLAGS_SAMPLE_SIZE_PRESENT) {
prev_sample_end += sample->sample_size;
} else if (traf->
tfhd.flags & GST_TFHD_FLAGS_DEFAULT_SAMPLE_SIZE_PRESENT) {
prev_sample_end += traf->tfhd.default_sample_size;
} else {
dashdemux: Implement downloading of only sync samples https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 09:09:34 +00:00
GST_FIXME_OBJECT (stream->pad,
"Sample size given by trex - can't download only keyframes");
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
g_array_free (dash_stream->moof_sync_samples, TRUE);
dash_stream->moof_sync_samples = NULL;
dashdemux: Remember if for a stream we could do key-units only mode This makes sure we don't even try going into that mode if we previously saw that the stream does not have the suitable metadata. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:32:50 +00:00
dashdemux->allow_trickmode_key_units = FALSE;
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
return FALSE;
}
/* Non-non-sync sample aka sync sample */
dashdemux: In KEY_UNITS trick mode, download all I-frames and not only IDR
2016-08-18 10:21:54 +00:00
if (!GST_ISOFF_SAMPLE_FLAGS_SAMPLE_IS_NON_SYNC_SAMPLE (sample_flags) ||
GST_ISOFF_SAMPLE_FLAGS_SAMPLE_DEPENDS_ON (sample_flags) == 2) {
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
GstDashStreamSyncSample sync_sample =
{ sample_offset, prev_sample_end - 1 };
/* TODO: need timestamps so we can decide to download or not */
g_array_append_val (dash_stream->moof_sync_samples, sync_sample);
}
}
prev_trun_end = prev_sample_end;
}
prev_traf_end = prev_trun_end;
}
dashdemux: Also allow key-unit only mode if (some) sample flags are given by trex but we can still find sync frames https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 08:54:21 +00:00
if (trex_sample_flags) {
if (dash_stream->moof_sync_samples->len > 0) {
GST_LOG_OBJECT (stream->pad,
"Some sample flags given by trex but still found sync samples");
} else {
GST_FIXME_OBJECT (stream->pad,
"Sample flags given by trex - can't download only keyframes");
g_array_free (dash_stream->moof_sync_samples, TRUE);
dash_stream->moof_sync_samples = NULL;
dashdemux: Remember if for a stream we could do key-units only mode This makes sure we don't even try going into that mode if we previously saw that the stream does not have the suitable metadata. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:32:50 +00:00
dashdemux->allow_trickmode_key_units = FALSE;
dashdemux: Also allow key-unit only mode if (some) sample flags are given by trex but we can still find sync frames https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 08:54:21 +00:00
return FALSE;
}
}
dashdemux: If a fragment contains no sync samples, disable key-unit mode https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-29 09:50:58 +00:00
if (dash_stream->moof_sync_samples->len == 0) {
GST_LOG_OBJECT (stream->pad, "No sync samples found in fragment");
g_array_free (dash_stream->moof_sync_samples, TRUE);
dash_stream->moof_sync_samples = NULL;
dashdemux->allow_trickmode_key_units = FALSE;
return FALSE;
}
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
{
GstDashStreamSyncSample *sync_sample =
&g_array_index (dash_stream->moof_sync_samples, GstDashStreamSyncSample,
0);
dashdemux: Collect average moof and first sync sample sizes And always request those in the beginning so that ideally we get the moof and the first sync sample all together with the first HTTP request. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:47:55 +00:00
guint size = sync_sample->end_offset + 1 - sync_sample->start_offset;
if (dash_stream->first_sync_sample_average_size) {
if (dash_stream->first_sync_sample_average_size < size)
dash_stream->first_sync_sample_average_size =
(size * 3 + dash_stream->first_sync_sample_average_size) / 4;
else
dash_stream->first_sync_sample_average_size =
(size + dash_stream->first_sync_sample_average_size * 3) / 4;
} else {
dash_stream->first_sync_sample_average_size = size;
}
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
if (dash_stream->moof_offset + dash_stream->moof_size + 8 <
sync_sample->start_offset) {
dash_stream->first_sync_sample_after_moof = FALSE;
dash_stream->first_sync_sample_always_after_moof = FALSE;
} else {
dashdemux: In KEY_UNITS trick mode, download all I-frames and not only IDR
2016-08-18 10:21:54 +00:00
dash_stream->first_sync_sample_after_moof =
(dash_stream->moof_sync_samples->len == 1
|| demux->segment.rate > 0.0);
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
}
}
dashdemux: Store parsed moof and extract offsets of sync samples in it https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-05-30 08:15:03 +00:00
return TRUE;
}
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
static GstFlowReturn
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
gst_dash_demux_handle_isobmff_buffer (GstAdaptiveDemux * demux,
adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-28 10:45:36 +00:00
GstAdaptiveDemuxStream * stream, GstBuffer * buffer)
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
{
GstDashDemuxStream *dash_stream = (GstDashDemuxStream *) stream;
dashdemux: don't meddle with the class struct from an instance Fix some very dubious code. The class methods should always be set, and the instance-specific check should then be done inside the method. For data_received that's there already, for finish_fragment we need to add it. https://bugzilla.gnome.org/show_bug.cgi?id=753937
2015-08-21 15:13:43 +00:00
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
GstFlowReturn ret = GST_FLOW_OK;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
dashdemux: Always parsing sidx for On-Demand profile The indexRange attribute is optional and if it's not present, we should extract the sidx box from incoming buffers. https://bugzilla.gnome.org/show_bug.cgi?id=776200
2016-12-20 02:16:11 +00:00
/* Parsing isobmff
* - TRICKMODE_KEY_UNITS can be supported and it's video stream
* - Or, it's On-Demand profile but index_uri for this stream (whatever video/audio)
* is not available, and sidx box was not parsed yet */
if ((dashdemux->allow_trickmode_key_units &&
dash_stream->active_stream->mimeType == GST_STREAM_VIDEO) ||
(gst_mpd_client_has_isoff_ondemand_profile (dashdemux->client) &&
dash_stream->sidx_parser.status != GST_ISOFF_SIDX_PARSER_FINISHED)) {
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
if (dash_stream->isobmff_parser.current_fourcc != GST_ISOFF_FOURCC_MDAT) {
buffer = gst_dash_demux_parse_isobmff (demux, dash_stream, buffer);
if (buffer
&& (ret =
gst_adaptive_demux_stream_push_buffer (stream,
buffer)) != GST_FLOW_OK)
return ret;
dashdemux: Do pending seek when SIDX is found Parsing SIDX box was allowed even if "indexRange" attribute does not appear for On-Demand profile. However, actual seeking using SIDX index did not happen since download loop keep working on. To use SIDX index in that case, demux should try it in the next download loop. https://bugzilla.gnome.org/show_bug.cgi?id=777394
2017-01-17 13:27:46 +00:00
/* Parser found sidx box now */
if (dash_stream->pending_seek_ts != GST_CLOCK_TIME_NONE &&
dash_stream->isobmff_parser.current_fourcc == GST_ISOFF_FOURCC_SIDX &&
dash_stream->sidx_parser.status == GST_ISOFF_SIDX_PARSER_FINISHED &&
gst_mpd_client_has_isoff_ondemand_profile (dashdemux->client)) {
GST_DEBUG_OBJECT (stream->pad,
"Found sidx box, return custom-success to do seeking now");
dash_stream->pending_seek_ts = GST_CLOCK_TIME_NONE;
/* Clear isobmff parser */
gst_adapter_clear (dash_stream->isobmff_adapter);
dash_stream->isobmff_parser.current_fourcc = 0;
dash_stream->isobmff_parser.current_start_offset = 0;
dash_stream->isobmff_parser.current_offset = -1;
dash_stream->isobmff_parser.current_size = 0;
return GST_ADAPTIVE_DEMUX_FLOW_END_OF_FRAGMENT;
}
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
if (dash_stream->isobmff_parser.current_fourcc != GST_ISOFF_FOURCC_MDAT)
return ret;
/* Jump to the next sync sample. As we're doing chunked downloading
* here, just drop data until our chunk is over so we can reuse the
* HTTP connection instead of having to create a new one or
* reuse the data if the sync sample follows the moof */
if (dash_stream->active_stream->mimeType == GST_STREAM_VIDEO
&& gst_dash_demux_find_sync_samples (demux, stream) &&
GST_ADAPTIVE_DEMUX (stream->demux)->
segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS) {
if (dash_stream->first_sync_sample_after_moof) {
/* If we're here, don't throw away data but collect sync
* sample while we're at it below. We're doing chunked
* downloading so might need to adjust the next chunk size for
* the remainder */
dash_stream->current_sync_sample = 0;
} else {
gst_adapter_clear (dash_stream->isobmff_adapter);
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
}
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
}
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
if (gst_adapter_available (dash_stream->isobmff_adapter) == 0)
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
return ret;
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
/* We have some data from the mdat available in the adapter, handle it
* below in the push code */
buffer =
gst_adapter_take_buffer (dash_stream->isobmff_adapter,
gst_adapter_available (dash_stream->isobmff_adapter));
} else {
if (dash_stream->isobmff_parser.current_offset == -1) {
dash_stream->isobmff_parser.current_offset =
GST_BUFFER_OFFSET_IS_VALID (buffer) ? GST_BUFFER_OFFSET (buffer) :
0;
}
}
/* At mdat and isobmff and trick modes are allowed */
/* We're actually running in key-units trick mode */
if (dash_stream->active_stream->mimeType == GST_STREAM_VIDEO
&& dash_stream->moof_sync_samples
&& GST_ADAPTIVE_DEMUX (stream->demux)->
segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS) {
if (dash_stream->current_sync_sample == -1) {
dashdemux: Use chunked downloading for the moof in KEY_UNITS mode Allows us to reuse the HTTP connection and reduce latencies a lot. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-07-12 17:09:52 +00:00
/* We're doing chunked downloading and wait for finishing the current
* chunk so we can jump to the first keyframe */
gst_buffer_unref (buffer);
return GST_FLOW_OK;
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
} else if (dash_stream->first_sync_sample_after_moof
&& dash_stream->current_sync_sample == 0) {
GstDashStreamSyncSample *sync_sample =
&g_array_index (dash_stream->moof_sync_samples,
GstDashStreamSyncSample, 0);
guint64 end_offset =
dash_stream->isobmff_parser.current_offset +
gst_buffer_get_size (buffer);
/* If the first keyframe follows directly the moof and we're
* downloading it here, make sure to not download too much */
if (end_offset > sync_sample->end_offset + 1) {
guint64 remaining =
sync_sample->end_offset + 1 -
dash_stream->isobmff_parser.current_offset;
if (remaining) {
GstBuffer *sub =
gst_buffer_copy_region (buffer, GST_BUFFER_COPY_ALL, 0,
remaining);
gst_buffer_unref (buffer);
buffer = sub;
} else {
gst_buffer_unref (buffer);
return GST_FLOW_OK;
}
}
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
}
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
}
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
GST_BUFFER_OFFSET (buffer) = dash_stream->isobmff_parser.current_offset;
dash_stream->isobmff_parser.current_offset += gst_buffer_get_size (buffer);
GST_BUFFER_OFFSET_END (buffer) = dash_stream->isobmff_parser.current_offset;
dashdemux: Drain remaining buffer in adapter Previous patch allows sidx box parsing from incoming buffers. Since the incoming buffer boundary might be over sidx box, there can be remaining buffer in isobmff parser adapter. https://bugzilla.gnome.org/show_bug.cgi?id=776352
2016-12-21 14:24:48 +00:00
} else if (gst_adapter_available (dash_stream->isobmff_adapter) > 0) {
guint64 offset;
/* Drain adapter */
gst_adapter_push (dash_stream->isobmff_adapter, buffer);
buffer =
gst_adapter_take_buffer (dash_stream->isobmff_adapter,
gst_adapter_available (dash_stream->isobmff_adapter));
/* Set buffer offset based on the last parser's offset */
offset = dash_stream->isobmff_parser.current_offset;
GST_BUFFER_OFFSET (buffer) = offset;
GST_BUFFER_OFFSET_END (buffer) = offset + gst_buffer_get_size (buffer);
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
}
return gst_adaptive_demux_stream_push_buffer (stream, buffer);
}
static GstFlowReturn
gst_dash_demux_data_received (GstAdaptiveDemux * demux,
GstAdaptiveDemuxStream * stream, GstBuffer * buffer)
{
GstDashDemuxStream *dash_stream = (GstDashDemuxStream *) stream;
GstDashDemux *dashdemux = GST_DASH_DEMUX_CAST (demux);
GstFlowReturn ret = GST_FLOW_OK;
guint index_header_or_data;
if (!gst_mpd_client_has_isoff_ondemand_profile (dashdemux->client)) {
if (dash_stream->is_isobmff)
return gst_dash_demux_handle_isobmff_buffer (demux, stream, buffer);
else
return gst_adaptive_demux_stream_push_buffer (stream, buffer);
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
}
adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-28 10:45:36 +00:00
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
if (stream->downloading_index)
index_header_or_data = 1;
else if (stream->downloading_header)
index_header_or_data = 2;
else
index_header_or_data = 3;
if (dash_stream->sidx_index_header_or_data != index_header_or_data) {
/* Clear pending data */
if (gst_adapter_available (dash_stream->sidx_adapter) != 0)
GST_ERROR_OBJECT (stream->pad,
"Had pending SIDX data after switch between index/header/data");
gst_adapter_clear (dash_stream->sidx_adapter);
dash_stream->sidx_index_header_or_data = index_header_or_data;
dash_stream->sidx_current_offset = -1;
}
if (dash_stream->sidx_current_offset == -1)
dash_stream->sidx_current_offset =
GST_BUFFER_OFFSET_IS_VALID (buffer) ? GST_BUFFER_OFFSET (buffer) : 0;
adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-28 10:45:36 +00:00
gst_adapter_push (dash_stream->sidx_adapter, buffer);
buffer = NULL;
dashdemux: don't meddle with the class struct from an instance Fix some very dubious code. The class methods should always be set, and the instance-specific check should then be done inside the method. For data_received that's there already, for finish_fragment we need to add it. https://bugzilla.gnome.org/show_bug.cgi?id=753937
2015-08-21 15:13:43 +00:00
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
if (stream->downloading_index) {
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
GstIsoffParserResult res;
guint consumed;
adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-28 10:45:36 +00:00
gsize available;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-28 10:45:36 +00:00
available = gst_adapter_available (dash_stream->sidx_adapter);
buffer = gst_adapter_take_buffer (dash_stream->sidx_adapter, available);
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
if (dash_stream->sidx_parser.status != GST_ISOFF_SIDX_PARSER_FINISHED) {
res =
gst_isoff_sidx_parser_add_buffer (&dash_stream->sidx_parser, buffer,
&consumed);
if (res == GST_ISOFF_PARSER_ERROR) {
} else if (res == GST_ISOFF_PARSER_UNEXPECTED) {
/* this is not a 'sidx' index, just skip it and continue playback */
} else {
/* when finished, prepare for real data streaming */
if (dash_stream->sidx_parser.status == GST_ISOFF_SIDX_PARSER_FINISHED) {
if (GST_CLOCK_TIME_IS_VALID (dash_stream->pending_seek_ts)) {
adaptivedemux: handle snap seeks Adaptive demuxers need to start downloading from specific positions (fragments) for every stream, this means that all streams can snap-seek to a different position when requested. Snap seeking in this case will be done in 2 steps: 1) do the snap seeking on the pad that received the seek event and get the final position 2) use this position to do a regular seek on the other streams to make sure they all start from the same position More arguments were added to the stream_seek function, allowing better control of how seeking is done. Knowing the flags and the playback direction allows subclasses to handle snap-seeking. And also adds a new return parameter to inform of the final selected seeking position that is used to align the other streams. https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-01-27 16:31:10 +00:00
/* FIXME, preserve seek flags */
dashdemux: implement snap seek handling Handle snap seeking at the stream_seek method and let superclass do the rest to support snap seeking https://bugzilla.gnome.org/show_bug.cgi?id=759158
2016-02-01 13:49:23 +00:00
gst_dash_demux_stream_sidx_seek (dash_stream,
demux->segment.rate >= 0, 0, dash_stream->pending_seek_ts,
NULL);
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
dash_stream->pending_seek_ts = GST_CLOCK_TIME_NONE;
} else {
SIDX (dash_stream)->entry_index = dash_stream->sidx_index;
}
} else if (consumed < available) {
GstBuffer *pending;
/* we still need to keep some data around for the next parsing round
* so just push what was already processed by the parser */
pending = _gst_buffer_split (buffer, consumed, -1);
adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-28 10:45:36 +00:00
gst_adapter_push (dash_stream->sidx_adapter, pending);
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
}
}
}
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
GST_BUFFER_OFFSET (buffer) = dash_stream->sidx_current_offset;
GST_BUFFER_OFFSET_END (buffer) =
GST_BUFFER_OFFSET (buffer) + gst_buffer_get_size (buffer);
dash_stream->sidx_current_offset = GST_BUFFER_OFFSET_END (buffer);
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
ret = gst_adaptive_demux_stream_push_buffer (stream, buffer);
} else if (dash_stream->sidx_parser.status == GST_ISOFF_SIDX_PARSER_FINISHED) {
adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-28 10:45:36 +00:00
gsize available;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
while (ret == GST_FLOW_OK
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
&& ((available =
gst_adapter_available (dash_stream->sidx_adapter)) > 0)) {
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
gboolean advance = FALSE;
dashdemux: Implement SIDX tracking based on buffer offset This simplifies the code but also removes a bug with tracking of the remaining size for the initial subfragment: we were not considering the size between the index and the start of the first moof here. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-05-27 13:08:09 +00:00
guint64 sidx_end_offset =
dash_stream->sidx_base_offset +
SIDX_CURRENT_ENTRY (dash_stream)->offset +
SIDX_CURRENT_ENTRY (dash_stream)->size;
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
dashdemux: Implement SIDX tracking based on buffer offset This simplifies the code but also removes a bug with tracking of the remaining size for the initial subfragment: we were not considering the size between the index and the start of the first moof here. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-05-27 13:08:09 +00:00
if (dash_stream->sidx_current_offset + available < sidx_end_offset) {
adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-28 10:45:36 +00:00
buffer = gst_adapter_take_buffer (dash_stream->sidx_adapter, available);
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
} else {
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
/* In key-units mode, we advance the fragments manually once the
* current key-unit is over but throw away all data that is after
* the current sidx entry end */
if (dash_stream->moof_sync_samples
&& (GST_ADAPTIVE_DEMUX (stream->demux)->
segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS)) {
if (sidx_end_offset <= dash_stream->sidx_current_offset) {
buffer = NULL;
gst_adapter_clear (dash_stream->sidx_adapter);
} else {
buffer =
gst_adapter_take_buffer (dash_stream->sidx_adapter,
sidx_end_offset - dash_stream->sidx_current_offset);
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
}
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
} else {
buffer =
gst_adapter_take_buffer (dash_stream->sidx_adapter,
sidx_end_offset - dash_stream->sidx_current_offset);
advance = TRUE;
dashdemux: Implement parsing of moof box https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-04-07 18:33:51 +00:00
}
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
}
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
if (buffer != NULL) {
GST_BUFFER_OFFSET (buffer) = dash_stream->sidx_current_offset;
GST_BUFFER_OFFSET_END (buffer) =
GST_BUFFER_OFFSET (buffer) + gst_buffer_get_size (buffer);
dash_stream->sidx_current_offset = GST_BUFFER_OFFSET_END (buffer);
if (dash_stream->is_isobmff)
ret = gst_dash_demux_handle_isobmff_buffer (demux, stream, buffer);
else
ret = gst_adaptive_demux_stream_push_buffer (stream, buffer);
if (!(dash_stream->moof_sync_samples
&& (GST_ADAPTIVE_DEMUX (stream->demux)->
segment.flags & GST_SEGMENT_FLAG_TRICKMODE_KEY_UNITS))
&& advance) {
dashdemux: Advance subfragment only if any exist SIDX based playback is not restricted to SegmentBase, but it possible with SegmentList/SegmentTemplate. In the latter case, each fragment has its own SIDX box and might be subdivided into subfragment. So, demux should not assume that the end of subfragment is the end of stream. Moreover, should try advance subfragment only if there are remaining subfragments. With additional fixes by Sebastian Dröge <sebastian@centricular.com> https://bugzilla.gnome.org/show_bug.cgi?id=776200
2017-03-07 12:56:03 +00:00
if (gst_dash_demux_stream_has_next_subfragment (stream)) {
GstFlowReturn new_ret;
new_ret =
gst_adaptive_demux_stream_advance_fragment (demux, stream,
SIDX_CURRENT_ENTRY (dash_stream)->duration);
/* only overwrite if it was OK before */
if (ret == GST_FLOW_OK)
ret = new_ret;
} else {
break;
}
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
}
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
}
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
}
adaptivedemux: refactor chunk downloading flow Add more power to the chunk_received function (renamed to data_received) and also to the fragment_finish function. The data_received function must parse/decrypt the data if necessary and also push it using the new push_buffer function that is exposed now. The default implementation gets data from the stream adapter (all available) and pushes it. The fragment_finish function must also advance the fragment. The default implementation only advances the fragment. This allows the subsegment handling in dashdemux to continuously download the same file from the server instead of stopping at every subsegment boundary and starting a new request
2015-01-15 20:44:45 +00:00
} else {
/* this should be the main header, just push it all */
dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-31 10:39:59 +00:00
buffer = gst_adapter_take_buffer (dash_stream->sidx_adapter,
gst_adapter_available (dash_stream->sidx_adapter));
GST_BUFFER_OFFSET (buffer) = dash_stream->sidx_current_offset;
GST_BUFFER_OFFSET_END (buffer) =
GST_BUFFER_OFFSET (buffer) + gst_buffer_get_size (buffer);
dash_stream->sidx_current_offset = GST_BUFFER_OFFSET_END (buffer);
dashdemux: Download any sync-sample following the moof directly in key-units only mode We don't have to do yet another additional request but can just download the data directly. Also unify the key-unit only mode buffer pushing and extract it into its own function now that it became more complicated. https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-02 05:35:26 +00:00
if (dash_stream->is_isobmff)
return gst_dash_demux_handle_isobmff_buffer (demux, stream, buffer);
else
return gst_adaptive_demux_stream_push_buffer (stream, buffer);
dashdemux: implement ISOBMFF profile handling The ISOBMFF profile allows definind subsegments in a segment. At those subsegment boundaries the client can switch from one representation to another as they have aligned indexes. To handle those the 'sidx' index is parsed from the stream and the entries point to pts/offset of the samples in the stream. Knowing that the entries are aligned in the different representation allows the client to switch mid fragment. In this profile a single fragment is used per representation and the subsegments are contained in this fragment. To notify the superclass about the subsegment boundary the chunk_received function returns a special flow return that indicates that. In this case, the super class will check if a more suitable bitrate is available and will change to the same subsegment in this new representation. It also requires special handling of the position in the stream as the fragment advancing is now done by incrementing the index of the subsegment. It will only advance to the next fragment once all subsegments have been downloaded. https://bugzilla.gnome.org/show_bug.cgi?id=741248
2015-01-12 20:40:47 +00:00
}
return ret;
dashdemux: parse the sidx index from isobmff streams Allows dashdemux to identify the subsegments in the stream and switch bitrates when needed
2015-01-12 14:57:02 +00:00
}
static void
gst_dash_demux_stream_free (GstAdaptiveDemuxStream * stream)
{
GstDashDemuxStream *dash_stream = (GstDashDemuxStream *) stream;
gst_isoff_sidx_parser_clear (&dash_stream->sidx_parser);
adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets. https://bugzilla.gnome.org/show_bug.cgi?id=764684
2016-03-28 10:45:36 +00:00
if (dash_stream->sidx_adapter)
g_object_unref (dash_stream->sidx_adapter);
dashdemux: Implement parsing of ISOBMFF boxes https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-03-28 10:45:36 +00:00
if (dash_stream->isobmff_adapter)
g_object_unref (dash_stream->isobmff_adapter);
dashdemux: Fix leak in gst_dash_demux_stream_free Free parsed moof and sync samples with _stream_free(). https://bugzilla.gnome.org/show_bug.cgi?id=774702
2016-11-19 07:12:06 +00:00
if (dash_stream->moof)
gst_isoff_moof_box_free (dash_stream->moof);
if (dash_stream->moof_sync_samples)
g_array_free (dash_stream->moof_sync_samples, TRUE);
dashdemux: Fix issue when manifest update sets slow start without passing necessary header & caps changes downstream https://bugzilla.gnome.org/show_bug.cgi?id=777206
2017-01-17 02:33:03 +00:00
g_free (dash_stream->last_representation_id);
dashdemux: parse the sidx index from isobmff streams Allows dashdemux to identify the subsegments in the stream and switch bitrates when needed
2015-01-12 14:57:02 +00:00
}
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
static GstDashDemuxClockDrift *
adaptivedemux: use GstSystemClock to all real-time calculations A realtime clock is used in many places, such as deciding which fragment to select at start up and deciding how long to sleep before a fragment becomes available. For example dashdemux needs sample the client's estimate of UTC when selecting where to start in a live DASH stream. The problem with dashdemux calculating the client's idea of UTC is that it makes it difficult to create unit tests, because the passage of time is a factor in the test. This commit changes dashdemux and adaptivedemux to use the GstSystemClock, so that a unit test can replace the system clock when it needs to be able to control the clock. This commit makes no change to the behaviour under normal usage, as GstSystemClock is based upon the system time. https://bugzilla.gnome.org/show_bug.cgi?id=762147
2016-02-16 14:44:10 +00:00
gst_dash_demux_clock_drift_new (GstDashDemux * demux)
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
{
GstDashDemuxClockDrift *clock_drift;
clock_drift = g_slice_new0 (GstDashDemuxClockDrift);
g_mutex_init (&clock_drift->clock_lock);
adaptivedemux: use GstSystemClock to all real-time calculations A realtime clock is used in many places, such as deciding which fragment to select at start up and deciding how long to sleep before a fragment becomes available. For example dashdemux needs sample the client's estimate of UTC when selecting where to start in a live DASH stream. The problem with dashdemux calculating the client's idea of UTC is that it makes it difficult to create unit tests, because the passage of time is a factor in the test. This commit changes dashdemux and adaptivedemux to use the GstSystemClock, so that a unit test can replace the system clock when it needs to be able to control the clock. This commit makes no change to the behaviour under normal usage, as GstSystemClock is based upon the system time. https://bugzilla.gnome.org/show_bug.cgi?id=762147
2016-02-16 14:44:10 +00:00
clock_drift->next_update =
GST_TIME_AS_USECONDS (gst_adaptive_demux_get_monotonic_time
(GST_ADAPTIVE_DEMUX_CAST (demux)));
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
return clock_drift;
}
static void
gst_dash_demux_clock_drift_free (GstDashDemuxClockDrift * clock_drift)
{
if (clock_drift) {
g_mutex_lock (&clock_drift->clock_lock);
if (clock_drift->ntp_clock)
g_object_unref (clock_drift->ntp_clock);
g_mutex_unlock (&clock_drift->clock_lock);
g_mutex_clear (&clock_drift->clock_lock);
g_slice_free (GstDashDemuxClockDrift, clock_drift);
}
}
dashdemux: post-review fixup of UTCTiming element This commit addresses the following items from the code review: use a portable way to define NTP_TO_UNIX_EPOCH, fix memory leak on error, and add documentation to UTCTiming parse functions Using LL is not portable, so the G_GUINT64_CONSTANT needs to be instead. If an error occurs during DNS resolution, the GError was not being released, causing a memory leak. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-13 17:21:29 +00:00
/*
* The value attribute of the UTCTiming element contains a white-space
* separated list of servers that are recommended to be used in
* combination with the NTP protocol as defined in IETF RFC 5905 for
* getting the appropriate time.
*
* The DASH standard does not specify which version of NTP. This
* function only works with NTPv4 servers.
*/
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
static GstDateTime *
gst_dash_demux_poll_ntp_server (GstDashDemuxClockDrift * clock_drift,
gchar ** urls)
{
GstClockTime ntp_clock_time;
GDateTime *dt, *dt2;
if (!clock_drift->ntp_clock) {
GResolver *resolver;
GList *inet_addrs;
GError *err;
gchar *ip_addr;
resolver = g_resolver_get_default ();
/* We don't round-robin NTP servers. If the manifest specifies multiple
NTP time servers, select one at random */
clock_drift->selected_url = g_random_int_range (0, g_strv_length (urls));
GST_DEBUG ("Connecting to NTP time server %s",
urls[clock_drift->selected_url]);
inet_addrs = g_resolver_lookup_by_name (resolver,
urls[clock_drift->selected_url], NULL, &err);
g_object_unref (resolver);
if (!inet_addrs || g_list_length (inet_addrs) == 0) {
dashdemux: post-review fixup of UTCTiming element This commit addresses the following items from the code review: use a portable way to define NTP_TO_UNIX_EPOCH, fix memory leak on error, and add documentation to UTCTiming parse functions Using LL is not portable, so the G_GUINT64_CONSTANT needs to be instead. If an error occurs during DNS resolution, the GError was not being released, causing a memory leak. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-13 17:21:29 +00:00
GST_ERROR ("Failed to resolve hostname of NTP server: %s",
err ? (err->message) : "unknown error");
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
if (inet_addrs)
g_resolver_free_addresses (inet_addrs);
dashdemux: post-review fixup of UTCTiming element This commit addresses the following items from the code review: use a portable way to define NTP_TO_UNIX_EPOCH, fix memory leak on error, and add documentation to UTCTiming parse functions Using LL is not portable, so the G_GUINT64_CONSTANT needs to be instead. If an error occurs during DNS resolution, the GError was not being released, causing a memory leak. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-13 17:21:29 +00:00
if (err)
g_error_free (err);
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
return NULL;
}
ip_addr =
g_inet_address_to_string ((GInetAddress
*) (g_list_first (inet_addrs)->data));
clock_drift->ntp_clock = gst_ntp_clock_new ("dashntp", ip_addr, 123, 0);
g_free (ip_addr);
g_resolver_free_addresses (inet_addrs);
if (!clock_drift->ntp_clock) {
GST_ERROR ("Failed to create NTP clock");
return NULL;
}
if (!gst_clock_wait_for_sync (clock_drift->ntp_clock, 5 * GST_SECOND)) {
g_object_unref (clock_drift->ntp_clock);
clock_drift->ntp_clock = NULL;
GST_ERROR ("Failed to lock to NTP clock");
return NULL;
}
}
ntp_clock_time = gst_clock_get_time (clock_drift->ntp_clock);
if (ntp_clock_time == GST_CLOCK_TIME_NONE) {
GST_ERROR ("Failed to get time from NTP clock");
return NULL;
}
ntp_clock_time -= NTP_TO_UNIX_EPOCH * GST_SECOND;
dt = g_date_time_new_from_unix_utc (ntp_clock_time / GST_SECOND);
if (!dt) {
GST_ERROR ("Failed to create GstDateTime");
return NULL;
}
ntp_clock_time =
gst_util_uint64_scale (ntp_clock_time % GST_SECOND, 1000000, GST_SECOND);
dt2 = g_date_time_add (dt, ntp_clock_time);
g_date_time_unref (dt);
return gst_date_time_new_from_g_date_time (dt2);
}
dashdemux: accept 2 or 4 digit year when using HTTP HEAD for calculating clock compensation Convert year from 2 digits to 4 digits in gst_dash_demux_parse_http_head https://bugzilla.gnome.org/show_bug.cgi?id=759743 Also updated references to Rfc822 to Rfc5322
2015-12-21 14:50:15 +00:00
struct Rfc5322TimeZone
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
{
const gchar *name;
gfloat tzoffset;
};
/*
dashdemux: accept 2 or 4 digit year when using HTTP HEAD for calculating clock compensation Convert year from 2 digits to 4 digits in gst_dash_demux_parse_http_head https://bugzilla.gnome.org/show_bug.cgi?id=759743 Also updated references to Rfc822 to Rfc5322
2015-12-21 14:50:15 +00:00
Parse an RFC5322 (section 3.3) date-time from the Date: field in the
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
HTTP response.
dashdemux: accept 2 or 4 digit year when using HTTP HEAD for calculating clock compensation Convert year from 2 digits to 4 digits in gst_dash_demux_parse_http_head https://bugzilla.gnome.org/show_bug.cgi?id=759743 Also updated references to Rfc822 to Rfc5322
2015-12-21 14:50:15 +00:00
See https://tools.ietf.org/html/rfc5322#section-3.3
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
*/
static GstDateTime *
gst_dash_demux_parse_http_head (GstDashDemuxClockDrift * clock_drift,
GstFragment * download)
{
static const gchar *months[] = { NULL, "Jan", "Feb", "Mar", "Apr",
"May", "Jun", "Jul", "Aug",
"Sep", "Oct", "Nov", "Dec", NULL
};
dashdemux: accept 2 or 4 digit year when using HTTP HEAD for calculating clock compensation Convert year from 2 digits to 4 digits in gst_dash_demux_parse_http_head https://bugzilla.gnome.org/show_bug.cgi?id=759743 Also updated references to Rfc822 to Rfc5322
2015-12-21 14:50:15 +00:00
static const struct Rfc5322TimeZone timezones[] = {
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
{"Z", 0},
{"UT", 0},
{"GMT", 0},
{"BST", 1},
{"EST", -5},
{"EDT", -4},
{"CST", -6},
{"CDT", -5},
{"MST", -7},
{"MDT", -6},
{"PST", -8},
{"PDT", -7},
{NULL, 0}
};
GstDateTime *value = NULL;
const GstStructure *response_headers;
const gchar *http_date;
const GValue *val;
gint ret;
const gchar *pos;
gint year = -1, month = -1, day = -1, hour = -1, minute = -1, second = -1;
gchar zone[6];
gchar monthstr[4];
gfloat tzoffset = 0;
gboolean parsed_tz = FALSE;
g_return_val_if_fail (download != NULL, NULL);
g_return_val_if_fail (download->headers != NULL, NULL);
val = gst_structure_get_value (download->headers, "response-headers");
if (!val) {
return NULL;
}
response_headers = gst_value_get_structure (val);
http_date = gst_structure_get_string (response_headers, "Date");
if (!http_date) {
return NULL;
}
/* skip optional text version of day of the week */
pos = strchr (http_date, ',');
if (pos)
pos++;
else
pos = http_date;
ret =
sscanf (pos, "%02d %3s %04d %02d:%02d:%02d %5s", &day, monthstr, &year,
&hour, &minute, &second, zone);
if (ret == 7) {
gchar *z = zone;
dashdemux: Don't declare variables inside the for loop header This is a C99 feature.
2016-12-13 20:21:25 +00:00
gint i;
for (i = 1; months[i]; ++i) {
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
if (g_ascii_strncasecmp (months[i], monthstr, strlen (months[i])) == 0) {
month = i;
break;
}
}
dashdemux: Don't declare variables inside the for loop header This is a C99 feature.
2016-12-13 20:21:25 +00:00
for (i = 0; timezones[i].name && !parsed_tz; ++i) {
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
if (g_ascii_strncasecmp (timezones[i].name, z,
strlen (timezones[i].name)) == 0) {
tzoffset = timezones[i].tzoffset;
parsed_tz = TRUE;
}
}
if (!parsed_tz) {
gint hh, mm;
gboolean neg = FALSE;
/* check if it is in the form +-HHMM */
if (*z == '+' || *z == '-') {
if (*z == '+')
++z;
else if (*z == '-') {
++z;
neg = TRUE;
}
ret = sscanf (z, "%02d%02d", &hh, &mm);
if (ret == 2) {
tzoffset = hh;
tzoffset += mm / 60.0;
if (neg)
tzoffset = -tzoffset;
parsed_tz = TRUE;
}
}
}
dashdemux: accept 2 or 4 digit year when using HTTP HEAD for calculating clock compensation Convert year from 2 digits to 4 digits in gst_dash_demux_parse_http_head https://bugzilla.gnome.org/show_bug.cgi?id=759743 Also updated references to Rfc822 to Rfc5322
2015-12-21 14:50:15 +00:00
/* Accept year in both 2 digit or 4 digit format */
if (year < 100)
year += 2000;
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
}
if (month > 0 && parsed_tz) {
value = gst_date_time_new (tzoffset,
year, month, day, hour, minute, second);
}
return value;
}
dashdemux: post-review fixup of UTCTiming element This commit addresses the following items from the code review: use a portable way to define NTP_TO_UNIX_EPOCH, fix memory leak on error, and add documentation to UTCTiming parse functions Using LL is not portable, so the G_GUINT64_CONSTANT needs to be instead. If an error occurs during DNS resolution, the GError was not being released, causing a memory leak. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-13 17:21:29 +00:00
/*
The timing information is contained in the message body of the HTTP
response and contains a time value formatted according to NTP timestamp
format in IETF RFC 5905.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Timestamp Format
*/
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
static GstDateTime *
gst_dash_demux_parse_http_ntp (GstDashDemuxClockDrift * clock_drift,
GstBuffer * buffer)
{
gint64 seconds;
guint64 fraction;
GDateTime *dt, *dt2;
GstMapInfo mapinfo;
/* See https://tools.ietf.org/html/rfc5905#page-12 for details of
the NTP Timestamp Format */
gst_buffer_map (buffer, &mapinfo, GST_MAP_READ);
if (mapinfo.size != 8) {
gst_buffer_unmap (buffer, &mapinfo);
return NULL;
}
seconds = GST_READ_UINT32_BE (mapinfo.data);
fraction = GST_READ_UINT32_BE (mapinfo.data + 4);
gst_buffer_unmap (buffer, &mapinfo);
fraction = gst_util_uint64_scale (fraction, 1000000,
G_GUINT64_CONSTANT (1) << 32);
/* subtract constant to convert from 1900 based time to 1970 based time */
seconds -= NTP_TO_UNIX_EPOCH;
dt = g_date_time_new_from_unix_utc (seconds);
dt2 = g_date_time_add (dt, fraction);
g_date_time_unref (dt);
return gst_date_time_new_from_g_date_time (dt2);
}
dashdemux: post-review fixup of UTCTiming element This commit addresses the following items from the code review: use a portable way to define NTP_TO_UNIX_EPOCH, fix memory leak on error, and add documentation to UTCTiming parse functions Using LL is not portable, so the G_GUINT64_CONSTANT needs to be instead. If an error occurs during DNS resolution, the GError was not being released, causing a memory leak. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-13 17:21:29 +00:00
/*
The timing information is contained in the message body of the
HTTP response and contains a time value formatted according to
xs:dateTime as defined in W3C XML Schema Part 2: Datatypes specification.
*/
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
static GstDateTime *
gst_dash_demux_parse_http_xsdate (GstDashDemuxClockDrift * clock_drift,
GstBuffer * buffer)
{
dashdemux: correctly handle an HTTP-XSDATE that is exactly the size of the date string The code in the gst_dash_demux_parse_http_xsdate() was trying to handle the case where the string is not null terminated by resizing the buffer and appending a zero byte. This does not work if the buffer is exactly the length of the string because the gst_buffer_resize() function does not re-allocate the buffer, it just changes its size. If a buffer is passed to gst_dash_demux_parse_http_xsdate() that is exactly the length of the string, the function fails with an assert failure in gst_buffer_resize(). https://bugzilla.gnome.org/show_bug.cgi?id=762148
2016-02-23 10:49:40 +00:00
GstDateTime *value = NULL;
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
GstMapInfo mapinfo;
/* the string from the server might not be zero terminated */
dashdemux: correctly handle an HTTP-XSDATE that is exactly the size of the date string The code in the gst_dash_demux_parse_http_xsdate() was trying to handle the case where the string is not null terminated by resizing the buffer and appending a zero byte. This does not work if the buffer is exactly the length of the string because the gst_buffer_resize() function does not re-allocate the buffer, it just changes its size. If a buffer is passed to gst_dash_demux_parse_http_xsdate() that is exactly the length of the string, the function fails with an assert failure in gst_buffer_resize(). https://bugzilla.gnome.org/show_bug.cgi?id=762148
2016-02-23 10:49:40 +00:00
if (gst_buffer_map (buffer, &mapinfo, GST_MAP_READ)) {
gchar *str;
str = g_strndup ((const gchar *) mapinfo.data, mapinfo.size);
gst_buffer_unmap (buffer, &mapinfo);
value = gst_date_time_new_from_iso8601_string (str);
g_free (str);
}
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
return value;
}
static gboolean
gst_dash_demux_poll_clock_drift (GstDashDemux * demux)
{
GstDashDemuxClockDrift *clock_drift;
GDateTime *start = NULL, *end;
GstBuffer *buffer = NULL;
GstDateTime *value = NULL;
gboolean ret = FALSE;
gint64 now;
GstMPDUTCTimingType method;
gchar **urls;
g_return_val_if_fail (demux != NULL, FALSE);
g_return_val_if_fail (demux->clock_drift != NULL, FALSE);
clock_drift = demux->clock_drift;
adaptivedemux: use GstSystemClock to all real-time calculations A realtime clock is used in many places, such as deciding which fragment to select at start up and deciding how long to sleep before a fragment becomes available. For example dashdemux needs sample the client's estimate of UTC when selecting where to start in a live DASH stream. The problem with dashdemux calculating the client's idea of UTC is that it makes it difficult to create unit tests, because the passage of time is a factor in the test. This commit changes dashdemux and adaptivedemux to use the GstSystemClock, so that a unit test can replace the system clock when it needs to be able to control the clock. This commit makes no change to the behaviour under normal usage, as GstSystemClock is based upon the system time. https://bugzilla.gnome.org/show_bug.cgi?id=762147
2016-02-16 14:44:10 +00:00
now =
GST_TIME_AS_USECONDS (gst_adaptive_demux_get_monotonic_time
(GST_ADAPTIVE_DEMUX_CAST (demux)));
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
if (now < clock_drift->next_update) {
/*TODO: If a fragment fails to download in adaptivedemux, it waits
for a manifest reload before another attempt to fetch a fragment.
Section 10.8.6 of the DVB-DASH standard states that the DASH client
shall refresh the manifest and resynchronise to one of the time sources.
Currently the fact that the manifest refresh follows a download failure
does not make it into dashdemux. */
return TRUE;
}
urls = gst_mpd_client_get_utc_timing_sources (demux->client,
SUPPORTED_CLOCK_FORMATS, &method);
if (!urls) {
return FALSE;
}
/* Update selected_url just in case the number of URLs in the UTCTiming
element has shrunk since the last poll */
clock_drift->selected_url = clock_drift->selected_url % g_strv_length (urls);
g_mutex_lock (&clock_drift->clock_lock);
if (method == GST_MPD_UTCTIMING_TYPE_NTP) {
value = gst_dash_demux_poll_ntp_server (clock_drift, urls);
if (!value) {
GST_ERROR_OBJECT (demux, "Failed to fetch time from NTP server %s",
urls[clock_drift->selected_url]);
g_mutex_unlock (&clock_drift->clock_lock);
goto quit;
}
}
adaptivedemux: use GstSystemClock to all real-time calculations A realtime clock is used in many places, such as deciding which fragment to select at start up and deciding how long to sleep before a fragment becomes available. For example dashdemux needs sample the client's estimate of UTC when selecting where to start in a live DASH stream. The problem with dashdemux calculating the client's idea of UTC is that it makes it difficult to create unit tests, because the passage of time is a factor in the test. This commit changes dashdemux and adaptivedemux to use the GstSystemClock, so that a unit test can replace the system clock when it needs to be able to control the clock. This commit makes no change to the behaviour under normal usage, as GstSystemClock is based upon the system time. https://bugzilla.gnome.org/show_bug.cgi?id=762147
2016-02-16 14:44:10 +00:00
start =
gst_adaptive_demux_get_client_now_utc (GST_ADAPTIVE_DEMUX_CAST (demux));
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
if (!value) {
GstFragment *download;
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
gint64 range_start = 0, range_end = -1;
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
GST_DEBUG_OBJECT (demux, "Fetching current time from %s",
urls[clock_drift->selected_url]);
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
if (method == GST_MPD_UTCTIMING_TYPE_HTTP_HEAD) {
range_start = -1;
}
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
download =
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
gst_uri_downloader_fetch_uri_with_range (GST_ADAPTIVE_DEMUX_CAST
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
(demux)->downloader, urls[clock_drift->selected_url], NULL, TRUE, TRUE,
dashdemux: add support for HTTP HEAD method of time sync The urn:mpeg:dash:utc:http-head:2014 method of time synchronisation uses an HTTP HEAD request to a specified URL and then parses the Date: HTTP response header. This commit adds support to dashdemux for this method of time synchronisation by making a HEAD request and then parsing the Date: response. This commit adds support to gstfragment to return the HTTP headers and to uridownloader to support HEAD requests. To avoid creating a new API, the RANGE get function is re-used (abused?) with start=-1 and end=-1 to indicate a HEAD request. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-08-14 08:44:24 +00:00
TRUE, range_start, range_end, NULL);
if (download) {
if (method == GST_MPD_UTCTIMING_TYPE_HTTP_HEAD && download->headers) {
value = gst_dash_demux_parse_http_head (clock_drift, download);
} else {
buffer = gst_fragment_get_buffer (download);
}
g_object_unref (download);
}
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
}
g_mutex_unlock (&clock_drift->clock_lock);
if (!value && !buffer) {
GST_ERROR_OBJECT (demux, "Failed to fetch time from %s",
urls[clock_drift->selected_url]);
goto quit;
}
adaptivedemux: use GstSystemClock to all real-time calculations A realtime clock is used in many places, such as deciding which fragment to select at start up and deciding how long to sleep before a fragment becomes available. For example dashdemux needs sample the client's estimate of UTC when selecting where to start in a live DASH stream. The problem with dashdemux calculating the client's idea of UTC is that it makes it difficult to create unit tests, because the passage of time is a factor in the test. This commit changes dashdemux and adaptivedemux to use the GstSystemClock, so that a unit test can replace the system clock when it needs to be able to control the clock. This commit makes no change to the behaviour under normal usage, as GstSystemClock is based upon the system time. https://bugzilla.gnome.org/show_bug.cgi?id=762147
2016-02-16 14:44:10 +00:00
end = gst_adaptive_demux_get_client_now_utc (GST_ADAPTIVE_DEMUX_CAST (demux));
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
if (!value && method == GST_MPD_UTCTIMING_TYPE_HTTP_NTP) {
value = gst_dash_demux_parse_http_ntp (clock_drift, buffer);
} else if (!value) {
/* GST_MPD_UTCTIMING_TYPE_HTTP_XSDATE or GST_MPD_UTCTIMING_TYPE_HTTP_ISO */
value = gst_dash_demux_parse_http_xsdate (clock_drift, buffer);
}
if (buffer)
gst_buffer_unref (buffer);
if (value) {
GTimeSpan download_duration = g_date_time_difference (end, start);
GDateTime *client_now, *server_now;
/* We don't know when the server sampled its clock, but we know
it must have been before "end" and probably after "start".
A reasonable estimate is to use (start+end)/2
*/
client_now = g_date_time_add (start, download_duration / 2);
server_now = gst_date_time_to_g_date_time (value);
/* If gst_date_time_new_from_iso8601_string is given an unsupported
ISO 8601 format, it can return a GstDateTime that is not valid,
which causes gst_date_time_to_g_date_time to return NULL */
if (server_now) {
g_mutex_lock (&clock_drift->clock_lock);
clock_drift->clock_compensation =
g_date_time_difference (server_now, client_now);
g_mutex_unlock (&clock_drift->clock_lock);
GST_DEBUG_OBJECT (demux,
"Difference between client and server clocks is %lfs",
((double) clock_drift->clock_compensation) / 1000000.0);
g_date_time_unref (server_now);
ret = TRUE;
} else {
GST_ERROR_OBJECT (demux, "Failed to parse DateTime from server");
}
g_date_time_unref (client_now);
gst_date_time_unref (value);
} else {
GST_ERROR_OBJECT (demux, "Failed to parse DateTime from server");
}
g_date_time_unref (end);
quit:
if (start)
g_date_time_unref (start);
/* if multiple URLs were specified, use a simple round-robin to
poll each server */
g_mutex_lock (&clock_drift->clock_lock);
if (method == GST_MPD_UTCTIMING_TYPE_NTP) {
clock_drift->next_update = now + FAST_CLOCK_UPDATE_INTERVAL;
} else {
clock_drift->selected_url =
(1 + clock_drift->selected_url) % g_strv_length (urls);
if (ret) {
clock_drift->next_update = now + SLOW_CLOCK_UPDATE_INTERVAL;
} else {
clock_drift->next_update = now + FAST_CLOCK_UPDATE_INTERVAL;
}
}
g_mutex_unlock (&clock_drift->clock_lock);
return ret;
}
static GTimeSpan
gst_dash_demux_get_clock_compensation (GstDashDemux * demux)
{
GTimeSpan rv = 0;
if (demux->clock_drift) {
g_mutex_lock (&demux->clock_drift->clock_lock);
rv = demux->clock_drift->clock_compensation;
g_mutex_unlock (&demux->clock_drift->clock_lock);
}
GST_LOG_OBJECT (demux, "Clock drift %" GST_STIME_FORMAT, GST_STIME_ARGS (rv));
return rv;
}
static GDateTime *
gst_dash_demux_get_server_now_utc (GstDashDemux * demux)
{
adaptivedemux: use GstSystemClock to all real-time calculations A realtime clock is used in many places, such as deciding which fragment to select at start up and deciding how long to sleep before a fragment becomes available. For example dashdemux needs sample the client's estimate of UTC when selecting where to start in a live DASH stream. The problem with dashdemux calculating the client's idea of UTC is that it makes it difficult to create unit tests, because the passage of time is a factor in the test. This commit changes dashdemux and adaptivedemux to use the GstSystemClock, so that a unit test can replace the system clock when it needs to be able to control the clock. This commit makes no change to the behaviour under normal usage, as GstSystemClock is based upon the system time. https://bugzilla.gnome.org/show_bug.cgi?id=762147
2016-02-16 14:44:10 +00:00
GDateTime *client_now;
GDateTime *server_now;
client_now =
gst_adaptive_demux_get_client_now_utc (GST_ADAPTIVE_DEMUX_CAST (demux));
server_now =
g_date_time_add (client_now,
dashdemux: add support for UTCTiming elements for clock drift compensation Unless the DASH client can compensate for the difference between its clock and the clock used by the server, the client might request fragments that either not yet on the server or fragments that have already been expired from the server. This is an issue because these requests can propagate all the way back to the origin ISO/IEC 23009-1:2014/Amd 1 [PDAM1] defines a new UTCTiming element to allow a DASH client to track the clock used by the server generating the DASH stream. Multiple UTCTiming elements might be present, to indicate support for multiple methods of UTC time gathering. Each element can contain a white space separated list of URLs that can be contacted to discover the UTC time from the server's perspective. This commit provides parsing of UTCTiming elements, unit tests of this parsing and a function to poll a time server. This function supports the following methods: urn:mpeg:dash:utc:ntp:2014 urn:mpeg:dash:utc:http-xsdate:2014 urn:mpeg:dash:utc:http-iso:2014 urn:mpeg:dash:utc:http-ntp:2014 The manifest update task is used to poll the clock time server, to save having to create a new thread. When choosing the starting fragment number and when waiting for a fragment to become available, the difference between the server's idea of UTC and the client's idea of UTC is taken into account. For example, if the server's time is behind the client's idea of UTC, we wait for longer before requesting a fragment [PDAM1]: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=66068 dashdemux: support NTP time servers in UTCTiming elements Use the gst_ntp_clock to support the use of an NTP server. https://bugzilla.gnome.org/show_bug.cgi?id=752413
2015-07-15 10:56:13 +00:00
gst_dash_demux_get_clock_compensation (demux));
g_date_time_unref (client_now);
return server_now;
}
Reference in a new issue Copy permalink