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
Although FRAME-RATE is optional per HLS specification, but per HLS
Authoring Specification for Apple Devices (https://apple.co/30n90DC):
Each EXT-X-STREAM-INF tag MUST have a FRAME-RATE attribute.
Also, iOS and TVos refuse to play the content if VIDEO-RANGE is
present but FRAME-RATE is missing.
Issue #632, #634.
Change-Id: Ica282f023a7e8538f7b506094e2286840cf5c193
Note that TTML in ISO-BMFF is not supported yet.
Also updated packager_test.py:
- Added a test using TTML passthrough.
- Computed output extension from input extension unless output_format
is specified.
Fixes#478.
Change-Id: Ia917fc4ed3c326782791ed67601fba02ea28b11d
- EditLists in input files are parsed and applied to sample timestamps.
- An EditList will be inserted in the ISO-BMFF output if
- There is an offset between the initial presentation timestamp (pts)
and decoding timestamp (dts). Chrome, as of M67, still uses dts in
buffered range API [1], which creates various problems when buffered
range by pts does not align with buffered range by dts. There is
another bug in Chrome that applies EditList to pts only [2]. This
means that we can insert an EditList to align pts range and dts range.
- MediaSamples have negative timestamps (e.g. for Audio Priming).
You may notice the below change on some contents:
- Some media duration is reduced by one or two frames. This is because
EditList in the input file was ignored in the previous code, so video
streams start with a zero dts and a non-zero pts; the smaller of dts
and pts was used as the starting timestamp (related to the earlier
workaround for Chrome's dts bug), so the calculated duration was
actually a bit larger than the actual duration. Now with EditList
applied, the initial pts is reduced to zero, so the media duration is
also reduced to reflect the actual and correct media duration.
It may also result in negative timestamps in TS/HLS Packed Audio, which
will be addressed in a follow up CL.
Fixes#112.
Partially address b/110782437.
[1] https://crbug.com/718641, fixed but behind MseBufferByPts.
[2] https://crbug.com/354518. Chrome is planning to enable the fix for
[1] before addressing this bug, so we are safe.
Change-Id: I59317740ad3807ca66fa74b3a18fdf7f32c96aeb
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
Having "wvtt" in the codec string (in the master playlist) causes
errors on some older Apple products. As including it is optional,
we are opted to omit it to ensure support for all Apple products.
Close#402
Change-Id: Ib1072bcc26a3ff66e3a6d3204789c0c8c678d4db
Create an end-to-end test for ad cues. This test's final result is not
correct but illustrates the problem we have in the cue insertion and will
be fixed by a later CL.
Change-Id: Ia8b43a53848941be52cf9ade018668e6477e8df2
Jacob Trimble
koln67
KongQun Yang
Aaron Vaage