RealAudio 28.8 (like other RealAudio codecs) uses a special demuxing
mode in which the data of the existing Matroska Blocks is not simply
forwarded as-is. Instead data from several Blocks is recombined
together to output several packets. The parameters governing this
process are parsed from the CodecPrivate: Coded framesize (cfs), frame
size (w) and sub_packet_h (h).

During demuxing, h/2 pieces of data of size cfs each are read from every
Matroska (Simple)Block and put at offset m * 2 * w + n * cfs of a buffer
of size h * w, where m ranges from 0 to h/2 - 1 for each Block while n
is initially zero and incremented after a Block has been parsed until it
is h, at which poin the assembled packets are output and n reset.

The highest offset is given by (h/2 - 1) * 2 * w + (h - 1) * cfs + cfs
while the destination buffer's size is given by h * w. For even h, this
leads to a buffer overflow (and potential segfault) if h * cfs > 2 * w;
for odd h, the condition is h * cfs > 3 * w.

This commit adds a check to rule this out.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

RealAudio 28.8 does not need or use sub_packet_size for its demuxing
and this field is therefore commonly set to zero. But since 18ca491b
the Real Audio specific demuxing is no longer applied if sub_packet_size
is zero because the codepath for cook and ATRAC3 divide by it; this made
these files undecodable.

Furthermore, since 569d18aa (merged in 2c8d876d) sub_packet_size being
zero is used as an indicator for invalid data, so that a file containing
such a track was completely skipped.

This commit fixes this by not checking sub_packet_size for RealAudio
28.8 at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

They need a special parsing mode and in order to find out whether this
mode is in use, several checks have to be performed. They can all be
combined into one: If the buffer that is only used to assemble their
packets has been allocated, use the RealAudio parsing mode.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Only flavors 0..3 seem to exist. E.g. rmdec.c treats any flavor > 3
as invalid data. Furthermore, we do not know how big the packets to
create ought to be given that for sipr these values are not read from
the bitstream, but from a table.

Furthermore, flavor is only used for sipr, so only check it for sipr;
rmdec.c does the same. (The old check for flavor being < 0 was
always wrong given that flavor is an int that is read via avio_rb16(),
so it has been removed completely.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Failure was due to the extra comment printed by libavcodec/utils.c since
side data is used to signal the skipped samples.

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Part of this patch is based on Paul B Mahol's patch from last year.

This also allows for single-stream parameter/codec changes.

This cleans up the code and simplifies it.
It also speeds up parsing since the old pb position was incorrect.

This makes decoding far more robust, since OggS, the ogg magic,
can be commonly found randomly in streams, which previously made
the demuxer think there's a new stream or a change in such.

This also makes implementing CRC checking far simpler and more robust.

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

We only care about the right most bit.
Signed-off-by: James Almer <jamrial@gmail.com>

v4l2_m2m uses device memory mapped buffers to store dequeued
frames/packets (reference counted by AVBufferRef). When the reference
count drops to zero, the buffer ownership is returned back to the
device, so that they can re-filled with frames/packets.

There are some cases when all the capture buffers are in userspace
(i.e. due to internal buffering in ffmpeg). On the s5p-mfc this causes
an infinite wait when polling to dequeue the buffers, which can be
prevented by increasing the total number of buffers. This commit adds a
warning when all the capture buffers are dequeued.
Reviewed-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>

Apparently the changes from 3c9185bf
aren't enough; even with that in place, I got errors like this
when trying to build for iOS:

src/libavdevice/avfoundation.m:135:5: error:
      'AVCaptureDeviceTransportControlsPlaybackMode' is unavailable: not
      available on iOS
    AVCaptureDeviceTransportControlsPlaybackMode observed_mode;
    ^

Use A in calculation.

Signed-off-by: Josh de Kock <josh@itanimul.li>

The data of an AVPacket may be a part of the data of an AVBufferRef;
Therefore av_grow_packet() doesn't reallocate if the available space in
the actual buffer is sufficient for the enlargement. But given that it
also zeroes the padding it also needs to make sure that the buffer is
actually writable; this commit implements this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

hdsenc already had an explicit function to free all allocations in case
of an error, but it was not marked as deinit function, so that it was
not called automatically when the AVFormatContext for muxing gets freed.

Using an explicit deinit function also makes the code cleaner by
allowing to return immediately without "goto fail".
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Enqueue/dequeue of the capture buffers should continue while draining.

Reference: linux/Documentation/media/uapi/v4l/dev-decoder.rst

    "The client must continue to handle both queues independently,
     similarly to normal decode operation. This includes:
     ...
     - queuing and dequeuing CAPTURE buffers, until a buffer marked with
       the V4L2_BUF_FLAG_LAST flag is dequeued"
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>

Found-by: 黄宁 <tsukimurarin@163.com>
Reviewed-by: Nick Renieris <velocityra@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The DNG code hardcodes plane 0 at some places, so its better to disallow cases
that have more planes.

Fixes: eg_crash
Found-by: 黄宁 <tsukimurarin@163.com>
Reviewed-by: Nick Renieris <velocityra@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This is less confusing
Reviewed-by: Nick Renieris <velocityra@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

dng spec 1.5.0.0
"BitsPerSample
Supported values are from 8 to 32 bits/sample. The depth must be the same for each sample if
SamplesPerPixel is not equal to 1."

Fixes: eg_crash
Found-by: 黄宁 <tsukimurarin@163.com>
Reviewed-by: Nick Renieris <velocityra@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: Timeout (21sec -> 80ms)
Fixes: 20673/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TXD_fuzzer-5177453863763968

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

Fixes: Timeout (21sec -> 255ms)
Fixes: 20709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SVQ1_fuzzer-5085075089915904

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

"slice mode" option seems to be unnecessary since it could be
determined by -slices/max_nal_size.

default:        SM_FIXEDSLCNUM_SLICE mode with cpu-number slices.
-slices N:      SM_FIXEDSLCNUM_SLICE mode with N slices.
-max_nal_size:  SM_SIZELIMITED_SLICE mode with limited size slices.

Add FF_API_OPENH264_SLICE_MODE macro to remove this option after
LIBAVCODEC_VERSION_MAJOR = 59.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

Libopenh264enc would set the slice according to the number of cpu cores
if uiSliceNum equals to 0 (auto) in SM_FIXEDSLCNUM_SLICE mode.

Prompt a warning for user to catch this.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

RC_BITRATE_MODE:
    set BITS_EXCEEDED to iCurrentBitsLevel and allows QP adjust
    in RcCalculatePictureQp().

RC_BUFFERBASED_MODE:
    use buffer status to adjust the video quality.

RC_TIMESTAMP_MODE:
    bit rate control based on timestamp, introduced in release 1.4.

Default to use RC_QUALITY_MODE.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

It would be 200kbps bitrate with gop size = 12 by default
which generated too many IDR frames in rather low bit rate.
The quality would be poor.

Set these default values to -1 to check whether it's specified
by user explicitly.

Use 2Mbps bitrate as nvenc sugguested, and leave gop size
untouched in libopenh264.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

Clip iMinQp/iMaxQp to (1, 51) for user specified qp range.

If not set, leave iMinQp/iMaxQp untouched and use the values (0, 51)
initialized in FillDefault(), and the QP range would be adjusted to the
defaults inside libopenh264 library according to the iUsageType, (12, 42)
for iUsageType == CAMERA_VIDEO_REAL_TIME which is default.

<https://github.com/cisco/openh264/blob/master/codec/encoder/core/src/encoder_ext.cpp#L375>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

Remove any usage of padding for this format.

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Because not every user know about in_pad and out_pad reasonable value range
so maybe try to set 1.0, but setting 1.0 is so hugh to get an fatal error.
Suggested-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>