Commit graph

67 commits

Author SHA1 Message Date
WeiChungChang
c9fbf3459a 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-18 13:13:15 +02:00
Sebastian Dröge
4734b10c6f dashdemux: Add properties to select maximum allowed width/height and framerate
https://bugzilla.gnome.org/show_bug.cgi?id=770408
2016-08-26 18:12:23 +03:00
Sebastian Dröge
9c04d1e13c 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-11 11:56:55 +02:00
Sebastian Dröge
7f1f777b92 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-11 11:56:55 +02:00
Sebastian Dröge
cfad48ce5a 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-08-11 11:56:55 +02:00
Sebastian Dröge
70bc183a52 dashdemux: Implement downloading of only sync samples
https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-11 11:56:55 +02:00
Sebastian Dröge
5b943135ac dashdemux: Store parsed moof and extract offsets of sync samples in it
https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-11 11:56:55 +02:00
Sebastian Dröge
0b0a1a52d3 dashdemux: Implement parsing of ISOBMFF boxes
https://bugzilla.gnome.org/show_bug.cgi?id=741104
2016-08-11 11:56:54 +02:00
Sebastian Dröge
a7adb5cb60 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 20:44:29 +03:00
Sebastian Dröge
91e398ddd6 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-07-01 14:10:31 +02:00
Sebastian Dröge
9374643089 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-07-01 14:10:31 +02:00
Sebastian Dröge
ca9f62e1d0 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-07-01 14:10:31 +02:00
Alex Ashley
c8ef39cac7 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-10-29 13:26:46 +00:00
Chris Bass
69f86e51b2 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-09-26 00:50:55 +02:00
Alex Ashley
95c705ae8f 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-08-14 06:47:20 -03:00
Thiago Santos
a48a361256 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 11:12:42 -03:00
Thiago Santos
85bb450a44 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 18:03:40 -03:00
Thiago Santos
229a15b393 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-19 15:30:04 -03:00
Thiago Santos
fb760a563c dashdemux: remove unused segment attribute
It was never used, only initialized
2015-01-16 17:07:22 -03:00
Thiago Santos
3055bb331a 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-16 17:07:05 -03:00
Thiago Santos
f5b98f24c2 dashdemux: parse the sidx index from isobmff streams
Allows dashdemux to identify the subsegments in the stream and
switch bitrates when needed
2015-01-16 15:00:11 -03:00
Thiago Santos
58a1b0d058 dashdemux: port to adaptive demux 2014-11-30 21:56:25 -03:00
Matthieu Bouron
22c7559152 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-24 13:30:20 -03:00
George Kiagiadakis
55032ae5fe 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-09-18 13:38:25 -03:00
Matthieu Bouron
82fdb3aefc 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-08-19 15:34:01 -03:00
Thiago Santos
21b1d37023 dashdemux: remove unused stream uridownloader
The uridownloader for the stream fragments isn't used anymore.
2014-05-11 15:26:45 -03:00
Thiago Santos
f09dd7e7a5 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-07 01:00:49 -03:00
Thiago Santos
d6671e73a6 dashdemux: measure download rate just like hlsdemux
new bitrate = (old bitrate + (last fragment bitrate * 3)) / 4
2014-05-07 01:00:49 -03:00
Thiago Santos
bed3d66605 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-05-07 01:00:49 -03:00
Thiago Santos
da329b44a4 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-24 17:07:52 -03:00
Thiago Santos
be54766975 dashdemux: use a separate GstUriDownloader per stream
Avoids one download having to wait for another to finish
before starting
2013-12-24 17:07:52 -03:00
Thiago Santos
f33c52377f dashdemux: store GstActiveStream to avoid getting it every time
GstActiveStream is used everywhere to operate on the MPD client,
better store it in the GstDashDemuxStream to avoid getting it
everytime
2013-12-24 17:07:52 -03:00
Thiago Santos
7c6ccda3ec dashdemux: simplify locking for streams
Use a single lock for all streams instead of having separate locks.
This makes maintenance easier and at most points we would need
a single lock before iterating on all streams data. So not much
is gained from individual locks.
2013-12-24 17:07:51 -03:00
Thiago Santos
6611d14eed 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-24 17:07:51 -03:00
Thiago Santos
31e4ba0094 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-24 17:07:51 -03:00
Thiago Santos
3bd66d17fc 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-24 17:07:51 -03:00
Sebastian Dröge
493ee3383a dash: Add support for group-id in the stream-start event 2013-07-23 10:33:31 +02:00
Thiago Santos
5a5e66ec90 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-08 23:40:14 -03:00
Thiago Santos
9f190cdff7 dashdemux: port to 1.0 2013-05-08 18:14:46 -03:00
Wim Taymans
4f9f0b84cf dashdemux: make timestamps start from 0
Non-live streams should timestamp buffers with a running-time starting from
0. Since we already push a 0 -> -1 segment, bring the timestamps to 0
by subtracting the initial timestamp.
2013-05-08 18:14:45 -03:00
Thiago Santos
c82606a600 dashdemux: remove unused mutexes 2013-05-08 18:14:41 -03:00
Andre Moreira Magalhaes (andrunko)
fbbf713e45 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-05-08 18:14:41 -03:00
Andre Moreira Magalhaes (andrunko)
6ecb58c4f8 dashdemux: Remove unused members. 2013-05-08 18:14:40 -03:00
Andre Moreira Magalhaes (andrunko)
497500dbfe dashdemux: Only send newsegment on seek. 2013-05-08 18:14:40 -03:00
Thiago Santos
460542daaf dashdemux: add a downloadrate utility
A small struct that keeps a short history of fragment download bitrates
to have an average measure of N last fragments instead of using only
the last downloaded bitrate
2013-05-08 18:14:39 -03:00
Thiago Santos
94dcb60127 dashdemux: change bitrates based on the stream bitrate
Do not use a global bitrate as the sizes of the fragments matter
when calculating the download rate as the connection setup time is
also being taken into the download duration, a smaller fragment
will have a lower bitrate than a larger one.

This avoids switching the bitrates for streams frequently because
of bitrate mismatches
2013-05-08 18:14:39 -03:00
Thiago Santos
770df6277a dashdemux: refactor to use the uridownloader lib instead of internal copy 2013-05-08 18:14:39 -03:00
Thiago Santos
83c0e1e25d dashdemux: download the next fragment with smaller timestamp
Instead of downloading 1 fragment per stream per download loop,
select the stream with the earlier timestamp and get a fragment
only for that one.

The old algorithm would lead to problems when the fragment durations
were too different for streams.
2013-05-08 18:14:39 -03:00
Thiago Santos
dbd6bde9d1 dashdemux: track segments in the demuxer
Use a GstSegment to track the current segment information in the
demuxer.
2013-05-08 18:14:38 -03:00
Thiago Santos
39924c60a1 dashdemux: remove buffering message emission from dashdemux
dashdemux shouldn't emit the buffering message as that can pause
the pipeline. It has no proper knowledge of the downstream buffering
status so it can pause the pipeline when it isn't necessary. It should
have an internal buffer for downloading the streams ahead of playback,
but that shouldn't make it able to stop the pipeline for buffering.

A particular case in which this is bad is when a pad switch happens
(changing bitrates for example), the new pads dashdemux creates
will get linked to demuxers and new queues will be created,
these queues are initially empty and dashdemux will quickly
drain its buffers by pushing them to those queues. So it
would have no more buffers internally and would emit a
buffering message with a low ratio, causing the pipeline
to pause when it wouldn't be necessary.
2013-05-08 18:14:35 -03:00