Unnecessary since acf63d5350adeae551d412db699f8ca03f7e76b9;
also avoids relocations.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It may be NULL, as is the case for D3D11VA_VLD.
Running "ffmpeg -h decoder=h264" on a Windows build
Before:
Decoder h264 [H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10]:
Supported hardware devices: dxva2 (null) d3d11va cuda
After:
Decoder h264 [H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10]:
Supported hardware devices: dxva2 d3d11va cuda
Signed-off-by: James Almer <jamrial@gmail.com>
Look for the generic "USR" labels instead of "?" to skip channels with no
known names, and actually print the decomposition of standard channel layouts.
Signed-off-by: James Almer <jamrial@gmail.com>
This avoids including version.h in all source files, avoiding
unnecessary rebuilds when the version number is bumped. Only
version_major.h is included by the main header, which defines
availability of e.g. FF_API_* macros, and which is bumped much
less often.
This isn't done for libavutil/version.h, because that header needs
to be included essentially everywhere due to LIBAVUTIL_VERSION_INT
being used wherever an AVClass is constructed.
Signed-off-by: Martin Storsjö <martin@martin.st>
fftools now print info about what media type(s), if any, are provided by
sink and source avdevices.
Signed-off-by: Diederick Niehorster <dcnieho@gmail.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
If 'opts' could not be allocated, exiting the program to avoid crash when release it.
Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: Yu Yang <yuyang14@kuaishou.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>
Treat values returned from av_dict_get() as const, since they are
internal to AVDictionary.
Signed-off-by: Chad Fraleigh <chadf@triularity.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These were intended to pass options to auto-inserted avresample
resampling filters. Yet FFmpeg uses swresample for this purpose
(with its own AVDictionary swr_opts similar to resample_opts).
Therefore said options were not forwarded any more since commit
911417f0b34e611bf084319c5b5a4e4e630da940; moreover since commit
420cedd497 avresample options are
not even recognized and ignored any more. Yet there are still
remnants of all of this. This commit gets rid of them.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Besides being nicer code this also has the advantage of not making
assumptions about the internal implementation: While it is documented
that the AVFilter.inputs and AVFilter.outputs arrays are terminated
by a zeroed sentinel, one is not allowed to infer that one can just
check avfilter_pad_get_name(padarray, i) to see whether one has reached
the sentinel:
It could be that the pointer to the string is contained
in a different structure than AVFilterPad that needs to be accessed
first: return pad->struct->string.
It could be that for small strings an internal buffer in
AVFilterPad is used (to avoid a relocation) whereas for longer strings
an external string is used; this is useful to avoid relocations:
return pad->string_ptr ? pad->string_ptr : pad->interal_string
Or it could be that the name has a default value:
return pad->name ? pad->name : "default"
(This actually made sense for us because the name of most of our
AVFilterPads is just "default"; doing so would save lots of relocations.)
The only thing one is allowed to infer from the existence of the
sentinel is that one is allowed to use avfilter_pad_count() to get
the number of pads. Therefore it is used.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>