Due to the lack of an active AMF maintainer at the moment, as well
as plans to add the av1 encoder and other improvements of AMF,
I added myself to the maintainers. Timely review and merging
patches targeting AMF integration should improve support
of AMD GPUs and APUs in FFmpeg.
For the last couple of years I have been working on AMF related
patches to ffmpeg and other open source projects.
This updates the list closer to reality.
Iam not a professional server admin, iam happy to help maintain the box as i have
done in the past. But iam not qualified nor volunteering to fix sudden problems
nor do i do major upgrades (i lack the experience to recover the box remotely if
something goes wrong) and also iam not maintaining backups ATM (our backup system
had a RAID-5 failure, raz is working on setting a new one up)
Maybe this should be signaled in a different way than spliting the lines but ATM
people ping me if something is wrong and what i do is mainly mail/ping raz
and try to find another root admin so raz is not the only active & professional
admin on the team. It would be more efficient if people contact raz and others
directly instead of depending on my waking up and forwarding a "ffmpeg.org" is down note
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
So I can merge my own changes to this filter after they pass peer
review, as well as keeping it in sync with upstream API changes / new
features.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: James Almer <jamrial@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>
Current listed maintainers for vaapi plugin are
not reponsive and/or currently active in the
ffmpeg community. Thus, vaapi plugin patches
(and qsv plugin) have generally gone ignored or
lost in the ether for too long.
Remove Gwenole Beauchesne from vaapi maintainer
who has not been active since 2016.
Current alternative maintainer for vaapi is Mark
Thompson whom has not been active since
March/April 2021.
Therefore, add Haihao Xiang to vaapi maintainer
who's primary role is FFmpeg development with a
focus on the vaapi and qsv plugins. Haihao has
over a decade of media experience and many years
of FFmpeg development experience, amongst other
media frameworks.
The additional patch for adding Haihao as qsv
plugin maintainer has been submitted previously:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210608141134.27448-1-zhongli_dev@126.com/
This will help FFmpeg to continue to be the leading
multimedia framework by allowing these plugins to be
actively improved, enhanced, and maintained for existing
and future HW platforms.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
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.
AMV is a hard-coded (and broken) subset of AVI. It's not worth sullying
the existing AVI muxer with its filth.
Fixes ticket #747.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Used in FMVs for FX Fighter and Croc. Supports BVID and BASF streams,
requests samples for anything else.
Due to the way BASF streams are contained in the file, only one is
supported. I have yet to see a BRP file with multiple.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
The Xiph foundation never standardized either Daala nor its mapping in Ogg,
and all files that were created are undecodable without knowledge of the
git hash.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It has been shut down in April 2019.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
