This should fix the first undefined behavior reported in:
https://trac.ffmpeg.org/ticket/4727.

I can't reproduce the runtime behavior reported in the ticket, hence I
can't confirm that this actually fixes the exact issue reported in the
ticket.

Regardless, I can confirm that this is a genuine issue, and that
negative shifts can (and do) occur, fixed by this.

Tested with FATE.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Currently only 2 profiles are evaluated because they are the only 2
with distributed test sequences.
- CID 1260: YUV 4:2:2 10 bits with block-adaptive interlace coding,
  from ticket 4876;
- CID 1270: YUV 4:4:4 10 bits (HR), 1920x839, from ticket 4581.

They were generated from the ticket sequences by running the
following kind of command-line;
ffmpeg -i $INPUT -an -sn -vcodec copy -vframes 1 -y $OUTPUT.mov
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

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

On lines 1633,1634 FFABS(pts) is performed. However, if av_stream_get_end_pts
returns AV_NOPTS_VALUE always, pts remains stuck at INT64_MIN, leading
to undefined behavior on FFABS.

One could conceive of a solution using FFNABS. However, such a solution
has to deal with the implementation defined rounding of integer division
with at least one negative operand in ANSI C89. C99 forces truncation to
zero, but I am not sure that all of our platforms compile with full C99
support, and in particular whether we can safely assume a fixed
rounding behavior across all platforms.

This solution is simple, and I doubt changing INT64_MIN to INT64_MIN + 1
has any practical loss - if it is stuck at its initial value, the stream
is messed up anyway.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

RFC 2435 suggests that mjpeg over rtp uses both two tables.

Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

When trying to build the binary dct-test under MSYS2/Win64, the
makefile rule does not have the SUBDIR in the target for its
object file.

Consequently, modifications to various include files (e.g. C ones)
do not trigger a recompilation.

When tracing the dependency generating, the dependency generation
has this strange content (linebreak inserted):
sed -e "/^#.*/d" -e "s,^[[:space:]]*dct\\.o,libavcodec/dct.o," \
 > libavcodec/dct-test.d

For some reason, the $(*F) has weird content. It looks simpler to
use $(@F) instead of $(*F)\\.o, although this was tested on one
single version of make.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes regression since 7218352e: WebVTT
files were matching the SRT probing.

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Change to https for FFmpeg websites.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes #4919

Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

tests: update fate-filter-delogo test reference after commit 8bc708fc

The original interpolation algorithm behaved poorly on the borders and
did not even guarantee continuity at the borders. For this reason, a
second interpolation/blending pass was required on the borders to make
them seamless.

However, since the interpolation algorithm was improved in June 2013,
the border issues no longer exist. The new algorithm does guarantee
continuity at the borders, making the second pass useless. A larger
band always increases the cumulated interpolation error. In most cases
it also increases the average interpolation error, even though the
samples in the band are only partially interpolated.

For this reason I would like to get rid of the "band" parameter. As a
first step, let's change its default value from 4 to 1 and document it
as deprecated.

I have benchmarked this change on a combination of input sources and
realistic logo areas. Lowering the band value from 4 to 1 resulted in
8 to 39 % less interpolation error per frame (or 1 to 34 % less
interpolation error per luma sample.)
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>

The MBAFF handling recently introduced on the decoder side shows that
the encoder does not support it correctly. Therefore, make the related
profile experimental.

Furthermore, current encoder logic treats it as unable to encode as
progressive, which isn't the case.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

MBAFF-like handling of interlaced content in CID 1260 is different from
the other CIDs, and in particular doesn't use the same syntax.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Profiles 1256 & 1270 (currently) signal at the frame header and MB
levels the colorspace used, either RGB or YUV. While a MB-level
varying colorspace is not supported, whether it is constant can be
tracked so as to determine the exact colorspace.

This requires having bitdepth and the ACT and 4:4:4 flags, in turn
needing the CID. Because setting those before having validated
enough things may result in invalid/unset DSP fucntions, setting
the bitdepth in the context is delayed.

It is not tested against a true RGB sequence, though.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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>