The only caller of do_video_out() doesn't need the frame afterwards,
ergo one can replace an av_frame_ref() by av_frame_move_ref().

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Fixes a potential crash upon av_frame_alloc() failure.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Simplifies code and reduces the number of allocations a bit
by overallocating.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Currently, adding a (separately allocated) element to a list of pointers
works by first reallocating the array of pointers and (on success)
incrementing its size and only then allocating the new element.
If the latter allocation fails, the size is inconsistent, i.e.
array[nb_array_elems - 1] is NULL. Our cleanup code crashes in such
scenarios.

Fix this by adding an auxiliary function that atomically allocates
and adds a new element to a list of pointers.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

AVFrame.data[] elements not used by the format should ALWAYS be null,
hwaccel formats are not an exception.

All frames we deal with should always be refcounted now.

I.e. when the only filters that are applied do not modify the frame
data.

Also, document it and make it apply to audio in addition to video.

This flag allows distinguishing between filters that actually modify the
data and those that only modify metadata or gather some stream
information.

The data stored in data[3] in VAAPI AVFrame is VASurfaceID while
the data stored in pair->first is the pointer of VASurfaceID, so
we need to do cast to make following commandline works:

ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 \
-hwaccel_output_format vaapi -i input.264 \
-vf "hwmap=derive_device=qsv,format=qsv" -c:v h264_qsv output.264

Signed-off-by: nyanmisaka <nst799610810@gmail.com>
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

The documentation states that here 0 should be used for read-only and
1 for a writable buffer. AVIO_FLAG_WRITE however is 2, while it works
due to the way the flag is handled internally, it is still wrong
according to the documentation.

Additionally it makes it seem as if the AVIO_FLAG_* values could be used
here, which is actually not true, as when AVIO_FLAG_READ would be used
here it would create a writable buffer as AVIO_FLAG_READ is defined as 1.

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Old system is:
OSX version: 10.11.6
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

this allows getting rid of the hardcoded max size of SDP.

Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

without it, read_packet_wrapper() will return AVERROR(EINVAL) and avio_read
will be failed.

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

This adds a time_base field to AVFrame, as an analogue to the
AVPacket.time_base field.

These lists have size fields since
e48ded85.

Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

The length of this list is a compile-time constant, so there is
no need to calculate it again at runtime.
(This also avoids an implicit requirement of -1 == AV_SAMPLE_FMT_NONE.)

Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

An AVBPrint's internal string is always already zero-terminated;
writing another '\0' is unnecessary as long as one treats
the string only as a C-string.

Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

choose_pix_fmts() used the dynamic buffer API to write strings;
as is common among uses of this API, only opening the dynamic buffer
was checked, but not the end result, leading to crashes in case
of allocation failure.
Furthermore, some static strings were duplicated; the allocations
performed here were not properly checked: Allocation failure would
be treated as "could not determine pixel format".
The first issue is fixed by switching to the AVBPrint API which allows
to easily perform checks at the end. Furthermore, the internal buffer
avoids almost all allocations in case the AVBPrint is used.
The AVBPrint also allows to solve the second issue in an elegant way,
because it allows to return the static strings directly.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It is not really natural, it requires internal allocations
of its own and its error handling is horrible (i.e. the implicit
(re)allocations here are unchecked).

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Newer versions of Clang detect this and emit warnings for it.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Up until now, the h264_redundant_pps_bsf stored the initial value
of pic_init_qp_minus26 of the most recently encountered PPS;
it also modified the slices based upon to assumption that
the most recent PPS is the PPS the slice belongs to.
Yet this assumption is flawed, as there can be several PPS
with different IDs that are visible at any given time.
If these have different pic_init_qp_minus26 values,
the output can be invalid.

Fix this by directly using the pic_init_qp_minus26 value of
the input PPS.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

extradata_pic_init_qp is unset since
fa75e438
(and resetting current_pic_init_qp to the value it had in extradata
never made much sense).

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It is not documented that freeing the last (and only) entry of
an AVDictionary frees the dictionary.

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

SWR_CH_MAX is internal only and the arrays are therefore not required
to have that many elements (and they typically don't do it). So remove
this potentially confusing hint.

(Newer versions of GCC emit -Warray-parameter= warnings for this,
because the definition with explicit size differs from the declaration
(which leaves the size unspecified); this is IMO a false-positive,
because definition and declaration didn't conflict, but anyway it is
fixed by this commit.)

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Adds support for reading audio sample size from the data instead of
assuming all audio is 16 bits per sample.

Reviewed-by: Peter Ross <pross@xvid.org>

The number of audio channels is stored after the magic number
identifying the audio format.  Prior to this patch the code has been
reading it earlier, causing files with only one audio channel to be
handled incorrectly.

Reviewed-by: Peter Ross <pross@xvid.org>