- 03 Apr, 2020 7 commits
-
-
Andreas Rheinhardt authored
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Paul B Mahol authored
-
Andreas Rheinhardt authored
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>
-
Andreas Rheinhardt authored
When updating the Tags at the end, the Matroska muxer would twice check for whether (!mkv->is_live) is true, despite this code being only executed if it is. Furthermore, a loop iterates over all the streams even when there is no Tags element to update at all, because the check for whether there are Tags is only performed later. This commit fixes this. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
avio_close_dyn_buf() has a bug: When the write pointer does not point to the end of the written data when calling it (i.e. when one has performed a seek back to update already written data), it would not add padding to the end of the buffer, but to the current position, overwriting other data; furthermore the reported size would be wrong (off by the amount of data it has overwritten with padding). In order not to run into this when updating already written elements or elements for which size has only been reserved, the Matroska muxer would first record the current position of the dynamic buffer, then seek to the desired position, perform the update and seek back to the earlier position. But now that end_ebml_master_crc32() does not make use of avio_close_dyn_buf() any more, this is no longer necessary. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The Matroska muxer uses a dynamic buffer to buffer the content of Clusters before eventually writing them. Up until now, each time a Cluster was written, the dynamic buffer was closed, i.e. freed; now it is only reset, saving allocations of the AVIOContext itself, its opaque as well as most of the reallocations of the buffer. This is advantageous performance-wise, in particular on systems where reallocations are slow (namely Windows). The following table shows the decicyles for writing a frame on Linux (Ubuntu 19.10) and Windows (7) on an x64 Haswell (to /dev/null on Linux, to stdout which is discarded on Windows (the default values of the size and duration of clusters for seekable output have been explicitly set in this case); in all tests, writing CRC-32 values has been disabled in all tests; calls to the muxer's write_packet function in write_packet() in libavformat/mux.c have been timed; each of the following tests has been repeated 50 times): | Windows before | Windows after | Linux before | Linux after _________________________________________________________________ A | 979437 | 192304 | 259500 | 183320 B | 715936 | 155648 | 152786 | 130879 C | 265115 | 56034 | 78496 | 53243 D | 386224 | 80307 | 128894 | 75354 E | 21732 | 10695 | 11320 | 9801 (A is a 10.2 mb/s file with a GOP length of 2s, amounting to an average Cluster size of about 2.5 MiB; the average Cluster size of B is 1.1 MiB; for C it is 2.35 MiB, for D it is 0.46 MiB; for E - a file with just a single audio track of 158kb/s resulting in a Cluster size of about 100 kB, the relative gains were the smallest, probably because of the small Cluster size.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Guo, Yejun authored
vf_dnn_processing.c recently changed to use swscale to trasfer data between AVFrame and dnn model. Signed-off-by: Guo, Yejun <yejun.guo@intel.com> Signed-off-by: Linjie Fu <linjie.fu@intel.com>
-
- 02 Apr, 2020 18 commits
-
-
John Rummell authored
If the buffer doesn't contain enough bytes when reading a stream, fail rather than continuing on with initialized data. Caught by Chromium fuzzeras (crbug.com/1065731). Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Ruiling Song authored
Signed-off-by: Ruiling Song <ruiling.song@intel.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
David Michael authored
Using a compiler with a different host triplet is considered cross-compiling, even when it is for the same architecture as the build system. With such a cross-compiler, it is still valid to optimize builds with --cpu=host. Make the condition that aborts in this case into a warning instead, since a cross-compiler for an incompatible architecture will fail with -mtune=native anyway. Signed-off-by: David Michael <fedora.dm0@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Andreas Rheinhardt authored
containing updated extradata, in this case a new FLAC streaminfo. Furthermore, it also tests that the Matroska muxer is able to preserve uncommon channel layouts by adding Vorbis comments to the CodecPrivate. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The hnm demuxer's context struct contained lots of fields that are write-only variables or that are not used outside of parsing the header and that can therefore be replaced by local variables of hnm_read_header(). This commit removes all of these from the context; the second type has been replaced by local variables. An AVPacket (that was initialized when reading the header and for which dead code to unreference it existed in hnm_read_close()) is among the removed things. Removing it allowed to remove hnm_read_close() altogether and also removes another instance of usage of sizeof(AVPacket). Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Writing the language of WebVTT in WebM proceeded differently than the language of all other tracks: In case no language was given, it does not write anything instead of "und" (for undefined). Because the default value of the Language element in WebM (that inherited it from Matroska) is "eng" (for English), any such track will actually be flagged as English. Doing it this way goes back to commit 509642b4 (the commit adding support for WebVTT) and no reason for this has been given in the commit message or in the discussion about this patch on the mailing list; the best I can think of is this: the WebM wiki contains "The srclang attribute is stored as the Language sub-element." Someone unfamiliar with default values in Matroska/WebM could interpret this as meaning that no Language element should be written if the language is unknown. And this is wrong and this commit changes it. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Also remove { } after an if if there is only one statement inside { }. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
mkv_write_track() currently has three places where it checks for whether the current codec type is audio: One in a switch and two outside of it. These checks can be combined by moving the code after the other two checks inside the audio-related part of the switch. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Reserving space in Matroska works by writing a Void element. And until now this worked as follows: The current position was recorded and the EBML ID as well as the length field written; then the new position was recorded to know how much more to write. Afterwards the actual writing has been performed via ffio_fill(). But it is unnecessary to explicitly use the positions (obtained via avio_tell()) to find out how much still needs to be written, because the length of the ID and the length field are known. So rewrite the function to no longer use them. Also, given that ffio_fill() uses an int parameter and given that no current caller (and no sane future caller) will want to reserve several GB of space, make the size parameter of put_ebml_void() itself an int. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
When the Cues are written in front of the Cluster, the muxer would seek to the beginning (to where the Cues ought to be written) and write the Cues; afterwards it would seek back to the end of the file only to seek to the beginning once again to update several elements there. This commit removes the seek to the end. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The Matroska muxer has the ability to write the Cues (the index) at the beginning of the file (in front of the Cluster): The user inputs the amount of space that should be reserved at the beginning of the file and if this is sufficient, the Cues will be written there and the part of the reserved space not used up by the Cues will be filled with a "Void" element. There is just one problem with this: One can not fill a single byte this way, because said Void element is minimally two bytes long (one byte ID, one byte length field). Up until now, if one reserved one byte more than needed, one would run into an assert when writing the Void element. There are two solutions for this: Error out if it happens. Or adjust the length field of the Cues in order to ensure that the above situation can't happen (i.e. write the length on one byte more than necessary). The first solution is very unsatisfactory, as enough space has been reserved. Therefore this commit implements the second solution. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
When the user opted to write the Cues at the beginning, the Cues were simply written without checking in advance whether enough space has been reserved for them. If it wasn't enough, the data following the space reserved for the Cues was simply overwritten, corrupting the file. This commit changes this by checking whether enough space has been reserved for the Cues before outputting anything. If it isn't enough, no Cues will be output at all and the file will be finalized normally, yet writing the trailer will nevertheless return an error to notify the user that his wish of having Cues at the front of the file hasn't been fulfilled. This change opens new usecases for this option: It is now safe to use this option to e.g. record live streams or to use it when muxing the output of an expensive encoding, because when the reserved space turns out to be insufficient, one ends up with a file that just lacks Cues but is otherwise fine. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Andreas Rheinhardt authored
The Matroska muxer currently assumed WavPack version 4.03 in case it was not explicitly signalled via extradata; but following a recommendation from David Bryant, the WavPack creator, this is changed to 4.10. Reviewed-by: David Bryant <david@wavpack.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
It might be used by the Matroska muxer. This is also the reason why the FATE-tests for muxing WavPack into Matroska needed to be updated: They now write the correct version 4.07 and not 4.03 as before. Reviewed-by: David Bryant <david@wavpack.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
mkvmerge versions 6.2 to 40.0 had a bug that made it not propagate the WavPack extradata (containing the WavPack version) during remuxing from a Matroska file; currently our demuxer would treat every WavPack block encountered as invalid data (unless the WavPack stream is to be discarded (i.e. the streams discard is >= AVDISCARD_ALL)) and try to resync to the next level 1 element. Luckily, the WavPack version is currently not really important; so we fix this problem by assuming a version. David Bryant, the creator of WavPack, recommended using version 0x410 (the most recent version) for this. And this is what this commit does. A FATE-test for this has been added. Reviewed-by: David Bryant <david@wavpack.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
- 01 Apr, 2020 9 commits
-
-
John Rummell authored
Found by Chromium fuzzers (crbug.com/1057205). Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
John Rummell authored
If the buffer doesn't contain enough bytes when reading a stream, fail rather than continuing on with unitialized data. Caught by Chromium fuzzers (crbug.com/1054229). Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Bradshaw authored
The clli atom isn't in ISO/IEC 14496-12:2015 so the flag is marked as experimental and the clli atom is not written by default. The clli atom is already parsed by FFmpeg in mov.c. Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
-
Carl Eugen Hoyos authored
Fixes ticket #8591.
-
Andreas Rheinhardt authored
1. When set_parameters was removed from AVOutputFormat in 2fb75019, it was forgotten to remove the comment pertaining to it. Said comment now appeared to apply to interleave_packet(); it is of course nonsense and has been replaced by an accurate description. 2. The description of av_write_uncoded_frame() suggested av_interleaved_write_frame() as a replacement if the input is not already correctly interleaved; it also referred to said function for details. Given that said function can't write AVFrames and that the specifics of writing uncoded frames are explained in the description of av_interleaved_write_uncoded_frame(), both references have been fixed. 3. Removed an outdated comment about avformat_seek_file(). Reviewed-by: Marton Balint <cus@passwd.hu> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andriy Gelman authored
struct v4l2_selection contains reserved bytes which should be set to zero before the ioctl call. Fixes valgrind error: Syscall param ioctl(VKI_V4L2_S_SELECTION) points to uninitialised byte(s) Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
-
Andreas Rheinhardt authored
If ff_interleave_add_packet failed, the content of the newly created packet new_pkt would leak. Also, it is unnecessary to zero-initialize a packet that will be put into av_new_packet lateron as the latter already initializes the packet. Therefore this has been removed, too. Reviewed-by: Marton Balint <cus@passwd.hu> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
It is unnecessary to call prepare_input_packet if there is no packet as it doesn't do anything, except when the currently inactive code guarded by !FF_API_COMPUTE_PKT_FIELDS2 || !FF_API_LAVF_AVCTX becomes active: Then attempting to access pkt->stream_index will crash. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
If one calls av_opt_set() with an incorrect string to set the value of an option of type AV_OPT_TYPE_VIDEO_RATE, the given string is used in a log message via %s. This also happens when the string is actually a nullpointer in which case using it for %s is forbidden. This commit changes this by erroring out early in case of a nullpointer. This also fixes a warning from GCC 9.2: "‘%s’ directive argument is null [-Wformat-overflow=]" Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
- 31 Mar, 2020 3 commits
-
-
Ming Qian authored
Currently the driver's frame period is incorrectly set to the frame rate. This is fixed in the commit. Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
-
Michael Niedermayer authored
Fixes: out of array read Fixes: 21286/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HCA_fuzzer-5683183715876864 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
rcombs authored
git only supports <new> <old>, not <new> <old1> <old2>
-
- 30 Mar, 2020 3 commits
-
-
Carl Eugen Hoyos authored
Reported-by: Forum user NewPlaza
-
Andreas Rheinhardt authored
Don't use typedef struct MXFTrack {...} MXFTimecodeComponent, in particular given the fact that MXFTrack is a type of its own. Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
before setting the field indicating that a Cluster has been opened. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-