Commit graph

77 commits

Author SHA1 Message Date
Seungha Yang
7d06ecb3a4 isoff: Move isoff to gst-libs
Also rename unit test dash_isoff to isoff

https://bugzilla.gnome.org/show_bug.cgi?id=777825
2017-08-25 17:21:04 -07:00
Sebastian Dröge
e2a6573c7d dashdemux: Smooth out skip distances in keyframe-only trick modes
This ensures smoother playback. It looks weird if we first do a big
jump, then play a couple of consecutive frames, just to again skip ahead
quite a bit because we ran late again.
2017-05-18 19:04:57 +02:00
Sebastian Dröge
ddef518701 dashdemux: Take configure max bitrate/framerate into account for keyframe skipping
And by default only produce up to 10 fps.
2017-05-18 19:04:57 +02:00
Sebastian Dröge
b3e2657ac1 dashdemux: Snap-seek for skipping ahead and use actual keyframe distance in the current fragment if applicable 2017-05-18 19:04:57 +02:00
Edward Hervey
245d73e516 dashdemux: Improve key-unit trick mode downloading
When dealing with key-unit trick mode downloads, the goal is to
provide the best "Quality of Experience". This is achieved by:
1) maximizing the number of frames displayed per second
2) avoiding "stalling" as much as possible (i.e. not downloading and
  decoding frames fast enough)

This implementation achives this by:
1) Knowing very precisely the current keyframe being download (i.e
  more accurate than at the fragment level which might contain more
  than one keyfram). This is the new "actual_position" variable
  introduced by this commit
2) Knowing the position of downstream (provided by QoS and stored
  in the adaptivedemuxstream qos_earliest_time variable)
3) Knowing how long it takes to request and fully download a keyframe
  (the average_download_time variable)

Taking those 3 variables into account, whenever a keyframe has been
pushed downstream we calculate a "target time" (target_time variable)
which is the ideal next keyframe time to request so that:
1) It will be requested/downloaded/demuxed/decoded in time to be
  displayed without being too late
2) It will not be too far ahead that it would cause too few frames
  per second to be displayed.

How far ahead we will request is inversily proportional to how close
the actual position (actual_position) is from the downstream
position (qos_earliest_time). The more is buffered between the source
and the sink, the "closer" the target time will be, and therefore
the more frames per seconds will be displayed (up to the limit
of keyframes_per_second * absolute_rate).
2017-05-18 19:04:57 +02:00
Edward Hervey
04224ad440 dashdemux: Store average download time
This will be used to bound the download rate when working in
keyframe-only trick mode
2017-05-18 19:04:57 +02:00
Sebastian Dröge
2379dc3f5b dashdemux: Collect keyunit distance and size statistics 2017-05-18 19:04:57 +02:00
Sebastian Dröge
db57a3b04f dashdemux: Rewrite ISOBMFF & SIDX handling
The previous code was handling both as separate steps and then tried to
combine the results, but this resulted in all kinds of bugs which showed
themselves as failures during seeking and offset tracking getting wrong.
This also showed itself with gst-validate on the sample stream.

The rewritten code now parses everything in one go and tracks the
current offset only once, and as a side effect simplifies the code a
lot.

Also added is detection of SIDX that point to other SIDX instead of
actual media segments, e.g. with this stream:
  http://dash.akamaized.net/dash264/TestCases/1a/sony/SNE_DASH_SD_CASE1A_REVISED.mpd
Support for this will have to be added at some point but that should
also be easier with the rewritten code.

https://bugzilla.gnome.org/show_bug.cgi?id=781233
2017-04-18 13:49:08 +02:00
Sebastian Dröge
e0e1db212f Revert "dashdemux: Fix issue when manifest update sets slow start without passing necessary header & caps changes downstream"
This reverts commit c9fbf3459a.

The representation ID comparision here was wrong and triggering always
if the ID did *not* change, causing needless redownloading of the
header. The sample stream provided in the bug does not exist anymore.
2017-04-12 20:11:16 +03:00
Sebastian Dröge
b76a2200de dashdemux: Keep track of the PTS, not the SIDX index position between representations
There is no guarantee that the index positions are the same between
representations, and assuming this easily causes us to get into invalid
index positions.
2017-03-15 13:27:23 +02:00
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