- 01 May, 2020 19 commits
-
-
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>
-
Andreas Rheinhardt authored
Matroska is built around the principle that a reader does not need to understand everything in a file in order to be able to make use of it; it just needs to ignore the data it doesn't know about. Our demuxer typically follows this principle, but there is one important instance where it does not: A Block belonging to a TrackEntry with no associated stream is treated as invalid data (i.e. the demuxer will try to resync to the next level 1 element because it takes this as a sign that it has lost sync). Given that we do not create streams if we don't know or don't support the type of the TrackEntry, this impairs this demuxer's forward compability. Furthermore, ignoring Blocks belonging to a TrackEntry without corresponding stream can (in future commits) also be used to ignore TrackEntries with obviously bogus entries without affecting the other TrackEntries (by not creating a stream for said TrackEntry). Finally, given that matroska_find_track_by_num() already emits its own error message in case there is no TrackEntry with a given TrackNumber, the error message (with level AV_LOG_INFO) for this can be removed. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
A Block (meaning both a Block in a BlockGroup as well as a SimpleBlock) must have at least three bytes after the field containing the encoded TrackNumber. So if there are <= 3 bytes, the Matroska demuxer would skip this block, believing it to be an empty, but valid Block. This might discard valid nonempty Blocks, namely if the track uses header stripping. And certain definitely spec-incompliant Blocks don't raise errors: Those with two or less bytes left after the encoded TrackNumber and those with three bytes left, but with flags indicating that the Block uses lacing as then there has to be further data describing the lacing. Furthermore, zero-sized packets were still possible because only the size of the last entry of a lace was checked. This commit fixes this. All spec-compliant Blocks that contain data (even if side data only) are now returned to the caller; spec-compliant Blocks that don't contain anything are not returned. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Some conditions which don't change and which can therefore be checked in read_header() were instead rechecked upon parsing each block. This has been changed. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
The Matroska demuxer splits every sequence of h Matroska Blocks into h * w / cfs packets of size cfs; here h (sub_packet_h), w (frame_size) and cfs (coded_framesize) are parameters from the track's CodecPrivate. It does this by splitting the Block's data in h/2 pieces of size cfs each and putting them into a buffer at offset m * 2 * w + n * cfs where m (range 0..(h/2 - 1)) indicates the index of the current piece in the current Block and n (range 0..(h - 1)) is the index of the current Block in the current sequence of Blocks. The data in this buffer is then used for the output packets. The problem is that there is currently no check to actually guarantee that no uninitialized data will be output. One instance where this is trivially so is if h == 1; another is if cfs * h is so small that the input pieces do not cover everything that is output. In order to preclude this, rmdec.c checks for h * cfs == 2 * w and h >= 2. The former requirement certainly makes much sense, as it means that for every given m the input pieces (corresponding to the h different values of n) form a nonoverlapping partition of the two adjacent frames of size w corresponding to m. But precluding h == 1 is not enough, other odd values can cause problems, too. That is because the assumption behind the code is that h frames of size w contain data to be output, although the real number is h/2 * 2. E.g. for h = 3, cfs = 2 and w = 3 the current code would output four (== h * w / cfs) packets. although only data for three (== h/2 * h) packets has been read. (Notice that if h * cfs == 2 * w, h being even is equivalent to cfs dividing w; the latter condition also seems very reasonable: It means that the subframes are a partition of the frames.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
RealAudio 28.8 (like other RealAudio codecs) uses a special demuxing mode in which the data of the existing Matroska Blocks is not simply forwarded as-is. Instead data from several Blocks is recombined together to output several packets. The parameters governing this process are parsed from the CodecPrivate: Coded framesize (cfs), frame size (w) and sub_packet_h (h). During demuxing, h/2 pieces of data of size cfs each are read from every Matroska (Simple)Block and put at offset m * 2 * w + n * cfs of a buffer of size h * w, where m ranges from 0 to h/2 - 1 for each Block while n is initially zero and incremented after a Block has been parsed until it is h, at which poin the assembled packets are output and n reset. The highest offset is given by (h/2 - 1) * 2 * w + (h - 1) * cfs + cfs while the destination buffer's size is given by h * w. For even h, this leads to a buffer overflow (and potential segfault) if h * cfs > 2 * w; for odd h, the condition is h * cfs > 3 * w. This commit adds a check to rule this out. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
RealAudio 28.8 does not need or use sub_packet_size for its demuxing and this field is therefore commonly set to zero. But since 18ca491b the Real Audio specific demuxing is no longer applied if sub_packet_size is zero because the codepath for cook and ATRAC3 divide by it; this made these files undecodable. Furthermore, since 569d18aa (merged in 2c8d876d) sub_packet_size being zero is used as an indicator for invalid data, so that a file containing such a track was completely skipped. This commit fixes this by not checking sub_packet_size for RealAudio 28.8 at all. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
They need a special parsing mode and in order to find out whether this mode is in use, several checks have to be performed. They can all be combined into one: If the buffer that is only used to assemble their packets has been allocated, use the RealAudio parsing mode. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
Only flavors 0..3 seem to exist. E.g. rmdec.c treats any flavor > 3 as invalid data. Furthermore, we do not know how big the packets to create ought to be given that for sipr these values are not read from the bitstream, but from a table. Furthermore, flavor is only used for sipr, so only check it for sipr; rmdec.c does the same. (The old check for flavor being < 0 was always wrong given that flavor is an int that is read via avio_rb16(), so it has been removed completely.) Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@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
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Lynne authored
Failure was due to the extra comment printed by libavcodec/utils.c since side data is used to signal the skipped samples.
-
- 30 Apr, 2020 18 commits
-
-
Limin Wang authored
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
Reviewed-by: Nicolas George <george@nsup.org> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
Lynne authored
Part of this patch is based on Paul B Mahol's patch from last year. This also allows for single-stream parameter/codec changes.
-
Lynne authored
This cleans up the code and simplifies it. It also speeds up parsing since the old pb position was incorrect.
-
Lynne authored
This makes decoding far more robust, since OggS, the ogg magic, can be commonly found randomly in streams, which previously made the demuxer think there's a new stream or a change in such.
-
Lynne authored
This also makes implementing CRC checking far simpler and more robust.
-
Limin Wang authored
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
-
James Almer authored
We only care about the right most bit. Signed-off-by: James Almer <jamrial@gmail.com>
-
Andriy Gelman authored
v4l2_m2m uses device memory mapped buffers to store dequeued frames/packets (reference counted by AVBufferRef). When the reference count drops to zero, the buffer ownership is returned back to the device, so that they can re-filled with frames/packets. There are some cases when all the capture buffers are in userspace (i.e. due to internal buffering in ffmpeg). On the s5p-mfc this causes an infinite wait when polling to dequeue the buffers, which can be prevented by increasing the total number of buffers. This commit adds a warning when all the capture buffers are dequeued. Reviewed-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
-
Martin Storsjö authored
Apparently the changes from 3c9185bf aren't enough; even with that in place, I got errors like this when trying to build for iOS: src/libavdevice/avfoundation.m:135:5: error: 'AVCaptureDeviceTransportControlsPlaybackMode' is unavailable: not available on iOS AVCaptureDeviceTransportControlsPlaybackMode observed_mode; ^
-
Paul B Mahol authored
-
Paul B Mahol authored
-
Paul B Mahol authored
Use A in calculation.
-
Paul B Mahol authored
-
Josh de Kock authored
Signed-off-by: Josh de Kock <josh@itanimul.li>
-
Andreas Rheinhardt authored
The data of an AVPacket may be a part of the data of an AVBufferRef; Therefore av_grow_packet() doesn't reallocate if the available space in the actual buffer is sufficient for the enlargement. But given that it also zeroes the padding it also needs to make sure that the buffer is actually writable; this commit implements this. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Andreas Rheinhardt authored
hdsenc already had an explicit function to free all allocations in case of an error, but it was not marked as deinit function, so that it was not called automatically when the AVFormatContext for muxing gets freed. Using an explicit deinit function also makes the code cleaner by allowing to return immediately without "goto fail". Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
-
Ming Qian authored
Enqueue/dequeue of the capture buffers should continue while draining. Reference: linux/Documentation/media/uapi/v4l/dev-decoder.rst "The client must continue to handle both queues independently, similarly to normal decode operation. This includes: ... - queuing and dequeuing CAPTURE buffers, until a buffer marked with the V4L2_BUF_FLAG_LAST flag is dequeued" Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
-
- 29 Apr, 2020 3 commits
-
-
Michael Niedermayer authored
Found-by: 黄宁 <tsukimurarin@163.com> Reviewed-by: Nick Renieris <velocityra@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
The DNG code hardcodes plane 0 at some places, so its better to disallow cases that have more planes. Fixes: eg_crash Found-by: 黄宁 <tsukimurarin@163.com> Reviewed-by: Nick Renieris <velocityra@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
Michael Niedermayer authored
This is less confusing Reviewed-by: Nick Renieris <velocityra@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-