Commit graph

72 commits

Author SHA1 Message Date
Alex Ashley
d9bcf4dbd9 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-08-02 12:52:34 +01:00
Florin Apostol
9ccd541980 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
2016-02-09 16:49:37 -03:00
Thiago Santos
731ab94cc3 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-02-04 14:05:08 -03:00
suhwang.kim
6cbaec7593 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 09:51:02 +02:00
suhwang.kim
6d8dd482c4 dashdemux: maxFrameRate & minFrameRate should be in RepresentationBase.
According to the spec, they can be in AdaptationSet, Representation and SubRepresentation.
So They should be in RepresentationBase.

https://bugzilla.gnome.org/show_bug.cgi?id=758515
2015-12-08 09:51:02 +02:00
Florin Apostol
9a7bf5fbf1 mpdparser: remove gst_mpd_client_check_time_position
https://bugzilla.gnome.org/show_bug.cgi?id=758593
2015-11-24 10:01:58 -03:00
Florin Apostol
ef84f294c0 mpdparser: remove unused functions gst_mpdparser_get_chunk_by_index and gst_mpdparser_find_segment_by_index
https://bugzilla.gnome.org/show_bug.cgi?id=758233
2015-11-19 15:53:30 -03:00
Vincent Penquerc'h
e48e68416c mpdparser: make durations unsigned where appropriate
The standard does not seem to make any particular explicit not
implicit reference to the signedness of durations, and the code
does not rely on such, nor on the negativity of the -1 value
that's used as a placeholder when a duration property is not
present in the XML.

https://bugzilla.gnome.org/show_bug.cgi?id=750847
2015-10-30 16:29:46 +00: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
Sebastian Dröge
93d85bd361 dashdemux: Implement lazy-loading of external periods
https://bugzilla.gnome.org/show_bug.cgi?id=752230
2015-09-25 23:52:28 +02:00
Sebastian Dröge
572e54574b 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-09-25 23:52:28 +02:00
Sebastian Dröge
07ee57228b mpdparser: Parse xlink attributes from Period, AdaptationSet and SegmentList
We still have to do something useful with them, like actually loading the
content behind the URL.

https://bugzilla.gnome.org/show_bug.cgi?id=752230
2015-09-25 23:52:28 +02:00
Vincent Penquerc'h
69bfa8222f mpdparser: properly read signed r values for S elements
The spec defines these as signed in 5.3.9.6.1.
Since we don't support this behavior, warn and default to 0
(non repeating), which is the spec's default when the value
is not present.

https://bugzilla.gnome.org/show_bug.cgi?id=752480
2015-09-16 09:44:19 +01:00
Sebastian Dröge
0d0455e346 dashdemux: Export the period start time to the base class
https://bugzilla.gnome.org/show_bug.cgi?id=754222
2015-09-14 19:53:03 +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
Florin Apostol
581ae1d24d dashdemux: regrouped functions in gstmpdparser.h file
Moved gst_mpd_client_get_next_segment_availability_end_time and
gst_mpd_client_add_time_difference functions to be grouped with
functions from the same category.

https://bugzilla.gnome.org/show_bug.cgi?id=752027
2015-07-07 14:02:10 +03:00
Florin Apostol
e4d6e96c82 dashdemux: corrected comments in gstmpdparser.h
Corrected some comments in gstmpdparser.h file.
Moved gst_mpd_client_get_adaptation_sets function to be grouped with
other functions from AdaptationSet group

https://bugzilla.gnome.org/show_bug.cgi?id=751149
2015-06-18 12:40:01 -03:00
Alex Ashley
5beeccdba2 dashdemux: fix error calculating large presentationTimeOffset values
If the presentationTimeOffset attribute of a DASH manifest contains
a value that is larger than 2^32, gstmpdparser incorrectly calculates
the stream's presentation time offset. This is due to two bugs:

1: Using gst_mpdparser_get_xml_prop_unsigned_integer rather than
   gst_mpdparser_get_xml_prop_unsigned_integer_64 to parse the
   attribute
2: gst_mpd_client_setup_representation multiplying the value by
   GST_SECOND and then dividing by timescale

https://bugzilla.gnome.org/show_bug.cgi?id=750804
2015-06-11 19:41:11 +02:00
Thiago Santos
0910540d58 dashdemux: use signed integet to represent segment index
We need to be able to represent -1 to check when we are EOS
on reverse playback and unsigned integer won't allow that.

CID #1298193
CID #1298194
CID #1298195

https://bugzilla.gnome.org/show_bug.cgi?id=749534
2015-05-25 09:02:30 -03:00
Thiago Santos
f4789d0430 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-13 13:39:32 -03:00
Thiago Santos
23ad922b64 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-13 13:39:31 -03:00
Thiago Santos
f298fca8ad dashdemux: remove unused functions
These functions of directly getting and setting segment indexes
are no longer useful as now we need 2 indexes: repeat and segment
index.

The only operations needed are advance_segment, going back to the
first one or seeking for a timestamp.
2015-05-13 13:39:18 -03:00
Thiago Santos
d617139ee7 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-13 13:35:14 -03:00
Thiago Santos
57a2105a31 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-13 13:35:14 -03:00
Thiago Santos
6344f86e44 dashdemux: improve mpd parsing for repeated segment entries
Use a single segment to represent it internally to avoid using too
much memory. This has the drawback of issuing a linear search to
find the correct segment to play but this can be fixed by using
binary searches or caching the current position and just looking
for the next one.

https://bugzilla.gnome.org/show_bug.cgi?id=748369
2015-05-13 13:35:14 -03:00
Mathieu Duponchelle
bd70c73a8a 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-10 15:17:37 +01:00
Thiago Santos
b40e5decb2 dashdemux: check for profiles
Check for available profiles to enable certain features for
dash playback. For now we check for the ISOFF On Demand 2011 profile.
2015-01-16 15:00:11 -03:00
David Waring
95c3fdc193 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-12-02 14:22:09 -03:00
Thiago Santos
58a1b0d058 dashdemux: port to adaptive demux 2014-11-30 21:56:25 -03:00
George Kiagiadakis
ea90ceac01 dashdemux: support downloading segments in reverse order
When a seek with a negative rate is requested, find the target
segment where gstsegment.stop belongs in and then download from
this segment backwards until the first segment.

This allows proper reverse playback.
2014-08-07 16:52:37 +03:00
Sebastian Dröge
ae679506b1 dashdemux: Always use the redirect target to resolve relative URIs
But redownload the playlists from the original URI if it's not
a permanent redirect.
2014-05-28 12:47:51 +02:00
Thiago Santos
08636f3bab 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-24 17:07:51 -03:00
Alex Ashley
42fd04ce48 dashdemux: stop fetching live fragments that don't yet exist
There is an issue for live streams where download_loop will keep
downloading segments until it gets a 404 error for a segment
that has not yet been published. This is a problem because this
request for a segment that doesn't exist will propagate all the
way back to the origin server(s). This means that dashdemux causes
extra load on the origin server(s) for segments that aren't yet
available.

This patch uses availabilityStartTime, period
and the host's idea of UTC to decide if a fragment is available to
be requested from an HTTP server and filter out requests for fragments
that are not yet available.

https://bugzilla.gnome.org/show_bug.cgi?id=701404
2013-10-03 09:15:37 -03:00
Josep Torra
0b54b0568d dashdemux: Fix warnings when building in OS X Snow Leopard
gstmpdparser.h:530: warning: type qualifiers ignored on function return type
gstmpdparser.c:4177: warning: type qualifiers ignored on function return type
2013-08-30 21:36:19 +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
b316d8a677 dashdemux: fix template based segment generation
When using a template based segment list, do not try to
contruct a finite segment list for the limits of the available periods.

We might not know when the period ends (for live streams) and we can
always create the segment on demand when requested by dashdemux,
avoiding use of some memory and cpu when re-creating this list.
2013-07-08 23:39:49 -03:00
Thiago Santos
a8a355108a dashdemux: use more appropriate data structures for parsing
Replaces the 2 likely larger lists with more appropriate structures
to improve performance.

Replaces S nodes GList for a GQueue, this reduces latency to startup
because of traversing the list just append an element.

Replaces the processed media segments GList for a GPtrArray as it is
constantly acessed by index during playback.
2013-07-08 23:39:49 -03:00
Thiago Santos
788757dc1f dashdemux: various cleanups
Removing unused function, replacing // comments with /* */ and
replacing some GST_WARNING with GST_INFO/_DEBUG as they are meant
to be
2013-07-03 15:34:41 -03:00
Alex Ashley
5ad2a2d161 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-07-03 15:34:30 -03:00
Thiago Santos
aa1fe88a08 dashdemux: each fragment can have its own index
Return index URI/range to dashdemux from the mpdparser to be able
to download and deliver them downstream for playback.
2013-07-01 18:52:08 -03:00
Thiago Santos
d68fffc217 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 18:52:08 -03:00
Thiago Santos
4f17112392 dashdemux: add support for range based segments
Use the mediaRange information and pass it to the uridownloader
to correctly download only the segment ranges indicated in the
MPD

https://bugzilla.gnome.org/show_bug.cgi?id=702206
2013-07-01 14:22:01 -03:00
Thiago Santos
919cb34fee dash: do not use deprecated glib mutex API 2013-05-08 18:14:46 -03:00
Thiago Santos
14feeb3ccb 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-05-08 18:14:42 -03:00
Thiago Santos
cff4498f7c dash: mpdparser: use guint64 for timestamps
The timestamps can be pretty big, so use guint64 for them
2013-05-08 18:14:41 -03:00
Thiago Santos
4ca530f2fe dashdemux: plug some leaks
Add some missing free/unrefs spotted by valgrind
2013-05-08 18:14:41 -03:00
Andre Moreira Magalhaes (andrunko)
b9272dc0e6 dashdemux: Properly parse base uri from mpd. 2013-05-08 18:14:40 -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
2d85107299 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-05-08 18:14:34 -03:00