- 13 Apr, 2020 13 commits
-
-
Michael Bradshaw authored
The switch cases were missing: - Primaries: bt470m, film, smpte428, and ebu3213. - TRCs: gamma22, gamma28, linear, log, log_sqrt, iec61966_2_4, bt1361, iec61966_2_1, bt2020_10bit, and bt2020_12bit. - Space: rgb, fcc, ycgco, bt2020_cl, smpte2085, chroma-derived-nc, chroma-derived-c, and ictcp. They also annoyingly remapped the following (which are functionally equivalent but can be treated differently by clients): - smpte240m primaries to smpte170m. - smpte170m TRC to bt709. - bt470bg color space to smpte170m. The enum values in FFmpeg are the same values as ITU-T H.273 and ISO/IEC 23001-8 so we can just use them directly, which is both simpler and preserves the user intent. Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
-
Paul B Mahol authored
-
Linjie Fu authored
Verified with ./configure --enable-vaapi --disable-hwaccel=hevc_vaapi Failure reported in: http://fate.ffmpeg.org/report.cgi?time=20200401135031&slot=x86_64-archlinux-gcc-randomSigned-off-by: Linjie Fu <linjie.fu@intel.com>
-
Andreas Rheinhardt authored
Up until now, mkv_write_track() received the index of the stream whose header data it is about to write as parameter; this index has until recently been explicitly used to generate both TrackNumber and TrackUID. But this is no longer so and as there is no reason why the function for writing a single TrackEntry should even know the index of the TrackEntry it is about to write, said index is replaced in the list of function parameters by the corresponding AVStream and mkv_track. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
mkv_cuepoint (the structure used to store the index entries in the Matroska muxer) currently contains fields for both the index of the packet's stream in the AVFormatContext.streams array and for the Matroska TrackNumber; correspondingly, mkv_add_cuepoint() has parameters for both. But these two numbers can't be chosen independently, so get rid of the TrackNumber. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Attachments are streams in FFmpeg, but they are not tracks in Matroska. Yet they were counted when checking a limit for the number of tracks that the Matroska muxer imposes. This is unnecessary and has been changed. Also use unsigned variables for the variables denoting TrackNumbers as negative TrackNumbers are impossible. (The Matroska file format actually has practically no limit on the number of tracks and this is purely what our muxer supports. But even if this limit were removed/relaxed in the future, it still makes sense to use small TrackNumbers as this patch does, because greater numbers need more bytes to encode.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
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>
-
Andreas Rheinhardt authored
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>
-
Andreas Rheinhardt authored
This commit reuses the random seed generated in mkv_init() (to determine the TrackUIDs) for the SegmentUID in order to avoid a potentially expensive call to av_get_random_seed(). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Up until now, the TrackUID of a Matroska track which is supposed to be random was not random at all: It always coincided with the TrackNumber which is usually the 1-based index of the corresponding stream in the array of AVStreams. This has been changed: It is now set via an AVLFG if AVFMT_FLAG_BITEXACT is not set. Otherwise it is set like it is set now (the only change happens if an explicit track number has been chosen via dash_track_number, because the system used in the normal situation is now used, too). In particular, no FATE tests need to be updated. This also fixes a bug in case the dash_track_number option was used: In this case the TrackUID was set to the provided number, but the tags were written with a TagTrackUID simply based upon the index, so that the tags didn't apply to the track they ought to apply to. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
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>
-
Andreas Rheinhardt authored
AVChapters have an int as id field and therefore this value can appear <= 0. When remuxing from Matroska, this value actually contains the lower 32 bits of the original ChapterUID (which can be 64 bits). In order to ensure that the ChapterUID is always > 0, they were offset as follows (since 07704c61): First max(0, 1LL - chapter[i].id) was computed and stored in an uint32_t. And then the IDs were offset using this value. This has two downsides: 1. It does not ensure that the UID is actually != 0: Namely if there is a chapter with id == INT_MIN, then the offset will be 2^31 + 1 and a chapter with id == INT_MAX will become 2^31 - 1 + 2^31 + 1 = 2^32 = 0, because the actual calculation was performed in 32 bits. 2. As soon as a chapter id appears to be negative, a nontrivial offset is used, so that not even a ChapterUID that only uses 32 bits is preserved. So change this by treating the id as an unsigned value internally and only offset (by 1) if an id vanishes. The actual offsetting then has to be performed in 64 bits in order to make sure that no UINT32_MAX wraps around. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Gyan Doshi authored
-
- 12 Apr, 2020 8 commits
-
-
Marton Balint authored
Signed-off-by: Marton Balint <cus@passwd.hu>
-
Andreas Rheinhardt authored
According to C99, there has to be at least one argument for every ... in a variadic function-like macro. In practice most (all?) compilers also allow to leave it completely out, but it is nevertheless required: In a variadic macro "there shall be more arguments in the invocation than there are parameters in the macro definition (excluding the ...)." (C99, 6.10.3.4). CBS (not the framework itself, but the macros used in the cbs_*_syntax_template.c files) relies on the compiler allowing to leave a variadic macro argument out. This leads to warnings when compiling in -pedantic mode, e.g. "warning: must specify at least one argument for '...' parameter of variadic macro [-Wgnu-zero-variadic-macro-arguments]" from Clang. Most of these warnings can be easily avoided: The syntax_templates mostly contain helper macros that expand to more complex variadic macros and these helper macros often omit an argument for the .... Modifying them to always expand to complex macros with an empty argument for the ... at the end fixes most of these warnings: The number of warnings went down from 400 to 0 for cbs_av1, from 1114 to 32 for cbs_h2645, from 38 to 0 for cbs_jpeg, from 166 to 0 for cbs_mpeg2 and from 110 to 8 for cbs_vp9. These eight remaining warnings for cbs_vp9 have been fixed by switching to another macro in cbs_vp9_syntax_template: The fixed values for the sync bytes as well as the trailing bits for byte-alignment are now read via the fixed() macro (this also adds a check to ensure that trailing bits are indeed zero as they have to be). Reviewed-by: Mark Thompson <sw@jkqxz.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Carl Eugen Hoyos authored
Do not limit the array allocation functions and av_calloc() to allocations of INT_MAX, instead depend on max_alloc_size like av_malloc(). Allows a workaround for ticket #7140.
-
Andreas Rheinhardt authored
Forgotten in ab502fab. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Michael Niedermayer authored
Fixes: Timeout (147sec -> 1sec) Fixes: 20764/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ZEROCODEC_fuzzer-5068274603917312 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: Infinite loop Fixes: Ticket8594 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Rosen Penev authored
On other platforms, the functions are named get_cabac_inline_xxx but not this one. There's also a define. Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 11 Apr, 2020 19 commits
-
-
Peter Ross authored
fix link error introduced in 481ebb1cSigned-off-by: Peter Ross <pross@xvid.org> Reviewed-by: Anton Khirnov <anton@khirnov.net>
-
James Zern authored
tradeof -> trade-off Signed-off-by: James Zern <jzern@google.com>
-
Wang Cao authored
Signed-off-by: Wang Cao <wangcao@google.com> Signed-off-by: James Zern <jzern@google.com>
-
John Stebbins authored
dts would start over at the beginning of each trun when they should be computed contiguously for each trun in a traf Fixes ticket 8070 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
John Stebbins authored
If some but not all moof's are referenced in an sidx, whole fragments were being skipped. Fixes tickets 7377, 7389, and 8502 Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: shift exponent 32 is too large for 32-bit type 'int' Fixes: 21200/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_XAN_DPCM_fuzzer-5754704894361600 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Gautam Ramakrishnan authored
The calculation of precinct boundaries has been fixed. The precinct boundaries were calculated as an offset to the band boundary, but must instead be calculated as an offset from the reslevel. This patch fixes #4669 and #4679. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Gautam Ramakrishnan authored
This patch fixes an error where the COC marker overrides all data of the SPcod field of the COD marker. It must override only one bit of SPcod field. This now allows p0_08.j2k to be decoded correctly (mentioned in #4679). Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Andreas Rheinhardt authored
This is required to use it as an AVCodec.supported_samplerates array. Adding the sentinel has been forgotten in 4679a474. Without it e.g. the FATE-test ffmpeg-filter_complex_audio fails with ASAN. Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Zane van Iperen authored
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
-
Carl Eugen Hoyos authored
-
Carl Eugen Hoyos authored
Fixes ticket #7113.
-
Carl Eugen Hoyos authored
Modes > MODE_SID are already filtered out at this point. Simplifies the following change.
-
Rosen Penev authored
Place HAVE_MIPSFPU further up so that functions that use floating point ASM are defined away. Otherwise compilation failures result when soft float in enabled on the toolchain. Signed-off-by: Rosen Penev <rosenp@gmail.com>
-
Carl Eugen Hoyos authored
-
Mattias Wadman authored
Regression since 8d3630c5 where keys were changed to not be touppered but the picture block strcmp was not changed to be case-insensitive. Fixes ticket #8608.
-
John Stebbins authored
This was inadvertantly removed in 4a9d32baReviewed-by: Gyan Doshi <ffmpeg@gyani.pro>
-
Gyan Doshi authored
-
Gyan Doshi authored
Deprecated in 2015 in 8bc708fc
-