| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Fix fate tests with asan. Introduced during bytestream2 porting
(in revision 62cc8f4d79dad119e8efeaae080a58a8dcb1e89d).
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These variables are coming from mpegvideoenc where are supposedly used
as bit counters on various frame properties. However their use is
unclear as they lack documentation, are available only from a very small
subset of encoders, and they are hardly used in the wild. Also frame_bits
in aacenc is employed in a similar way.
Remove this functionality from AVCodecContex, these variable are mostly
frame properties, and too few encoders support setting them with anything
useful.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
Most option values are simply unused or ignored and in practice the
majory of codecs only need to check whether to enable rle or not.
Add appropriate codec private options which better expose the allowed
features.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
|
| |
We do not need to do a full setup like for a real frame, just allocate a
buffer and set cur_pic(_ptr).
|
| |
|
|
|
|
| |
EOVERFLOW seems to be unavailable on certain platforms.
|
|
|
|
| |
Also, stop using AVCodecContext for storing the stream parameters.
|
| |
|
| |
|
|
|
|
| |
Deprecate AVCodecContext.vbv_delay
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This is similar to what is done for AVStream.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fall back to maximum DPB size if the level is unknown.
This should be more spec-compliant and does not depend on the caller
setting has_b_frames before opening the decoder.
The old behaviour, when the delay is supplied by the caller setting
has_b_frames, can still be obtained by setting strict_std_compliance
below normal.
|
|
|
|
|
| |
That is a more appropriate place for it, since it is not allowed to
change between slices.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the spec, the reference list for a slice should be
constructed by first generating an initial (what we now call "default")
reference list and then optionally applying modifications to it.
Our code has an optimization where the initial reference list is
constructed for the first inter slice and then rebuilt for other slices
if needed. This, however, adds complexity to the code, requires an extra
2.5kB array in the codec context and there is no reason to think that it
has any positive effect on performance. Therefore, simplify the code by
generating the reference list from scratch for each slice.
|
| |
|
|
|
|
|
|
| |
Currently, the frame stride is passed in bytes, while the MC buffer size
is in int16_t elements, This can be confusing, so pass both strides in
bytes.
|
|
|
|
| |
This should allow for more efficient SIMD.
|
|
|
|
| |
This should allow for more efficient SIMD.
|
|
|
|
|
|
|
| |
This should allow for more efficient SIMD.
Keep the C versions as they are now, to allow the compiler to inline the
interpolation coefficients.
|
|
|
|
| |
Avoid the warning `-Wempty-body`.
|
|
|
|
|
|
| |
The end-marked was typoed in
f7edcac040f73635fc1127489c9bb29ca8b43532
|
| |
|
|
|
|
| |
Bug-Id: 761
|
|
|
|
| |
Unbreak make check.
|
|
|
|
|
|
| |
Additional improvements by Michael Niedermayer <michaelni@gmx.at>.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
| |
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
| |
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
|
|
|
|
| |
Fixes out of array reads.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
|
|
|
| |
Copy pointers to AVPicture after memory has been allocated.
Fixes NULL pointers in AVPicture after a17a7661906ba295d67afd80ac0770422e1b02b3.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
|
|
|
| |
Silences warnings when using -Wshift-overflow (GCC 6+).
Found-by: James Almer <jamrial@gmail.com>
|
|
|
|
| |
Use the result directly, removing an unneeded cast.
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
|
|
| |
SGI RLE encoding is slighlty different than the one provided by rle
module (especially at high bit depth). The pixel count function however
does not change, so it is simply made library-public.
|
| |
|
|
|
|
|
|
|
|
| |
This is never mentioned in the specifications, and decoders work
just as fine without it. Update the fate references since the compressed
file is smaller.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
|
|
|
|
|
|
|
| |
VP8E_UPD_ENTROPY, VP8E_UPD_REFERENCE, VP8E_USE_REFERENCE were removed
from libvpx and the remaining values were never used here
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Zern <jzern@google.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
|
|
|
|
|
|
| |
The auxiliary data length field is not reliable,
and incorrect overread errors could be returned
for valid, real-world bitstreams.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function returns the encoded data of a frame, one slice at a time
directly when that slice is encoded, instead of waiting for the full
frame to be done. However this field has a debatable usefulness, since
it looks like it is just a convoluted way to get data at lowest
possible latency, or a somewhat hacky way to store h263 in RFC-2190
rtp encapsulation.
Moreover when multi-threading is enabled (which is by default) the order
of returned slices is not deterministic at all, making the use of this
function not reliable at all (or at the very least, more complicated
than it should be).
So, for the reasons stated above, and being used by only a single encoder
family (mpegvideo), this field is deemed unnecessary, overcomplicated,
and not really belonging to libavcodec. Libavformat features a complete
implementation of RFC-2190, for any other case.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
| |
|
| |
|
| |
|
| |
|