Signed-off-by: James Almer <jamrial@gmail.com>

It's the correct place for them.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

The function avformat_alloc_context() will return a NULL pointer on
failure. However, in function read_ffserver_streams(), its return value
is not validated and the subsequent dereference may result in a bad
memory access bug. Check its return value against NULL and avoid
potential NULL dereference.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The function avformat_new_stream() returns a NULL pointer on failure.
However, in function rtp_mpegts_write_header(), its return value is not
validated before it is dereferenced. Check the return value against NULL
to avoid potential NULL dereference.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Prevents out of array accesses. Adressess ticket #6873
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

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

Fixes recording from ATI Wonder 600 USB adapter, regression since e35c674d.

Reported and analyzed by: Marco Paolieri, paolieri at gmail

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

Writes one set of field framing information for progressive streams and
two sets for interlaced streams. Fixes ticket #6383.

Unfortunately the OpenDML v1.02 document is not very specific on what
value to use for start_line when frame data is not coming from a
capturing device, so this is just using 0/1 depending on the field order
as a best-effort guess.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>

I'm told my prefix work-around wasn't enough to make it compile,
although I'm not sure why; I did some basic testing and that
approach appeared to work, but I'm not in a position to do a
full compile on CentOS 6 so I can't be sure of anything.

I have had it confirmed that the additional change to not use
named initialisers is enough to make it compile, so let's
throw that into the mix too.

Ancient versions of gcc (pre 4.6) can't directly initialise
members of anonymous inner unions/structs by name.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676

Unfortunately, RHEL 6 shipped with one of these ancient
versions and so we're stuck with it until approximately the
heat death of the universe.

Putting explicit braces into the initialisation is possibly a
work-around but the behaviour there was never fully understood
before direct initialisation was made to work.

So, this may or may not work.

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

The outputted bits should match what is used in the lossless check

Fixes: runtime error: signed integer overflow: -538697856 * 256 cannot be represented in type 'int'
Fixes: 4326/clusterfuzz-testcase-minimized-5689449645080576

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: signed integer overflow: 452986184 - -2113885312 cannot be represented in type 'int'
Fixes: 4196/clusterfuzz-testcase-minimized-5580648594014208

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Timeout
Fixes: 4271/clusterfuzz-testcase-4676667768307712

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Tested for 10000 iterations on x86-32

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

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Enables VP8 decoding - the decoder places the the bitstream version
in the profile field, which we want to ignore.

Also adds some extra fields to the main context structure that may
be needed by a hwaccel decoder.

The current behaviour of the WebP decoder is maintained by adding an
additional field to the VP8 decoder private context to indicate that
it is actually being used as WebP (no hwaccel is supported for that
case).

Also fixes a bug where it could attempt to decode with an unsupported
codec if allow-profile-mismatch was set.

Removes specific support for all hwaccels supported by the generic code
(DXVA2, D3D11VA, NVDEC, VAAPI and VDPAU).

They are now unused.

There is no longer any need for a list of them at runtime, because
decoders now carry the pointers to their associated hwaccels internally.
The file containing external declarations is now used to make the list
of hwaccels for configure.

This removes the dependency that hardware pixel formats previously had on
AVHWAccel instances, meaning only those which actually do something need
exist after this patch.

Also updates avcodec_default_get_format() to be able to choose hardware
formats if either a matching device has been supplied or no additional
external configuration is required, and avcodec_get_hw_frames_parameters()
to use the hardware config rather than searching the old hwaccel list.

The FF_CODEC_CAP_HWACCEL_REQUIRE_CLASS mechanism is deleted because it
no longer does anything (the codec already contains the pointers to the
matching hwaccels).

This includes a pointer to the associated hwaccel for decoders using
hwaccels - these will be used later to implement the hwaccel setup
without needing a global list.

Also added is a new file listing all hwaccels as external declarations -
this will be used later to generate the hwaccel list at configure time.

Fixes: chromium-773637/clusterfuzz-testcase-minimized-6418078673141760

Found-by: ossfuzz/chromium
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: runtime error: signed integer overflow: -2143827186 - 7404944 cannot be represented in type 'int'
Fixes: 4354/clusterfuzz-testcase-minimized-4671122764201984

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Prevents a segfault when alloc fails.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>

Drivers can support a format for surfaces without also supporting it for
images, so we can't assume that sw_format is usable for transfer.  This
would previously hit an assert in cases where it isn't.