Fixes sync in some samples (e.g. bugs 7581 and 8374 in VLC).
Based on a commit by Matthieu Bouron <matthieu.bouron@gmail.com>
Reported-by: Jean-Baptiste Kempf <jb@videolan.org>
CC: libav-stable@libav.org

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

This prevents odd characters from ending in the fate test
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

For codecs where decoding of a whole plane can simply
be skipped, we should offer applications to not decode
alpha for better performance (ca. 30% less CPU usage
and 40% reduced memory bandwidth).
It also means applications do not need to implement support
(even if it is rather simple) for YUVA formats in order to be
able to play these files.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>

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>

This fixes issues with gimp reading animated gifs
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Update the fate reference since the last broken frame is not decoded
anymore.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Fixes 2nd half of Ticket2274
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The bug it was working seems to have been fixed.
This change causes ffmpeg to use the trim filter to implement
the -t option.
FATE tests are updated due to the more accurate handling of
the last packets.

This hopefully fixes fate-timefilter
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

for the n0=0 case there are multiple solutions and different
platforms pick different ones
This should reduce the issues with fate and the timefilter test
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

The option is used to sort the streams by program.
Signed-off-by: Florent Tribouilloy <florent.tribouilloy@smartjog.com>
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>

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

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>

Get rid of ugly hacks, also add support for more pixel formats.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

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

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

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

When operating on subsampled chroma planes, some rounding is taking
place. The left and top borders are rounded down while the width and
height are rounded up, so all rounding is done outward to guarantee the
logo area is fully covered.

The problem is that the width and height are counted from the
unrounded left and top borders, respectively. So if the left or top
border position has indeed been rounded down, and the width or height
needs no rounding (up), the position of the the right or bottom border
will be effectively rounded down, i.e. inward.

The issue can easily be seen with a yuv240p input and
  -vf delogo=45:45:60:40:show=1 -vframes 1 delogo-bug.png
(or virtually any logo area with odd x and y and even width and
height.) The right and bottom chroma borders (in green) are clearly
off.

In order to fix this, the width and height must be adjusted to include
the bits lost in the rounding of the left and top border positions,
respectively, prior to being themselves rounded up.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The original delogo algorithm interpolates both horizontally and
vertically and uses the average to compute the resulting sample. This
works reasonably well when the logo area is almost square. However
when the logo area is significantly larger than high or higher than
large, the result is largely suboptimal.

The issue can be clearly seen by testing the delogo filter with a fake
logo area that is 200 pixels large and 2 pixels high. Vertical
interpolation gives a very good result in that case, horizontal
interpolation gives a very bad result, and the overall result is poor,
because both are given the same weight.

Even when the logo is roughly square, the current algorithm gives poor
results on the borders of the logo area, because it always gives
horizontal and vertical interpolations an equal weight, and this is
suboptimal on borders. For example, in the middle of the left hand
side border of the logo, you want to trust the left known point much
more than the right known point (which the current algorithm already
does) but also much more than the top and bottom known points (which
the current algorithm doesn't do.)

By properly weighting each known point when computing the value of
each interpolated pixel, the visual result is much better, especially
on borders and/or for high or large logo areas.

The algorithm I implemented guarantees that the weight of each of the
4 known points directly depends on its distance to the interpolated
point. It is largely inspired from the original algorithm, the key
difference being that it computes the relative weights globally
instead of separating the vertical and horizontal interpolations and
combining them afterward.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Includes RIPEMD-128, RIPEMD-160, RIPEMD-256 and RIPEMD-320
Signed-off-by: James Almer <jamrial@gmail.com>

Also replace custom tests for MD5 with those published in RFC 2202
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

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