## 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
# LL-DASH Support
These changes add support for LL-DASH streaming.
**NOTE:** LL-HLS support is still in progress, but it's coming. :)
## Testing
`./chunking_unittest --gtest_filter="ChunkingHandlerTest.LowLatencyDash"`
`./media_event_unittest --gtest_filter="MpdNotifyMuxerListenerTest.LowLatencyDash"`
`./mpd_unittest --gtest_filter="PeriodTest.LowLatencyDashMpdGetXml"`
`./mpd_unittest --gtest_filter="SimpleMpdNotifierTest.NotifyAvailabilityTimeOffset"`
`./mpd_unittest --gtest_filter="SimpleMpdNotifierTest.NotifySegmentDuration"`
`./mpd_unittest --gtest_filter="LowLatencySegmentTest.LowLatencySegmentTemplate"`
Note, packager_test must be run from the main project directory
`./out/Release/packager_test --gtest_filter="PackagerTest.LowLatencyDashEnabledAndUtcTimingNotSet"`
`./out/Release/packager_test --gtest_filter="PackagerTest.LowLatencyDashEnabledAndUtcTimingNotSet"`
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
The file deletion could fail if it is still held by the web server.
This CL adds retry logic to retry the deletion.
Closes#533.
Change-Id: Ib42ed8db11f32897a29e3b58c1be89d05f5dd034
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
This is needed to support one file per representation per period where
there will be multiple content files generated.
Issue: #384
Change-Id: Ib7af750edf864d99075b8da4f3640217a5a94302
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
Removed the logic in MuxerListener to estimate bandwidth from file
size and duration, since it is not compliant to the spec.
MpdBuilder will estimate bandwidth from segment size and duration
if bandwidth is not specified in MediaInfo.
Here is the statement from 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.
Fixes#376.
Change-Id: I0fddce39e709d0cded0a4c9ae59adbbcc97ec5ea
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
Caitlin O'Callaghan
Joey Parrish
Samidh
Jacob Trimble
KongQun Yang
Aaron Vaage