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>
The encoder now doesn't produce any extra graphic control extension
block anymore. Only the image is encoded, and the muxer writing
its own GCE containing notably the timing information now includes the
optional palette transmitted through packet side data.
This commit avoid setting clashes between the two GCE, and reduce the
size of the generated file with pal8 output.
This commit removes the badly duplicated code between the encoder and
the muxer. That may sound surprising, but the encoder is now responsible
from the encoding of the picture when muxing to a .gif file. It also
does not require anymore a manual user intervention such as a -pix_fmt
rgb24 to work properly. To summarize, output gif are now easier to
generate, code is saner and simpler, and files are smaller (thanks to
the lzw encoding which was unused so far with the default .gif output).
We can certainly make things even better, but this is the first step.
FATE is updated because of the output being produced by the encoder and
not the muxer (no lzw in the muxer), and in the seek test only the size
mismatches.
Fixes Ticket #2262
Some code was copy pasted from muxer, which still
have same comments but unlike encoder they are still
relevant to muxer.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Maybe someone can add a check in the second gif encoder (rgb24), because I'm not sure where it should be added.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Also break some long lines, remove codec function placeholder comments
and add spaces in sample/pixel format lists.
Signed-off-by: Martin Storsjö <martin@martin.st>
None of these symbols should be accessed directly, so declare them as
hidden.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit d36beb3f69)
AVERROR(ENOMEM).
AVERROR_NOMEM is deprecated and will be dropped at the next libavutil
major bump.
Originally committed as revision 22791 to svn://svn.ffmpeg.org/ffmpeg/trunk
Vittorio Giovara
Michael Niedermayer
Clément Bœsch
Clément Bœsch
Diego Biurrun
Anton Khirnov
Michael Niedermayer
Paul B Mahol
Clément Bœsch
Piotr Bandurski
Martin Storsjö
Carl Eugen Hoyos
Stefano Sabatini
Mans Rullgard
Diego Elio Pettenò
Baptiste Coudurier