# Low Latency DASH - `availabilityTimeComplete=false`
Low Latency DASH manifests generated by Packager were missing the
attribute `availabilityTimeComplete`. As per the [DASH
specs](https://dashif.org/docs/CR-Low-Latency-Live-r8.pdf):
**_the AdaptationSet@availabilityTimeCompleteshould be present and be
set to 'FALSE'_**
## The Issue
The missing attribute caused ULL streams from Shaka Packager to no
longer be compatible with DASH.js. Previous versions of DASH.js allowed
users to specify ULL mode when initializing the player. However, the
most recent releases of DASH.js automatically detect ULL by scanning the
manifest for ULL specific attributes. Although there are many attributes
only associated with ULL, [DASH.js only greps for
`availabilityTimeComplete` in its detection
logic](https://github.com/Dash-Industry-Forum/dash.js/blob/development/src/streaming/controllers/PlaybackController.js#L792-L805).
Because of the missing attribute in Packager and the limited ULL
verification criteria by DASH.js, Packager streams were not being
treated as low latency streams by DASH.js.
## Testing
### Unit Testing
`./mpd_unittest
--gtest_filter="SegmentTemplateTest.OneSegmentLowLatency"`
` ./mpd_unittest
--gtest_filter="LowLatencySegmentTest.LowLatencySegmentTemplate"`
### Manual Testing
- Created a low latency stream with Shaka Packager
- Observed the expected `availabilityTimeComplete=false` attribute in
the generated DASH manifest.
## The issue
- With LL-DASH mode enabled, the gap size warning was hit and printed to the console every time a new segment was registered to the manifest.
- This occurred because the first chunk's size and duration were being stored for each segment, rather than the full segment size and duration. Note, only the first chunk's metrics are known at first because in low latency mode, the segment is registered to the manifest before it is finished being processed and written.
- Because of this, the gap size check was comparing the end time of the first chunk in the previous segment to the beginning time of the current segment, causing the check to fail every time.
## The Fix
- Update a low latency segment's duration and size once the segment file has been fully written.
- The full segment size and duration will be used to update the bandwidth estimator and the segment info list.
- Updating the segment info list to hold the full duration is necessary for satisfying [the gap size check found in Represenation.cc](https://github.com/google/shaka-packager/blob/master/packager/mpd/base/representation.cc#L391).
- NOTE: bandwidth estimation is currently only used in HLS
This converts all time parameters to signed, finishing a cleanup that
was started in 2018 in b4256bf0. This changes the type of:
- timestamps
- PTS specifically
- timestamp offsets
- timescales
- durations
This excludes:
- MP4 box definitions
- DTS specifically
This is meant to address signed/unsigned conversion issues on arm64
that caused some test cases to fail.
Change-Id: Ic752a20cbc6e31fea6bc0894d1771833171e7cbe
- Use std::move to transfer ownership.
- Avoid libxml primitives outside XmlNode.
- Have attribute setting return errors.
- Mark bool returns with WARN_UNUSED_RESULTS and use return value.
- Use std::string over char*.
Change-Id: Ia00bb29c690025275e270f10e5c065722481c0c5
We used to use the target segment duration provided by the user.
Unfortunately that does not work for iframe only playlist which
the target duration is effectively equal to the GOP duration.
In the new approach, we estimate the target duration from the initial
few blocks (10 blocks right now).
Fixes#610.
Change-Id: Ie8bf943e157149ca7ed3b9382fe0a1088d0774e2
Segment start,end time was used previously, which could result in
problems if there are discontinuity in the streams. E.g. if the
stream has timestamp, 10000, 10001, 10002 and then next segment
comes in with timestamp 1. With the previous logic, all the segments
would remain in the time shift buffer until after 10000 segments
even with a small time shift buffer depth of 10.
This could also happen when timestamp wraps around, which could
happen during long time of live streaming.
This change will also be useful to support multi-period live DASH.
Fixes#563.
Change-Id: Ie078d76c6e4af13ade9ad46191c8e3529069ed4d
https://tools.ietf.org/html/rfc8216#section-4.1
The peak segment bit rate of a Media Playlist is the largest bit rate
of any contiguous set of segments whose total duration is between 0.5
and 1.5 times the target duration.
Fixes#498.
Change-Id: I1f28972b9cc5977735e47906bdcd88ba3942db5a
Instead, caclulating average bandwidth by dividing the sum of the
sizes of every segment by the sum of the durations of every segment.
This aligns with the requirement in HLS spec:
https://tools.ietf.org/html/draft-pantos-http-live-streaming-23 4.1.
BandwidthEstimator is also simplified to handle all blocks only.
Fixes#361
Change-Id: I89e7d415a841f4d4048f199de8dae7ffa250467b
Configurable under flag --use_legacy_vp9_codec_string, which defaults
to false as all major browsers and platforms support new style vp09
codec string already.
Closes#406.
Change-Id: I22e917777f9d66db815ff9d55eb47b6d55806269
It is not always possible to align segment duration to target duration
exactly. For example, for AAC with sampling rate of 44100, there are
always 1024 audio frames per sample, so the sample duration is
1024/44100. For a target duration of 2 seconds, the closest segment
duration would be 1.984 or 2.00533.
This feature allows MPD generator to treat these segments as having
the same duration, thus allows MPD generator to generate less
SegmentTimeline entries and potentially no SegmentTimeline entries
(replaced with SegmentTemplate@duration instead if
--segment_template_constant_duration flag is enabled).
Under flag --allow_approximate_segment_timeline. Disabled by default.
Fixes#330.
Change-Id: I5044eaa348ebbf45bf792a2af53fc95a115ae21b
The file_name fields will be used to solely indicate file paths on the
designated file system, and they are used to do normal file operations,
including file creation, file updating and file removal if needed;
added new xxx_url fields, for the URLs that should appear on DASH
manifest or HLS playlists.
xxx_url are the URIs of the media in the manifest. The fields are
converted from file_name fields but adjusted to be relative to DASH
manifest path or HLS playlist path, optionally with base_url prepended.
Previously the file_name fields are converted in place to indicate
URLs when passing to manifest / playlist builders. The original file
names were lost, which made it difficult to remove files outside of
live window.
Now that the input file names are preserved. File system APIs can
operate on the original file names while manifest / playlist generation
functions can operate on URLs.
Issue: #233
Change-Id: I36a64f16e3d1261ce91783a86588f24ad1371662
According to DASH spec (23009-1:2014):
Consider a hypothetical constant bitrate channel of
bandwidth with the value of this attribute in bits per second
(bps). Then, if the Representation is continuously delivered
at this bitrate, starting at any SAP that is indicated either by
@startwithsap or by any Segment Index box, a client can
be assured of having enough data for continuous playout
providing playout begins after @minbuffertime *
@bandwidth bits have been received (i.e. at time
@minbuffertime after the first bit is received).
For dependent Representations this value specifies the
bandwidth according to the above definition for the
aggregation of this Representation and all complementary
Representations.
This suggests that max bitrate should be used instead of average
bitrate.
Also cleaned up BandwidthEstimator code.
Fixes#376.
Change-Id: Ibf5896394c5c6bb820849771a2129c59202d2273
This flag was introduced to workaround a rounding error in Chrome
(probably in other browsers too).
Also although this flag avoids the first frame of a Period to be
dropped due to rounding error but it could cause the last frame of a
Period to be dropped.
Now that we use a high precision Period@duration, we do not expect to
see rounding errors any more. The player would be a better place for
the workaround even if it is still needed.
Related issue: #368.
Change-Id: I3bd517ecc6d548ff62e0c13394edb49d4bc68e8f
Prefer timestamps from Video AdaptationSets if available - this avoids
possible video playback jitters due to gaps.
presentationTimeOffset is not applied to the first period as it may in
negative dts which Chrome does not like: https://crbug.com/398141.
It is safe to apply to subsequent periods as the actual offset applied
takes Period@start into consideration:
offset = Period@start - presentationTimeOffset
The result timestamp with offset applied is close to Period@start, so
it is unlikely to result in a negative dts value.
Closes b/73899306.
Change-Id: If8361f5469610093b3aac6675754536ad7e83c4c
This change has the hls master playlist add the text codec string
to the list of codecs in a variant.
Bug: 72942756
Change-Id: Ib25bb2064a291d10d7b1d261a4307991df62220c
Also added Period::GetAdaptationSets and
AdaptationSet::GetRepresentations.
Instead of implementing GetDurationSeconds in all MpdBuilder classes
(MpdBuilder/Period/Adaptation/Representation) like what we used to do
with GetEarliestTimestamp, the two new functions allows MpdBuilder to
iterate through the Representations to get durations.
Also updates GetEarliestTimestamp functions to use the same iteration
method.
Change-Id: I682b70c07c248c0f6511ec3d9019086f986ee10e
Move AdaptationSet related functions to the new Period class, which
maps to <Period> element and provides methods to add AdaptationSets.
Change-Id: I0fee290769fbe9a6355cc1b8c86baec8fbc4b4fd
Moved from mpd_unittest.cc to representation_unittest.cc.
Also removed unused test data files in packager/mpd/test/data.
Change-Id: I23811390b4b1ffbfac3e69c1ffcf92544099a53d
Move AdaptationSet related tests to adaptation_set_unittest.cc and
Representation related tests to representation_unittest.cc.
Change-Id: I360e9aea3ba08a32e5ba3b0e8b34345f2b3f0b20
Caitlin O'Callaghan
Joey Parrish
Joey Parrish
Jacob Trimble
KongQun Yang
Aaron Vaage