This commit:
1. Reads the WebM and Matroska ContentEncryption subelements.
2. Creates a GST_PROTECTION event for each ContentEncryption, which
will be sent before pushing the first source buffer.
The DRM system id field in this event is set to GST_PROTECTION_UNSPECIFIED_SYSTEM_ID,
because it isn't specified neither by Matroska nor by the WebM spec.
3. Reads the protection information of encrypted Block/SimpleBlock and
extracts the IV and the partitioning format (subsamples).
4. Creates the metadata protection for each encrypted Block/SimpleBlock,
with those informations: KeyID (extracted from ContentEncryption element),
IV and partitioning format.
5. Adds a new caps for WebM encrypted content named "application/x-webm-enc",
with the following new fields:
"encryption-algorithm": The encryption algorithm used.
values: "None", "DES", "3DES", "Twofish", "Blowfish", "AES".
"encoding-scope": The field that describes which Elements have been modified.
Values: "frame", "codec-data", "next-content".
"cipher-mode": The cipher mode used in the encryption.
Values: "None", "CTR".
https://bugzilla.gnome.org/show_bug.cgi?id=765275
Currently matroskademux does not emit no-more-pads until the first
Cluster is parsed, even though the Tracks have already been parsed and
from that point on there can be no more tracks.
This is important in MSE because the browser needs to know when the MSE
initialization segment has been completely parsed so that it can expose
the tracks to the user. Some applications depend on this been done
before they feed frames to the demuxer.
As a consequence, historically WebKit has relied on hacks such as
listening to the `pad-added` event, which made impossible to support
multiple tracks in the same file. Let's fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=797187
This patch allows matroskademux to parse a second Tracks element,
erroring out if the tracks are not compatible (different number, type or
codec) and emitting new caps and tag events should they have changed.
https://bugzilla.gnome.org/show_bug.cgi?id=793333
This splits gst_matroska_demux_add_stream() into:
* gst_matroska_demux_parse_stream(): will read the Matroska bytestream
and fill a GstMatroskaTrackContext.
* gst_matroska_demux_parse_tracks(): will check there are no repeated
tracks.
* gst_matroska_demux_add_stream(): creates and sets up the pad for the
track.
https://bugzilla.gnome.org/show_bug.cgi?id=793333
This is necessary for MSE, where a new MSE initialization segment may be
appended at any point. These MSE initialization segments consist of an
entire WebM file until the first Cluster element (not included). [1]
Note that track definitions are ignored on successive headers, they must
match, but this is not checked by matroskademux (look for
`(!demux->tracks_parsed)` in the code).
Source pads are not altered when the new headers are read.
This patch has been splitted from the original patch from eocanha in [2].
[1] https://www.w3.org/TR/mse-byte-stream-format-webm/
[2] https://bug334082.bugzilla-attachments.gnome.org/attachment.cgi?id=362212https://bugzilla.gnome.org/show_bug.cgi?id=793333
If we have cluster prev size (GStreamer muxer will write it by default),
we can go back to the previous cluster efficiently, but if we don't then
just search backwards until we find a cluster ebml identifier, like we
do when searching for clusters in the bisection loop.
Add property instead of hardcoding it in the code.
In some scenarios such as CCTV variable fps and extra long GOPs are
used to minimise storage space, for example. In those cases there might
not be any keyframes for many minutes, so provide a property to override
the max allowed distance.
https://bugzilla.gnome.org/show_bug.cgi?id=790696
When seeking in pull mode without an index (because there is no index
or the file is still being written to) we bisect to find the right
cluster to jump to. However, it's possible the cluster we found doesn't
start with a keyframe, which leads to decoding errors, so if we know
that the found cluster starts with a delta frame try to scan back to
previous clusters until we find one that starts with a keyframe or
we are back at the beginning. Theoretically it's possible that all
clusters but the first one do not start with a keyframe and the
keyframes are in the middle of clusters, but this is extremely
unusual, so we will cover this case with a basic sanity check.
This problem is especially problematic with content recorded with
dynamic GOP and FPS, where long GOP lengths and low FPS may cause a
large set of clusters to lack key frames. Playback would then be
started on a non-keyframe cluster, and the large number of such frames
would make the content impossible to decode fo a long stretch of time.
Based on patch by: Mats Lindestam <matslm@axis.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790696
This is useful for reverse playback/trickmodes
without an index, and will also be useful in the
seek handler if we need to scan back to find a cluster
that starts with a keyframe.
https://bugzilla.gnome.org/show_bug.cgi?id=790696
This is an enum not a boolean, and a value of 2 signals
that the video is progressive, but we would mistakenly set
interlace-mode=mixed on the output caps.
https://bugzilla.gnome.org/show_bug.cgi?id=787206
... and forward colorimetry to downstream. The Colour element describes
various color information (similar to 'colr' box in isobmff).
Note that, due to the comparatively limited syntax for color information
in vpx codecs, the color information in mkv/wemb container level
should be used for sophisticated color handling (e.g., HDR video).
https://bugzilla.gnome.org/show_bug.cgi?id=790023
Similar to what was done in adaptivedemux, ignore seek
events we've already handled - such as when they are received
on every srcpad of files with lots of streams.
After finding a cluster id in the byte reader, we skip ahead the reader
position by one further byte to be able to continue searching from there
inside the same chunk if the cluster candidate was a false positive.
We have to accomodate for that additional byte when resuming the search,
otherwise all following pulls are off-by-one for every resume and we run
into an assertion.
matroskademux would take the GST_OBJECT_LOCK in
- gst_matroska_demux_push_codec_data_all()
- gst_matroska_demux_query()
Some parse element such as FLAC checks upstream seekability, and
there is some use cases that matroska-demux is linked to a parse element
(e.g.,FLAC format) without intermediate elements (e.g., queue).
In this case, matroska-demux never returns from _push_codec_data_all()
because the parser can return only after it receives the response to
the upstream query, but that's not going to happen because it's
deadlocked.
Elements must not hold the object lock whilst pushing out events
or data.
https://bugzilla.gnome.org/show_bug.cgi?id=766645
Send GAP events for non-subtitle streams too if they lag too much
behind, but use a higher threshold than for subtitles.
This helps with fixing prerolling with a file where one of the
audio streams only has data starting from 19s onwards. It's not
a complete fix yet, it also requires changes elsewhere, such as
in baseparse, to make sure caps are propagated.
https://bugzilla.gnome.org/show_bug.cgi?id=614460https://bugzilla.gnome.org/show_bug.cgi?id=753899
