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

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

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>

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

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>

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

The current code can fail to return the last frame if it contains
exactly the requested number of samples.

Fixes the join filter test, which previously did not include the last
408 samples in most cases.

CC:libav-stable@libav.org
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>

This is required since there are bit-inexact implementations
of the vp3 idct (for bfin).
Signed-off-by: Martin Storsjö <martin@martin.st>

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>

This is heavily based on 2831b307 by Anton Khirnov <anton@khirnov.net>

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

Also add and use the '|' separator instead of ':' since it's
incompatible with the new option system...

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: Michael Niedermayer <michaelni@gmx.at>

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

The gcov/lcov are a common toolchain for visualizing code coverage with
the GNU/Toolchain. The documentation and implementation of this
integration was heavily inspired from the blog entry by Mike Melanson:
http://multimedia.cx/eggs/using-lcov-with-ffmpeg/

It is breaking support from files with unknown layout.