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
The time for the previous segment was used when generating the segment
name. This resulted in the first segment being overwritten and
mismatching manifest and media files. It led to playback problems.
Issue #472.
Change-Id: Ia8130ce261585e1a2ede83b26de3e32508de087f
The VP9 level is computed when the container is missing a codec config
or if the level is missing from the codec config.
This fixes VP9 in ISO-BMFF files generated by FFmpeg v4.0.2 or earlier
which does not have level set in the codec config.
Fixes#469.
Change-Id: I685bfd48be16ee6b2209da1c3173f7d6bb02b36a
This also ensures that it does not violate std::sort() requirement on
strict ordering, which is enforced in gcc/g++ though not in clang.
std::sort() strict ordering requirement:
std::sort() need a comparator that return true iff the first argument is
strictly lower than the second one. That is: must return false when they
are equal.
Change-Id: I781cf4ed4125fcad212eba5430a264f3a3d71c16
This is recommended by Apple and other content providers:
https://apple.co/2uTTAc4
- Set default --clear_lead to 12 seconds, i.e. about 2 segments.
- Set default --fragment_duration to 0 so fragment (sub-segment) is not
generated by default.
Change-Id: Ie6ec3ab6f0ce973547989c663a92b637a2fdc47c
It is possible to see a negative timestamp if the input mp4 file
contains EditList.
Also increase the queue size for EncryptionKey to be able to handle
smaller crypto_period_duration during testing.
Change-Id: I68278bf482d6662e771d9b80f4d5409605065aac
Configurable with --transport_stream_offset_ms.
This is needed to compensate for possible negative timestamps in
inputs, which could happen on ISO-BMFF with EditLists.
Issue #112.
Change-Id: I0fce8766c9df2911b9bb859c1e54052a8ed2abfb
In some ISO-BMFF files, there is an initial non-zero composition offset,
but there is no EditList present.
This is against ISO-BMFF spec recommentation [1] and we believe in most
cases it is just missing the EditList.
[1] 14496-12:2015 8.6.6.1
It is recommended that such an edit be used to establish a presentation
time of 0 for the first presented sample, when composition offsets are
used.
Issue: #112.
Fixes: b/110782437.
Change-Id: I23d33810ce536b09a1e22a2644828d824c1314f5
- 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
MPD cannot be validated right now since we do not generate deterministic
mpd with multiple inputs due to thread racing.
Exclude mpd comparison in this case.
Change-Id: I03b68b4969a39e20927c8a9b1475f72493682696
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
- Support decryption verification in _CheckTestResults
- Allow diff_files in _CheckTestResults
- Update all functional tests to use _CheckTestResults
Change-Id: I3f9c02f35808eba787becf9b1e5c1ce9238f943e
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 flag was designed for two purpose:
- Grouping fragments into subsegments, achieving three level hierarchy:
segment < subsegment < fragment.
- Indicate whether to generate 'sidx' box in media segments (when the
value is set to a negative number).
There are no practical use case for the first purpose. Removing it to
simplify the code and reduce the confusion.
Introduce another flag --generate_sidx_in_media_segments for the second
purpose.
Change-Id: I4be7cd42662fb324c1158b978e05768ee49dd048
It was implemented to workaround Chromium's DTS
https://crbug.com/398130, but the workaround does not really work in
all situations.
Remove it now as we already have another workaround available.
Change-Id: I291f559d78120fb743a6679b7d927e5bbc5b6b4e
DTS was used in ChunkingHandler. As a result, SegmentInfo contained
timestamp in DTS. MP4Muxer has a logic to change SegmentInfo to use
PTS but not in other muxers.
Benefits of using PTS in ChunkingHandler:
- De-dup the redundant logic in MP4Muxer
- Ensure consistent behavior in different output containers
- Consistent with other timestamps, e.g. Ad Cue timestamps
Issue #413
Change-Id: Ib671badf144e0c0866d60f4ff0ac0cbbdd33817e
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
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
EPT (earliest presentation time) may be adjusted not to be lower than
the decoding timestamp (dts), but the adjustment should only be done
on the first file when there is one file per Representation per Period.
The second file and onwards should not be adjusted otherwise a GAP
would be created.
Closes#384
Closes b/78517422
Change-Id: I56771ad8fbbe6a87b832ec58854cfbf37d5f1817
The previous text to mp4 webvtt pipeline was incomplete. It
did not insert ad cues and it could only insert a segment
after a sample ended.
Now the pipeline supports ad cue insert and segment insertion
mid text sample. This required the pipeline to use the text
chunker (to split samples and insert segments) and required
a major overhaul of the text to mp4 converter.
Before the converter came before the chunker. This meant that
the converter only expected to see stream info and text samples.
Moving the converter after the cue aligner and chunker means
that the convert had to be aware of segments and cues.
The general approach is the same, however the converter will
convert the samples per-segment as the chunker will introduce
duplicate samples if a sample spans across segments.
Closes#362Closes#382
Change-Id: I0f54a40524c36a602ad3804a0da26e80851c92fd
Allow the output file to contain template identifiers like $Number$,
$Time$ etc. Unlike the actual template used in SegmentTemplate, the
identifiers in output will be populated before pushing to the DASH
manifest.
Issue: #384
Change-Id: Ife1caadb6fccd32167fa1bc83fe2afcb2d2ad087
- Add command line flag --test_packager_version to inject packager
version; packager_main.cc is also updated to use the same flag.
- Also add a MpdGenerator test in packager_test.py.
Change-Id: I9a11a0ee5502ba30a8acc4d44ebbfaabbe0f2f6e
Previously for the last iframe in a segment, we wait for the next
segment to arrive before writing the EXTINF tag. If an Ad Cue comes
in before the next segment, the EXT-X-PLACEMENT_OPPORTUNITY tag would
be inserted before the iframe in previous segment.
Fixes#378, #396.
Change-Id: I1ede72a4d4edca94781c7b05bc25397d67916d1a
- Added a new --enable_entitlement_license flag, which sets
'enable_entitlement_license' in Widevine CommonEncryptionRequest;
- Support 'boxes' in Widevine CommonEncryptionResponse.
b/78171767
Change-Id: Id399fc7fcb2948c571e12c8af7687cfcfcef41fe
Requiring output format determined from 'output' to be consistent with
output format determined from 'segment_template'.
Change-Id: I32cbd63fcd6e2a4272dd0db531c1d5b385315445
Make sure to use the output format when given when setting up our
tests. Not doing so results in text always being set to "vtt" when
the output format is "mp4".
Change-Id: I11c5f861091598a67fc76dc19b1b16a9a773a2e0
Problem : Text samples have variable length and therefore act
more like continuous samples whereas audio and video
act more like discrete samples. Since we use sample
start time, a cue event could be inserted after the
start time of the last text sample and never get
inserted as there are no more samples.
Change : After all streams have requested flushing, we make sure
to collect all remaining cue events from the sync point
queue and insert them into each stream.
Issue #362
Change-Id: Id8f136f7ef53531f7a7f412613eac352324e0130
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
In H265Parser::ParseSliceHeader, the parser does not handle
byte_alignment() from the spec. byte_alignment() reportedly contains
at least one bit, which is not handled right now.
See Section 7.3.2.12 Rec. ITU-T H.265 v3 (04/2015).
Also added a few size sanity checks in H265Parser to make sure the
code does not crash if an invalid input is provided.
Fixes#383.
Change-Id: I33b31396058fc5ba67a0fc119be5fe56ec9443b0
KongQun Yang
Aaron Vaage