[FFmpeg-devel] [PATCH] lavf: stop filtering side data in mkv

Andreas Rheinhardt andreas.rheinhardt at gmail.com
Mon Feb 10 23:22:24 EET 2020

On Mon, Feb 10, 2020 at 9:54 PM Michael Bradshaw <
mjbshaw-at-google.com at ffmpeg.org> wrote:

> matroskaenc.c currently only allows BlockMore elements if the BlockAddID is
> 1. Recently YouTube has been using BlockAddID == 4 for HDR10+ dynamic
> metadata (see [1]), which FFmpeg drops because of its filtering.
> The attached patch changes matroskaenc.c so it stops filtering
> by BlockAddID, allowing FFmpeg to retain metadata from WebM and Matroska
> streams when remuxing.
> [1]: https://www.webmproject.org/docs/container/#BlockAddID
1. This partially overlaps and partially conflicts with [2]. The problem
here is that Matroska has redone the BlockAdditions: Only BlockAdditions
with BlockAddID equal to one are now codec-specific (and its content has to
be described in the Codec Mapping (if the codec uses BlockAdditions)); the
other values now belong to more codec-agnostic structures that depend on
new elements that need to be written in the corresponding TrackEntry. We
currently don't support writing these elements (and no such Block
Additional Mapping has been defined yet), so we should not write it for
Matroska atm. WebM is of course different in this regard. See [3] for these
new elements and [4] for a proposal of such a Block Additional Mapping.
2. The patch as-is is dangerous: There is currently no check that the size
of the BlockAdditions-side-data is at least eight; but if the data contains
zeroed padding, then the BlockAddID read will not be 1 and this check will
ensure that one does not try to write a BlockAddition with a negative size
(it would be converted to an uint64_t and therefore to a number so big that
put_ebml_num doesn't like it). So [1] would need to be applied first.
3. Anyway, your patch would allow to write BlockAdditions with a BlockAddID
of zero, although that value is illegal.

- Andreas

[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-January/256317.html
[2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-January/256318.html
[4]: https://github.com/cellar-wg/matroska-specification/pull/348

More information about the ffmpeg-devel mailing list