diff options
author | Andreas Rheinhardt <andreas.rheinhardt@gmail.com> | 2019-12-29 02:28:07 +0100 |
---|---|---|
committer | Andreas Rheinhardt <andreas.rheinhardt@gmail.com> | 2020-04-13 08:34:59 +0200 |
commit | 358b58cb290defe706dd2f5bae96b29321059dfe (patch) | |
tree | 2dad65458dda5e75ef5776ca92a0ec1c1b855687 /tests/ref/seek/acodec-pcm-s24be | |
parent | 4b18999beea72867d4ae449a3f01a32812c81ac0 (diff) | |
download | ffmpeg-358b58cb290defe706dd2f5bae96b29321059dfe.tar.gz |
avformat/matroskaenc: Remove allocations for Attachments
If there are Attachments to write, the Matroska muxer currently
allocates two objects: An array that contains an entry for each
AttachedFile containing just the stream index of the corresponding
stream and the FileUID used for this AttachedFile; and a structure with
a pointer to said array and a counter for said array. These uids are
generated via code special to Attachments: It uses an AVLFG in the
normal and a sha of the attachment data in the bitexact case. (Said sha
requires an allocation, too.)
But now that an uid is generated for each stream in mkv_init(), there is
no need any more to use special code for generating the FileUIDs of
AttachedFiles: One can simply use the uid already generated for the
corresponding stream. And this makes the whole allocations of the
structures for AttachedFiles as well as the structures itself superfluous.
They have been removed.
In case AVFMT_FLAG_BITEXACT is set, the uids will be different from the
old ones which is the reason why the FATE-test lavf-mkv_attachment
needed to be updated. The old method had the drawback that two
AttachedFiles with the same data would have the same FileUID.
The new one doesn't.
Also notice that the dynamic buffer used to write the Attachments leaks
if an error happens when writing the buffer. By removing the
allocations potential sources of errors have been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Diffstat (limited to 'tests/ref/seek/acodec-pcm-s24be')
0 files changed, 0 insertions, 0 deletions