Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit cff1c0edaa)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5736
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c1bfeda5a3)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fix segfault with too large slice_count
Fixes Ticket4879
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit aa6c43f3fd)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This parameter can be used to inform the allocation code about how much
downsizing might occur, and can be used to optimize how to allocate the
packet
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The rationale is that coded_frame was only used to communicate key_frame,
pict_type and quality to the caller, as well as a few other random fields,
in a non predictable, let alone consistent way.
There was agreement that there was no use case for coded_frame, as it is
a full-sized AVFrame container used for just 2-3 int-sized properties,
which shouldn't even belong into the AVCodecContext in the first place.
The appropriate AVPacket flag can be used instead of key_frame, while
quality is exported with the new AVPacketSideData quality factor.
There is no replacement for the other fields as they were unreliable,
mishandled or just not used at all.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Allocating coded_frame is what most encoders do anyway, so it makes
sense to always allocate and free it in a single place. Moreover a lot
of encoders freed the frame with av_freep() instead of the correct API
av_frame_free().
This bring uniformity to encoder behaviour and prevents applications
from erroneusly accessing this field when not allocated. Additionally
this helps isolating encoders that export information with coded_frame,
and heavily simplifies its deprecation.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
A bit more complex than e.g. adding it to the context, but
using the context for something that will be used only during
initialization seemed a bit wasteful.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This isnt needed but it cant hurt, its also more consistent with
how its calculated a few lines before.
See: CID1108593
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The fate tests change as they used 1.2 previously
The increased size is due to:
32bit CRCs per slice by default (can be disabled),
it adds slice headers to allow decoding one slice without the others
an additional slice size field is added to make it possible to find
slices within corrupted surroundings.
these add up to about 57bit per slice more
at 50 frames and 4 slices thats 1425 byte
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Michael Niedermayer
Timothy Gu
Vittorio Giovara
Michael Niedermayer
Carl Eugen Hoyos
Diego Biurrun
Reimar Döffinger
Lukasz Marek
Anton Khirnov
Paul B Mahol