diff options
author | Andreas Rheinhardt <andreas.rheinhardt@gmail.com> | 2019-11-20 15:10:34 +0100 |
---|---|---|
committer | Andreas Rheinhardt <andreas.rheinhardt@gmail.com> | 2020-04-03 09:04:22 +0200 |
commit | 52523b69638967341a8c211c11b1cdb5d3978f78 (patch) | |
tree | e4dcc48f6ad460e75e1c0d4620b0eb72b0226745 /libavformat/tls_libtls.c | |
parent | af97a3a4d6b9d199654ab6328c79e6be808ce6f9 (diff) | |
download | ffmpeg-52523b69638967341a8c211c11b1cdb5d3978f78.tar.gz |
avformat/matroskaenc: Improve BlockAdditions
8ffcc826 added support for muxing BlockAdditions with BlockAddID equal
to one. The restriction to BlockAddID == 1 probably resulted from
a limitation to what was needed; yet over time this led to three
occurences of "(side_data_size && additional_id == 1)". This commit
changes this by setting side_data_size to 0 if additional_id != 1.
It also stops hardcoding 1 for the value of BlockAddID to write;
but it still upholds the requirement that it is 1. See below.
Despite BlockAddId actually having a default value of 1, it is still
written, because until very recently (namely dbc50f8a) our demuxer
used a wrong default value of 0.
Furthermore, use put_ebml_binary() to write the BlockAdditional element.
(The Matroska specifications have evolved and now the BlockAddID 1 is
reserved for the codec (as described in the codec's codec mapping),
BlockMore elements with BlockAddID > 1 are now of a more
codec-independent nature and require a BlockAdditionalMapping in the
track's TrackEntry. Given that this muxer does not support writing said
BlockAdditionalMapping yet (actually, none have been defined yet), we
have to uphold the requirement that BlockAddID == 1.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Diffstat (limited to 'libavformat/tls_libtls.c')
0 files changed, 0 insertions, 0 deletions