Fixes: https://trac.ffmpeg.org/attachment/ticket/685/movie.264

In the available testcase the actual PPS only uses a few bits
while there are 7kbyte of apparently random data after it
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

* commit '1aa24df7':
  lavu: Deprecate AVFrame.error[]
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '3f1f6053':
  configure: address a copy-paste typo
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

This error was produced by rtmproto.c, it is possibly such streams
where dumped, this commit is needed to support them

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

This affects Annex B streams (such as demuxed from .ts and others). It
also handles the format change in reinit-large_420_8-to-small_420_8.h264
correctly.

Instead of passing through the extradata, create it on the fly it from
the currently active SPS and PPS. Since reconstructing the PPS and SPS
NALs would be very complicated and verbose, we use the NALs as they
originally appeared in the bitstream.

The code for writing the extradata is somewhat derived from
libavformat/avc.c, but it's small and different enough that sharing it
is not really worth it.

We assume an upper bound of 4096 bytes for each raw SPS/PPS. It's hard
to determine an exact maximum size, but this value was was considered
high enough and safe.

Needed for the following VideotoolBox commit.

Otherwise, the dsp may change without its permuation being applied.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The current one, while correct, does not yield the best possible
results. The specificiations suggest another formula, which results
in quality gains in the decoded output from fate tests. This
justifies changing said formula.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The coded size is a multiple of the macroblock size, which is 16.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

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

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

It is only (mis-)used to set the dsp fucntions clear_block(s). But
these functions always work on 16bits-wide elements, which make
the parameter useless and actually harmful, as it causes all content
on more than 8-bits to not use accelerated functions.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

This should fix RTMP input which was broken by cbbd906b
the 40 + 11 case is untested as it did not occur in the testcase
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>

Makes it possible to use them in arithmetic expressions.

Reviewed-by: Ivan Uskov <ivan.uskov@nablet.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes Ticket #4898

Fixes deadlock with threads

Found-by: Paul B Mahol
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The variable is not a constant and can lead to race conditions

Fixes: repro.webm (not reproducable with FFmpeg alone)
Found-by: Dale Curtis <dalecurtis@google.com>
Tested-by: Dale Curtis <dalecurtis@google.com>
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>

This ensures that chroma format is never set to an invalid value
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

These field are difficult to interpret, and are provided by a single
encoder (mpegvideoenc). In general they do not belong to a structure
containing raw data only, so remove them from AVFrame.

Mpegvideoenc now uses a private field in Picture for its internal
computations.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Commits 43bc5cf9 and c5371f77 add code for skipping initial zeros in mp3
packets. This code forgot to report to the user that data was skipped at
all.

Since audio codecs allow partial packet decoding, the user application
has to rely on the return value. It will remove the data reported as
consumed by the decoder, and feed it to the decoder again. This resulted
in the mp3 frame after the zero region to be decoded over and over
again, until the zero region was finally skipped by the application.

Fix this by including the amount of skipped bytes to the number of
consumed bytes returned by the decode call.

Fixes trac ticket #4890.

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

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

The DDTS atom is defined in ETSI TS 102 114, v1.4.1, Annex E.
This is useful for DTS-HD formats, some of which cannot be
decoded by dcadec.c or libdcadec.
Signed-off-by: Shawn Singh <shawnsingh@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

CID 1256 is specified as using the same table for luma and chroma,
which is the same as CID 1235 luma table. This is consistent with
the format supposedly being RGB, although most sequences seem to
actually be YCbCr-encoded.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

VideoToolbox also implements a software decoder for h264, and will fallback to
using it if the file cannot be decoded on the GPU. In these cases though,
we want the hwaccel to fail so that we can use the libavcodec software decoder
instead of the Apple one.
Signed-off-by: wm4 <nfxjfg@googlemail.com>

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