It does not belong there.

Resolves issues with some transparent gifs.

Unbreaks gif image2 muxer.

Based on patch by Bjorn Roche.

Fixes #6813.

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.

It generally does not work.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

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>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

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>

Fixes some gif encoding failures
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This prevents issues in case any header #includes put_bits.h
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

While this is not always optimal, in practice most of the common cases are.

  ffmpeg -i big_buck_bunny_1080p_h264.mov -ss 45 -vf scale=320:160 -gifflags -transdiff -frames:v 50 -y bbb-notrans.gif
  ffmpeg -i big_buck_bunny_1080p_h264.mov -ss 45 -vf scale=320:160 -gifflags +transdiff -frames:v 50 -y bbb-trans.gif

  -rw-r--r-- 1 ubitux ubitux 1.1M Apr 19 19:00 bbb-notrans.gif
  -rw-r--r-- 1 ubitux ubitux 378K Apr 19 19:00 bbb-trans.gif

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.

It seems browsers don't like it very much.

Increase compression when pictures are similar.

-f lavfi testsrc=300: 61M -> 21M

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>

Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>