This is possible, because every given FFCodec has to implement
exactly one of these. Doing so decreases sizeof(FFCodec) and
therefore decreases the size of the binary.
Notice that in case of position-independent code the decrease
is in .data.rel.ro, so that this translates to decreased
memory consumption.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This increases type-safety by avoiding conversions from/through void*.
It also avoids the boilerplate "AVSubtitle *sub = data;" line
for subtitle decoders. Its only downside is that it increases
sizeof(FFCodec), yet this can be more than offset lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, codec.h contains both public and private parts
of AVCodec. This exposes the internals of AVCodec to users
and leads them into the temptation of actually using them
and forces us to forward-declare structures and types that
users can't use at all.
This commit changes this by adding a new structure FFCodec to
codec_internal.h that extends AVCodec, i.e. contains the public
AVCodec as first member; the private fields of AVCodec are moved
to this structure, leaving codec.h clean.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move FF_CODEC_TAGS_END as well as struct AVCodecDefault.
This reduces the amount of files that have to include internal.h
(which comes with quite a lot of indirect inclusions), as e.g.
most encoders don't need it. It is furthemore in preparation
for moving the private part of AVCodec out of the public codec.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since the request_channel_layout is used only by a handful of codecs,
move the option to codec private contexts.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@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>
The majority of frame-threaded decoders (mainly the intra-only)
need exactly one part of ThreadFrame: The AVFrame. They don't
need the owners nor the progress, yet they had to use it because
ff_thread_(get|release)_buffer() requires it.
This commit changes this and makes these functions work with ordinary
AVFrames; the decoders that need the extra fields for progress
use ff_thread_(get|release)_ext_buffer() which work exactly
as ff_thread_(get|release)_buffer() used to do.
This also avoids some unnecessary allocations of progress AVBuffers,
namely for H.264 and HEVC film grain frames: These frames are not
used for synchronization and therefore don't need a ThreadFrame.
Also move the ThreadFrame structure as well as ff_thread_ref_frame()
to threadframe.h, the header for frame-threaded decoders with
inter-frame dependencies.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These will be used by the codecs that need allocated progress
and is in preparation for no longer using ThreadFrame by the codecs
that don't.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for further commits that will stop
using ThreadFrame for frame-threaded codecs that don't use
ff_thread_(await|report)_progress(); the API for those codecs
having inter-frame depdendencies will live in threadframe.h.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is by definition the appropriate place for it.
Remove all the now unnecessary libavcodec/internal.h inclusions;
also remove other unnecessary headers from the affected files.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This function is quite small (96B with GCC 11.2 on x64 Ubuntu 21.10
at -O3), making it more economical to duplicate it into libavformat
instead of exporting it as avpriv: Doing so saves 2x24B in .dynsim,
2x16B in .dynstr, 2x2B .gnu.version, 24B in .rela.plt, 16B in .plt,
16B in .plt.sec (if enabled), 4B .gnu.hash; besides the actual
duplicated code this also adds 2x8B .eh_frame_hdr and 24B .eh_frame.
In other words: Duplicating is neutral size-wise (it is also presumed
neutral for other systems). Given that it avoids the runtime
overhead of dynamic symbols, it is advantageouos to duplicate the
function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
libavcodec currently exports four avpriv symbols that deal with
PixelFormatTags: avpriv_get_raw_pix_fmt_tags, avpriv_find_pix_fmt,
avpriv_pix_fmt_bps_avi and avpriv_pix_fmt_bps_mov. The latter two are
lists of PixelFormatTags, the former returns such a list and the second
searches a list for a pixel format that matches a given fourcc; only
one of the aforementioned three lists is ever searched.
Yet for avpriv_pix_fmt_bps_avi, avpriv_pix_fmt_bps_mov and
avpriv_find_pix_fmt the overhead of exporting these functions actually
exceeds the size of said objects (at least for ELF; the following numbers
are for x64 Ubuntu 20.10):
The code size of avpriv_find_pix_fmt is small (GCC 10.2 37B, Clang 11 41B),
yet exporting it adds a 20B string for the name alone to the exporting
as well as to each importing library; there is more: Four bytes in the
exporting libraries .gnu.hash; two bytes each for the exporting as well
as each importing libraries .gnu.version; 24B in the exporting as well
as each importing libraries .dynsym; 16B+24B for an entry in .plt as
well as the accompanying relocation entry in .rela.plt for each
importing library.
The overhead for the lists is similar: The strings are 23B and the
.plt+.rela.plt pair is replaced by 8B+24B for an entry in .got and
a relocation entry in .rela.dyn. These lists have a size of 80 resp.
72 bytes.
Yet for ff_raw_pix_fmt_tags, exporting it is advantageous compared to
duplicating it into libavformat and potentially libavdevice. Therefore
this commit replaces all library uses of the four symbols with a single
function that is exported for shared builds. It has an enum parameter
to choose the desired list besides the parameter for the fourcc. New
lists can be supported with new enum values.
Unfortunately, avpriv_get_raw_pix_fmt_tags could not be removed, as the
fourcc2pixfmt tool uses the table of raw pix fmts. No other user of this
function remains.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array access
Fixes: 39736/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ARGO_fuzzer-4820016722214912
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 37197/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ARGO_fuzzer-5877046382297088
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In some extrme cases, like with adpcm_ms samples with an extremely high channel
count, get_audio_frame_duration() may return a negative frame duration value.
Don't propagate it, and instead return 0, signaling that a duration could not
be determined.
Fixes ticket #9312
Signed-off-by: James Almer <jamrial@gmail.com>
These have mostly been added because of FF_API_*; yet when these were
removed, removing the header has been forgotten.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: signed integer overflow: 486539264 * 14 cannot be represented in type 'int'
Fixes: 35281/clusterfuzz-testcase-minimized-ffmpeg_dem_RSD_fuzzer-6068262742917120
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 104962766 * 32 cannot be represented in type 'int'
Fixes: 33614/clusterfuzz-testcase-minimized-ffmpeg_dem_RSD_fuzzer-6252129036664832
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 44331634 * 65 cannot be represented in type 'int'
Fixes: 32120/clusterfuzz-testcase-minimized-ffmpeg_dem_RSD_fuzzer-5760221223583744
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
AV_CODEC_CAP_AUTO_THREADS was originally added in b4d44a45f9 to mark
codecs that spawn threads internally and are able to select an optimal
threads count by themselves (all such codecs are wrappers around
external libraries). It is used by lavc generic code to check whether it
should handle thread_count=0 itself or pass the zero directly to the
codec implementation. Within this meaning, it is clearly supposed to be
an internal cap rather than a public one, since from the viewpoint of a
libavcodec user, lavc ALWAYS handles thread_count=0. Whether it happens
in the generic code or within the codec internals is not a meaningful
difference for the caller.
External aspects of this flag will be dealt with in the following
commit.
Fixes: signed integer overflow: 1172577312 * 2 cannot be represented in type 'int'
Fixes: 29924/clusterfuzz-testcase-minimized-ffmpeg_dem_BOA_fuzzer-4882912874594304
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It has been deprecated for 4 years and certain new codecs do not work
with it.
Also include AVCodecContext.refcounted_frames, as it has no effect with
the new API.
Fixes: signed integer overflow: 131203586 * 28 cannot be represented in type 'int'
Fixes: 26817/clusterfuzz-testcase-minimized-ffmpeg_dem_MSF_fuzzer-6296902548848640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 617890810133996544 * 16 cannot be represented in type 'long'
Fixes: 26565/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-5092054700654592
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This function existed to enable codecs with non-threadsafe init functions
to initialize other codecs despite the fact that normally no two codecs
with non-threadsafe init functions can be initialized at the same time
(there is a mutex guarding this). Yet there are no users of this
function any more as all users have been made thread-safe (switching
away from ff_codec_open2_recursive() was required for this as said
function requires the caller to hold the lock to the mutex guarding the
initializations and this is only true for codecs with the
FF_CODEC_CAP_INIT_THREADSAFE flag unset); so remove it.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This avoids per codec checks for channels not being 0
Fixes: division by 0
Fixes: 25419/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FASTAUDIO_fuzzer-5632544761184256
Fixes: 25433/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FASTAUDIO_fuzzer-6215671900536832
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Suggested-by: Paul B Mahol <onemda@gmail.com>
See: [FFmpeg-devel] [PATCH 1/3] avcodec/fastaudio: Check channel
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
They add considerable complexity to frame-threading implementation,
which includes an unavoidably leaking error path, while the advantages
of this option to the users are highly dubious.
It should be always possible and desirable for the callers to make their
get_buffer2() implementation thread-safe, so deprecate this option.
This ensures no queued timestamps or side data are kept and used after
seeking, preventing potential desyncs.
Signed-off-by: James Almer <jamrial@gmail.com>
Andreas Rheinhardt
Vittorio Giovara
Jack Bruienne
Michael Niedermayer
James Almer
Cameron Cawley
Andreas Rheinhardt
Anton Khirnov
Paul B Mahol
Zane van Iperen