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

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

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

It is a part of the sample that got broken by recent indeo3 changes.

Merge of b963f021b6 is now complete.

Should fix a FATE failure.

Also make life test a bit more useful.

It was considered a comment.

The standalone alphaextract tests are removed since already the filters
are already tested by the alphamerge tests.

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

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

This changes the default to avoid negative timestamps.

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

Most formats do not support negative timestamps, shift them to avoid
unexpected behaviour and a number of bad crashes.

CC:libav-stable@libav.org

Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Address trac ticket #2431.

The sample is already included in the FATE suite, but is not tested
because cropping wasn't fully supported before.

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Based on the 2007 GSoC project from Kamil Nowosad <k.nowosad@students.mimuw.edu.pl>
Updated to current programming standards, style and many more small
fixes by Diego Biurrun <diego@biurrun.de>.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

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

To define accurately the delay between two frames, it is necessary to
have both available. Before this commit, the first frame had a delay of
0; while in practice the problem is not visible in most situation, it is
problematic with low frame rate and large scene change.

This commit notably fixes output generated with commands such as:

  ffmpeg -i big_buck_bunny_1080p_h264.mov
     -vf "select='gt(scene,0.4)',scale=320:-1,setpts=N/TB"
     -frames:v 5 -y out.gif

Also, to avoid odd loop delays, the N-1 delay is duplicated for the last
frame.

pkt->duration can not be used since the values are only based on frame
rate.

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

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

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

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

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

Using the first names of authors sounds somewhat unprofessional
and might be considered offensive which is not intended.
The new names use the initials of the authors due to simplicity
and the possibility to apply it consistently without the need
to find political correct names for each future case where
alternative codecs might exist. Also its shorter ...

If someone has a better idea, like maybe 2 random letters
and people prefer it then iam happy to switch to that ...

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

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Text subtitles packets are not 0-terminated (and if they are,
it is handled by the recoding process since 0 is a valid
Unicode code point). The terminating 0 would overwrite the
last payload octet.

OTOH, packets must be 0-padded.

Fix a problem reported in trac ticket #2431.

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

It is breaking support from files with unknown layout.