## 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
This allows us to have presentationTimeOffset for text streams since
this needs to appear on a SegmentList/SegmentBase/SegmentTemplate.
Issue #832
Change-Id: Id3ab3308029185815d50a6cb1142e6a97f744d4f
This only supports TTML output; meaning the user can convert WebVTT
into TTML, but not the other way around. This will be useful for
DVB-sub subtitles that would be better supported within TTML.
This only adds text-based output; a follow-up will add MP4 support.
Change-Id: I0944b7df95d7765e55f203fc5e9a644f5c455dd8
- 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
Now text-based WebVTT also uses the generic media pipeline. This
converts the WebVttTextOutputHandler to a WebVttMuxer to be more
consistent with the other muxer types.
This also allows choosing between single-segment text and multi-segment.
Before, we would generate both and use single-segment for DASH and
multi-segment for HLS; but now you can choose between either and either
are supported in both DASH and HLS.
Change-Id: I6f7edda09e01b5f40e819290d3fe6e88677018d9
Per https://dashif.org/docs/DASH-IF-IOP-v4.3.pdf 4.4.3.6 Signalling the last segment number in Period, there are three ways to signal the last segment number:
a. Use the lmsg signalling as defined in clause 4.4.3.5.
b. Use the Segment Timeline with @r value greater or equal to 0.
c. Add a Supplemental Descriptor with @schemeIdUri set to http://dashif.org/guidelines/last-segment-number with the @value set to the last segment number.
We do not support (a). This change adds support for (c) when Segment Timeline (b) is not used, i.e. when Representation has constant duration (could be approximate).
Under flag --dash_add_last_segment_number_when_needed (disabled by default).
- Parse and extract transfer_characteristics from H264/H265 VUI
parameters.
- Set VIDEO-RANGE attribute in HLS according to HLS specification:
https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-02#section-4.4.4.2
- Also added an end to end test.
Fixes#632.
Change-Id: Iadf557d967b42ade321fb0b152e8e7b64fe9ff3e
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
Add dash_accessibilities stream descriptor, which is a semi-colon
separated list of accessibility_scheme_id_uri=value. It is optional.
Add dash_roles stream descriptor, which is a semi-colon separated
list of strings. It is optional.
Closes#565.
Change-Id: Idb1c20bb410fdd016db07e11fe507c102a3dd8ea
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
It allows users to override the default language for text tracks.
If not specified, --default_language applies to both audio and text
tracks.
Issue #430.
Change-Id: I86a9baba2072be27b6661fa7b65a8bc8b6adb3cc
Add hls_characteristics stream descriptor, which is a colon or semi-colon
separated list of strings. It is optional.
Fixes#430.
Change-Id: Ifcf79316e68768ff065891933de565cd0ff32ec4
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
Only Marlin Adaptive Streaming Specification – Simple Profile is
supported.
Two additional updates:
- Remove FairPlay ContentProtection element from DASH mpd as FairPlay
does not define a signaling in DASH.
- Updated end to end test to include all DRMs we support.
Closes#381.
Change-Id: Id12269b471ea34983b782cbd92f687332292ef59
This was introduced earlier to indicate FairPlay protection system. But
in fact, it is sufficient to just use the system id for the indication.
- Also updated various parts of the pipeline to support empty PSSH.
- Added an additional FairPlay end to end test using fMP4.
Change-Id: Ica48b7b5235e9a2b5a7f722bcd0fc1ef2073ac13
DASH live profile with static MPD was incorrectly handled in the same
way as live profile with dynamic MPD, i.e. by assuming the synchronized
Representations, which is incorrect.
It can be easily re-produced in multiple period outputs, i.e. with Ad
cues. It may happen with regular contents as well, due to race
condition, though with a much lower chance of occurring.
Fixes#435.
Bug: 111359775.
Change-Id: I7de087f5dd8602b4c4e35cb697d589fa3699e8a5
I.e. enable --generate_dash_if_iop_compliant_mpd in mpd_generator by
default.
It was enabled in the main packager binary in v1.6.1.
Change-Id: Icfb19758c52c107e8ab17d3fb581923fa291cc0a
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
This is needed to support one file per representation per period where
there will be multiple content files generated.
Issue: #384
Change-Id: Ib7af750edf864d99075b8da4f3640217a5a94302
The number of preserved segments outside live window can be
configured using flag --preserved_segments_outside_live_window,
which is default to 50, i.e. 5 minutes for 6s segment.
Note that the segment removal will be disabled if it is set to 0.
Only HLS live playlist and DASH dynamic MPD are affected by this flag.
- Also add end to end tests.
Fixes#223.
Change-Id: I8a566efebe2f1552c7d9509ab017bade5a4a1c98
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
Bartek Zdanowski
Joey Parrish
Vishal Shah
Caitlin O'Callaghan
Joey Parrish
Samidh
Jacob Trimble
Weiguo Shao
Tim Lansen
sr90
KongQun Yang
Yohann Connell