- 03 May, 2020 6 commits
-
-
Andreas Rheinhardt authored
This has previously only been checked if the chapters were initially available, but not if they were only written in the trailer. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Up until now ff_vorbiscomment_write() used the bytestream API to write VorbisComments. Therefore the caller had to provide a sufficiently large buffer to write the output. Yet two of the three callers (namely the FLAC and the Matroska muxer) actually want the output to be written via an AVIOContext; therefore they allocated buffers of the right size just for this purpose (i.e. they get freed immediately afterwards). Only the Ogg muxer actually wants a buffer. But given that it is easy to wrap a buffer into an AVIOContext this commit changes ff_vorbiscomment_write() to use an AVIOContext for its output. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
ff_vorbiscomment_write() used an AVDictionary ** parameter for a dictionary whose contents ought to be written; yet this can be replaced by AVDictionary * since commit 042ca05f; and this in turn can be replaced by const AVDictionary * to indicate that the dictionary isn't modified; the latter also applies to ff_vorbiscomment_length(). Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
If a FLAC track uses an unconventional channel layout, the Matroska muxer adds a WAVEFORMATEXTENSIBLE_CHANNEL_MASK VorbisComment to the CodecPrivate to preserve this information. And given that FLAC uses 24bit length fields, the muxer checks if the length is more than this and errors out if it is. Yet this can never happen, because we create the AVDictionary that is the source for the VorbisComment. It only contains exactly one entry that can't grow infinitely large (in fact, the length of the VorbisComment is <= 4 + 33 + 1 + 18 + strlen(LIBAVFORMAT_IDENT)). So we can simply assert the size to be < (1 << 24) - 4. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Commit 6fd300ac added support for WebM Chunk livestreaming; in this case, both the header as well as each Cluster is written to a file of its own, so that even if the AVIOContext seems seekable, the muxer has to behave as if it were not. Yet one of the added checks makes no sense: It ensures that no SeekHead is written preliminarily (and hence no SeekHead is written at all) if the option for livestreaming is set, although one should write the SeekHead in this case when writing the Header. E.g. the WebM-DASH specification [1] never forbids writing a SeekHead and in some instances (that don't apply here) even requires it (if Cues are written after the Clusters). [1]: https://sites.google.com/a/webmproject.org/wiki/adaptive-streaming/webm-dash-specificationSigned-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Since commit 4aa0665f, the dynamic buffer destined for the contents of the current Cluster is no longer constantly allocated, reallocated and then freed after writing the content; instead it is reset and reused when closing a Cluster. Yet the code in mkv_write_trailer() still checked for whether a Cluster is open by checking whether the pointer to the dynamic buffer is NULL or not (instead of checking whether the position of the current Cluster is -1 or not). If a Cluster was not open, an empty Cluster would be output. One usually does not run into this issue, because unless there are errors, there are only three possibilities to not have an opened Cluster at the end of writing a packet: The first is if one sent an audio packet to the muxer. It might trigger closing and outputting the old Cluster, but because the muxer caches audio packets internally, it would not be output immediately and therefore no new Cluster would be opened. The second is an audio packet that does not contain data (such packets are sometimes sent for side-data only, e.g. by the FLAC encoder). The only difference to the first scenario is that such packets are not cached. The third is if one explicitly flushes the muxer by sending a NULL packet via av_write_frame(). If one also allows for errors, then there is also another possibility: Caching the audio packet may fail in the first scenario. If one calls av_write_trailer() after the first scenario, the cached audio packet will be output when writing the trailer, for which a Cluster is opened and everything is fine; because flushing the muxer does currently not output the cached audio packet (if one is cached), the issue also does not exist if an audio packet has been cached before flushing. The issue only exists in one of the other scenarios. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
- 02 May, 2020 19 commits
-
-
Limin Wang authored
Please tested with below command: ./ffmpeg -i ../fate-suite/mpeg2/t.mpg -c:v prores_aw -color_primaries bt2020 -colorspace bt2020_ncl -color_trc smpte2084 -an output.mov mediainfo outout.mov ... Color primaries : BT.2020 Transfer characteristics : PQ Matrix coefficients : BT.2020 non-constant ./ffmpeg -i ../fate-suite/mpeg2/t.mpg -c:v prores_aw -color_primaries bt2020 -colorspace bt2020_ncl -color_trc arib-std-b67 -an output.mov mediainfo outout.mov ... Color primaries : BT.2020 Transfer characteristics : HLG Matrix coefficients : BT.2020 non-constant Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
It's based on the following specs: RDD 45:2017 - SMPTE Registered Disclosure Doc - Interoperable Master Format - Application ProRes Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
It's based on the following specs: RDD 36:2015 - SMPTE Registered Disclosure Doc - Apple ProRes Bitstream Syntax and Decoding Process Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Marton Balint authored
Signed-off-by: Marton Balint <cus@passwd.hu>
-
Marton Balint authored
Signed-off-by: Marton Balint <cus@passwd.hu>
-
Marton Balint authored
Signed-off-by: Marton Balint <cus@passwd.hu>
-
vectronic authored
Signed-off-by: vectronic <hello.vectronic@gmail.com> Signed-off-by: Marton Balint <cus@passwd.hu>
-
Michael Niedermayer authored
Fixes: signed integer overflow: -193177 * 11585 cannot be represented in type 'int' Fixes: 20557/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VP9_fuzzer-5704852816789504 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: left shift of negative value -1 Fixes: 21390/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-6242539519868928 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: left shift of negative value -8321365 Fixes: 20506/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMALOSSLESS_fuzzer-4798062906310656 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: signed integer overflow: -16 * 134217879 cannot be represented in type 'int' Fixes: 20492/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DST_fuzzer-5639509530378240 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
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Carl Eugen Hoyos authored
Fixes ticket #8649. Reported-by: irc user Xogium
-
Sebastian Dröge authored
linear. Instead of mixing these in the calculations, convert the former first to have all following calculations in the same unit. Signed-off-by: Kyle Swanson <k@ylo.ph>
-
- 01 May, 2020 15 commits
-
-
Timo Rothenpieler authored
The old approach used some highly complex delta computation math and output-delaying. I do not remember what the initial reasoning behind that was, but given that we can just offset the dts by the amount of bframes, it seems wholy unnecessary. This leaves open an issue with VFR content, for which some more complex logic might be needed. Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
-
Piotr Oleszczyk authored
Due to a typo, it was impossible to write 0.595 / -4.5 dB of ltrt_cmixlev, ltrt_surmixlev, loro_cmixlev, loro_surmixlev. Without any error 0.841 / -1.5 dB was written to file. Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Fixes: out of array write Fixes: Regression since f619e1ecReviewed-by: Lynne <dev@lynne.ee> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Derek Buitenhuis authored
Rav1e currently uses the time base given to it only for ratecontrol... where the inverse is taken and used as a framerate. So, do what we do in other wrappers and use the framerate if we can. Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
-
Timo Rothenpieler authored
Fixes ticket #7303 Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
-
Marton Balint authored
Sequence numbers of segments should be unique, if an encoder is using shorter than 1 second segments and it is restarted, then future segments will be using already used sequence numbers if initial sequence number is based on the number of seconds since epoch and not microseconds. Signed-off-by: Marton Balint <cus@passwd.hu>
-
Marton Balint authored
Fixes problems when non-rational options were set using rational expressions, causing rounding errors and the option range limits not to be enforced properly. ffmpeg -f lavfi -i "sine=r=96000/2" This caused an assertion failure with assert level 2. Signed-off-by: Marton Balint <cus@passwd.hu>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Andreas Rheinhardt authored
Reindentation as well as marking several variables used for demuxing RealAudio as const to clearly see that they don't change during demuxing. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The Matroska demuxer has three functions for creating packets out of the data read: One for certain RealAudio codecs (ATRAC3, cook, sipr, RealAudio 28.8), one for WebVTT (actually, the WebM flavour of it) and one for all the others. Only the last function supported Matroska's ContentCompression (e.g. it reversed zlib compression or added the removed headers to the packets). But in Matroska, all tracks are allowed to be compressed. This commit adds support for this. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
There is no need to recheck this for every frame. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-