GIF palette entries are not compressed, and writing 256 entries,
which can be up to every frame, uses a significant amount of
space, especially in extreme cases, where palettes can be very
small.
Example, first six seconds of Tears of Steel, palette generated
with libimagequant, 320x240 resolution, and with transparency
optimization + per frame palette:
* Before patch: 186765 bytes
* After patch: 77895 bytes
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This option will disable the writing of the global palette in global
GIF header if it is set to 0, causing only the frame-level palette
to ever be written.
This will be useful later on when further frame-level palette
optimizations are introduced.
The default is 1, which maintains current default behavior.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
If one of several allocations the gif encoder performs in its init
function fails, the successful allocations leak. Fix this by adding the
FF_CODEC_CAP_INIT_CLEANUP flag.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
lzwenc stores a function pointer to either put_bits or put_bits_le;
however, after the recent change, the function pointer's prototype
would depend on BitBuf. BitBuf is defined in put_bits.h, whose
definition depends on whether BITSTREAM_WRITER_LE is #defined or not.
For safety, we set a boolean flag for little/big endian instead,
which also allows the definition to be inlined.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Now "-c copy" works.
Update FATE files.
Demuxer only split file into packets, no data is trimmed.
Encoder & muxer currently expect completely another format
where muxer writes stuff like disposal method which should
be really encoder job.
With this patch muxer only modifies delay between two packets.
Codec copy need to have same behavior between demuxer and
muxer to work correctly.
Fixes#6640.
Fixes out of array access
Fixes: aaa479088e6fb40b04837b3119f47b04/asan_heap-oob_e38c68_8576_9d653078b2470700e2834636f12ff557.tga
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
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>
* commit '57e7b3a89f5a0879ad039e8f04273b48649799a8':
dnxhdenc: use the AVFrame API properly.
libx264: use the AVFrame API properly.
svq1enc: use the AVFrame API properly.
gif: use the AVFrame API properly.
Conflicts:
libavcodec/gif.c
libavcodec/svq1enc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
