[FFmpeg-devel] [PATCH] libavformat/tcp: add local_addr/local_port for network option
Signed-off-by: jack
---
libavformat/tcp.c | 44
1 file changed, 44 insertions(+)
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index a11ccbb913..598d61067e 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -36,6 +36,8 @@ typedef struct TCPContext {
const AVClass *class;
int fd;
int listen;
+int local_port;
+char *local_addr;
int open_timeout;
int rw_timeout;
int listen_timeout;
@@ -52,6 +54,8 @@ typedef struct TCPContext {
#define E AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
{ "listen", "Listen for incoming connections", OFFSET(listen),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 2, .flags = D|E },
+{ "local_port", "Local port",
OFFSET(local_port), AV_OPT_TYPE_INT,{ .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
+{ "local_addr", "Local address",
OFFSET(local_addr), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0,
.flags = D|E },
{ "timeout", "set timeout (in microseconds) of socket I/O operations",
OFFSET(rw_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
{ "listen_timeout", "Connection awaiting timeout (in milliseconds)",
OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
{ "send_buffer_size", "Socket send buffer size (in bytes)",
OFFSET(send_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
@@ -73,6 +77,39 @@ static const AVClass tcp_class = {
static void customize_fd(void *ctx, int fd)
{
TCPContext *s = ctx;
+
+if (s->local_addr) {
+struct addrinfo hints = { 0 }, *ai;
+int ret;
+int port = 0;
+
+hints.ai_family = AF_UNSPEC;
+hints.ai_socktype = SOCK_STREAM;
+
+if (s->local_port > 0)
+port = s->local_port;
+
+ret = getaddrinfo(s->local_addr, "0", , );
+if (ret) {
+av_log(ctx, AV_LOG_WARNING,
+ "Failed to bind local addr: %s port: %d err: %s\n",
+s->local_addr, s->local_port, gai_strerror(ret));
+} else {
+if (ai->ai_family == AF_INET6) {
+struct sockaddr_in6 * sockaddr_v6 = (struct sockaddr_in6
*)ai->ai_addr;
+sockaddr_v6->sin6_port = htons(port);
+} else {
+struct sockaddr_in * sockaddr = (struct sockaddr_in
*)ai->ai_addr;
+sockaddr->sin_port = htons(port);
+}
+ret = bind(fd, (struct sockaddr *)ai->ai_addr,
(int)ai->ai_addrlen);
+if (ret) {
+av_log(ctx, AV_LOG_WARNING,
+"Failed to bind local addr: %s port: %d err: %s\n",
+s->local_addr, s->local_port, gai_strerror(ret));
+}
+}
+}
/* Set the socket's send or receive buffer sizes, if specified.
If unspecified or setting fails, system default is used. */
if (s->recv_buffer_size > 0) {
@@ -129,6 +166,13 @@ static int tcp_open(URLContext *h, const char *uri, int
flags)
if (buf == endptr)
s->listen = 1;
}
+if (av_find_info_tag(buf, sizeof(buf), "local_port", p)) {
+s->local_port = strtol(buf, NULL, 10);
+}
+if (av_find_info_tag(buf, sizeof(buf), "local_addr", p)) {
+av_freep(>local_addr);
+s->local_addr = av_strndup(buf, strlen(buf));
+}
if (av_find_info_tag(buf, sizeof(buf), "timeout", p)) {
s->rw_timeout = strtol(buf, NULL, 10);
}
--
2.39.2
___
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".
Re: [FFmpeg-devel] Possibly a little bug in af_loudnorm.c
Please check the code:line 209 if (c == 0 || fabs(buf[index + c]) > max_peak) max_peak = fabs(buf[index + c]); 'max_peak' is initialized. On Sat, Aug 20, 2022 at 5:39 PM jagad hariseno wrote: > Hi All, > > at af_loudnorm.c in line number 188: > double this, next, max_peak; > > max_peak is not initialized with 0. and could be contains any value or > noise. > I could be wrong but I think init with 0. should be better: > > double this, next, max_peak=0.; > > Best Regards > > jagad. > ___ > 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". > ___ 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".
[FFmpeg-devel] [PATCH] avcodec: Fix time reporting for DFPWM streams
This adds the exact bits per sample for DFPWM to
av_get_exact_bits_per_sample.
Previously, the DTS and PTS were set to 0 because the codec never
reported them, but adding this allows libavformat to automatically
set DTS and PTS from the byte position of the stream.
Signed-off-by: Jack Bruienne
---
libavcodec/utils.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index eb7e505a..940f25fe 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -495,6 +495,8 @@ const char *avcodec_profile_name(enum AVCodecID codec_id, int profile)
int av_get_exact_bits_per_sample(enum AVCodecID codec_id)
{
switch (codec_id) {
+case AV_CODEC_ID_DFPWM:
+return 1;
case AV_CODEC_ID_8SVX_EXP:
case AV_CODEC_ID_8SVX_FIB:
case AV_CODEC_ID_ADPCM_ARGO:
___
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".
[FFmpeg-devel] [PATCH v7 3/3] libavformat: Added DFPWM WAV container support
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
---
libavformat/riff.c| 3 +++
libavformat/riffenc.c | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 0c19d3f..f098c1d 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -587,6 +587,8 @@ const AVCodecTag ff_codec_wav_tags[] = {
{ AV_CODEC_ID_AAC, 0xA106 },
{ AV_CODEC_ID_SPEEX, 0xA109 },
{ AV_CODEC_ID_FLAC,0xF1AC },
+/* DFPWM does not have an assigned format tag; it uses a GUID in WAVEFORMATEX instead */
+{ AV_CODEC_ID_DFPWM, 0xFFFE },
{ AV_CODEC_ID_ADPCM_SWF, ('S' << 8) + 'F' },
/* HACK/FIXME: Does Vorbis in WAV/AVI have an (in)official ID? */
{ AV_CODEC_ID_VORBIS, ('V' << 8) + 'o' },
@@ -637,5 +639,6 @@ const AVCodecGuid ff_codec_wav_guids[] = {
{ AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D, 0xFB, 0x42, 0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
{ AV_CODEC_ID_MP2, { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB, 0xCF, 0x11, 0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
{ AV_CODEC_ID_ADPCM_AGM,{ 0x82, 0xEC, 0x1F, 0x6A, 0xCA, 0xDB, 0x19, 0x45, 0xBD, 0xE7, 0x56, 0xD3, 0xB3, 0xEF, 0x98, 0x1D } },
+{ AV_CODEC_ID_DFPWM,{ 0x3A, 0xC1, 0xFA, 0x38, 0x81, 0x1D, 0x43, 0x61, 0xA4, 0x0D, 0xCE, 0x53, 0xCA, 0x60, 0x7C, 0xD1 } },
{ AV_CODEC_ID_NONE }
};
diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index ffccfa3..96750e7 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -81,7 +81,7 @@ int ff_put_wav_header(AVFormatContext *s, AVIOContext *pb,
par->channels == 1 && par->channel_layout && par->channel_layout != AV_CH_LAYOUT_MONO ||
par->channels == 2 && par->channel_layout && par->channel_layout != AV_CH_LAYOUT_STEREO ||
par->sample_rate > 48000 ||
- par->codec_id == AV_CODEC_ID_EAC3 ||
+ par->codec_id == AV_CODEC_ID_EAC3 || par->codec_id == AV_CODEC_ID_DFPWM ||
av_get_bits_per_sample(par->codec_id) > 16;
if (waveformatextensible)
@@ -188,7 +188,7 @@ int ff_put_wav_header(AVFormatContext *s, AVIOContext *pb,
/* dwChannelMask */
avio_wl32(pb, write_channel_mask ? par->channel_layout : 0);
/* GUID + next 3 */
-if (par->codec_id == AV_CODEC_ID_EAC3) {
+if (par->codec_id == AV_CODEC_ID_EAC3 || par->codec_id == AV_CODEC_ID_DFPWM) {
ff_put_guid(pb, ff_get_codec_guid(par->codec_id, ff_codec_wav_guids));
} else {
avio_wl32(pb, par->codec_tag);
___
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".
[FFmpeg-devel] [PATCH v7 2/3] libavformat: Add DFPWM raw format
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.
Changes since v4:
Fixed descriptions of formats.
Changes since v2/v3:
Removed unused MIME parsing code, and added channels option.
Signed-off-by: Jack Bruienne
---
Changelog | 2 +-
MAINTAINERS | 1 +
doc/general_contents.texi | 1 +
libavformat/Makefile | 2 +
libavformat/allformats.c | 2 +
libavformat/dfpwmdec.c| 82 +++
libavformat/rawenc.c | 13 +++
libavformat/version.h | 4 +-
8 files changed, 104 insertions(+), 3 deletions(-)
create mode 100644 libavformat/dfpwmdec.c
diff --git a/Changelog b/Changelog
index f3249fe..ac614f8 100644
--- a/Changelog
+++ b/Changelog
@@ -5,7 +5,7 @@ version 5.1:
- dialogue enhance audio filter
- dropped obsolete XvMC hwaccel
- pcm-bluray encoder
-- DFPWM audio encoder/decoder
+- DFPWM audio encoder/decoder and raw muxer/demuxer
version 5.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 57b6f33..931cf4b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -416,6 +416,7 @@ Muxers/Demuxers:
dashdec.c Steven Liu
dashenc.c Karthick Jeyapal
daud.cReimar Doeffinger
+ dfpwmdec.cJack Bruienne
dss.c Oleksij Rempel
dtsdec.c foo86
dtshddec.cPaul B Mahol
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index 14aeaed..fcd9da1 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -578,6 +578,7 @@ library:
@item raw aptX @tab X @tab X
@item raw aptX HD @tab X @tab X
@item raw Chinese AVS video @tab X @tab X
+@item raw DFPWM @tab X @tab X
@item raw Dirac @tab X @tab X
@item raw DNxHD @tab X @tab X
@item raw DTS @tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 16d019d..322c8e7 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -166,6 +166,8 @@ OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
OBJS-$(CONFIG_DCSTR_DEMUXER) += dcstr.o
OBJS-$(CONFIG_DERF_DEMUXER) += derf.o pcm.o
OBJS-$(CONFIG_DFA_DEMUXER) += dfa.o
+OBJS-$(CONFIG_DFPWM_DEMUXER) += dfpwmdec.o pcm.o
+OBJS-$(CONFIG_DFPWM_MUXER) += rawenc.o
OBJS-$(CONFIG_DHAV_DEMUXER) += dhav.o
OBJS-$(CONFIG_DIRAC_DEMUXER) += diracdec.o rawdec.o
OBJS-$(CONFIG_DIRAC_MUXER) += rawenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d066a77..587ad59 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -124,6 +124,8 @@ extern const AVOutputFormat ff_daud_muxer;
extern const AVInputFormat ff_dcstr_demuxer;
extern const AVInputFormat ff_derf_demuxer;
extern const AVInputFormat ff_dfa_demuxer;
+extern const AVInputFormat ff_dfpwm_demuxer;
+extern const AVOutputFormat ff_dfpwm_muxer;
extern const AVInputFormat ff_dhav_demuxer;
extern const AVInputFormat ff_dirac_demuxer;
extern const AVOutputFormat ff_dirac_muxer;
diff --git a/libavformat/dfpwmdec.c b/libavformat/dfpwmdec.c
new file mode 100644
index 000..85d9b61
--- /dev/null
+++ b/libavformat/dfpwmdec.c
@@ -0,0 +1,82 @@
+/*
+ * RAW PCM demuxers
+ * Copyright (c) 2002 Fabrice Bellard
+ * Copyright (c) 2022 Jack Bruienne
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "avformat.h"
+#include "internal.h"
+#include "pcm.h"
+#include "libavutil/log.h"
+#include "libavutil/opt.h"
+#include "libavutil/avassert.h"
+
+typedef struct DFPWMAudioDemuxerContext {
+AVClass *class;
+int sample_rate;
+int channels;
+} DFPWMA
[FFmpeg-devel] [PATCH v7 1/3] libavcodec: Added DFPWM1a codec
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 " 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. Changes since v5: Moved channel check to init, and added sample size check in decoder. Changes since v4: Fixed missing channel check in decoder. Changes since v3: Added support for multiple interleaved channels, and cleaned up the code a bunch. Changes since v2: I've found that the reference encoder has a few errors, and sounds worse than the Java-based implementation that is used most often. I got in contact with someone who knows DFPWM much better than I do, and I worked with them to make a few adjustments that should improve the audio quality. I also made sure that the output matches the Java codec exactly, so it should have the exact same quality as other codecs. Signed-off-by: Jack Bruienne --- 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 + 10 files changed, 272 insertions(+) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 3af8aa0..f3249fe 100644 --- a/Changelog +++ b/Changelog @@ -5,6 +5,7 @@ version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel - pcm-bluray encoder +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca*
Re: [FFmpeg-devel] [PATCH v6 1/2] libavcodec: Added DFPWM1a codec
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 ff
[FFmpeg-devel] [PATCH v6 1/2] libavcodec: Added DFPWM1a codec
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 " 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. Changes since v5: Moved channel check to init, and added sample size check in decoder. Changes since v4: Fixed missing channel check in decoder. Changes since v3: Added support for multiple interleaved channels, and cleaned up the code a bunch. Changes since v2: I've found that the reference encoder has a few errors, and sounds worse than the Java-based implementation that is used most often. I got in contact with someone who knows DFPWM much better than I do, and I worked with them to make a few adjustments that should improve the audio quality. I also made sure that the output matches the Java codec exactly, so it should have the exact same quality as other codecs. Signed-off-by: Jack Bruienne --- 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 diff --git a/Changelog b/Changelog index 5ad2cef..5170a6a 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.c
[FFmpeg-devel] [PATCH v5 2/2] libavformat: Add DFPWM raw format
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. Note on the channels argument: The -ac argument can only be used as an alias if -f dfpwm is passed. If missing, -ac has no effect. The -channels argument will work regardless of the presence of -f. Please see the previous patch for more information on DFPWM. Changes since v4: Fixed descriptions of formats. Changes since v2/v3: Removed unused MIME parsing code, and added channels option. Signed-off-by: Jack Bruienne --- Changelog | 2 +- MAINTAINERS | 1 + doc/general_contents.texi | 1 + libavformat/Makefile | 2 + libavformat/allformats.c | 2 + libavformat/dfpwmdec.c| 82 +++ libavformat/rawenc.c | 13 +++ libavformat/version.h | 4 +- 8 files changed, 104 insertions(+), 3 deletions(-) create mode 100644 libavformat/dfpwmdec.c diff --git a/Changelog b/Changelog index 5170a6a..ec688da 100644 --- a/Changelog +++ b/Changelog @@ -4,7 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel -- DFPWM audio encoder/decoder +- DFPWM audio encoder/decoder and raw muxer/demuxer version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index 57b6f33..931cf4b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -416,6 +416,7 @@ Muxers/Demuxers: dashdec.c Steven Liu dashenc.c Karthick Jeyapal daud.cReimar Doeffinger + dfpwmdec.cJack Bruienne dss.c Oleksij Rempel dtsdec.c foo86 dtshddec.cPaul B Mahol diff --git a/doc/general_contents.texi b/doc/general_contents.texi index 14aeaed..fcd9da1 100644 --- a/doc/general_contents.texi +++ b/doc/general_contents.texi @@ -578,6 +578,7 @@ library: @item raw aptX @tab X @tab X @item raw aptX HD @tab X @tab X @item raw Chinese AVS video @tab X @tab X +@item raw DFPWM @tab X @tab X @item raw Dirac @tab X @tab X @item raw DNxHD @tab X @tab X @item raw DTS @tab X @tab X diff --git a/libavformat/Makefile b/libavformat/Makefile index 6566e40..b89073a 100644 --- a/libavformat/Makefile +++ b/libavformat/Makefile @@ -165,6 +165,8 @@ OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o OBJS-$(CONFIG_DCSTR_DEMUXER) += dcstr.o OBJS-$(CONFIG_DERF_DEMUXER) += derf.o pcm.o OBJS-$(CONFIG_DFA_DEMUXER) += dfa.o +OBJS-$(CONFIG_DFPWM_DEMUXER) += dfpwmdec.o pcm.o +OBJS-$(CONFIG_DFPWM_MUXER) += rawenc.o OBJS-$(CONFIG_DHAV_DEMUXER) += dhav.o OBJS-$(CONFIG_DIRAC_DEMUXER) += diracdec.o rawdec.o OBJS-$(CONFIG_DIRAC_MUXER) += rawenc.o diff --git a/libavformat/allformats.c b/libavformat/allformats.c index d066a77..587ad59 100644 --- a/libavformat/allformats.c +++ b/libavformat/allformats.c @@ -124,6 +124,8 @@ extern const AVOutputFormat ff_daud_muxer; extern const AVInputFormat ff_dcstr_demuxer; extern const AVInputFormat ff_derf_demuxer; extern const AVInputFormat ff_dfa_demuxer; +extern const AVInputFormat ff_dfpwm_demuxer; +extern const AVOutputFormat ff_dfpwm_muxer; extern const AVInputFormat ff_dhav_demuxer; extern const AVInputFormat ff_dirac_demuxer; extern const AVOutputFormat ff_dirac_muxer; diff --git a/libavformat/dfpwmdec.c b/libavformat/dfpwmdec.c new file mode 100644 index 000..85d9b61 --- /dev/null +++ b/libavformat/dfpwmdec.c @@ -0,0 +1,82 @@ +/* + * RAW PCM demuxers + * Copyright (c) 2002 Fabrice Bellard + * Copyright (c) 2022 Jack Bruienne + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "libavutil/avstring.h" +#include "avformat.h" +#include "internal.h" +#include "pcm.h" +#include "libavutil
[FFmpeg-devel] [PATCH v5 1/2] libavcodec: Added DFPWM1a codec
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 " 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. Changes since v4: Fixed missing channel check in decoder. Changes since v3: Added support for multiple interleaved channels, and cleaned up the code a bunch. Changes since v2: I've found that the reference encoder has a few errors, and sounds worse than the Java-based implementation that is used most often. I got in contact with someone who knows DFPWM much better than I do, and I worked with them to make a few adjustments that should improve the audio quality. I also made sure that the output matches the Java codec exactly, so it should have the exact same quality as other codecs. Signed-off-by: Jack Bruienne --- 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 | 133 ++ libavcodec/dfpwmenc.c | 121 ++ libavcodec/utils.c| 2 + libavcodec/version.h | 2 +- 11 files changed, 272 insertions(+), 1 deletion(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 5ad2cef..5170a6a 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca*
[FFmpeg-devel] [PATCH v4 2/2] libavformat: Add DFPWM raw format
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.
Changes since v2/v3:
Removed unused MIME parsing code, and added channels option.
Signed-off-by: Jack Bruienne
---
Changelog | 2 +-
MAINTAINERS | 1 +
doc/general_contents.texi | 1 +
libavformat/Makefile | 2 +
libavformat/allformats.c | 2 +
libavformat/dfpwmdec.c| 82 +++
libavformat/rawenc.c | 13 +++
libavformat/version.h | 4 +-
8 files changed, 104 insertions(+), 3 deletions(-)
create mode 100644 libavformat/dfpwmdec.c
diff --git a/Changelog b/Changelog
index 5170a6a..ec688da 100644
--- a/Changelog
+++ b/Changelog
@@ -4,7 +4,7 @@ releases are sorted from youngest to oldest.
version 5.1:
- dialogue enhance audio filter
- dropped obsolete XvMC hwaccel
-- DFPWM audio encoder/decoder
+- DFPWM audio encoder/decoder and raw muxer/demuxer
version 5.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 57b6f33..931cf4b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -416,6 +416,7 @@ Muxers/Demuxers:
dashdec.c Steven Liu
dashenc.c Karthick Jeyapal
daud.cReimar Doeffinger
+ dfpwmdec.cJack Bruienne
dss.c Oleksij Rempel
dtsdec.c foo86
dtshddec.cPaul B Mahol
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index 14aeaed..fcd9da1 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -578,6 +578,7 @@ library:
@item raw aptX @tab X @tab X
@item raw aptX HD @tab X @tab X
@item raw Chinese AVS video @tab X @tab X
+@item raw DFPWM @tab X @tab X
@item raw Dirac @tab X @tab X
@item raw DNxHD @tab X @tab X
@item raw DTS @tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6566e40..b89073a 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -165,6 +165,8 @@ OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
OBJS-$(CONFIG_DCSTR_DEMUXER) += dcstr.o
OBJS-$(CONFIG_DERF_DEMUXER) += derf.o pcm.o
OBJS-$(CONFIG_DFA_DEMUXER) += dfa.o
+OBJS-$(CONFIG_DFPWM_DEMUXER) += dfpwmdec.o pcm.o
+OBJS-$(CONFIG_DFPWM_MUXER) += rawenc.o
OBJS-$(CONFIG_DHAV_DEMUXER) += dhav.o
OBJS-$(CONFIG_DIRAC_DEMUXER) += diracdec.o rawdec.o
OBJS-$(CONFIG_DIRAC_MUXER) += rawenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d066a77..587ad59 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -124,6 +124,8 @@ extern const AVOutputFormat ff_daud_muxer;
extern const AVInputFormat ff_dcstr_demuxer;
extern const AVInputFormat ff_derf_demuxer;
extern const AVInputFormat ff_dfa_demuxer;
+extern const AVInputFormat ff_dfpwm_demuxer;
+extern const AVOutputFormat ff_dfpwm_muxer;
extern const AVInputFormat ff_dhav_demuxer;
extern const AVInputFormat ff_dirac_demuxer;
extern const AVOutputFormat ff_dirac_muxer;
diff --git a/libavformat/dfpwmdec.c b/libavformat/dfpwmdec.c
new file mode 100644
index 000..d5833f8
--- /dev/null
+++ b/libavformat/dfpwmdec.c
@@ -0,0 +1,82 @@
+/*
+ * RAW PCM demuxers
+ * Copyright (c) 2002 Fabrice Bellard
+ * Copyright (c) 2022 Jack Bruienne
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "avformat.h"
+#include "internal.h"
+#include "pcm.h"
+#include "libavutil/log.h"
+#include "libavutil/opt.h"
+#include "libavutil/avassert.h"
+
+typedef struct DFPWMAudioDemuxerContext {
+AVClass *class;
+int sample_rate;
+int channels;
+} DFPWMAudioDemuxerContext;
+
+static int dfpwm_re
[FFmpeg-devel] [PATCH v4 1/2] libavcodec: Added DFPWM1a codec
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 " 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. Changes since v3: Added support for multiple interleaved channels, and cleaned up the code a bunch. Changes since v2: I've found that the reference encoder has a few errors, and sounds worse than the Java-based implementation that is used most often. I got in contact with someone who knows DFPWM much better than I do, and I worked with them to make a few adjustments that should improve the audio quality. I also made sure that the output matches the Java codec exactly, so it should have the exact same quality as other codecs. Signed-off-by: Jack Bruienne --- 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 | 127 ++ libavcodec/dfpwmenc.c | 121 libavcodec/utils.c| 2 + libavcodec/version.h | 2 +- 11 files changed, 266 insertions(+), 1 deletion(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 5ad2cef..5170a6a 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca* foo86 + dfpwm*Ja
[FFmpeg-devel] [PATCH v3 1/2] libavcodec: Added DFPWM1a codec
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. 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. It will streamline the process for importing 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 " 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. Changes since the prior v2 patch: I've found that the reference encoder has a few errors, and sounds worse than the Java-based implementation that is used most often. I got in contact with someone who knows DFPWM much better than I do, and I worked with them to make a few adjustments that should improve the audio quality. I also made sure that the output matches the Java codec exactly, so it should have the exact same quality as other codecs. Signed-off-by: Jack Bruienne --- 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 | 129 ++ libavcodec/dfpwmenc.c | 123 libavcodec/utils.c| 2 + libavcodec/version.h | 2 +- 11 files changed, 270 insertions(+), 1 deletion(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 5ad2cef..5170a6a 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca* foo86 + dfpwm*Jack Bruienne dirac*Rostislav Pehlivanov dnxhd*Baptiste Coudurier dolby_e* foo86 diff --git a/doc/general_contents.texi b/doc/general_contents.texi index df1692c..14aeaed 100644 --- a/doc/general_contents.texi +++ b/doc/general_contents.texi @@ -1194,6 +1194,7 @@ following image formats are supported: @item CRI HCA@tab @tab X @item Delphine Software International CIN audio @tab @tab X @tab Codec used in Delphine Software International games. +@item DFPWM @tab X @tab X @item Digital Speech Standard - Standard Play mode (DSS SP) @tab @tab X @item Discworld II BMV Audio @tab @tab X @item COOK @tab @tab X diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 607
Re: [FFmpeg-devel] [PATCH v2 1/2] libavcodec: Added DFPWM1a codec
Sorry, I forgot to run make fate on the split patches, and I used the wrong capabilities for the decoder. I have attached a modified patch that removes AV_CODEC_CAP_VARIABLE_FRAME_SIZE from the decoder capabilities. Let me know if you'd like a full v3 patch email instead. On 2/25/22 18:43, Jack Bruienne wrote: 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. 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. It will streamline the process for importing 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 " 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 --- 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 | 129 ++ libavcodec/dfpwmenc.c | 123 libavcodec/utils.c | 2 + libavcodec/version.h | 2 +- 11 files changed, 270 insertions(+), 1 deletion(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 5ad2cef..5170a6a 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca* foo86 + dfpwm*Jack Bruienne dirac*Rostislav Pehlivanov dnxhd*Baptiste Coudurier dolby_e* foo86 diff --git a/doc/general_contents.texi b/doc/general_contents.texi index df1692c..14aeaed 100644 --- a/doc/general_contents.texi +++ b/doc/general_contents.texi @@ -1194,6 +1194,7 @@ following image formats are supported: @item CRI HCA@tab @tab X @item Delphine Software International CIN audio @tab @tab X @tab Codec used in Delphine Software International games. +@item DFPWM @tab X @tab X @item Digital Speech Standard - Standard Play mode (DSS SP) @tab @tab X @item Discworld II BMV Audio @tab @tab X @item COOK @tab @tab X diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 6076b4a..7474220 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -289,6 +289,8 @@ OBJS-$(CONFIG_DERF_DPCM_DECODER)
[FFmpeg-devel] [PATCH v2 2/2] libavformat: Add DFPWM raw format
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
---
Changelog | 2 +-
MAINTAINERS | 1 +
doc/general_contents.texi | 1 +
libavformat/Makefile | 2 +
libavformat/allformats.c | 2 +
libavformat/dfpwmdec.c| 107 ++
libavformat/rawenc.c | 13 +
libavformat/version.h | 4 +-
8 files changed, 129 insertions(+), 3 deletions(-)
create mode 100644 libavformat/dfpwmdec.c
diff --git a/Changelog b/Changelog
index 5170a6a..ec688da 100644
--- a/Changelog
+++ b/Changelog
@@ -4,7 +4,7 @@ releases are sorted from youngest to oldest.
version 5.1:
- dialogue enhance audio filter
- dropped obsolete XvMC hwaccel
-- DFPWM audio encoder/decoder
+- DFPWM audio encoder/decoder and raw muxer/demuxer
version 5.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 57b6f33..931cf4b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -416,6 +416,7 @@ Muxers/Demuxers:
dashdec.c Steven Liu
dashenc.c Karthick Jeyapal
daud.cReimar Doeffinger
+ dfpwmdec.cJack Bruienne
dss.c Oleksij Rempel
dtsdec.c foo86
dtshddec.cPaul B Mahol
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index 14aeaed..fcd9da1 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -578,6 +578,7 @@ library:
@item raw aptX @tab X @tab X
@item raw aptX HD @tab X @tab X
@item raw Chinese AVS video @tab X @tab X
+@item raw DFPWM @tab X @tab X
@item raw Dirac @tab X @tab X
@item raw DNxHD @tab X @tab X
@item raw DTS @tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 6566e40..b89073a 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -165,6 +165,8 @@ OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
OBJS-$(CONFIG_DCSTR_DEMUXER) += dcstr.o
OBJS-$(CONFIG_DERF_DEMUXER) += derf.o pcm.o
OBJS-$(CONFIG_DFA_DEMUXER) += dfa.o
+OBJS-$(CONFIG_DFPWM_DEMUXER) += dfpwmdec.o pcm.o
+OBJS-$(CONFIG_DFPWM_MUXER) += rawenc.o
OBJS-$(CONFIG_DHAV_DEMUXER) += dhav.o
OBJS-$(CONFIG_DIRAC_DEMUXER) += diracdec.o rawdec.o
OBJS-$(CONFIG_DIRAC_MUXER) += rawenc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d066a77..587ad59 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -124,6 +124,8 @@ extern const AVOutputFormat ff_daud_muxer;
extern const AVInputFormat ff_dcstr_demuxer;
extern const AVInputFormat ff_derf_demuxer;
extern const AVInputFormat ff_dfa_demuxer;
+extern const AVInputFormat ff_dfpwm_demuxer;
+extern const AVOutputFormat ff_dfpwm_muxer;
extern const AVInputFormat ff_dhav_demuxer;
extern const AVInputFormat ff_dirac_demuxer;
extern const AVOutputFormat ff_dirac_muxer;
diff --git a/libavformat/dfpwmdec.c b/libavformat/dfpwmdec.c
new file mode 100644
index 000..ad5bfa5
--- /dev/null
+++ b/libavformat/dfpwmdec.c
@@ -0,0 +1,107 @@
+/*
+ * RAW PCM demuxers
+ * Copyright (c) 2002 Fabrice Bellard
+ * Copyright (c) 2022 Jack Bruienne
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "avformat.h"
+#include "internal.h"
+#include "pcm.h"
+#include "libavutil/log.h"
+#include "libavutil/opt.h"
+#include "libavutil/avassert.h"
+
+typedef struct DFPWMAudioDemuxerContext {
+AVClass *class;
+int sample_rate;
+} DFPWMAudioDemuxerContext;
+
+static int dfpwm_read_header(AVFormatContext *s)
+{
+DFPWMAudioDemuxerContext *s1 = s->priv_data;
+
[FFmpeg-devel] [PATCH v2 1/2] libavcodec: Added DFPWM1a codec
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. 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. It will streamline the process for importing 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 " 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 --- 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 | 129 ++ libavcodec/dfpwmenc.c | 123 libavcodec/utils.c| 2 + libavcodec/version.h | 2 +- 11 files changed, 270 insertions(+), 1 deletion(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c diff --git a/Changelog b/Changelog index 5ad2cef..5170a6a 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..57b6f33 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca* foo86 + dfpwm*Jack Bruienne dirac*Rostislav Pehlivanov dnxhd*Baptiste Coudurier dolby_e* foo86 diff --git a/doc/general_contents.texi b/doc/general_contents.texi index df1692c..14aeaed 100644 --- a/doc/general_contents.texi +++ b/doc/general_contents.texi @@ -1194,6 +1194,7 @@ following image formats are supported: @item CRI HCA@tab @tab X @item Delphine Software International CIN audio @tab @tab X @tab Codec used in Delphine Software International games. +@item DFPWM @tab X @tab X @item Digital Speech Standard - Standard Play mode (DSS SP) @tab @tab X @item Discworld II BMV Audio @tab @tab X @item COOK @tab @tab X diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 6076b4a..7474220 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -289,6 +289,8 @@ OBJS-$(CONFIG_DERF_DPCM_DECODER) += dpcm.o OBJS-$(CONFIG_DIRAC_DECODER) += diracdec.o dirac.o diracdsp.o diractab.o \ dirac_arith.o dirac_dwt.o dirac_vlc.o OBJS-$(CONFIG_DFA_DECODER) += dfa.o +OBJS-$(CONFIG_DFPWM_DECODER) += dfpwmdec.o +OBJS-$(CONFIG_DFPWM_ENCODER)
Re: [FFmpeg-devel] [PATCH] libavcodec, libavformat: Added DFPWM1a codec and raw format
Thanks for looking over the patch. I used git format-patch to make the email and then sent it with Thunderbird; it appears that the command on the website doesn't put the patch in an attachment. I'll be adding --attach for future patches to fix this. I will be sending split updated patches fixing the issues you mentioned promptly. On 2/25/22 03:15, Paul B Mahol wrote: On Fri, Feb 25, 2022 at 02:54:35AM -0500, Jack Bruienne wrote: 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 both a new codec (with encoding and decoding), as well as 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 codec sources are pretty simple: they use the reference codec with a basic wrapper to connect it to the FFmpeg AVCodec system. There's a bit of extra code to convert from unsigned to signed 8-bit audio, as the codec implementation operates on signed data, which FFmpeg doesn't support. The muxers are mostly copied from the PCM demuxer and the raw muxers, as DFPWM is typically stored as raw data. 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. It will streamline the process for importing 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 " 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. One thing I noticed is that this sample file fails to decode to raw: https://samples.ffmpeg.org/ogg/virginradio-three-consecutive-chains.ogg It reports "Application provided invalid, non monotonically increasing dts to muxer in stream 0", which appears to be because the initial timestamp is not 0:00. This affects all raw muxers, including PCM. Signed-off-by: Jack Bruienne --- Changelog | 1 + MAINTAINERS | 2 + doc/general_contents.texi | 2 + libavcodec/Makefile | 2 + libavcodec/allcodecs.c| 2 + libavcodec/codec_desc.c | 7 ++ libavcodec/codec_id.h | 1 + libavcodec/dfpwmdec.c | 138 + libavcodec/dfpwmenc.c | 140 ++ libavcodec/utils.c| 2 + libavcodec/version.h | 2 +- libavformat/Makefile | 2 + libavformat/allformats.c | 2 + libavformat/dfpwmdec.c| 107 + libavformat/rawenc.c | 13 libavformat/version.h | 4 +- 16 files changed, 424 insertions(+), 3 deletions(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c create mode 100644 libavformat/dfpwmdec.c diff --git a/Changelog b/Changelog index 5ad2cef..ec688da 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder and raw muxer/demuxer Keep empty line here above and everywhere else you had removed them. Is patch corrupted somehow? Just attach file. And split demuxer and muxer addition from deco
[FFmpeg-devel] [PATCH] libavcodec, libavformat: Added DFPWM1a codec and raw format
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 both a new codec (with encoding and decoding), as well as 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 codec sources are pretty simple: they use the reference codec with a basic wrapper to connect it to the FFmpeg AVCodec system. There's a bit of extra code to convert from unsigned to signed 8-bit audio, as the codec implementation operates on signed data, which FFmpeg doesn't support. The muxers are mostly copied from the PCM demuxer and the raw muxers, as DFPWM is typically stored as raw data. 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. It will streamline the process for importing 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 " 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. One thing I noticed is that this sample file fails to decode to raw: https://samples.ffmpeg.org/ogg/virginradio-three-consecutive-chains.ogg It reports "Application provided invalid, non monotonically increasing dts to muxer in stream 0", which appears to be because the initial timestamp is not 0:00. This affects all raw muxers, including PCM. Signed-off-by: Jack Bruienne --- Changelog | 1 + MAINTAINERS | 2 + doc/general_contents.texi | 2 + libavcodec/Makefile | 2 + libavcodec/allcodecs.c| 2 + libavcodec/codec_desc.c | 7 ++ libavcodec/codec_id.h | 1 + libavcodec/dfpwmdec.c | 138 + libavcodec/dfpwmenc.c | 140 ++ libavcodec/utils.c| 2 + libavcodec/version.h | 2 +- libavformat/Makefile | 2 + libavformat/allformats.c | 2 + libavformat/dfpwmdec.c| 107 + libavformat/rawenc.c | 13 libavformat/version.h | 4 +- 16 files changed, 424 insertions(+), 3 deletions(-) create mode 100644 libavcodec/dfpwmdec.c create mode 100644 libavcodec/dfpwmenc.c create mode 100644 libavformat/dfpwmdec.c diff --git a/Changelog b/Changelog index 5ad2cef..ec688da 100644 --- a/Changelog +++ b/Changelog @@ -4,6 +4,7 @@ releases are sorted from youngest to oldest. version 5.1: - dialogue enhance audio filter - dropped obsolete XvMC hwaccel +- DFPWM audio encoder/decoder and raw muxer/demuxer version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index f33ccbd..931cf4b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -161,6 +161,7 @@ Codecs: cscd.cReimar Doeffinger cuviddec.cTimo Rothenpieler dca* foo86 + dfpwm* Jack Bruienne dirac*Rostislav Pehlivanov dnxhd*Baptiste Coudurier dolby_e* foo86 @@ -415,6 +416,7 @@ Muxers/Demuxers: dashdec.c
[FFmpeg-devel] Fix x264 SEI offset
Dear:
The libavcodec/libx264.c uses the wrong offset to obtain the SEI
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index f78365a4f7..9afaf19547 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -936,7 +936,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
for (i = 0; i < nnal; i++) {
/* Don't put the SEI in extradata. */
if (nal[i].i_type == NAL_SEI) {
-av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+24);
+av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+25);
x4->sei_size = nal[i].i_payload;
x4->sei = av_malloc(x4->sei_size);
if (!x4->sei)
fix_x264_SEI_offset.diff
Description: Binary data
___
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".
Re: [FFmpeg-devel] Fix x264 SEI offset
Oops
Sent wrong patch, Please use the following:
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 9afaf19547..f78365a4f7 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -936,7 +936,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
for (i = 0; i < nnal; i++) {
/* Don't put the SEI in extradata. */
if (nal[i].i_type == NAL_SEI) {
-av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+25);
+av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+24);
x4->sei_size = nal[i].i_payload;
x4->sei = av_malloc(x4->sei_size);
if (!x4->sei)
On Mon, Jul 26, 2021 at 8:09 PM Jack Waller wrote:
> Dear:
>
> The libavcodec/libx264.c uses the wrong offset to obtain the SEI
>
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index f78365a4f7..9afaf19547 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -936,7 +936,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
> for (i = 0; i < nnal; i++) {
> /* Don't put the SEI in extradata. */
> if (nal[i].i_type == NAL_SEI) {
> -av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+24);
> +av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload+25);
> x4->sei_size = nal[i].i_payload;
> x4->sei = av_malloc(x4->sei_size);
> if (!x4->sei)
>
fix_x264_SEI_offset_2.diff
Description: Binary data
___
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".
[FFmpeg-devel] Patch: aligin fix
Dear: In doc/example/resampling_audio.c /* buffer is going to be directly written to a rawaudio file, no alignment */ dst_nb_channels = av_get_channel_layout_nb_channels(dst_ch_layout); ret = av_samples_alloc_array_and_samples(_data, _linesize, dst_nb_channels, dst_nb_samples, dst_sample_fmt, 0); if the comment "no alignment" is right, we should change the last parameter of av_samples_alloc_array_and_samples() from 0 to 1. patch is attached. align_fix.diff Description: Binary data ___ 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".
Re: [FFmpeg-devel] [PATCH 48/48] fftools/ffmpeg: use av_packet_alloc() to allocate packets
On Sat, Mar 6, 2021 at 12:44 AM James Almer wrote:
> Signed-off-by: James Almer
> ---
> fftools/ffmpeg.c | 318 +++
> fftools/ffmpeg.h | 4 +
> fftools/ffmpeg_opt.c | 5 +-
> 3 files changed, 177 insertions(+), 150 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 2abbc0ff29..46bb014de8 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
>
> @@ -610,9 +611,9 @@ static void ffmpeg_cleanup(int ret)
>
> if (ost->muxing_queue) {
> while (av_fifo_size(ost->muxing_queue)) {
> -AVPacket pkt;
> +AVPacket *pkt;
> av_fifo_generic_read(ost->muxing_queue, ,
> sizeof(pkt), NULL);
>
Should you modify av_fifo_generic_read() for its second arguments( ) as
well?
___
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".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Hi Andreas, You're right - apologies. So in fact there was an exchange of one kind of undefined behaviour for another. Thanks Jack On Thu, Aug 6, 2020 at 1:52 PM Andreas Rheinhardt < andreas.rheinha...@gmail.com> wrote: > Jack Haughton: > > A NULL check in av_parse_video_rate() would certainly not be a bad idea. > It > > wouldn't (on its own) restore the NULL input robustness to > > set_string_video_rate() though, as any error value returned from > > av_parse_video_rate() would result in val being logged using %s, which is > > the whole problem that a500b975 was aiming to solve. > > > > av_parse_video_rate() is also called from a lot more places (most of > which > > already have an explicit NULL check immediately before the call), so > > changing the behaviour of that function by adding a NULL check > potentially > > has a lot more knock-on effects than simply restoring the previously > > existing robustness to set_string_video_rate(), which is also in keeping > > with the other av_parse_video_rate() callsites. > > > > You say that the caller 'should not' pass NULL to > set_string_video_rate(). > > Absolutely, agreed, but the point of checks is to handle unexpected > > situations. If someone does pass NULL, as of a500b975 the response will > be > > undefined behaviour, where previously it would have been cleanly handled > > with an explicit error code. I'd contend that this is a bad response. > > > You are contradicting yourself here: As the commit message of a500b975 > makes clear and as you explain in the first paragraph, a NULL value > would not have been handled cleanly before a500b975: Using NULL for %s > is undefined behaviour, too. Just wanted to mention it because you > repeat this point later in another mail: > > Jack Haughton: > > Isn't it better for that condition to be handled cleanly (as it was > > before a500b975) rather than causing undefined behaviour? > > - Andreas > ___ > 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". -- Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company Registered in England with registered office at St John's Innovation Centre, Cowley Road, Cambridge, CB4 0WS ___ 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".
[FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Commit a500b975 removed NULL input handling from this function,
moving the check higher up the call tree in one branch. However,
there is another call to set_string_video_rate() which may pass
NULL, and future users of the function may not be clear that
a NULL check is required. This patch restores the NULL check to
avoid these problems.
---
libavutil/opt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index c8413fa5e1..50bf769cbd 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -333,7 +333,10 @@ static int set_string_image_size(void *obj, const AVOption
*o, const char *val,
static int set_string_video_rate(void *obj, const AVOption *o, const char
*val, AVRational *dst)
{
-int ret = av_parse_video_rate(dst, val);
+int ret;
+
+av_assert0(val);
+ret = av_parse_video_rate(dst, val);
if (ret < 0)
av_log(obj, AV_LOG_ERROR, "Unable to parse option value \"%s\" as
video rate\n", val);
return ret;
--
2.17.1
___
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".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Fair enough, I agree an assert would be better - I'll send another patch. I was not intending to advocate for defensive programming - the patch was done this way in order to restore the previous behaviour. Although I agree with you that the outcome of passing NULL to strcmp is pretty much certainly a segmentation fault, the documentation marks it as undefined behaviour, which is, well, undefined - and therefore not to be relied upon IMO. Thanks Jack On Tue, Aug 4, 2020 at 2:58 PM Nicolas George wrote: > Jack Haughton (12020-08-04): > > Absolutely, he should fix his code. But let's say some code gets by code > > review that has a corner case whereby NULL can be passed. Isn't it better > > for that condition to be handled cleanly (as it was before a500b975) > rather > > than causing undefined behaviour? Then the error will be reported to the > > user with a clear error message and can be diagnosed and fixed quickly. > > Currently, what happens in this case will be implementation-dependent, > > making it much more difficult to diagnose. > > It depends on what kind of undefined behavior we are talking about. > Here, it is about dereferencing NULL, which always result in a > segmentation fault, and if we really want to make sure, we can force it > with an assert. > > What you are advocating is a typical example of what is called > "defensive programming". When there is some invariant that the code is > supposed to enforce (here: a pointer that should not be NULL), defensive > programming involves making provisions so that the programs continues > even if that invariant is broken. > > The thing is: defensive programming is almost always wrong. If an > invariant is broken, that means there is a bug. We do not know which > bug, but there is a bug. And since we do not know what it is, we have to > assume the worst is possible: exploitable security issue, silent data > corruption. > > And even if the worst does not happen, defensive programming makes > debugging harder: it hides the bugs, let the program seems to work, or > it delays the manifestation of the bug, and therefore requires more work > to track it. Also note that people will (irrationally) be in more hurry > to fix a crash than to fix an error message that looks clean. > > In this kind of cases, we have to ask ourselves a series of questions: > > 1. Is it convenient to let the caller pass NULL and have a sane result? >→ For free(), yes. >→ For av_parse_video_rate(), no, so we go to the next question. > > 2. Is it easy for the caller to check the validity of the parameter? >→ For == NULL, yes. > > Then the correct way of dealing with it is (1) document "the parameter > must not be NULL", (2) make sure it crashes early if the parameter is > NULL. > > Regards, > > -- > Nicolas George > ___ > 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". -- Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company Registered in England with registered office at St John's Innovation Centre, Cowley Road, Cambridge, CB4 0WS ___ 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".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Commit a500b975 removed NULL input handling from this function,
moving the check higher up the call tree in one branch. However,
there is another call to set_string_video_rate() which may pass
NULL, and future users of the function may not be clear that
a NULL check is required. This patch restores the NULL check to
avoid these problems.
---
libavutil/opt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index c8413fa5e1..bcb46451e0 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -333,7 +333,10 @@ static int set_string_image_size(void *obj, const
AVOption *o, const char *val,
static int set_string_video_rate(void *obj, const AVOption *o, const char
*val, AVRational *dst)
{
-int ret = av_parse_video_rate(dst, val);
+int ret;
+
+av_assert0(val);
+ret = av_parse_video_rate(dst, val);
if (ret < 0)
av_log(obj, AV_LOG_ERROR, "Unable to parse option value \"%s\" as
video rate\n", val);
return ret;
--
2.17.0.windows.1
On Wed, Aug 5, 2020 at 2:12 PM Jack Haughton
wrote:
> Fair enough, I agree an assert would be better - I'll send another patch.
>
> I was not intending to advocate for defensive programming - the patch was
> done this way in order to restore the previous behaviour. Although I agree
> with you that the outcome of passing NULL to strcmp is pretty much
> certainly a segmentation fault, the documentation marks it as undefined
> behaviour, which is, well, undefined - and therefore not to be relied upon
> IMO.
>
> Thanks
> Jack
>
> On Tue, Aug 4, 2020 at 2:58 PM Nicolas George wrote:
>
>> Jack Haughton (12020-08-04):
>> > Absolutely, he should fix his code. But let's say some code gets by code
>> > review that has a corner case whereby NULL can be passed. Isn't it
>> better
>> > for that condition to be handled cleanly (as it was before a500b975)
>> rather
>> > than causing undefined behaviour? Then the error will be reported to the
>> > user with a clear error message and can be diagnosed and fixed quickly.
>> > Currently, what happens in this case will be implementation-dependent,
>> > making it much more difficult to diagnose.
>>
>> It depends on what kind of undefined behavior we are talking about.
>> Here, it is about dereferencing NULL, which always result in a
>> segmentation fault, and if we really want to make sure, we can force it
>> with an assert.
>>
>> What you are advocating is a typical example of what is called
>> "defensive programming". When there is some invariant that the code is
>> supposed to enforce (here: a pointer that should not be NULL), defensive
>> programming involves making provisions so that the programs continues
>> even if that invariant is broken.
>>
>> The thing is: defensive programming is almost always wrong. If an
>> invariant is broken, that means there is a bug. We do not know which
>> bug, but there is a bug. And since we do not know what it is, we have to
>> assume the worst is possible: exploitable security issue, silent data
>> corruption.
>>
>> And even if the worst does not happen, defensive programming makes
>> debugging harder: it hides the bugs, let the program seems to work, or
>> it delays the manifestation of the bug, and therefore requires more work
>> to track it. Also note that people will (irrationally) be in more hurry
>> to fix a crash than to fix an error message that looks clean.
>>
>> In this kind of cases, we have to ask ourselves a series of questions:
>>
>> 1. Is it convenient to let the caller pass NULL and have a sane result?
>>→ For free(), yes.
>>→ For av_parse_video_rate(), no, so we go to the next question.
>>
>> 2. Is it easy for the caller to check the validity of the parameter?
>>→ For == NULL, yes.
>>
>> Then the correct way of dealing with it is (1) document "the parameter
>> must not be NULL", (2) make sure it crashes early if the parameter is
>> NULL.
>>
>> Regards,
>>
>> --
>> Nicolas George
>> ___
>> 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".
>
>
>
> --
>
> Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company
>
> Registered in England with registered office at St John's Innovation
> Centre, Cowley Road, Cambridge, CB4 0WS
>
--
Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company
Registered in England with registered office at St John's Innovation
Centre, Cowley Road, Cambridge, CB4 0WS
___
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".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
I think we're talking past each other. You're asking me to demonstrate a current way in which NULL might be passed to this function. I don't think it's necessary to do that in order for this patch to be a good idea. > Is this about something iam missing or a lib user passing invalidly > setup AVOptions ? (he should fix his code) Absolutely, he should fix his code. But let's say some code gets by code review that has a corner case whereby NULL can be passed. Isn't it better for that condition to be handled cleanly (as it was before a500b975) rather than causing undefined behaviour? Then the error will be reported to the user with a clear error message and can be diagnosed and fixed quickly. Currently, what happens in this case will be implementation-dependent, making it much more difficult to diagnose. To be clear, I do not have a specific case in mind that will currently pass NULL to this function. The point of this patch is to stop relying on all current and future callers to this function always being completely bug-free, but instead to handle any error condition properly, as it is at most of the other av_parse_video_rate callsites. Could you explain why you would not want to do that? Thanks Jack On Mon, Aug 3, 2020 at 11:27 PM Michael Niedermayer wrote: > On Mon, Aug 03, 2020 at 02:07:36PM +0100, Jack Haughton wrote: > > A NULL check in av_parse_video_rate() would certainly not be a bad idea. > It > > wouldn't (on its own) restore the NULL input robustness to > > set_string_video_rate() though, as any error value returned from > > av_parse_video_rate() would result in val being logged using %s, which is > > the whole problem that a500b975 was aiming to solve. > > > > av_parse_video_rate() is also called from a lot more places (most of > which > > already have an explicit NULL check immediately before the call), so > > changing the behaviour of that function by adding a NULL check > potentially > > has a lot more knock-on effects than simply restoring the previously > > existing robustness to set_string_video_rate(), which is also in keeping > > with the other av_parse_video_rate() callsites. > > > > You say that the caller 'should not' pass NULL to > set_string_video_rate(). > > Absolutely, agreed, but the point of checks is to handle unexpected > > situations. > > > If someone does pass NULL, as of a500b975 the response will be > > who is passing NULL in which way ? > this is not a public function > > You can achieve such a NULL input by seting up an invalid AVOption > but you dont seem to speak about that. > > please explain what sort of robustness you want to achieve here > Is this about something iam missing or a lib user passing invalidly > setup AVOptions ? (he should fix his code) or some FFmpeg internal > robustness or what else ? > > > > undefined behaviour, where previously it would have been cleanly handled > > with an explicit error code. I'd contend that this is a bad response. > > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If a bugfix only changes things apparently unrelated to the bug with no > further explanation, that is a good sign that the bugfix is wrong. > ___ > 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". -- Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company Registered in England with registered office at St John's Innovation Centre, Cowley Road, Cambridge, CB4 0WS ___ 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".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
A NULL check in av_parse_video_rate() would certainly not be a bad idea. It wouldn't (on its own) restore the NULL input robustness to set_string_video_rate() though, as any error value returned from av_parse_video_rate() would result in val being logged using %s, which is the whole problem that a500b975 was aiming to solve. av_parse_video_rate() is also called from a lot more places (most of which already have an explicit NULL check immediately before the call), so changing the behaviour of that function by adding a NULL check potentially has a lot more knock-on effects than simply restoring the previously existing robustness to set_string_video_rate(), which is also in keeping with the other av_parse_video_rate() callsites. You say that the caller 'should not' pass NULL to set_string_video_rate(). Absolutely, agreed, but the point of checks is to handle unexpected situations. If someone does pass NULL, as of a500b975 the response will be undefined behaviour, where previously it would have been cleanly handled with an explicit error code. I'd contend that this is a bad response. Thanks Jack On Sun, Aug 2, 2020 at 11:28 PM Michael Niedermayer wrote: > On Sun, Aug 02, 2020 at 08:40:27PM +0100, Jack Haughton wrote: > > Hello, > > > > Apologies for the delay in replying. This patch is not to address a > > specific problem that currently exists, but rather to restore the > > robustness to invalid input that previously existed in this function. The > > motivation for the patch is that we would like to merge a500b975 into our > > local tree to gain support for gcc 10, but there are concerns about the > > removal of the null check. av_parse_video_rate() passes its argument > > directly to strcmp, which would cause undefined behaviour if the argument > > was NULL. > > now it makes it even less sense to me. > av_parse_video_rate() doesnt support a NULL argument before or after your > patch, its undefined behaviour either way. > what you change is a private function using that public function. > > Now if you changed the public function to do something specific with a NULL > argument then that would be more robust maybe but not when its done to a > single caller which should not pass NULL there > > thx > > > > > > > Thanks, > > Jack > > > > On Fri, Jul 31, 2020 at 8:31 PM Michael Niedermayer > > > wrote: > > > > > Hi > > > > > > On Fri, Jul 31, 2020 at 03:53:56PM +0100, Jack Haughton wrote: > > > > Commit a500b975 removed NULL input handling from this function, > > > > moving the check higher up the call tree in one branch. However, > > > > there is another call to set_string_video_rate() which may pass > > > > NULL, and future users of the function may not be clear that > > > > a NULL check is required. This patch restores the NULL check to > > > > avoid these problems. > > > > > > Does this affect something else than the seting based on defaults ? > > > because the defaults should probably be valid values > > > or if you disagree, iam curious where the default would be > intentionally > > > invalid > > > > > > thx > > > > > > [...] > > > -- > > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > > > Breaking DRM is a little like attempting to break through a door even > > > though the window is wide open and the only thing in the house is a > bunch > > > of things you dont want and which you would get tomorrow for free > anyway > > > > > > > > > -- > > > > Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company > > > > Registered in England with registered office at St John's Innovation > > Centre, Cowley Road, Cambridge, CB4 0WS > > ___ > > 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". > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > It is what and why we do it that matters, not just one of them. > ___ > 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". -- Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company Registered in England with registered office at St John's Innovation Centre, Cowley Road, Cambridge, CB4 0WS ___ 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".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Hello, Apologies for the delay in replying. This patch is not to address a specific problem that currently exists, but rather to restore the robustness to invalid input that previously existed in this function. The motivation for the patch is that we would like to merge a500b975 into our local tree to gain support for gcc 10, but there are concerns about the removal of the null check. av_parse_video_rate() passes its argument directly to strcmp, which would cause undefined behaviour if the argument was NULL. Thanks, Jack On Fri, Jul 31, 2020 at 8:31 PM Michael Niedermayer wrote: > Hi > > On Fri, Jul 31, 2020 at 03:53:56PM +0100, Jack Haughton wrote: > > Commit a500b975 removed NULL input handling from this function, > > moving the check higher up the call tree in one branch. However, > > there is another call to set_string_video_rate() which may pass > > NULL, and future users of the function may not be clear that > > a NULL check is required. This patch restores the NULL check to > > avoid these problems. > > Does this affect something else than the seting based on defaults ? > because the defaults should probably be valid values > or if you disagree, iam curious where the default would be intentionally > invalid > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Breaking DRM is a little like attempting to break through a door even > though the window is wide open and the only thing in the house is a bunch > of things you dont want and which you would get tomorrow for free anyway > -- Argon Design Ltd., Registration No. 06977690, a Broadcom Inc. company Registered in England with registered office at St John's Innovation Centre, Cowley Road, Cambridge, CB4 0WS ___ 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".
[FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Commit a500b975 removed NULL input handling from this function,
moving the check higher up the call tree in one branch. However,
there is another call to set_string_video_rate() which may pass
NULL, and future users of the function may not be clear that
a NULL check is required. This patch restores the NULL check to
avoid these problems.
---
libavutil/opt.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index c8413fa5e1..9f36dc89a9 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -333,7 +333,13 @@ static int set_string_image_size(void *obj, const AVOption
*o, const char *val,
static int set_string_video_rate(void *obj, const AVOption *o, const char
*val, AVRational *dst)
{
-int ret = av_parse_video_rate(dst, val);
+int ret;
+
+if (!val) {
+av_log(obj, AV_LOG_ERROR, "NULL passed as video rate\n");
+return AVERROR(EINVAL);
+}
+ret = av_parse_video_rate(dst, val);
if (ret < 0)
av_log(obj, AV_LOG_ERROR, "Unable to parse option value \"%s\" as
video rate\n", val);
return ret;
--
2.17.1
___
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".
Re: [FFmpeg-devel] [PATCH] avformat/libsrt: Change latency option to milliseconds
On Wed, Apr 8, 2020 at 3:34 PM pkv wrote: > > Le 08/04/2020 à 3:45 am, Limin Wang a écrit : > > On Wed, Apr 08, 2020 at 02:16:23AM +0200, pkv wrote: > >> Hi > >> > >> Le 08/04/2020 à 12:33 am, Limin Wang a écrit : > >>> On Tue, Apr 07, 2020 at 08:25:44PM +0200, pkv wrote: > Hi > > new patch for latency option following the comments from N. George. > >>> I recall I had submit a patchset for related option incliding latency. > >>> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200331140808.8839-2-lance.lmw...@gmail.com/ > >> hadn't spotted it; why was it not merged ? > >> > >> > >>> Why I haven't change to use AV_OPT_TYPE_DURATION, for the latency can > >>> be used in format srt://:port?latency=?, it's in unit of ms, > >>> in addition, AV_OPT_TYPE_DURATION is in unit of second default, it'll > >>> break the old user. > >> i tested with ffmpeg.exe; the change to > >> > >> AV_OPT_TYPE_DURATION > >> > >> didn't seem to break anything. > >> > >> The default is still set to whatever the libsrt API has set (120 ms > >> for transtype=live). > >> > >> Can you produce code broken by that change ? > > What's your command line? > > I recall If use AV_OPT_TYPE_DURATION for option, the default is in unit > of second if your > > don't add suffix of ms, us. However the old is us, so it'll cause old > user > > setting broken. > > > Ok I get your point. > > here are the commands I tested with: > > ffmpeg.exe -re -i source.mp4 -c copy -f mpegts srt:://dest:port > > and > > ffmpeg.exe -re -i source.mp4 -c copy -f mpegts > srt:://dest:port?latency=40 > > These two don't break anything. > > But indeed > > ffmpeg.exe -re -i source.mp4 -c copy -latency=40 -f mpegts > srt:://dest:port > > is breaking stuff. > > I'll revert the change suggested by N. George in that case. > DO NOT CHANGE, Microsecond is better than millisecond. it's compatible with other ffmpeg options The fault is srt's implementation, not ffmpeg's ___ 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".
Re: [FFmpeg-devel] [PATCH v2] libavformat: Add ZeroMQ as a protocol option
On Wed, Aug 7, 2019 at 10:22 AM Andriy Gelman wrote: > On Sun, 04. Aug 14:36, Andriy Gelman wrote: > > Changes in v2: > > 1. Replaced zmq_poll with zmq_msg_recv. > > 2. Remove user timeout option as zmq_msg_recv(.., .., ZMQ_DONTWAIT) is > a > > non-blocking call. > > 3. Updated docs. > > > > Andriy > > > diff --git a/libavformat/Makefile b/libavformat/Makefile > > index a434b005a4..4a535429b7 100644 > > --- a/libavformat/Makefile > > +++ b/libavformat/Makefile > > @@ -631,6 +631,7 @@ OBJS-$(CONFIG_LIBRTMPTE_PROTOCOL)+= librtmp.o > > OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o > > OBJS-$(CONFIG_LIBSRT_PROTOCOL) += libsrt.o > > OBJS-$(CONFIG_LIBSSH_PROTOCOL) += libssh.o > > +OBJS-$(CONFIG_LIBZMQ_PROTOCOL) > += libzmq.o > > > There is a TAB here, Please remove it > > # libavdevice dependencies > > OBJS-$(CONFIG_IEC61883_INDEV)+= dv.o > > > ___ 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".
[FFmpeg-devel] [PATCH] Push hls_ts_options to every chunks (fix #5525)
Signed-off-by: jack <ffm...@jack.fr.eu.org>
---
libavformat/hlsenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index a9fa5d8..77712d0 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -624,6 +624,11 @@ static int hls_start(AVFormatContext *s)
err = avformat_write_header(vtt_oc,NULL);
if (err < 0)
return err;
+} else {
+HLSContext *hls = s->priv_data;
+av_dict_copy(, hls->format_options, 0);
+avformat_write_header(hls->avf, );
+av_dict_free();
}
return 0;
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
