tor 2022-03-03 klockan 10:44 -0500 skrev Jack Bruienne: > > 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.
This sounds similar to something I wrote for the Atari 2600 a number of years ago ( https://www.pouet.net/prod.php?which=59283 ) I found an encoder online for DFPWM, and it seems to suffer from the same "beeping" that my debeeping hack fixes (suppressing 0xAA and 0x55 bytes). Perhaps a similar hack could be useful in dfpwmenc.c > > 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. From experience it's usually better to be strict when it comes to stuff like this. The ComputerCraft people should work out a standard for this, preferably a container. We've had a similar problem in FreeDV where which codec was being used was implicit most of the time, which has been resolved with the .c2 format. > --- > Changelog | 1 + > MAINTAINERS | 1 + > doc/general_contents.texi | 1 + > libavcodec/Makefile | 2 + > libavcodec/allcodecs.c | 2 + > libavcodec/codec_desc.c | 7 ++ > libavcodec/codec_id.h | 1 + > libavcodec/dfpwmdec.c | 134 > ++++++++++++++++++++++++++++++++++++++ > libavcodec/dfpwmenc.c | 121 ++++++++++++++++++++++++++++++++++ > libavcodec/utils.c | 2 + > libavcodec/version.h | 4 +- > 11 files changed, 274 insertions(+), 2 deletions(-) > create mode 100644 libavcodec/dfpwmdec.c > create mode 100644 libavcodec/dfpwmenc.c Patch doesn't apply on current master (e645a1d) /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
