Chiebot-Mirror/FFmpeg - FFmpeg - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Andreas Rheinhardt	750631b098	avformat/matroskaenc: Pass dispositions through unchanged by default Up until now, the Matroska muxer did not use the dispositions it is given as-is; instead it by default overrode the disposition of the first track of a kind (audio, video, subtitles) if no track of this kind has the default disposition set. And up until recently, it also enforced by default that no more than one track of each kind be marked as default. The rationale for the former is that there are lots of containers which lack the concept of default streams, so that it is not uncommon for no stream to be marked as default at all; the rationale for the latter was that up until recently, it was dubious whether the Matroska specification allowed more than one default stream for track type (e.g. mkvmerge disallowed it). It was this point which led to the implementation of the above mentioned behaviour inspired by mkvmerge. Yet the Matroska specifications have changed and now explicitly allow to set more than one track of each type as default, so that the main reason of not using the dispositions as-is was rendered moot. Therefore this commit changes the default to pass the disposition through. The matroska-mpegts-remux FATE-test has been updated to still use the old "infer" mode so that it is still covered by FATE; the matroska-zero-length-block test has also been updated to cover the infer_no_subs mode. The references for lots of other FATE tests needed to be updated because of a newly added FlagDefault element with value zero (whereas a FlagDefault with value 1 needn't be coded at all, as it coincided with the default value of said element). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	3 years ago
Andreas Rheinhardt	4ebfc13c33	avformat/matroskaenc: Don't ignore tags of chapters written late The Matroska muxer writes the Chapters early when chapters were already available when writing the header; in this case any tags pertaining to these chapters get written, too. Yet if no chapters had been supplied before writing the header, Chapters can also be written when writing the trailer if any are supplied. Tags belonging to these chapters were up until now completely ignored. This commit changes this: Writing the tags belonging to chapters has been moved to mkv_write_chapters(). If mkv_write_tags() has not been called yet (i.e. when chapters are written when writing the header), the AVIOContext for writing the ordinary Tags element is used, but not output, as this is left to mkv_write_tags() in order to only write one Tags element. Yet if mkv_write_tags() has already been called, mkv_write_chapters() will output a Tags element of its own which only contains the tags for chapters. When chapters are available initially, the corresponding tags will now be the first tags in the Tags element; but the ordering of tags in Tags is irrelevant anyway. This commit also makes chapter_id_offset local to mkv_write_chapters() as it is used only there and not reused at all. Potentially writing a second Tags element means that the maximum number of SeekHead entries had to be incremented. All the changes to FATE result from the ensuing increase in the amount of space reserved for the SeekHead (21 bytes more). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>	5 years ago
Andreas Rheinhardt	5b6e164b4b	avformat/matroskaenc: Don't waste bytes on length fields Several EBML Master elements for which a good upper bound of the final length was available were nevertheless written without giving an upper bound of the final length to start_ebml_master(), so that their length fields were eight bytes long. This has been changed. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>	5 years ago
Andreas Rheinhardt	ccadd00a4a	avformat/matroskaenc: Make output more deterministic Using random values for TrackUID and FileUID (as happens when the AVFMT_FLAG_BITEXACT flag is not set) has the obvious downside of making the output indeterministic. This commit mitigates this by writing the potentially random values with a fixed size of eight byte, even if their actual values would fit into less than eight bytes. This ensures that even in non-bitexact mode, the differences between two files generated with the same settings are restricted to a few bytes in the header. (Namely the SegmentUID, the TrackUIDs (in Tracks as well as when referencing them via TagTrackUID), the FileUIDs (in Attachments as well as in TagAttachmentUID) as well as the CRC-32 checksums of the Info, Tracks, Attachments and Tags level-1-elements.) Without this patch, there might be an offset/a size difference between two such files. The FATE-tests had to be updated because the fixed-sized UIDs are also used in bitexact mode. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>	5 years ago
Andreas Rheinhardt	358b58cb29	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>	5 years ago
Andreas Rheinhardt	bd7dea3f4f	avformat/matroskaenc: Don't waste bytes writing durations Tags in the Matroska file format can be summarized as follows: There is a level 1-element called Tags containing one or many Tag elements each of which in turn contain a Targets element and one or many SimpleTags. Each SimpleTag roughly corresponds to a single key-value pair similar to an AVDictionaryEntry. The Targets meanwhile contains information to what the metadata contained in the SimpleTags contained in the containing Tag applies (i.e. to the file as a whole or to an individual track). The Matroska muxer writes such metadata. It puts the metadata of every stream into a Tag whose Targets makes it point to the corresponding track. And if the output is seekable, then it also adds another Tag for each track whose Targets corresponds to the track and where it reserves space in a SimpleTag to write the duration at the end of the muxing process into. Yet there is no reason to write two Tag elements for a track and a few bytes (typically 24 bytes per track) can be saved by adding the duration SimpleTag to the other Tag of the same track (if it exists). FATE has been updated because the output files changed. (Tests that write to unseekable output (pipes) needn't be updated (no duration tag has ever been written for them) and the same applies to tests without further metadata.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>	5 years ago
Andreas Rheinhardt	dc2f6b54ac	avformat/matroskaenc: Avoid allocations for SeekHead Up until `e7ddafd5`, the Matroska muxer wrote two SeekHeads: One at the beginning referencing the main level 1 elements (i.e. not the Clusters) and one at the end, referencing the Clusters. This second SeekHead was useless and has therefore been removed. Yet the SeekHead-related functions and structures are still geared towards this usecase: They are built around an allocated array of variable size that gets reallocated every time an element is added to it although the maximum number of Seek entries is a small compile-time constant, so that one should rather include the array in the SeekHead structure itself; and said structure should be contained in the MatroskaMuxContext instead of being allocated separately. The earlier code reserved space for a SeekHead with 10 entries, although we currently write at most 6. Reducing said number implied that every Matroska/Webm file will be 84 bytes smaller and required to adapt several FATE tests; furthermore, the reserved amount overestimated the amount needed for for the SeekHead's length field and how many bytes need to be reserved to write a EBML Void element, bringing the total reduction to 89 bytes. This also fixes a potential segfault: If !mkv->is_live and if the AVIOContext is initially unseekable when writing the header, the SeekHead is already written when writing the header and this used to free the SeekHead-related structures that have been allocated. But if the AVIOContext happens to be seekable when writing the trailer, it will be attempted to write the SeekHead again which will lead to segfaults because the corresponding structures have already been freed. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>	5 years ago
Andreas Rheinhardt	0b61ddb576	avformat/matroskaenc: Don't waste bytes writing level 1 elements Up until now, the length field of most level 1 elements has been written using eight bytes, although it is known in advance how much space the content of said elements will take up so that it would be possible to determine the minimal amount of bytes for the length field. This commit changes this. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>	6 years ago
Andreas Rheinhardt	4e6df068b5	avformat/matroskaenc: Don't waste bytes in EBML Header Up until now the EBML Header length field has been written with eight bytes, although the EBML Header is always so small that only one byte is needed for it. This patch saves seven bytes for every Matroska/Webm file. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>	6 years ago