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
Problem: The time scale for text was being set to zero in our tests
because it was never needed.
Change: This changes it to use MS as that is what's most common and
requires the least amount of changes.
Change-Id: Ia046ac1994b4cede079d2f801275c7f058d5bdd3
This change creates the webvtt segmenter which will be used for
segmented text webvtt for HLS. It takes a stream of text samples
and injects segment info messages based on the segment duration.
It is possible for samples to extend between segments, if so the
sample will appear twice (once in each segment).
Change-Id: Iae0134ee61cf269948026086520b6d3f8ce3785b
Use std::shared_ptr<const uint8_t> with a custom deleter to
represent MediaSample::data_ instead of std::vector<uint8_t>.
MediaSample::data_ can be shared by multiple MediaSamples and it is
immutable. A new data instance must be created if the clients want to
modify the underlying data. The new data instance can be transferred
to MediaSample using provided MediaSample::TransferData function.
This avoids unnecessary data copying.
Change-Id: Ib59785a9e19d0abb3283179b12eb6779ee922f79
Took the test structure for trick play and made a common test
structure that can be used for new tests. The next tests to
use this structure will be the new WebVtt pipeline.
Change-Id: I5faca306b8a2bd16b9f945d1ff5c336aed82bc35
This change create some matchers and text functions that
will be used by the upcoming webvtt work.
Change-Id: I2d7931d1bdabd761f74e8aee7524d5ecfb7cfdc4
To allow more tests to use the MediaHandlerTestBase and get access to the
helpful creation methods, this change moves the use of FakeMediaHandler
and setting up the graph to a sub class.
Change-Id: I90dd151e3c96d8fbe4bd02a1d6b11e66a279d95b
Created media handlers that make testing a handler easier by providing
methods to send messages from upstream and check messages downstream.
Change-Id: I7b3ba3a51bcf0d73bcaacd46b2dcbc16f87d8694
In prep for changes to Trick Play, we want to make all messages
copy on write so that if the same message is sent to multiple
handlers, it is not possible for one handler to change the data
another handler is using.
Change-Id: I554166ca11c532412e4dfced5603972ca24dc2bb
Added a flag --strip_parameter_set_nalus. When enabled, parameter
set NAL units, SPS/PPS for H264 and SPS/PPS/VPS for H265, are stripped
from frames when converting NAL byte stream (AnnexB stream) to NAL
unit stream, which generates avc1/hvc1; otherwise they are not
stripped, and avc3/hev1 is generated.
Parameter set NAL units should not be stripped if they are varying
in the frames otherwise the frames may fail to be decoded.
The flag is enabled by default as we don't usually see varying
SPS/PPS/VPS and it is more space efficient with them stripped.
Set --strip_parameter_set_nalus=false to disable the flag if there
are varying SPS/PPS/VPS in the frames. This addresses #206.
Change-Id: I34bde6f33069f9f77d51a510b39f58a0f0e141aa
This CL also removes EncryptionConfig stream data type and merges it
into StreamInfo/SegmentInfo instead.
Change-Id: Idb70ce503e61d3c951225cc78b6b15c084e16dcd
This handler is a multi-in multi-out handler. If more than one input is
provided, there should be one and only one video stream; also, all inputs
should come from the same thread and are synchronized.
There can be multiple chunking handler running in different threads or even
different processes, we use the "consistent chunking algorithm" to make sure
the chunks in different streams are aligned without explicit communcating
with each other - which is not efficient and often difficult.
Consistent Chunking Algorithm:
1. Find the consistent chunkable boundary
Let the timestamps for video frames be (t1, t2, t3, ...). Then a
consistent chunkable boundary is simply the first chunkable boundary after
(tk / N) != (tk-1 / N), where '/' denotes integer division, and N is the
intended chunk duration.
2. Chunk only at the consistent chunkable boundary
This algorithm will make sure the chunks from different video streams are
aligned if they have aligned GoPs. However, this algorithm will only work
for video streams. To be able to chunk non video streams at similar
positions as video streams, ChunkingHandler is designed to accept one video
input and multiple non video inputs, the non video inputs are chunked when
the video input is chunked. If the inputs are synchronized - which is true
if the inputs come from the same demuxer, the video and non video chunks
are aligned.
Change-Id: Id3bad51ab14f311efdb8713b6cd36d36cf9e4639
Aaron Vaage
KongQun Yang
Haoming Chen
Haoming Chen