The muxer seems to have had one seemingly accidental use of
LIBAVCODEC_IDENT, while LIBAVFORMAT_IDENT probably is the
relevant one (which is used multiple times in the same file).
Signed-off-by: Martin Storsjö <martin@martin.st>
This patch removes all occurences of DNNReturnType from the DNN module.
This commit replaces DNN_SUCCESS by 0 (essentially the same), so the
functions with DNNReturnType now return 0 in case of success, the negative
values otherwise.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
Switch to returning specific error codes or DNN_GENERIC_ERROR
when an error is encountered in the common DNN backend functions.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
Switch to returning specific error codes or DNN_GENERIC_ERROR
when an error is encountered.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
Switch to returning specific error codes or DNN_GENERIC_ERROR
when an error is encountered. For TensorFlow C API errors, currently
DNN_GENERIC_ERROR is returned.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
Switch to returning specific error codes or DNN_GENERIC_ERROR
when an error is encountered. For OpenVINO API errors, currently
DNN_GENERIC_ERROR is returned.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
This commit returns specific error codes from the functions in the
dnn_io_proc instead of DNN_ERROR.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
This commit returns specific error codes from the execution
functions in the Native Backend layers instead of DNN_ERROR.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
This commit prepares the filter side to handle specific error codes
from the DNN backends instead of current DNN_ERROR.
Signed-off-by: Shubhanshu Saxena <shubhanshu.e01@gmail.com>
In Gentoo and ChromeOS we want to allow pure LLVM builds without
using GNU tools, so we block any unwanted mixed GNU/LLVM usages
(GNU tools are still kept around in our chroots for projects
like glibc which cannot yet be built otherwise).
The default ${cross_prefix}${ranlib_default} points to GNU and
fails, so move the test a bit later - after the defaults are
set and the proper values get overriden - such that ffmpeg
configure calls the llvm-ranlib we desire. [1]
[1] https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/ffmpeg/ffmpeg-4.4.1-r1.ebuild?id=7a34377e3277a6a0e2eedd40e90452a44c55f1e6#n477
Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
This commit adds support for storing DFPWM audio in a WAV container.
It uses the WAVEFORMATEXTENSIBLE structure, following these conventions:
https://gist.github.com/MCJack123/90c24b64c8e626c7f130b57e9800962c
The implementation is very simple: it just adds the GUID to the list of
WAV GUIDs, and modifies the WAV muxer to always use WAVEFORMATEXTENSIBLE
format with that GUID.
This creates a standard container format for DFPWM besides raw data.
It will allow users to transfer DFPWM audio in a standard container
format, with the sample rate and channel count contained in the file
as opposed to being an external parameter as in the raw format.
This format is already supported in my AUKit library, which is the CC
analog to libav (albeit much smaller). Support in other applications is TBD.
Signed-off-by: Jack Bruienne <jackbruienne@gmail.com>
This patch builds on my previous DFPWM codec patch, adding a raw
audio format to be able to read/write the raw files that are most commonly
used (as no other container format supports it yet).
The muxers are mostly copied from the PCM demuxer and the raw muxers, as
DFPWM is typically stored as raw data.
Please see the previous patch for more information on DFPWM.
Signed-off-by: Jack Bruienne <jackbruienne@gmail.com>
From the wiki page (https://wiki.vexatos.com/dfpwm):
> DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec
> created by Ben “GreaseMonkey” Russell in 2012, originally to be used
> as a voice codec for asiekierka's pixmess, a C remake of 64pixels.
> It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole
> low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding
> creates a high-pitched whine, it is often followed by some post-processing
> filters to make the stream more listenable.
It has recently gained popularity through the ComputerCraft mod for
Minecraft, which added support for audio through this codec, as well as
the Computronics expansion which preceeded the official support. These
both implement the slightly adjusted 1a version of the codec, which is
the version I have chosen for this patch.
This patch adds a new codec (with encoding and decoding) for DFPWM1a.
The codec sources are pretty simple: they use the reference codec with
a basic wrapper to connect it to the FFmpeg AVCodec system.
To clarify, the codec does not have a specific sample rate - it is
provided by the container (or user), which is typically 48000, but has
also been known to be 32768. The codec does not specify channel info
either, and it's pretty much always used with one mono channel.
However, since it appears that libavcodec expects both sample rate and
channel count to be handled by either the codec or container, I have
made the decision to allow multiple channels interleaved, which as far
as I know has never been used, but it works fine here nevertheless. The
accompanying raw format has a channels option to set this. (I expect
most users of this will not use multiple channels, but it remains an
option just in case.)
This patch will be highly useful to ComputerCraft developers who are
working with audio, as it is the standard format for audio, and there
are few user-friendly encoders out there, and even fewer decoders. It
will streamline the process for importing and listening to audio,
replacing the need to write code or use tools that require very
specific input formats.
You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test
out DFPWM playback. To use it, run the program and type this command:
"attach left speaker" Then run "speaker play <file.dfpwm>" for each file.
The app runs in a sandbox, so files have to be transferred in first;
the easiest way to do this is to simply drag the file on the window.
(Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.)
Sample DFPWM files can be generated with an online tool at
https://music.madefor.cc. This is the current best way to encode DFPWM
files. Simply drag an audio file onto the page, and it will encode it,
giving a download link on the page.
I've made sure to update all of the docs as per Developer§7, and I've
tested it as per section 8. Test files encoded to DFPWM play correctly
in ComputerCraft, and other files that work in CC are correctly decoded.
I have also verified that corrupt files do not crash the decoder - this
should theoretically not be an issue as the result size is constant with
respect to the input size.
Signed-off-by: Jack Bruienne <jackbruienne@gmail.com>
This patch adds optional support for Arm Pointer Authentication Codes.
PAC support is turned on or off at compile time using additional
compiler flags. Unless any of these is enabled explicitly, no additional
code will be emitted at all.
Signed-off-by: André Kempe <andre.kempe@arm.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes: signed integer overflow: 10 * 808464428 cannot be represented in type 'int'
Fixes: assertion failure
Fixes: ticket9651
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself
Fixes: Ticket8486
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes hang at end of input with this command:
ffmpeg -f lavfi -i testsrc2=d=50,format=yuv444p -lavfi \
"extractplanes=y+u+v[y][u][v];[y]tpad=start=0[y];[u]tpad=start=0[u];[v]negate[v];[y][u][v]vstack=3" -f null -
While swscale can be reconfigured with sws_setColorspaceDetails,
the in/out ranges also need to be set before calling
sws_init_context, otherwise the initialization might choose
fastpaths that don't take the ranges into account.
Therefore, look at in->color_range too, when deciding on whether
the scaler needs to be reconfigured.
Add a new member variable for keeping track of this, for being
able to differentiate between whether the scale filter parameter
"in_range" has been set (which should override whatever the input
frame has set) or whether it has been configured based on the
latest frame (which should trigger reconfiguring the scaler if
the input frame ranges change).
Fixes: Ticket #9576
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes building for arm after 10c2ef1ca4.
The argument to av_clip_uintp2 must be an assembly time immediate
constant.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by and commit message details-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Paul B Mahol
Martin Storsjö
Shubhanshu Saxena
Andreas Rheinhardt
Adrian Ratiu
Wu Jianhua
Jack Bruienne
Limin Wang
Andre Kempe
Thilo Borgmann
Michael Niedermayer