Apparently Metal.framework is included with the command line tools
(and thus may be present without Xcode), but the Metal compiler is only
included as part of Xcode.
Check for the patch version as well as the major+minor version.
The VK_API_VERSION macros are not usable in preprocessor code due
to casts.
The patch (header) version is meant to linearly increment and
not be reset, however it's better to trust, but verify.
deinterlaces CVPixelBuffers, i.e. AV_PIX_FMT_VIDEOTOOLBOX frames
for example, an interlaced mpeg2 video can be decoded by avcodec,
uploaded into a CVPixelBuffer, deinterlaced by Metal, and then
encoded to h264 by VideoToolbox as follows:
ffmpeg \
-init_hw_device videotoolbox \
-i interlaced.ts \
-vf hwupload,yadif_videotoolbox \
-c:v h264_videotoolbox \
-b:v 2000k \
-c:a copy \
-y progressive.ts
(note that uploading AVFrame into CVPixelBuffer via hwupload
requires 504c60660d)
this work is sponsored by Fancy Bits LLC
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Aman Karmani <aman@tmm1.net>
Support for mapping/unmapping hardware frames has been added into
libplacebo itself, so we can scrap this code in favor of using the new
functions. This has the additional benefit of being forwards-compatible
as support for more complicated frame-related state management is added
to libplacebo (e.g. mapping dolby vision metadata).
It's worth pointing out that, technically, this would also allow
`vf_libplacebo` to accept, practically unmodified, other frame types
(e.g. vaapi or drm), or even software input formats. (Although we still
need a vulkan *device* to be available)
To keep things simple, though, retain the current restriction to vulkan
frames. It's possible we could rethink this in a future commit, but for
now I don't want to introduce any more potentially breaking changes.
LSX and LASX is loongarch SIMD extention.
They are enabled by default if compiler support it, and can be disabled
with '--disable-lsx' '--disable-lasx'.
Change-Id: Ie2608ea61dbd9b7fffadbf0ec2348bad6c124476
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Reviewed-by: guxiwei <guxiwei-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The following command is on how to apply transpose_vulkan filter:
ffmpeg -init_hw_device vulkan -i input.264 -vf \
hwupload=extra_hw_frames=16,transpose_vulkan,hwdownload,format=yuv420p output.264
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
This filter flips the input video both horizontally and vertically
in one compute pipeline, and it's no need to use two pipelines for
hflip_vulkan,vflip_vulkan anymore.
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
This reverts commit 5258f64a14.
The premise of said commit (that conversions from pointer to int
are ok) is wrong: C99/C11 6.3.2.3 5: "Any pointer type may be converted
to an integer type. [...] If the result cannot be represented in the
integer type, the behavior is undefined." (C90 6.3.4 contains a similar
restriction.) So don't disable -Wpointer-to-int-cast.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The following command is on how to apply vflip_vulkan filter:
ffmpeg -init_hw_device vulkan -i input.264 -vf hwupload=extra_hw_frames=16,vflip_vulkan,hwdownload,format=yuv420p output.264
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
The following command is on how to apply hflip_vulkan filter:
ffmpeg -init_hw_device vulkan -i input.264 -vf hwupload=extra_hw_frames=16,hflip_vulkan,hwdownload,format=yuv420p output.264
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
It's got a much better API that's actually maintained, it eliminates
race conditions, it comes with a pkg-config file by default, and
unfortunately isn't currently packaged by Debian or other large
distributions.
This commit adds a powerful and customizable gblur Vulkan filter,
which provides a maximum 127x127 kernel size of Gaussian Filter.
The size could be adjusted by requirements on quality or performance.
The following command is on how to apply gblur_vulkan filter:
ffmpeg -init_hw_device vulkan -i input.264 -vf hwupload=extra_hw_frames=16,gblur_vulkan,hwdownload,format=yuv420p output.264
Signed-off-by: Wu Jianhua <jianhua.wu@intel.com>
This filter conceptually maps the libplacebo `pl_renderer` API into
libavfilter, which is a high-level image rendering API designed to work
with an RGB pipeline internally. As such, there's no way to avoid e.g.
chroma interpolation with this filter, although new versions of
libplacebo support outputting back to subsampled YCbCr after processing
is done.
That being said, `pl_renderer` supports automatic integration of the
majority of libplacebo's shaders, ranging from debanding to tone
mapping, and also supports loading custom mpv-style user shaders, making
this API a natural candidate for getting a lot of functionality out of
relatively little code.
In the future, I may approach this problem either by rewriting this
filter to also support a non-renderer codepath, or by upgrading
libplacebo's renderer to support a full YCbCr pipeline.
This unfortunately requires a very new version of libplacebo (unreleased
at time of writing) for timeline semaphore support. But the amount of
boilerplate needed to hack in backwards compatibility would have been
very unreasonable.
Finally, this is as close to usable as it gets for glslang.
Much faster to compile as well, and eliminates the need for a C++
compiler, which is great.
Also, changes to the resource limits won't break users, as we
can use designated initializers in C90.
OpenBSD only supports riscv64 but this is an attempt at adding
some of the initial bits for RISC-V support.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some packages may not define custom cflags, in which case a simple
"pkg-config --cflags" call will return an empty string.
This change will be useful to get a valid include path that can be
used in library checks.
Reviewed-by: Haihao Xiang <haihao.xiang@intel.com>
Signed-off-by: James Almer <jamrial@gmail.com>
If no --cpu= option was passed to configure, we detect what the
compiler defaults to. This detected value was then fed back to the
rest of the configure logic, as if it was an explicit choice.
This breaks on Ubuntu 21.10 with GCC 11.1.
Since GCC 8, it's possible to add configure extra features via the
-march option, like e.g. -march=armv7-a+neon. If the -mfpu= option
is configured to default to 'auto', the fpu setting gets taken
from the -march option.
GCC 11.1 in Ubuntu seems to be configured to use -mfpu=auto. This
has the effect of breaking any compilation command that specifies
-march=armv7-a, because the driver implicitly also adds -mfloat-abi=hard,
and that combination results in this error:
cc1: error: ‘-mfloat-abi=hard’: selected processor lacks an FPU
One can compile successfully by passing e.g. -march=armv7-a+fp.
Therefore, restructure configure. If no specific preference was set
(and the 'cpu' configure variable was set as the output of
probe_arm_arch), the value we tried to set via -march= was the same
value that we just tried to detect as the compiler default.
So instead, just try to detect what the compiler defaults to, with
to allow setting other configure settings (such as 'fast_unaligned'),
but don't try to spell out the compiler's default via the -march flag.
Signed-off-by: Martin Storsjö <martin@martin.st>
After standardizing the use of 'pxor' in commit 'ebedd26', FFmpeg
build failed with upstream compiler, for 'pxor' is not supported
in time. This patch helps to workaround the build failure by
checking whether 'pxor' is supported during configuration, if not,
MMI will be disabled.
Reviewed-by: yinshiyou-hf@loongson.cn
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Adds schema validation for ffprobe XML output so that updating the
ffprobe.xsd file upon changes to ffprobe is not forgotten. This was
suggested by Marton Balint in:
http://ffmpeg.org/pipermail/ffmpeg-devel/2021-March/278428.html
The schema FATE test is only run if xmllint command is available.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
We already require X264_BUILD >= 118, which includes an unconditional
definition of X264_CSP_BGR in itself, thus making this check
effectively always true.
This makes the libx264rgb check work when pkg-config is utilized
and x264.h is not part of the standard include path (as is often
with cross-compilation, or when you just have a custom prefix in
general in f.ex. your home directory).
The X264_BUILD >= 118 required by configure since 2011 should have
X264_CSP_BGR defined unconditionally (it was added a few X264_BUILD
updates earlier), but as 134cba728b
added this additional check, I have kept it for now.
Instead use --preprocessor-arg; in binutils 2.36, the --preprocessor
flag was changed so that it no longer accepts a string containing
multiple arguments, but the whole --preprocessor argument is
treated as the path to the preprocessor executable (where the path
can contain spaces).
It's currently unclear whether this behaviour will stay or if it
is going to be reverted in the future, see discussion at [1]. Just
to be safe, avoid using the --preprocessor argument. Don't redeclare
the full preprocessing command, but just add the $(CC_DEPFLAGS) options.
Based on a patch by Kyle Schwartz.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=27594
Signed-off-by: Martin Storsjö <martin@martin.st>
MSA2 optimizations are attached to MSA macros in generic_macros_msa.h.
It's difficult to do runtime check for them. Remove this part of code
can make it more robust. H264 1080p decoding: 5.13x==>5.12x.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
classification is done on every detection bounding box in frame's side data,
which are the results of object detection (filter dnn_detect).
Please refer to commit log of dnn_detect for the material for detection,
and see below for classification.
- download material for classifcation:
wget https://github.com/guoyejun/ffmpeg_dnn/raw/main/models/openvino/2021.1/emotions-recognition-retail-0003.bin
wget https://github.com/guoyejun/ffmpeg_dnn/raw/main/models/openvino/2021.1/emotions-recognition-retail-0003.xml
wget https://github.com/guoyejun/ffmpeg_dnn/raw/main/models/openvino/2021.1/emotions-recognition-retail-0003.label
- run command as:
./ffmpeg -i cici.jpg -vf dnn_detect=dnn_backend=openvino:model=face-detection-adas-0001.xml:input=data:output=detection_out:confidence=0.6:labels=face-detection-adas-0001.label,dnn_classify=dnn_backend=openvino:model=emotions-recognition-retail-0003.xml:input=data:output=prob_emotion:confidence=0.3:labels=emotions-recognition-retail-0003.label:target=face,showinfo -f null -
We'll see the detect&classify result as below:
[Parsed_showinfo_2 @ 0x55b7d25e77c0] side data - detection bounding boxes:
[Parsed_showinfo_2 @ 0x55b7d25e77c0] source: face-detection-adas-0001.xml, emotions-recognition-retail-0003.xml
[Parsed_showinfo_2 @ 0x55b7d25e77c0] index: 0, region: (1005, 813) -> (1086, 905), label: face, confidence: 10000/10000.
[Parsed_showinfo_2 @ 0x55b7d25e77c0] classify: label: happy, confidence: 6757/10000.
[Parsed_showinfo_2 @ 0x55b7d25e77c0] index: 1, region: (888, 839) -> (967, 926), label: face, confidence: 6917/10000.
[Parsed_showinfo_2 @ 0x55b7d25e77c0] classify: label: anger, confidence: 4320/10000.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
While Vulkan itself went more or less the way it was expected to go,
libvulkan didn't quite solve all of the opengl loader issues. It's multi-vendor,
yes, but unfortunately, the code is Google/Khronos QUALITY, so suffers from
big static linking issues (static linking on anything but OSX is unsupported),
has bugs, and due to the prefix system used, there are 3 or so ways to type out
functions.
Just solve all of those problems by dlopening it. We even have nice emulation
for it on Windows.
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Deprecated in c29038f304.
The resample filter based upon this library has been removed as well.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Deprecated in commits 7fc329e2dd
and 31f6a4b4b8.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
These filters depend on avcodec APIs that are to be removed. Some people
have expressed potential interest in updating these filters, so they are
merely disabled for now instead of being removed.
Signed-off-by: James Almer <jamrial@gmail.com>
Below are the example steps to do object detection:
1. download and install l_openvino_toolkit_p_2021.1.110.tgz from
https://software.intel.com/content/www/us/en/develop/tools/openvino-toolkit/download.html
or, we can get source code (tag 2021.1), build and install.
2. export LD_LIBRARY_PATH with openvino settings, for example:
.../deployment_tools/inference_engine/lib/intel64/:.../deployment_tools/inference_engine/external/tbb/lib/
3. rebuild ffmpeg from source code with configure option:
--enable-libopenvino
--extra-cflags='-I.../deployment_tools/inference_engine/include/'
--extra-ldflags='-L.../deployment_tools/inference_engine/lib/intel64'
4. download model files and test image
wget https://github.com/guoyejun/ffmpeg_dnn/raw/main/models/openvino/2021.1/face-detection-adas-0001.bin
wget https://github.com/guoyejun/ffmpeg_dnn/raw/main/models/openvino/2021.1/face-detection-adas-0001.xml
wget
https://github.com/guoyejun/ffmpeg_dnn/raw/main/models/openvino/2021.1/face-detection-adas-0001.label
wget https://github.com/guoyejun/ffmpeg_dnn/raw/main/images/cici.jpg
5. run ffmpeg with:
./ffmpeg -i cici.jpg -vf dnn_detect=dnn_backend=openvino:model=face-detection-adas-0001.xml:input=data:output=detection_out:confidence=0.6:labels=face-detection-adas-0001.label,showinfo -f null -
We'll see the detect result as below:
[Parsed_showinfo_1 @ 0x560c21ecbe40] side data - detection bounding boxes:
[Parsed_showinfo_1 @ 0x560c21ecbe40] source: face-detection-adas-0001.xml
[Parsed_showinfo_1 @ 0x560c21ecbe40] index: 0, region: (1005, 813) -> (1086, 905), label: face, confidence: 10000/10000.
[Parsed_showinfo_1 @ 0x560c21ecbe40] index: 1, region: (888, 839) -> (967, 926), label: face, confidence: 6917/10000.
There are two faces detected with confidence 100% and 69.17%.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
This change supports the "HEVC Video with Alpha" profile introduced in WWDC 2019
<https://developer.apple.com/videos/play/wwdc2019/506/>. (This change is a
partial fix for Ticket #7965.)
For example, the following command converts an animation PNG file to an HEVC
with Alpha video:
./ffmpeg -i fate-suite/apng/clock.png -c:v hevc_videotoolbox -allow_sw 1 -alpha_quality 0.75 -vtag hvc1 clock.mov
(This change uses the "HEVC Video with Alpha" profile only when the
'-alpha_quality' value is not 0 for backward compatibility.)
Signed-off-by: Hironori Bono <bouno@rouge.plala.or.jp>
This commit adds a "gophers" handler to the gopher protocol. gophers
is a community-adopted protocol that acts the same way like normal
gopher with the added TLS encapsulation.
The gophers protocol is supported by gopher servers like geomydae(8),
and clients like curl(1), clic(1), and hurl(1).
This commit also adds compilation guards to both gopher and gophers,
since now there are two protocols in the file it makes sense to
have this addition.
Signed-off-by: parazyd <parazyd@dyne.org>
Signed-off-by: Marton Balint <cus@passwd.hu>
AVID streams - currently handled by the AVRN decoder - can be (depending
on extradata contents) either MJPEG or raw video. To decode the MJPEG
variant, the AVRN decoder currently instantiates a MJPEG decoder
internally and forwards decoded frames to the caller (possibly after
cropping them).
This is suboptimal, because the AVRN decoder does not forward all the
features of the internal MJPEG decoder, such as direct rendering.
Handling such forwarding in a full and generic manner would be quite
hard, so it is simpler to just handle those streams in the MJPEG decoder
directly.
The AVRN decoder, which now handles only the raw streams, can now be
marked as supporting direct rendering.
This also removes the last remaining internal use of the obsolete
decoding API.
The NUT and avi demuxers only need ff_codec_movvideo_tags and so this
removes a dependency on the rest of isom.c as well as on mpeg4audio.c
(which isom depends on); it is similar for the Matroska demuxer and
muxers, except that the mpeg4audio.c dependency can't be avoided.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It only existed because some code in mjpegenc_common.c relied on it;
yet said code was actually only used by mjpegenc.c and has been moved
there.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The avrn decoder actually only needs one thing: The MJPEG decoder.
Instead the Makefile made it compile mjpegdec and configure required
some of the prerequisites of the MJPEG decoder (exif and jpegtables).
Even if all the prerequisites of the MJPEG decoder were required, it
would still not make the MJPEG decoder usable, because for that
the MJPEG decoder needs to be in the list of codecs in codec_list.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The fixed-point AAC decoder is the only user of the fixed-point sinewin
tables from sinewin; and it only uses a few of them (about 10% when
counting by size). This means that guarding initializing these tables by
an AVOnce (as done in 3719122065) is
unnecessary for them. Furthermore the array of pointers to the
individual arrays is also unneeded.
Therefore this commit moves these tables directly into aacdec_fixed.c;
this is done by ridding the original sinewin.h and sinewin_tablegen.h
headers completely of any fixed-point code at the cost of a bit of
duplicated code (the alternative is an ugly ifdef-mess).
This saves about 58KB from the binary when using hardcoded tables (as
these tables are hardcoded in this scenario); when not using hardcoded
tables, most of these savings only affect the .bss segment, but the rest
(< 1KB) contains relocations (i.e. savings in .data.rel.ro).
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Setting the defaults for $arch happens only later, so
the current code would not set AS correctly if --arch
was not specified on the command-line.
Fix it by adding an explicit fallback to $arch_default.
Signed-off-by: Josh Dekker <josh@itanimul.li>
avcodec has no facilities to generate timestamps properly from
output frame numbers (and it would be wrong for VFR anyway),
so pass through the timestamps using rav1e's opaque user data
feature, which was added in v0.4.0.
This bumps the minimum librav1e version to 0.4.0.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This was introduced in version 4.6. And may not exist all without an
optional package. So to prevent a hard dependency on needing the Linux
kernel headers to compile, make this optional.
Also ignore the status of the ioctl, since it may fail on older kernels
which don't support it. It's okay to ignore as its not fatal and any
serious errors will be caught later by the mmap call.
SMVJPEG stores frames as slices of a big JPEG image. The decoder is
implemented as a wrapper that instantiates a full internal MJPEG
decoder, then forwards the decoded frames with offset data pointers.
This is unnecessarily complex and fragile, not supporting useful decoder
capabilities like direct rendering.
Re-implement the decoder inside the MJPEG decoder, which is accomplished
by returning each decoded frame multiple times, setting cropping
information appropriately on each instance.
One peculiar aspect of the previous design is that since
- the smvjpeg decoder returns one frame per input packet
- there are multiple frames in each packets (the aformentioned slices)
the demuxer needs to return each packet multiple times.
This is now also eliminated - the demuxer now returns each packet
exactly once, with the duration set to the number of frames it decodes
to.
This also removes one of the last remaining internal uses of the old
video decoding API.
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.
AV1 decoder is supported on Tiger Lake+ platforms since libmfx 1.34
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
Signed-off-by: Zhong Li <zhongli_dev@126.com>
Currently, every filter needs to provide code to transfer data from
AVFrame* to model input (DNNData*), and also from model output
(DNNData*) to AVFrame*. Actually, such transfer can be implemented
within DNN module, and so filter can focus on its own business logic.
DNN module also exports the function pointer pre_proc and post_proc
in struct DNNModel, just in case that a filter has its special logic
to transfer data between AVFrame* and DNNData*. The default implementation
within DNN module is used if the filter does not set pre/post_proc.
This AV1 decoder is currently only used for hardware accelerated decoding.
It can be extended into a native decoder in the future, so set its name to
"av1" and temporarily give it the lowest priority in the codec list.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: James Almer <jamrial@gmail.com>
There are compiler and runtime check for MSA and MMI.
Remove the redundant setting of MSA and MMI for cores specified by "--cpu".
Signed-off-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The latest builds of glslang introduce new libraries that need to be
linked for all symbols to be fully resolved.
This change will break building against older installations of glslang
and it's very hard to tell them apart as the library change upstream
was not accompanied by any version bump and no official release has
been made with this change it - just lots of people packaging up git
snapshots. So, apologies in advance.
The most useful feature here is the ability to automatically extract the
framebuffer format and modifiers. It also makes support for multi-plane
framebuffers possible, though none are added to the format table in this
patch.
This requires libdrm 2.4.101 (from April 2020) to build, so it includes a
configure check to allow compatibility with existing distributions. Even
with libdrm support, it still won't do anything at runtime if you are
running Linux < 5.7 (before June 2020).
To enable runtime detection for MIPS, we need to refine ffbuild
part to support buildding these feature together.
Firstly, we fixed configure, let it probe native ability of toolchain
to decide wether a feature can to be enabled, also clearly marked
the conflictions between loongson2 & loongson3 and Release 6 & rest.
Secondly, we compile MMI and MSA C sources with their own flags to ensure
their flags won't pollute the whole program and generate illegal code.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
OpenVINO is a Deep Learning Deployment Toolkit at
https://github.com/openvinotoolkit/openvino, it supports CPU, GPU
and heterogeneous plugins to accelerate deep learning inferencing.
Please refer to https://github.com/openvinotoolkit/openvino/blob/master/build-instruction.md
to build openvino (c library is built at the same time). Please add
option -DENABLE_MKL_DNN=ON for cmake to enable CPU path. The header
files and libraries are installed to /usr/local/deployment_tools/inference_engine/
with default options on my system.
To build FFmpeg with openvion, take my system as an example, run with:
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/deployment_tools/inference_engine/lib/intel64/:/usr/local/deployment_tools/inference_engine/external/tbb/lib/
$ ../ffmpeg/configure --enable-libopenvino --extra-cflags=-I/usr/local/deployment_tools/inference_engine/include/ --extra-ldflags=-L/usr/local/deployment_tools/inference_engine/lib/intel64
$ make
Here are the features provided by OpenVINO inference engine:
- support more DNN model formats
It supports TensorFlow, Caffe, ONNX, MXNet and Kaldi by converting them
into OpenVINO format with a python script. And torth model
can be first converted into ONNX and then to OpenVINO format.
see the script at https://github.com/openvinotoolkit/openvino/tree/master/model-optimizer/mo.py
which also does some optimization at model level.
- optimize at inference stage
It optimizes for X86 CPUs with SSE, AVX etc.
It also optimizes based on OpenCL for Intel GPUs.
(only Intel GPU supported becuase Intel OpenCL extension is used for optimization)
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>
This contains encoder wrappers for H264, HEVC, AAC, AC3 and MP3.
This is based on top of an original patch by wm4
<nfxjfg@googlemail.com>. The original patch supported both encoding
and decoding, but this patch only includes encoding.
The patch contains further changes by Paweł Wegner
<pawel.wegner95@gmail.com> (primarily for splitting out the encoding
parts of the original patch) and further cleanup, build compatibility
fixes and tweaks for use with Qualcomm encoders by Martin Storsjö.
Signed-off-by: Martin Storsjö <martin@martin.st>
And rename it to retimeinterleave, use the pcm_rechunk bitstream filter for
rechunking.
By seperating the two functions we hopefully get cleaner code.
Signed-off-by: Marton Balint <cus@passwd.hu>
Adding the support to build FFMPEG with HW accelerated decode(nvdec) and
encode on aarch64 architecture.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The webm_chunk muxer requires the WebM muxer, yet it does not directly
require anything from libavformat/matroska.c (it does not even include
the corresponding header). So remove the dependency from the Makefile
and add a _select to configure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
vf_dnn_processing.c recently changed to use swscale to trasfer data
between AVFrame and dnn model.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Using a compiler with a different host triplet is considered
cross-compiling, even when it is for the same architecture as the
build system. With such a cross-compiler, it is still valid to
optimize builds with --cpu=host. Make the condition that aborts in
this case into a warning instead, since a cross-compiler for an
incompatible architecture will fail with -mtune=native anyway.
Signed-off-by: David Michael <fedora.dm0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
