Re: [FFmpeg-devel] [PATCH v6 1/2] libavcodec: Added DFPWM1a codec

[Jack Bruienne <jackbruienne@gmail.com>]

On 3/7/22 06:03, Tomas Härdin wrote:

> 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

I'm curious how this works. Do you just cut out those bytes from the encoder output, or is it modified in some way? Wouldn't removing the data entirely eventually cause much of the audio to be lost?

>> 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.

I think the best standardized container for DFPWM will be WAV. I'll have to figure out the best place to properly standardize this, but one first step may be to implement this in CC directly. Unfortunately, ComputerCraft is currently without a maintainer - the previous one stepped down in December, and no changes are being made outside of critical bugfixes. I do hope to pick up development in the future, and I already run a reimplementation of the mod outside Minecraft, but as it stands today, getting this to be picked up by users will be quite difficult.

However, I do also maintain my own audio processing library AUKit, which now includes support for DFPWM in WAV. Since CC only has a basic raw DFPWM player built-in (which strictly requires 48kHz mono audio), many users turn to it to play more complex formats like WAV with a different sample rate, FLAC, etc. This may be a decent start, but it's far from having full support built-in.

I'll see if I can get in contact with the owner of the DFPWM wiki page. This will be especially important if this patch gets merged, as people likely won't see that you can use FFmpeg on those pages. I am able to submit pull requests to the ComputerCraft documentation site, however, so I'm able to get changes made there much easier.

In the meantime, I've made a sort-of RFC for the format:https://gist.github.com/MCJack123/90c24b64c8e626c7f130b57e9800962c

>> ---
>>    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)

I'll update the patch to apply to the current master, but I feel like by the time this next gets reviewed master may break again. Should I just keep updating the patch to master and resubmitting whenever I notice a new commit breaks it?

> /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-request@ffmpeg.org  with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".