This feeds into efforts to create a working install target.
The order of headers is still funky, and was "fixed" by clang-format,
but in a way that doesn't exactly align with the style guide. Further
cleanup of header order is coming in a follow-up PR.
Rebasing #1155 and applying some fixes. Had to comment out the
`mpd_notify_muxer_listener_unittest` because it depends on
`MockMpdNotifier` from `mpd/base` which has not been ported yet. Can
bring this test back once that has been ported.
Related to #1047
---------
Co-authored-by: Carlos Bentzen <carlos.bentzen@bitmovin.com>
Co-authored-by: Joey Parrish <joeyparrish@google.com>
# 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
# 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