The manual states "there is virtually no reason to use that encoder.".

It supports less sample formats than the native encoder, is less efficient
than the native encoder and is also slower and pretty much remains untested.
libwavpack also isn't being fuzzed, which given that we plug the parameters
without any sanitizing them looks concerning.

The generated text streams for chapters lack an AVStream since they
are but an internal concept within movenc.

Fixes #8910

Fixes: signed integer overflow: 20 * 5184056935931942919 cannot be represented in type 'long'
Fixes: 25466/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4798660247552000

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

Fixes: signed integer overflow: 8224000000 * 1629552639 cannot be represented in type 'long'
Fixes: 24908/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4658478506049536

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

Fixes: signed integer overflow: 25488 * 87381 cannot be represented in type 'int'
Fixes: 24765/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-5108259565076480

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

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

changes since v1:
- made into fate test
- fixed c90 warnings
- tests more intermediate formats
- tested on BE mips too
Signed-off-by: NMichael Niedermayer <michael@niedermayer.cc>

1. Remove the assumption that the message method is TEARDOWN.
2. Don't ignore the error code of ff_rtsp_parse_streaming_commands.
Signed-off-by: NMartin Storsjö <martin@martin.st>

In listen mode with UDP transport, once the sender has sent
the TEARDOWN and closed the connection, poll will indicate that
one can read from the connection (indicating that the socket has
reached EOF and should be closed by the receiver as well). In this
case, parse_rtsp_message won't try to parse the command (because
it's no longer in state STREAMING), but previously just returned
zero.

Prior to f6161fcc, this caused
udp_read_packet to return zero, which is treated as EOF by
read_packet. But after that commit, udp_read_packet would continue
if parse_rtsp_message didn't return an explicit error code.

To keep the original behaviour from before that commit, more
explicitly return an error in parse_rtsp_message when in the wrong
state.

Fixes: #8840
Signed-off-by: NMartin Storsjö <martin@martin.st>

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

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

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

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

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

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

There are two possible kinds of timecode tracks (with tag "tmcd") in the
mov muxer: Tracks created internally by the muxer and timecode tracks
sent by the user. If any of the latter exists, the former are
deactivated. The former all belong to another track, the source
track; the latter don't have a source track set, but the index of the
source track is initially zeroed by av_mallocz_array(). This is a
problem since 3d894db7: Said commit added
a function that calculates the duration of tracks and the duration of
timecode tracks is calculated by rescaling the duration (calculated by
the very same function) of the source track. This gives an infinite
recursion if the first track (the one that will be treated as source
track for all timecode tracks) is a timecode track itself, leading to a
stack overflow.

This commit fixes this by not using the nonexistent source track
when calculating the duration of timecode tracks not created internally
by the mov muxer.
Reviewed-by: NMartin Storsjö <martin@martin.st>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

It is owned by libavcodec for encoders.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Allocating an AVCodecContext's priv_data used to be the first object
allocated in avcodec_open2(), so it was unnecessary to goto free_and_end
(which does the cleanup) upon error here. But this is no longer so since
f3a29b75.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Don't check for AVCodec.priv_data_size (which is always true if
AVCodec.priv_class is set). Instead check for AVCodecContext.priv_data
to actually exist.

(Note: av_opt_free(NULL) is a no-op.)
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

The first thing avcodec_open2() allocates is the AVCodecInternal. If
allocating it fails, a jump to end occurs; but if an error happens after
its allocation, a jump to free_and_end happens which frees all
allocations performed so far and then jumps to end. Yet free_and_end
contained a check for AVCodecInternal (after having already dereferenced
it to check whether ff_thread_free() needs to be called) which is of
course always true. So remove it.
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

Decode and discard them.

Fixes ticket 4641.

Filters mostly work in native endianness, but they must output
a specified endianness, usually little: that requires a final
conversion for big endian.

I do not know what's the deal with gif-deal: inserting explicitly
the filters that are implicitly inserted result in less frames in
output. Probably a strange problem of duration.

Fixes ticket #8219.
Reviewed-by: NPaul B Mahol <onemda@gmail.com>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

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

We clear the AV1RawSequenceHeader pointer on flush, not the relevant AVBufferRef.
Signed-off-by: NJames Almer <jamrial@gmail.com>

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

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

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

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

Used to reset the codec's private internal state.
Signed-off-by: NJames Almer <jamrial@gmail.com>

Use proper integer variables.

avcodec_open2() also called the AVCodec's close function if an error
happened before init had ever been called if the AVCodec has the
FF_CODEC_CAP_INIT_CLEANUP flag set. This is against the documentation of
said flag: "The codec allows calling the close function for deallocation
even if the init function returned a failure."

E.g. the SVQ3 decoder is not ready to be closed if init has never been
called.

Fixes: NULL dereference
Fixes: 25762/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SVQ3_fuzzer-5716279070294016

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegReviewed-by: NPaul B Mahol <onemda@gmail.com>
Reviewed-by: NMichael Niedermayer <michael@niedermayer.cc>
Signed-off-by: NAndreas Rheinhardt <andreas.rheinhardt@gmail.com>

This reverts commit 5bbf58ab.

The setparams filters are not hwframe aware, so the default context
passthrough behaviour is needed to allow using them with hardware frames.