The old code had a couple of issues that all lead to potential memory
safety bugs.
- Use a constant for the Wavpack4Header size instead of using sizeof.
It's written out into the data and not from the struct and who knows
what special alignment/padding requirements some C compilers have.
- gst_buffer_set_size() does not realloc the buffer when setting a
bigger size than allocated, it only allows growing up to the maximum
allocated size. Instead use a GstAdapter to collect all the blocks
and take out everything at once in the end.
- Check that enough data is actually available in the input and
otherwise handle it an error in all cases instead of silently
ignoring it.
Among other things this fixes out of bounds writes because the code
assumed gst_buffer_set_size() can grow the buffer and simply wrote after
the end of the buffer.
Thanks to Natalie Silvanovich for reporting.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/859
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/902>
Previously we saved the buffer_timestamp straight into
mux->cluster_time. Since the cluster time saved into the file does not
have as high precision as GstClockTime depending on the timecodescale
the rounding of relative_timestamp was invalid as mux->cluster_time
which it was calculated relative to was not equal to the cluster time
written to the matroska file.
Example of "mkvinfo -v" of how it looks before and after this change in
an scenario where previously timestamps got out of order because of this
issue.
Notice the timestamp of the SimpleBlock right before and right after the
Cluster now being in order. The consequence of this however is that the
cluster timestamp is not necessarily the same as the timestamp of the
first buffer in the cluster however (in case it's rounded up).
Before
| + SimpleBlock (track number 1, 1 frame(s), timecode 126.922s = 00:02:06.922)
| + Frame with size 432
| + SimpleBlock (track number 2, 1 frame(s), timecode 126.933s = 00:02:06.933)
| + Frame with size 329
| + SimpleBlock (track number 2, 1 frame(s), timecode 126.955s = 00:02:06.955)
| + Frame with size 333
|+ Cluster
| + Cluster timecode: 126.954s
| + Cluster previous size: 97344
| + SimpleBlock (key, track number 1, 1 frame(s), timecode 126.954s = 00:02:06.954)
| + Frame with size 61239
| + SimpleBlock (track number 2, 1 frame(s), timecode 126.975s = 00:02:06.975)
| + Frame with size 338
After
| + SimpleBlock (track number 1, 1 frame(s), timecode 135.456s = 00:02:15.456)
| + Frame with size 2260
| + SimpleBlock (track number 2, 1 frame(s), timecode 135.468s = 00:02:15.468)
| + Frame with size 332
| + SimpleBlock (track number 2, 1 frame(s), timecode 135.490s = 00:02:15.490)
| + Frame with size 335
|+ Cluster
| + Cluster timecode: 135.489s
| + Cluster previous size: 158758
| + SimpleBlock (key, track number 1, 1 frame(s), timecode 135.490s = 00:02:15.490)
| + Frame with size 88070
| + SimpleBlock (track number 2, 1 frame(s), timecode 135.511s = 00:02:15.511)
| + Frame with size 336
Add a property that makes it possible for an application to set the
DateUTC header field in matroska files. This is useful for live feeds,
where the DateUTC header can be set to a UTC timestamp, matching the
beginning of the file.
Needs gstreamer!323
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/481
Various audio formats require an audio lead-in to decode it properly.
Most parsers would take care of it, but when a container like matroska is
involved, the demuxer handles the seeking and without its own lead-in
handling would never even pass the lead-in data to the parser.
This commit provides an initial implementation of that for audio/mpeg,
audio/x-ac3 and audio/x-eac3 by calculating the worst case lead-in time
needed from known samplerate, potential lead-in frames need and the
maximum blocksize possible for the format (as we don't parse that out
exactly in matroskademux) and seeking that much earlier in case of
accurate seeks. This is especially important for NLE use-cases with GES.
If accurate seeking to a position that happens to have a video keyframe,
it'll go back to the previous keyframe than needed, but with typical
video files that's the best we can do anyway without falling back to
scanning the clusters, as typically only keyframes are indexed in
Cueing Data.
If the media doesn't have a CUE, then we bisect for the cluster to seek
to with the same modified time as well in case of accurate seeking,
ensuring sufficient lead-in. This code path is typically hit only with
(suboptimal) audio-only matroska files, e.g. when created with ffmpeg,
which doesn't add a CUE for audio-only mkv muxing.
Clear the mastering_display_info_present field explicitly
after reallocating the track context into a video context
to avoid uninitialised warnings in valgrind
This takes the timestamp of the earliest stream and offsets it so that
it starts at 0. Some software (VLC, ffmpeg-based) does not properly
handle Matroska files that start at timestamps much bigger than zero.
Closes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/449
Modify the caps string to allow width and height greater than 4096.
There is no need to restrict it since the matroska format allows the
width and height values to be up to eight bytes long, and this also
applies to the webm subset of the format.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/550
This patch enables matroskademux to receive seeks before it reaches
GST_MATROSKA_READ_STATE_DATA.
Closes https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/514
This also enables receiving seeks in the element READY state.
When such a seek is received, it is stored to be later handled when
GST_MATROSKA_READ_STATE_DATA is reached.
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
