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.
