* [FFmpeg-devel] [PATCH 1/2] MAINTAINERS: remove inactive developer @ 2024-02-28 12:56 J. Dekker 2024-02-28 12:56 ` [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio J. Dekker 2024-02-28 14:38 ` [FFmpeg-devel] [PATCH 1/2] MAINTAINERS: remove inactive developer Vittorio Giovara 0 siblings, 2 replies; 26+ messages in thread From: J. Dekker @ 2024-02-28 12:56 UTC (permalink / raw) To: ffmpeg-devel Inactive since 2007. Signed-off-by: J. Dekker <jdek@itanimul.li> --- MAINTAINERS | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index cc7f564f48..ace58f02a1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -148,7 +148,6 @@ Codecs: cinepak.c Roberto Togni cinepakenc.c Rl / Aetey G.T. AB ccaption_dec.c Anshul Maheshwari, Aman Gupta - cljr Alex Beregszaszi cpia.c Stephan Hilb cscd.c Reimar Doeffinger cuviddec.c Timo Rothenpieler @@ -230,13 +229,12 @@ Codecs: rv10.c Michael Niedermayer smc.c Mike Melanson snow* Michael Niedermayer, Loren Merritt - sonic.c Alex Beregszaszi speedhq.c Steinar H. Gunderson srt* Aurelien Jacobs sunrast.c Ivo van Poorten svq3.c Michael Niedermayer truemotion1* Mike Melanson - tta.c Alex Beregszaszi, Jaikrishnan Menon + tta.c Jaikrishnan Menon txd.c Ivo van Poorten v4l2_* Jorge Ramirez-Ortiz vc2* Rostislav Pehlivanov @@ -446,7 +444,6 @@ Muxers/Demuxers: spdif* Anssi Hannula srtdec.c Aurelien Jacobs swf.c Baptiste Coudurier - tta.c Alex Beregszaszi txd.c Ivo van Poorten voc.c Aurelien Jacobs wav.c Michael Niedermayer @@ -493,7 +490,7 @@ Mac OS X / PowerPC Romain Dolbeau, Guillaume Poirier Amiga / PowerPC Colin Ward Linux / PowerPC Lauri Kasanen RISC-V Rémi Denis-Courmont -Windows MinGW Alex Beregszaszi, Ramiro Polla +Windows MinGW Ramiro Polla Windows Cygwin Victor Paesa Windows MSVC Hendrik Leppkes ADI/Blackfin DSP Marc Hoffman -- 2.43.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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 12:56 [FFmpeg-devel] [PATCH 1/2] MAINTAINERS: remove inactive developer J. Dekker @ 2024-02-28 12:56 ` J. Dekker 2024-02-28 13:23 ` Andreas Rheinhardt ` (2 more replies) 2024-02-28 14:38 ` [FFmpeg-devel] [PATCH 1/2] MAINTAINERS: remove inactive developer Vittorio Giovara 1 sibling, 3 replies; 26+ messages in thread From: J. Dekker @ 2024-02-28 12:56 UTC (permalink / raw) To: ffmpeg-devel This was an experimental/research codec of which ffmpeg is the only encoder and decoder, development has stalled and these files don't exist in the wild. Signed-off-by: J. Dekker <jdek@itanimul.li> --- Changelog | 1 + configure | 3 - libavcodec/Makefile | 3 - libavcodec/allcodecs.c | 3 - libavcodec/codec_desc.c | 14 - libavcodec/sonic.c | 1125 --------------------------------------- 6 files changed, 1 insertion(+), 1148 deletions(-) delete mode 100644 libavcodec/sonic.c diff --git a/Changelog b/Changelog index 610ee61dd6..e2096f249a 100644 --- a/Changelog +++ b/Changelog @@ -27,6 +27,7 @@ version <next>: - a C11-compliant compiler is now required; note that this requirement will be bumped to C17 in the near future, so consider updating your build environment if it lacks C17 support +- sonic lossy/lossless audio codec removed version 6.1: - libaribcaption decoder diff --git a/configure b/configure index bb5e630bad..e639a5e2b7 100755 --- a/configure +++ b/configure @@ -2991,9 +2991,6 @@ sipr_decoder_select="lsp" smvjpeg_decoder_select="mjpeg_decoder" snow_decoder_select="dwt h264qpel rangecoder videodsp" snow_encoder_select="dwt h264qpel hpeldsp me_cmp mpegvideoenc rangecoder videodsp" -sonic_decoder_select="golomb rangecoder" -sonic_encoder_select="golomb rangecoder" -sonic_ls_encoder_select="golomb rangecoder" sp5x_decoder_select="mjpeg_decoder" speedhq_decoder_select="blockdsp idctdsp" speedhq_encoder_select="mpegvideoenc" diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 09ae5270b3..3fc716ee68 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -687,9 +687,6 @@ OBJS-$(CONFIG_SNOW_DECODER) += snowdec.o snow.o snow_dwt.o OBJS-$(CONFIG_SNOW_ENCODER) += snowenc.o snow.o snow_dwt.o \ h263.o h263data.o ituh263enc.o OBJS-$(CONFIG_SOL_DPCM_DECODER) += dpcm.o -OBJS-$(CONFIG_SONIC_DECODER) += sonic.o -OBJS-$(CONFIG_SONIC_ENCODER) += sonic.o -OBJS-$(CONFIG_SONIC_LS_ENCODER) += sonic.o OBJS-$(CONFIG_SPEEDHQ_DECODER) += speedhqdec.o speedhq.o mpeg12.o \ mpeg12data.o OBJS-$(CONFIG_SPEEDHQ_ENCODER) += speedhq.o mpeg12data.o mpeg12enc.o speedhqenc.o diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index ef8c3a6d7d..e0a4a5421d 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -535,9 +535,6 @@ extern const FFCodec ff_shorten_decoder; extern const FFCodec ff_sipr_decoder; extern const FFCodec ff_siren_decoder; extern const FFCodec ff_smackaud_decoder; -extern const FFCodec ff_sonic_encoder; -extern const FFCodec ff_sonic_decoder; -extern const FFCodec ff_sonic_ls_encoder; extern const FFCodec ff_tak_decoder; extern const FFCodec ff_truehd_encoder; extern const FFCodec ff_truehd_decoder; diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c index 033344304c..9b456616be 100644 --- a/libavcodec/codec_desc.c +++ b/libavcodec/codec_desc.c @@ -3175,20 +3175,6 @@ static const AVCodecDescriptor codec_descriptors[] = { .long_name = NULL_IF_CONFIG_SMALL("Wave synthesis pseudo-codec"), .props = AV_CODEC_PROP_INTRA_ONLY, }, - { - .id = AV_CODEC_ID_SONIC, - .type = AVMEDIA_TYPE_AUDIO, - .name = "sonic", - .long_name = NULL_IF_CONFIG_SMALL("Sonic"), - .props = AV_CODEC_PROP_INTRA_ONLY, - }, - { - .id = AV_CODEC_ID_SONIC_LS, - .type = AVMEDIA_TYPE_AUDIO, - .name = "sonicls", - .long_name = NULL_IF_CONFIG_SMALL("Sonic lossless"), - .props = AV_CODEC_PROP_INTRA_ONLY, - }, { .id = AV_CODEC_ID_EVRC, .type = AVMEDIA_TYPE_AUDIO, diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c deleted file mode 100644 index 0544fecf46..0000000000 --- a/libavcodec/sonic.c +++ /dev/null @@ -1,1125 +0,0 @@ -/* - * Simple free lossless/lossy audio codec - * Copyright (c) 2004 Alex Beregszaszi - * - * 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 "config_components.h" - -#include "avcodec.h" -#include "codec_internal.h" -#include "decode.h" -#include "encode.h" -#include "get_bits.h" -#include "golomb.h" -#include "put_golomb.h" -#include "rangecoder.h" - - -/** - * @file - * Simple free lossless/lossy audio codec - * Based on Paul Francis Harrison's Bonk (http://www.logarithmic.net/pfh/bonk) - * Written and designed by Alex Beregszaszi - * - * TODO: - * - CABAC put/get_symbol - * - independent quantizer for channels - * - >2 channels support - * - more decorrelation types - * - more tap_quant tests - * - selectable intlist writers/readers (bonk-style, golomb, cabac) - */ - -#define MAX_CHANNELS 2 - -#define MID_SIDE 0 -#define LEFT_SIDE 1 -#define RIGHT_SIDE 2 - -typedef struct SonicContext { - int version; - int minor_version; - int lossless, decorrelation; - - int num_taps, downsampling; - double quantization; - - int channels, samplerate, block_align, frame_size; - - int *tap_quant; - int *int_samples; - int *coded_samples[MAX_CHANNELS]; - - // for encoding - int *tail; - int tail_size; - int *window; - int window_size; - - // for decoding - int *predictor_k; - int *predictor_state[MAX_CHANNELS]; -} SonicContext; - -#define LATTICE_SHIFT 10 -#define SAMPLE_SHIFT 4 -#define LATTICE_FACTOR (1 << LATTICE_SHIFT) -#define SAMPLE_FACTOR (1 << SAMPLE_SHIFT) - -#define BASE_QUANT 0.6 -#define RATE_VARIATION 3.0 - -static inline int shift(int a,int b) -{ - return (a+(1<<(b-1))) >> b; -} - -static inline int shift_down(int a,int b) -{ - return (a>>b)+(a<0); -} - -static av_always_inline av_flatten void put_symbol(RangeCoder *c, uint8_t *state, int v, int is_signed, uint64_t rc_stat[256][2], uint64_t rc_stat2[32][2]){ - int i; - -#define put_rac(C,S,B) \ -do{\ - if(rc_stat){\ - rc_stat[*(S)][B]++;\ - rc_stat2[(S)-state][B]++;\ - }\ - put_rac(C,S,B);\ -}while(0) - - if(v){ - const int a= FFABS(v); - const int e= av_log2(a); - put_rac(c, state+0, 0); - if(e<=9){ - for(i=0; i<e; i++){ - put_rac(c, state+1+i, 1); //1..10 - } - put_rac(c, state+1+i, 0); - - for(i=e-1; i>=0; i--){ - put_rac(c, state+22+i, (a>>i)&1); //22..31 - } - - if(is_signed) - put_rac(c, state+11 + e, v < 0); //11..21 - }else{ - for(i=0; i<e; i++){ - put_rac(c, state+1+FFMIN(i,9), 1); //1..10 - } - put_rac(c, state+1+9, 0); - - for(i=e-1; i>=0; i--){ - put_rac(c, state+22+FFMIN(i,9), (a>>i)&1); //22..31 - } - - if(is_signed) - put_rac(c, state+11 + 10, v < 0); //11..21 - } - }else{ - put_rac(c, state+0, 1); - } -#undef put_rac -} - -static inline av_flatten int get_symbol(RangeCoder *c, uint8_t *state, int is_signed){ - if(get_rac(c, state+0)) - return 0; - else{ - int i, e; - unsigned a; - e= 0; - while(get_rac(c, state+1 + FFMIN(e,9))){ //1..10 - e++; - if (e > 31) - return AVERROR_INVALIDDATA; - } - - a= 1; - for(i=e-1; i>=0; i--){ - a += a + get_rac(c, state+22 + FFMIN(i,9)); //22..31 - } - - e= -(is_signed && get_rac(c, state+11 + FFMIN(e, 10))); //11..21 - return (a^e)-e; - } -} - -#if 1 -static inline int intlist_write(RangeCoder *c, uint8_t *state, int *buf, int entries, int base_2_part) -{ - int i; - - for (i = 0; i < entries; i++) - put_symbol(c, state, buf[i], 1, NULL, NULL); - - return 1; -} - -static inline int intlist_read(RangeCoder *c, uint8_t *state, int *buf, int entries, int base_2_part) -{ - int i; - - for (i = 0; i < entries; i++) - buf[i] = get_symbol(c, state, 1); - - return 1; -} -#elif 1 -static inline int intlist_write(PutBitContext *pb, int *buf, int entries, int base_2_part) -{ - int i; - - for (i = 0; i < entries; i++) - set_se_golomb(pb, buf[i]); - - return 1; -} - -static inline int intlist_read(GetBitContext *gb, int *buf, int entries, int base_2_part) -{ - int i; - - for (i = 0; i < entries; i++) - buf[i] = get_se_golomb(gb); - - return 1; -} - -#else - -#define ADAPT_LEVEL 8 - -static int bits_to_store(uint64_t x) -{ - int res = 0; - - while(x) - { - res++; - x >>= 1; - } - return res; -} - -static void write_uint_max(PutBitContext *pb, unsigned int value, unsigned int max) -{ - int i, bits; - - if (!max) - return; - - bits = bits_to_store(max); - - for (i = 0; i < bits-1; i++) - put_bits(pb, 1, value & (1 << i)); - - if ( (value | (1 << (bits-1))) <= max) - put_bits(pb, 1, value & (1 << (bits-1))); -} - -static unsigned int read_uint_max(GetBitContext *gb, int max) -{ - int i, bits, value = 0; - - if (!max) - return 0; - - bits = bits_to_store(max); - - for (i = 0; i < bits-1; i++) - if (get_bits1(gb)) - value += 1 << i; - - if ( (value | (1<<(bits-1))) <= max) - if (get_bits1(gb)) - value += 1 << (bits-1); - - return value; -} - -static int intlist_write(PutBitContext *pb, int *buf, int entries, int base_2_part) -{ - int i, j, x = 0, low_bits = 0, max = 0; - int step = 256, pos = 0, dominant = 0, any = 0; - int *copy, *bits; - - copy = av_calloc(entries, sizeof(*copy)); - if (!copy) - return AVERROR(ENOMEM); - - if (base_2_part) - { - int energy = 0; - - for (i = 0; i < entries; i++) - energy += abs(buf[i]); - - low_bits = bits_to_store(energy / (entries * 2)); - if (low_bits > 15) - low_bits = 15; - - put_bits(pb, 4, low_bits); - } - - for (i = 0; i < entries; i++) - { - put_bits(pb, low_bits, abs(buf[i])); - copy[i] = abs(buf[i]) >> low_bits; - if (copy[i] > max) - max = abs(copy[i]); - } - - bits = av_calloc(entries*max, sizeof(*bits)); - if (!bits) - { - av_free(copy); - return AVERROR(ENOMEM); - } - - for (i = 0; i <= max; i++) - { - for (j = 0; j < entries; j++) - if (copy[j] >= i) - bits[x++] = copy[j] > i; - } - - // store bitstream - while (pos < x) - { - int steplet = step >> 8; - - if (pos + steplet > x) - steplet = x - pos; - - for (i = 0; i < steplet; i++) - if (bits[i+pos] != dominant) - any = 1; - - put_bits(pb, 1, any); - - if (!any) - { - pos += steplet; - step += step / ADAPT_LEVEL; - } - else - { - int interloper = 0; - - while (((pos + interloper) < x) && (bits[pos + interloper] == dominant)) - interloper++; - - // note change - write_uint_max(pb, interloper, (step >> 8) - 1); - - pos += interloper + 1; - step -= step / ADAPT_LEVEL; - } - - if (step < 256) - { - step = 65536 / step; - dominant = !dominant; - } - } - - // store signs - for (i = 0; i < entries; i++) - if (buf[i]) - put_bits(pb, 1, buf[i] < 0); - - av_free(bits); - av_free(copy); - - return 0; -} - -static int intlist_read(GetBitContext *gb, int *buf, int entries, int base_2_part) -{ - int i, low_bits = 0, x = 0; - int n_zeros = 0, step = 256, dominant = 0; - int pos = 0, level = 0; - int *bits = av_calloc(entries, sizeof(*bits)); - - if (!bits) - return AVERROR(ENOMEM); - - if (base_2_part) - { - low_bits = get_bits(gb, 4); - - if (low_bits) - for (i = 0; i < entries; i++) - buf[i] = get_bits(gb, low_bits); - } - -// av_log(NULL, AV_LOG_INFO, "entries: %d, low bits: %d\n", entries, low_bits); - - while (n_zeros < entries) - { - int steplet = step >> 8; - - if (!get_bits1(gb)) - { - for (i = 0; i < steplet; i++) - bits[x++] = dominant; - - if (!dominant) - n_zeros += steplet; - - step += step / ADAPT_LEVEL; - } - else - { - int actual_run = read_uint_max(gb, steplet-1); - -// av_log(NULL, AV_LOG_INFO, "actual run: %d\n", actual_run); - - for (i = 0; i < actual_run; i++) - bits[x++] = dominant; - - bits[x++] = !dominant; - - if (!dominant) - n_zeros += actual_run; - else - n_zeros++; - - step -= step / ADAPT_LEVEL; - } - - if (step < 256) - { - step = 65536 / step; - dominant = !dominant; - } - } - - // reconstruct unsigned values - n_zeros = 0; - for (i = 0; n_zeros < entries; i++) - { - while(1) - { - if (pos >= entries) - { - pos = 0; - level += 1 << low_bits; - } - - if (buf[pos] >= level) - break; - - pos++; - } - - if (bits[i]) - buf[pos] += 1 << low_bits; - else - n_zeros++; - - pos++; - } - av_free(bits); - - // read signs - for (i = 0; i < entries; i++) - if (buf[i] && get_bits1(gb)) - buf[i] = -buf[i]; - -// av_log(NULL, AV_LOG_INFO, "zeros: %d pos: %d\n", n_zeros, pos); - - return 0; -} -#endif - -static void predictor_init_state(int *k, int *state, int order) -{ - int i; - - for (i = order-2; i >= 0; i--) - { - int j, p, x = state[i]; - - for (j = 0, p = i+1; p < order; j++,p++) - { - int tmp = x + shift_down(k[j] * (unsigned)state[p], LATTICE_SHIFT); - state[p] += shift_down(k[j]* (unsigned)x, LATTICE_SHIFT); - x = tmp; - } - } -} - -static int predictor_calc_error(int *k, int *state, int order, int error) -{ - int i, x = error - (unsigned)shift_down(k[order-1] * (unsigned)state[order-1], LATTICE_SHIFT); - -#if 1 - int *k_ptr = &(k[order-2]), - *state_ptr = &(state[order-2]); - for (i = order-2; i >= 0; i--, k_ptr--, state_ptr--) - { - int k_value = *k_ptr, state_value = *state_ptr; - x -= (unsigned)shift_down(k_value * (unsigned)state_value, LATTICE_SHIFT); - state_ptr[1] = state_value + shift_down(k_value * (unsigned)x, LATTICE_SHIFT); - } -#else - for (i = order-2; i >= 0; i--) - { - x -= (unsigned)shift_down(k[i] * state[i], LATTICE_SHIFT); - state[i+1] = state[i] + shift_down(k[i] * x, LATTICE_SHIFT); - } -#endif - - // don't drift too far, to avoid overflows - if (x > (SAMPLE_FACTOR<<16)) x = (SAMPLE_FACTOR<<16); - if (x < -(SAMPLE_FACTOR<<16)) x = -(SAMPLE_FACTOR<<16); - - state[0] = x; - - return x; -} - -#if CONFIG_SONIC_ENCODER || CONFIG_SONIC_LS_ENCODER -// Heavily modified Levinson-Durbin algorithm which -// copes better with quantization, and calculates the -// actual whitened result as it goes. - -static void modified_levinson_durbin(int *window, int window_entries, - int *out, int out_entries, int channels, int *tap_quant) -{ - int i; - int *state = window + window_entries; - - memcpy(state, window, window_entries * sizeof(*state)); - - for (i = 0; i < out_entries; i++) - { - int step = (i+1)*channels, k, j; - double xx = 0.0, xy = 0.0; -#if 1 - int *x_ptr = &(window[step]); - int *state_ptr = &(state[0]); - j = window_entries - step; - for (;j>0;j--,x_ptr++,state_ptr++) - { - double x_value = *x_ptr; - double state_value = *state_ptr; - xx += state_value*state_value; - xy += x_value*state_value; - } -#else - for (j = 0; j <= (window_entries - step); j++); - { - double stepval = window[step+j]; - double stateval = window[j]; -// xx += (double)window[j]*(double)window[j]; -// xy += (double)window[step+j]*(double)window[j]; - xx += stateval*stateval; - xy += stepval*stateval; - } -#endif - if (xx == 0.0) - k = 0; - else - k = (int)(floor(-xy/xx * (double)LATTICE_FACTOR / (double)(tap_quant[i]) + 0.5)); - - if (k > (LATTICE_FACTOR/tap_quant[i])) - k = LATTICE_FACTOR/tap_quant[i]; - if (-k > (LATTICE_FACTOR/tap_quant[i])) - k = -(LATTICE_FACTOR/tap_quant[i]); - - out[i] = k; - k *= tap_quant[i]; - -#if 1 - x_ptr = &(window[step]); - state_ptr = &(state[0]); - j = window_entries - step; - for (;j>0;j--,x_ptr++,state_ptr++) - { - int x_value = *x_ptr; - int state_value = *state_ptr; - *x_ptr = x_value + shift_down(k*state_value,LATTICE_SHIFT); - *state_ptr = state_value + shift_down(k*x_value, LATTICE_SHIFT); - } -#else - for (j=0; j <= (window_entries - step); j++) - { - int stepval = window[step+j]; - int stateval=state[j]; - window[step+j] += shift_down(k * stateval, LATTICE_SHIFT); - state[j] += shift_down(k * stepval, LATTICE_SHIFT); - } -#endif - } -} - -static inline int code_samplerate(int samplerate) -{ - switch (samplerate) - { - case 44100: return 0; - case 22050: return 1; - case 11025: return 2; - case 96000: return 3; - case 48000: return 4; - case 32000: return 5; - case 24000: return 6; - case 16000: return 7; - case 8000: return 8; - } - return AVERROR(EINVAL); -} - -static av_cold int sonic_encode_init(AVCodecContext *avctx) -{ - SonicContext *s = avctx->priv_data; - int *coded_samples; - PutBitContext pb; - int i; - - s->version = 2; - - if (avctx->ch_layout.nb_channels > MAX_CHANNELS) - { - av_log(avctx, AV_LOG_ERROR, "Only mono and stereo streams are supported by now\n"); - return AVERROR(EINVAL); /* only stereo or mono for now */ - } - - if (avctx->ch_layout.nb_channels == 2) - s->decorrelation = MID_SIDE; - else - s->decorrelation = 3; - - if (avctx->codec->id == AV_CODEC_ID_SONIC_LS) - { - s->lossless = 1; - s->num_taps = 32; - s->downsampling = 1; - s->quantization = 0.0; - } - else - { - s->num_taps = 128; - s->downsampling = 2; - s->quantization = 1.0; - } - - // max tap 2048 - if (s->num_taps < 32 || s->num_taps > 1024 || s->num_taps % 32) { - av_log(avctx, AV_LOG_ERROR, "Invalid number of taps\n"); - return AVERROR_INVALIDDATA; - } - - // generate taps - s->tap_quant = av_calloc(s->num_taps, sizeof(*s->tap_quant)); - if (!s->tap_quant) - return AVERROR(ENOMEM); - - for (i = 0; i < s->num_taps; i++) - s->tap_quant[i] = ff_sqrt(i+1); - - s->channels = avctx->ch_layout.nb_channels; - s->samplerate = avctx->sample_rate; - - s->block_align = 2048LL*s->samplerate/(44100*s->downsampling); - s->frame_size = s->channels*s->block_align*s->downsampling; - - s->tail_size = s->num_taps*s->channels; - s->tail = av_calloc(s->tail_size, sizeof(*s->tail)); - if (!s->tail) - return AVERROR(ENOMEM); - - s->predictor_k = av_calloc(s->num_taps, sizeof(*s->predictor_k) ); - if (!s->predictor_k) - return AVERROR(ENOMEM); - - coded_samples = av_calloc(s->block_align, s->channels * sizeof(**s->coded_samples)); - if (!coded_samples) - return AVERROR(ENOMEM); - for (i = 0; i < s->channels; i++, coded_samples += s->block_align) - s->coded_samples[i] = coded_samples; - - s->int_samples = av_calloc(s->frame_size, sizeof(*s->int_samples)); - - s->window_size = ((2*s->tail_size)+s->frame_size); - s->window = av_calloc(s->window_size, 2 * sizeof(*s->window)); - if (!s->window || !s->int_samples) - return AVERROR(ENOMEM); - - avctx->extradata = av_mallocz(16); - if (!avctx->extradata) - return AVERROR(ENOMEM); - init_put_bits(&pb, avctx->extradata, 16*8); - - put_bits(&pb, 2, s->version); // version - if (s->version >= 1) - { - if (s->version >= 2) { - put_bits(&pb, 8, s->version); - put_bits(&pb, 8, s->minor_version); - } - put_bits(&pb, 2, s->channels); - put_bits(&pb, 4, code_samplerate(s->samplerate)); - } - put_bits(&pb, 1, s->lossless); - if (!s->lossless) - put_bits(&pb, 3, SAMPLE_SHIFT); // XXX FIXME: sample precision - put_bits(&pb, 2, s->decorrelation); - put_bits(&pb, 2, s->downsampling); - put_bits(&pb, 5, (s->num_taps >> 5)-1); // 32..1024 - put_bits(&pb, 1, 0); // XXX FIXME: no custom tap quant table - - flush_put_bits(&pb); - avctx->extradata_size = put_bytes_output(&pb); - - av_log(avctx, AV_LOG_INFO, "Sonic: ver: %d.%d ls: %d dr: %d taps: %d block: %d frame: %d downsamp: %d\n", - s->version, s->minor_version, s->lossless, s->decorrelation, s->num_taps, s->block_align, s->frame_size, s->downsampling); - - avctx->frame_size = s->block_align*s->downsampling; - - return 0; -} - -static av_cold int sonic_encode_close(AVCodecContext *avctx) -{ - SonicContext *s = avctx->priv_data; - - av_freep(&s->coded_samples[0]); - av_freep(&s->predictor_k); - av_freep(&s->tail); - av_freep(&s->tap_quant); - av_freep(&s->window); - av_freep(&s->int_samples); - - return 0; -} - -static int sonic_encode_frame(AVCodecContext *avctx, AVPacket *avpkt, - const AVFrame *frame, int *got_packet_ptr) -{ - SonicContext *s = avctx->priv_data; - RangeCoder c; - int i, j, ch, quant = 0, x = 0; - int ret; - const short *samples = (const int16_t*)frame->data[0]; - uint8_t state[32]; - - if ((ret = ff_alloc_packet(avctx, avpkt, s->frame_size * 5 + 1000)) < 0) - return ret; - - ff_init_range_encoder(&c, avpkt->data, avpkt->size); - ff_build_rac_states(&c, 0.05*(1LL<<32), 256-8); - memset(state, 128, sizeof(state)); - - // short -> internal - for (i = 0; i < s->frame_size; i++) - s->int_samples[i] = samples[i]; - - if (!s->lossless) - for (i = 0; i < s->frame_size; i++) - s->int_samples[i] = s->int_samples[i] << SAMPLE_SHIFT; - - switch(s->decorrelation) - { - case MID_SIDE: - for (i = 0; i < s->frame_size; i += s->channels) - { - s->int_samples[i] += s->int_samples[i+1]; - s->int_samples[i+1] -= shift(s->int_samples[i], 1); - } - break; - case LEFT_SIDE: - for (i = 0; i < s->frame_size; i += s->channels) - s->int_samples[i+1] -= s->int_samples[i]; - break; - case RIGHT_SIDE: - for (i = 0; i < s->frame_size; i += s->channels) - s->int_samples[i] -= s->int_samples[i+1]; - break; - } - - memset(s->window, 0, s->window_size * sizeof(*s->window)); - - for (i = 0; i < s->tail_size; i++) - s->window[x++] = s->tail[i]; - - for (i = 0; i < s->frame_size; i++) - s->window[x++] = s->int_samples[i]; - - for (i = 0; i < s->tail_size; i++) - s->window[x++] = 0; - - for (i = 0; i < s->tail_size; i++) - s->tail[i] = s->int_samples[s->frame_size - s->tail_size + i]; - - // generate taps - modified_levinson_durbin(s->window, s->window_size, - s->predictor_k, s->num_taps, s->channels, s->tap_quant); - - if ((ret = intlist_write(&c, state, s->predictor_k, s->num_taps, 0)) < 0) - return ret; - - for (ch = 0; ch < s->channels; ch++) - { - x = s->tail_size+ch; - for (i = 0; i < s->block_align; i++) - { - int sum = 0; - for (j = 0; j < s->downsampling; j++, x += s->channels) - sum += s->window[x]; - s->coded_samples[ch][i] = sum; - } - } - - // simple rate control code - if (!s->lossless) - { - double energy1 = 0.0, energy2 = 0.0; - for (ch = 0; ch < s->channels; ch++) - { - for (i = 0; i < s->block_align; i++) - { - double sample = s->coded_samples[ch][i]; - energy2 += sample*sample; - energy1 += fabs(sample); - } - } - - energy2 = sqrt(energy2/(s->channels*s->block_align)); - energy1 = M_SQRT2*energy1/(s->channels*s->block_align); - - // increase bitrate when samples are like a gaussian distribution - // reduce bitrate when samples are like a two-tailed exponential distribution - - if (energy2 > energy1) - energy2 += (energy2-energy1)*RATE_VARIATION; - - quant = (int)(BASE_QUANT*s->quantization*energy2/SAMPLE_FACTOR); -// av_log(avctx, AV_LOG_DEBUG, "quant: %d energy: %f / %f\n", quant, energy1, energy2); - - quant = av_clip(quant, 1, 65534); - - put_symbol(&c, state, quant, 0, NULL, NULL); - - quant *= SAMPLE_FACTOR; - } - - // write out coded samples - for (ch = 0; ch < s->channels; ch++) - { - if (!s->lossless) - for (i = 0; i < s->block_align; i++) - s->coded_samples[ch][i] = ROUNDED_DIV(s->coded_samples[ch][i], quant); - - if ((ret = intlist_write(&c, state, s->coded_samples[ch], s->block_align, 1)) < 0) - return ret; - } - - avpkt->size = ff_rac_terminate(&c, 0); - *got_packet_ptr = 1; - return 0; - -} -#endif /* CONFIG_SONIC_ENCODER || CONFIG_SONIC_LS_ENCODER */ - -#if CONFIG_SONIC_DECODER -static const int samplerate_table[] = - { 44100, 22050, 11025, 96000, 48000, 32000, 24000, 16000, 8000 }; - -static av_cold int sonic_decode_init(AVCodecContext *avctx) -{ - SonicContext *s = avctx->priv_data; - int *tmp; - GetBitContext gb; - int i; - int ret; - - s->channels = avctx->ch_layout.nb_channels; - s->samplerate = avctx->sample_rate; - - if (!avctx->extradata) - { - av_log(avctx, AV_LOG_ERROR, "No mandatory headers present\n"); - return AVERROR_INVALIDDATA; - } - - ret = init_get_bits8(&gb, avctx->extradata, avctx->extradata_size); - if (ret < 0) - return ret; - - s->version = get_bits(&gb, 2); - if (s->version >= 2) { - s->version = get_bits(&gb, 8); - s->minor_version = get_bits(&gb, 8); - } - if (s->version != 2) - { - av_log(avctx, AV_LOG_ERROR, "Unsupported Sonic version, please report\n"); - return AVERROR_INVALIDDATA; - } - - if (s->version >= 1) - { - int sample_rate_index; - s->channels = get_bits(&gb, 2); - sample_rate_index = get_bits(&gb, 4); - if (sample_rate_index >= FF_ARRAY_ELEMS(samplerate_table)) { - av_log(avctx, AV_LOG_ERROR, "Invalid sample_rate_index %d\n", sample_rate_index); - return AVERROR_INVALIDDATA; - } - s->samplerate = samplerate_table[sample_rate_index]; - av_log(avctx, AV_LOG_INFO, "Sonicv2 chans: %d samprate: %d\n", - s->channels, s->samplerate); - } - - if (s->channels > MAX_CHANNELS || s->channels < 1) - { - av_log(avctx, AV_LOG_ERROR, "Only mono and stereo streams are supported by now\n"); - return AVERROR_INVALIDDATA; - } - av_channel_layout_uninit(&avctx->ch_layout); - avctx->ch_layout.order = AV_CHANNEL_ORDER_UNSPEC; - avctx->ch_layout.nb_channels = s->channels; - - s->lossless = get_bits1(&gb); - if (!s->lossless) - skip_bits(&gb, 3); // XXX FIXME - s->decorrelation = get_bits(&gb, 2); - if (s->decorrelation != 3 && s->channels != 2) { - av_log(avctx, AV_LOG_ERROR, "invalid decorrelation %d\n", s->decorrelation); - return AVERROR_INVALIDDATA; - } - - s->downsampling = get_bits(&gb, 2); - if (!s->downsampling) { - av_log(avctx, AV_LOG_ERROR, "invalid downsampling value\n"); - return AVERROR_INVALIDDATA; - } - - s->num_taps = (get_bits(&gb, 5)+1)<<5; - if (get_bits1(&gb)) // XXX FIXME - av_log(avctx, AV_LOG_INFO, "Custom quant table\n"); - - s->block_align = 2048LL*s->samplerate/(44100*s->downsampling); - s->frame_size = s->channels*s->block_align*s->downsampling; -// avctx->frame_size = s->block_align; - - if (s->num_taps * s->channels > s->frame_size) { - av_log(avctx, AV_LOG_ERROR, - "number of taps times channels (%d * %d) larger than frame size %d\n", - s->num_taps, s->channels, s->frame_size); - return AVERROR_INVALIDDATA; - } - - av_log(avctx, AV_LOG_INFO, "Sonic: ver: %d.%d ls: %d dr: %d taps: %d block: %d frame: %d downsamp: %d\n", - s->version, s->minor_version, s->lossless, s->decorrelation, s->num_taps, s->block_align, s->frame_size, s->downsampling); - - // generate taps - s->tap_quant = av_calloc(s->num_taps, sizeof(*s->tap_quant)); - if (!s->tap_quant) - return AVERROR(ENOMEM); - - for (i = 0; i < s->num_taps; i++) - s->tap_quant[i] = ff_sqrt(i+1); - - s->predictor_k = av_calloc(s->num_taps, sizeof(*s->predictor_k)); - - tmp = av_calloc(s->num_taps, s->channels * sizeof(**s->predictor_state)); - if (!tmp) - return AVERROR(ENOMEM); - for (i = 0; i < s->channels; i++, tmp += s->num_taps) - s->predictor_state[i] = tmp; - - tmp = av_calloc(s->block_align, s->channels * sizeof(**s->coded_samples)); - if (!tmp) - return AVERROR(ENOMEM); - for (i = 0; i < s->channels; i++, tmp += s->block_align) - s->coded_samples[i] = tmp; - - s->int_samples = av_calloc(s->frame_size, sizeof(*s->int_samples)); - if (!s->int_samples) - return AVERROR(ENOMEM); - - avctx->sample_fmt = AV_SAMPLE_FMT_S16; - return 0; -} - -static av_cold int sonic_decode_close(AVCodecContext *avctx) -{ - SonicContext *s = avctx->priv_data; - - av_freep(&s->int_samples); - av_freep(&s->tap_quant); - av_freep(&s->predictor_k); - av_freep(&s->predictor_state[0]); - av_freep(&s->coded_samples[0]); - - return 0; -} - -static int sonic_decode_frame(AVCodecContext *avctx, AVFrame *frame, - int *got_frame_ptr, AVPacket *avpkt) -{ - const uint8_t *buf = avpkt->data; - int buf_size = avpkt->size; - SonicContext *s = avctx->priv_data; - RangeCoder c; - uint8_t state[32]; - int i, quant, ch, j, ret; - int16_t *samples; - - if (buf_size == 0) return 0; - - frame->nb_samples = s->frame_size / avctx->ch_layout.nb_channels; - if ((ret = ff_get_buffer(avctx, frame, 0)) < 0) - return ret; - samples = (int16_t *)frame->data[0]; - -// av_log(NULL, AV_LOG_INFO, "buf_size: %d\n", buf_size); - - memset(state, 128, sizeof(state)); - ff_init_range_decoder(&c, buf, buf_size); - ff_build_rac_states(&c, 0.05*(1LL<<32), 256-8); - - intlist_read(&c, state, s->predictor_k, s->num_taps, 0); - - // dequantize - for (i = 0; i < s->num_taps; i++) - s->predictor_k[i] *= (unsigned) s->tap_quant[i]; - - if (s->lossless) - quant = 1; - else - quant = get_symbol(&c, state, 0) * (unsigned)SAMPLE_FACTOR; - -// av_log(NULL, AV_LOG_INFO, "quant: %d\n", quant); - - for (ch = 0; ch < s->channels; ch++) - { - int x = ch; - - if (c.overread > MAX_OVERREAD) - return AVERROR_INVALIDDATA; - - predictor_init_state(s->predictor_k, s->predictor_state[ch], s->num_taps); - - intlist_read(&c, state, s->coded_samples[ch], s->block_align, 1); - - for (i = 0; i < s->block_align; i++) - { - for (j = 0; j < s->downsampling - 1; j++) - { - s->int_samples[x] = predictor_calc_error(s->predictor_k, s->predictor_state[ch], s->num_taps, 0); - x += s->channels; - } - - s->int_samples[x] = predictor_calc_error(s->predictor_k, s->predictor_state[ch], s->num_taps, s->coded_samples[ch][i] * (unsigned)quant); - x += s->channels; - } - - for (i = 0; i < s->num_taps; i++) - s->predictor_state[ch][i] = s->int_samples[s->frame_size - s->channels + ch - i*s->channels]; - } - - switch(s->decorrelation) - { - case MID_SIDE: - for (i = 0; i < s->frame_size; i += s->channels) - { - s->int_samples[i+1] += shift(s->int_samples[i], 1); - s->int_samples[i] -= s->int_samples[i+1]; - } - break; - case LEFT_SIDE: - for (i = 0; i < s->frame_size; i += s->channels) - s->int_samples[i+1] += s->int_samples[i]; - break; - case RIGHT_SIDE: - for (i = 0; i < s->frame_size; i += s->channels) - s->int_samples[i] += s->int_samples[i+1]; - break; - } - - if (!s->lossless) - for (i = 0; i < s->frame_size; i++) - s->int_samples[i] = shift(s->int_samples[i], SAMPLE_SHIFT); - - // internal -> short - for (i = 0; i < s->frame_size; i++) - samples[i] = av_clip_int16(s->int_samples[i]); - - *got_frame_ptr = 1; - - return buf_size; -} - -const FFCodec ff_sonic_decoder = { - .p.name = "sonic", - CODEC_LONG_NAME("Sonic"), - .p.type = AVMEDIA_TYPE_AUDIO, - .p.id = AV_CODEC_ID_SONIC, - .priv_data_size = sizeof(SonicContext), - .init = sonic_decode_init, - .close = sonic_decode_close, - FF_CODEC_DECODE_CB(sonic_decode_frame), - .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_EXPERIMENTAL | AV_CODEC_CAP_CHANNEL_CONF, - .caps_internal = FF_CODEC_CAP_INIT_CLEANUP, -}; -#endif /* CONFIG_SONIC_DECODER */ - -#if CONFIG_SONIC_ENCODER -const FFCodec ff_sonic_encoder = { - .p.name = "sonic", - CODEC_LONG_NAME("Sonic"), - .p.type = AVMEDIA_TYPE_AUDIO, - .p.id = AV_CODEC_ID_SONIC, - .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_EXPERIMENTAL | - AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE, - .priv_data_size = sizeof(SonicContext), - .init = sonic_encode_init, - FF_CODEC_ENCODE_CB(sonic_encode_frame), - .p.sample_fmts = (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_S16, AV_SAMPLE_FMT_NONE }, - .caps_internal = FF_CODEC_CAP_INIT_CLEANUP, - .close = sonic_encode_close, -}; -#endif - -#if CONFIG_SONIC_LS_ENCODER -const FFCodec ff_sonic_ls_encoder = { - .p.name = "sonicls", - CODEC_LONG_NAME("Sonic lossless"), - .p.type = AVMEDIA_TYPE_AUDIO, - .p.id = AV_CODEC_ID_SONIC_LS, - .p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_EXPERIMENTAL | - AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE, - .priv_data_size = sizeof(SonicContext), - .init = sonic_encode_init, - FF_CODEC_ENCODE_CB(sonic_encode_frame), - .p.sample_fmts = (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_S16, AV_SAMPLE_FMT_NONE }, - .caps_internal = FF_CODEC_CAP_INIT_CLEANUP, - .close = sonic_encode_close, -}; -#endif -- 2.43.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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 12:56 ` [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio J. Dekker @ 2024-02-28 13:23 ` Andreas Rheinhardt 2024-02-28 13:29 ` Michael Niedermayer 2024-03-01 20:14 ` Tomas Härdin 2 siblings, 0 replies; 26+ messages in thread From: Andreas Rheinhardt @ 2024-02-28 13:23 UTC (permalink / raw) To: ffmpeg-devel J. Dekker: > This was an experimental/research codec of which ffmpeg is the only > encoder and decoder, development has stalled and these files don't exist > in the wild. > > Signed-off-by: J. Dekker <jdek@itanimul.li> > --- > Changelog | 1 + > configure | 3 - > libavcodec/Makefile | 3 - > libavcodec/allcodecs.c | 3 - > libavcodec/codec_desc.c | 14 - > libavcodec/sonic.c | 1125 --------------------------------------- > 6 files changed, 1 insertion(+), 1148 deletions(-) > delete mode 100644 libavcodec/sonic.c > > diff --git a/Changelog b/Changelog > index 610ee61dd6..e2096f249a 100644 > --- a/Changelog > +++ b/Changelog > @@ -27,6 +27,7 @@ version <next>: > - a C11-compliant compiler is now required; note that this requirement > will be bumped to C17 in the near future, so consider updating your > build environment if it lacks C17 support > +- sonic lossy/lossless audio codec removed > > version 6.1: > - libaribcaption decoder > diff --git a/configure b/configure > index bb5e630bad..e639a5e2b7 100755 > --- a/configure > +++ b/configure > @@ -2991,9 +2991,6 @@ sipr_decoder_select="lsp" > smvjpeg_decoder_select="mjpeg_decoder" > snow_decoder_select="dwt h264qpel rangecoder videodsp" > snow_encoder_select="dwt h264qpel hpeldsp me_cmp mpegvideoenc rangecoder videodsp" > -sonic_decoder_select="golomb rangecoder" > -sonic_encoder_select="golomb rangecoder" > -sonic_ls_encoder_select="golomb rangecoder" > sp5x_decoder_select="mjpeg_decoder" > speedhq_decoder_select="blockdsp idctdsp" > speedhq_encoder_select="mpegvideoenc" > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > index 09ae5270b3..3fc716ee68 100644 > --- a/libavcodec/Makefile > +++ b/libavcodec/Makefile > @@ -687,9 +687,6 @@ OBJS-$(CONFIG_SNOW_DECODER) += snowdec.o snow.o snow_dwt.o > OBJS-$(CONFIG_SNOW_ENCODER) += snowenc.o snow.o snow_dwt.o \ > h263.o h263data.o ituh263enc.o > OBJS-$(CONFIG_SOL_DPCM_DECODER) += dpcm.o > -OBJS-$(CONFIG_SONIC_DECODER) += sonic.o > -OBJS-$(CONFIG_SONIC_ENCODER) += sonic.o > -OBJS-$(CONFIG_SONIC_LS_ENCODER) += sonic.o > OBJS-$(CONFIG_SPEEDHQ_DECODER) += speedhqdec.o speedhq.o mpeg12.o \ > mpeg12data.o > OBJS-$(CONFIG_SPEEDHQ_ENCODER) += speedhq.o mpeg12data.o mpeg12enc.o speedhqenc.o > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c > index ef8c3a6d7d..e0a4a5421d 100644 > --- a/libavcodec/allcodecs.c > +++ b/libavcodec/allcodecs.c > @@ -535,9 +535,6 @@ extern const FFCodec ff_shorten_decoder; > extern const FFCodec ff_sipr_decoder; > extern const FFCodec ff_siren_decoder; > extern const FFCodec ff_smackaud_decoder; > -extern const FFCodec ff_sonic_encoder; > -extern const FFCodec ff_sonic_decoder; > -extern const FFCodec ff_sonic_ls_encoder; > extern const FFCodec ff_tak_decoder; > extern const FFCodec ff_truehd_encoder; > extern const FFCodec ff_truehd_decoder; > diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c > index 033344304c..9b456616be 100644 > --- a/libavcodec/codec_desc.c > +++ b/libavcodec/codec_desc.c > @@ -3175,20 +3175,6 @@ static const AVCodecDescriptor codec_descriptors[] = { > .long_name = NULL_IF_CONFIG_SMALL("Wave synthesis pseudo-codec"), > .props = AV_CODEC_PROP_INTRA_ONLY, > }, > - { > - .id = AV_CODEC_ID_SONIC, > - .type = AVMEDIA_TYPE_AUDIO, > - .name = "sonic", > - .long_name = NULL_IF_CONFIG_SMALL("Sonic"), > - .props = AV_CODEC_PROP_INTRA_ONLY, > - }, > - { > - .id = AV_CODEC_ID_SONIC_LS, > - .type = AVMEDIA_TYPE_AUDIO, > - .name = "sonicls", > - .long_name = NULL_IF_CONFIG_SMALL("Sonic lossless"), > - .props = AV_CODEC_PROP_INTRA_ONLY, > - }, > { > .id = AV_CODEC_ID_EVRC, > .type = AVMEDIA_TYPE_AUDIO, You can't remove the codec descriptors as long as the codec id exists (every codec id should have a codec descriptor, even if there is no codec). Should the codec id be deprecated, too? - 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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 12:56 ` [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio J. Dekker 2024-02-28 13:23 ` Andreas Rheinhardt @ 2024-02-28 13:29 ` Michael Niedermayer 2024-02-28 13:31 ` J. Dekker 2024-02-28 22:13 ` Lynne 2024-03-01 20:14 ` Tomas Härdin 2 siblings, 2 replies; 26+ messages in thread From: Michael Niedermayer @ 2024-02-28 13:29 UTC (permalink / raw) To: FFmpeg development discussions and patches [-- Attachment #1.1: Type: text/plain, Size: 665 bytes --] On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > This was an experimental/research codec of which ffmpeg is the only > encoder and decoder, > development has stalled Thats not true, there was private dicussion making sonic the most advanced audio codec in FFmpeg a few months ago. Iam not saying that will happen, i am just saying there was a discussion about it. And that iam in principle interrested in working on this. Its possible i will not have enough time ... thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] [-- Attachment #2: Type: text/plain, Size: 251 bytes --] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 13:29 ` Michael Niedermayer @ 2024-02-28 13:31 ` J. Dekker 2024-02-28 13:41 ` Nicolas George ` (2 more replies) 2024-02-28 22:13 ` Lynne 1 sibling, 3 replies; 26+ messages in thread From: J. Dekker @ 2024-02-28 13:31 UTC (permalink / raw) To: ffmpeg-devel Michael Niedermayer <michael@niedermayer.cc> writes: > [[PGP Signed Part:Undecided]] > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: >> This was an experimental/research codec of which ffmpeg is the only >> encoder and decoder, > > >> development has stalled > > Thats not true, there was private dicussion making sonic the most > advanced audio codec in FFmpeg a few months ago. > Iam not saying that will happen, i am just saying there was a > discussion about it. And that iam in principle interrested in > working on this. Its possible i will not have enough time ... > The last commit which actually changed the codec was 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10 years ago. For an experimental codec I think it's pretty safe to say that development has stalled. Keeping the codec around based on 'what if?'s doesn't seem reasonable. Besides, if you do make sonic the most advanced audio codec in FFmpeg there's nothing which says you couldn't re-add it at a later date when it's being actively developed again. -- jd _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 13:31 ` J. Dekker @ 2024-02-28 13:41 ` Nicolas George 2024-02-28 13:57 ` Vittorio Giovara 2024-02-28 17:55 ` James Almer 2 siblings, 0 replies; 26+ messages in thread From: Nicolas George @ 2024-02-28 13:41 UTC (permalink / raw) To: FFmpeg development discussions and patches J. Dekker (12024-02-28): > Keeping the codec around based on 'what if?'s doesn't seem > reasonable. Spending your efforts on it, even if it is just to remove it, is a waste of your time. -- 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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 13:31 ` J. Dekker 2024-02-28 13:41 ` Nicolas George @ 2024-02-28 13:57 ` Vittorio Giovara 2024-02-28 14:08 ` J. Dekker 2024-02-28 17:55 ` James Almer 2 siblings, 1 reply; 26+ messages in thread From: Vittorio Giovara @ 2024-02-28 13:57 UTC (permalink / raw) To: FFmpeg development discussions and patches On Wed, Feb 28, 2024 at 2:38 PM J. Dekker <jdek@itanimul.li> wrote: > > Michael Niedermayer <michael@niedermayer.cc> writes: > > > [[PGP Signed Part:Undecided]] > > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > >> This was an experimental/research codec of which ffmpeg is the only > >> encoder and decoder, > > > > > >> development has stalled > > > > Thats not true, there was private dicussion making sonic the most > > advanced audio codec in FFmpeg a few months ago. > > Iam not saying that will happen, i am just saying there was a > > discussion about it. And that iam in principle interrested in > > working on this. Its possible i will not have enough time ... > > > > The last commit which actually changed the codec was > 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10 > years ago. For an experimental codec I think it's pretty safe to say > that development has stalled. > > Keeping the codec around based on 'what if?'s doesn't seem > reasonable. Besides, if you do make sonic the most advanced audio codec > in FFmpeg there's nothing which says you couldn't re-add it at a later > date when it's being actively developed again. > +1 but please do the deprecation dance as suggested -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 13:57 ` Vittorio Giovara @ 2024-02-28 14:08 ` J. Dekker 0 siblings, 0 replies; 26+ messages in thread From: J. Dekker @ 2024-02-28 14:08 UTC (permalink / raw) To: ffmpeg-devel Vittorio Giovara <vittorio.giovara@gmail.com> writes: > On Wed, Feb 28, 2024 at 2:38 PM J. Dekker <jdek@itanimul.li> wrote: > >> >> Michael Niedermayer <michael@niedermayer.cc> writes: >> >> > [[PGP Signed Part:Undecided]] >> > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: >> >> This was an experimental/research codec of which ffmpeg is the only >> >> encoder and decoder, >> > >> > >> >> development has stalled >> > >> > Thats not true, there was private dicussion making sonic the most >> > advanced audio codec in FFmpeg a few months ago. >> > Iam not saying that will happen, i am just saying there was a >> > discussion about it. And that iam in principle interrested in >> > working on this. Its possible i will not have enough time ... >> > >> >> The last commit which actually changed the codec was >> 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10 >> years ago. For an experimental codec I think it's pretty safe to say >> that development has stalled. >> >> Keeping the codec around based on 'what if?'s doesn't seem >> reasonable. Besides, if you do make sonic the most advanced audio codec >> in FFmpeg there's nothing which says you couldn't re-add it at a later >> date when it's being actively developed again. >> > > +1 > > but please do the deprecation dance as suggested As mentioned on IRC the suggestion was to leave the codec IDs as-is so that they can still be identified even if we cannot decode them. So there is no need to deprecate anything here, public API is left untouched and codec removed as if it were disabled at compile time. Will post an updated patch. -- jd _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 13:31 ` J. Dekker 2024-02-28 13:41 ` Nicolas George 2024-02-28 13:57 ` Vittorio Giovara @ 2024-02-28 17:55 ` James Almer 2024-02-28 18:36 ` Jean-Baptiste Kempf 2024-02-28 20:23 ` Rémi Denis-Courmont 2 siblings, 2 replies; 26+ messages in thread From: James Almer @ 2024-02-28 17:55 UTC (permalink / raw) To: ffmpeg-devel On 2/28/2024 10:31 AM, J. Dekker wrote: > > Michael Niedermayer <michael@niedermayer.cc> writes: > >> [[PGP Signed Part:Undecided]] >> On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: >>> This was an experimental/research codec of which ffmpeg is the only >>> encoder and decoder, >> >> >>> development has stalled >> >> Thats not true, there was private dicussion making sonic the most >> advanced audio codec in FFmpeg a few months ago. >> Iam not saying that will happen, i am just saying there was a >> discussion about it. And that iam in principle interrested in >> working on this. Its possible i will not have enough time ... >> > > The last commit which actually changed the codec was > 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10 > years ago. For an experimental codec I think it's pretty safe to say > that development has stalled. > > Keeping the codec around based on 'what if?'s doesn't seem > reasonable. Besides, if you do make sonic the most advanced audio codec > in FFmpeg there's nothing which says you couldn't re-add it at a later > date when it's being actively developed again. Does it hurt keeping it around? If it can at some point be developed again, then removing the codec id to re-add it later will be a bit dirty. IMO, just disable both modules by default during configure, or tag the encoder as experimental to prevent new streams to be created unless explicitly requested knowing that it's an unfinished format. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 17:55 ` James Almer @ 2024-02-28 18:36 ` Jean-Baptiste Kempf 2024-03-10 13:12 ` Alexander Strasser via ffmpeg-devel 2024-02-28 20:23 ` Rémi Denis-Courmont 1 sibling, 1 reply; 26+ messages in thread From: Jean-Baptiste Kempf @ 2024-02-28 18:36 UTC (permalink / raw) To: ffmpeg-devel On Wed, 28 Feb 2024, at 18:55, James Almer wrote: > On 2/28/2024 10:31 AM, J. Dekker wrote: >> >> Michael Niedermayer <michael@niedermayer.cc> writes: >> >>> [[PGP Signed Part:Undecided]] >>> On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: >>>> This was an experimental/research codec of which ffmpeg is the only >>>> encoder and decoder, >>> >>> >>>> development has stalled >>> >>> Thats not true, there was private dicussion making sonic the most >>> advanced audio codec in FFmpeg a few months ago. >>> Iam not saying that will happen, i am just saying there was a >>> discussion about it. And that iam in principle interrested in >>> working on this. Its possible i will not have enough time ... >>> >> >> The last commit which actually changed the codec was >> 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10 >> years ago. For an experimental codec I think it's pretty safe to say >> that development has stalled. >> >> Keeping the codec around based on 'what if?'s doesn't seem >> reasonable. Besides, if you do make sonic the most advanced audio codec >> in FFmpeg there's nothing which says you couldn't re-add it at a later >> date when it's being actively developed again. > > Does it hurt keeping it around? If it can at some point be developed > again, then removing the codec id to re-add it later will be a bit dirty. > > IMO, just disable both modules by default during configure, or tag the > encoder as experimental to prevent new streams to be created unless > explicitly requested knowing that it's an unfinished format. +1 -- Jean-Baptiste Kempf - President +33 672 704 734 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 18:36 ` Jean-Baptiste Kempf @ 2024-03-10 13:12 ` Alexander Strasser via ffmpeg-devel 0 siblings, 0 replies; 26+ messages in thread From: Alexander Strasser via ffmpeg-devel @ 2024-03-10 13:12 UTC (permalink / raw) To: FFmpeg development discussions and patches; +Cc: Alexander Strasser On 2024-02-28 19:36 +0100, Jean-Baptiste Kempf wrote: > > On Wed, 28 Feb 2024, at 18:55, James Almer wrote: > > On 2/28/2024 10:31 AM, J. Dekker wrote: > >> > >> Michael Niedermayer <michael@niedermayer.cc> writes: > >> > >>> [[PGP Signed Part:Undecided]] > >>> On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > >>>> This was an experimental/research codec of which ffmpeg is the only > >>>> encoder and decoder, > >>> > >>> > >>>> development has stalled > >>> > >>> Thats not true, there was private dicussion making sonic the most > >>> advanced audio codec in FFmpeg a few months ago. > >>> Iam not saying that will happen, i am just saying there was a > >>> discussion about it. And that iam in principle interrested in > >>> working on this. Its possible i will not have enough time ... > >>> > >> > >> The last commit which actually changed the codec was > >> 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10 > >> years ago. For an experimental codec I think it's pretty safe to say > >> that development has stalled. > >> > >> Keeping the codec around based on 'what if?'s doesn't seem > >> reasonable. Besides, if you do make sonic the most advanced audio codec > >> in FFmpeg there's nothing which says you couldn't re-add it at a later > >> date when it's being actively developed again. > > > > Does it hurt keeping it around? If it can at some point be developed > > again, then removing the codec id to re-add it later will be a bit dirty. > > > > IMO, just disable both modules by default during configure, or tag the > > encoder as experimental to prevent new streams to be created unless > > explicitly requested knowing that it's an unfinished format. > > +1 +1 But if it stays it should be regularly compiled (at least on a fate client). Alexander _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 17:55 ` James Almer 2024-02-28 18:36 ` Jean-Baptiste Kempf @ 2024-02-28 20:23 ` Rémi Denis-Courmont 1 sibling, 0 replies; 26+ messages in thread From: Rémi Denis-Courmont @ 2024-02-28 20:23 UTC (permalink / raw) To: ffmpeg-devel Le keskiviikkona 28. helmikuuta 2024, 19.55.11 EET James Almer a écrit : > > The last commit which actually changed the codec was > > 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10 > > years ago. For an experimental codec I think it's pretty safe to say > > that development has stalled. > > > > Keeping the codec around based on 'what if?'s doesn't seem > > reasonable. Besides, if you do make sonic the most advanced audio codec > > in FFmpeg there's nothing which says you couldn't re-add it at a later > > date when it's being actively developed again. > > Does it hurt keeping it around? Considering the sheer number of audio codecs in libavcodec, the difference is peanuts. But in principle, any dead code is an extra maintenance burden, whether it be reported security vulnerabilities that "need" to be fixed to appease Linux distros and corporate freeloaders, or to update the internal interfaces. > If it can at some point be developed > again, then removing the codec id to re-add it later will be a bit dirty. Slightly, but the chance of that seem almost zero. Also compared to moving stuff in and out of staging like the kernel does, or between good, bad and ugly like a certain competing OSS framework does, it's pretty much nothing. People are not going to ditch FFmpeg on the basis of misusing the VCS over that hypothetical. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 13:29 ` Michael Niedermayer 2024-02-28 13:31 ` J. Dekker @ 2024-02-28 22:13 ` Lynne 2024-02-29 1:50 ` Vittorio Giovara 1 sibling, 1 reply; 26+ messages in thread From: Lynne @ 2024-02-28 22:13 UTC (permalink / raw) To: FFmpeg development discussions and patches Feb 28, 2024, 14:29 by michael@niedermayer.cc: > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > >> This was an experimental/research codec of which ffmpeg is the only >> encoder and decoder, >> > > >> development has stalled >> > > Thats not true, there was private dicussion making sonic the most > advanced audio codec in FFmpeg a few months ago. > Iam not saying that will happen, i am just saying there was a > discussion about it. And that iam in principle interrested in > working on this. Its possible i will not have enough time ... > I would strongly prefer for it to be kept around as well. Otherwise it creates precedence to throw out codecs if they're not popular enough, and we're known for being able to play most formats ever created. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 22:13 ` Lynne @ 2024-02-29 1:50 ` Vittorio Giovara 2024-02-29 13:30 ` Lynne 0 siblings, 1 reply; 26+ messages in thread From: Vittorio Giovara @ 2024-02-29 1:50 UTC (permalink / raw) To: FFmpeg development discussions and patches On Wed, Feb 28, 2024 at 11:13 PM Lynne <dev@lynne.ee> wrote: > Feb 28, 2024, 14:29 by michael@niedermayer.cc: > > > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > > > >> This was an experimental/research codec of which ffmpeg is the only > >> encoder and decoder, > >> > > > > > >> development has stalled > >> > > > > Thats not true, there was private dicussion making sonic the most > > advanced audio codec in FFmpeg a few months ago. > > Iam not saying that will happen, i am just saying there was a > > discussion about it. And that iam in principle interrested in > > working on this. Its possible i will not have enough time ... > > > > I would strongly prefer for it to be kept around as well. > > Otherwise it creates precedence to throw out codecs if they're > not popular enough, and we're known for being able to play > most formats ever created. > IMO there is a big difference between a game codec and an experimental codec that hasn't come out of ffmpeg -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-29 1:50 ` Vittorio Giovara @ 2024-02-29 13:30 ` Lynne 2024-02-29 14:44 ` Vittorio Giovara 2024-03-01 18:59 ` Anton Khirnov 0 siblings, 2 replies; 26+ messages in thread From: Lynne @ 2024-02-29 13:30 UTC (permalink / raw) To: FFmpeg development discussions and patches Feb 29, 2024, 02:50 by vittorio.giovara@gmail.com: > On Wed, Feb 28, 2024 at 11:13 PM Lynne <dev@lynne.ee> wrote: > >> Feb 28, 2024, 14:29 by michael@niedermayer.cc: >> >> > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: >> > >> >> This was an experimental/research codec of which ffmpeg is the only >> >> encoder and decoder, >> >> >> > >> > >> >> development has stalled >> >> >> > >> > Thats not true, there was private dicussion making sonic the most >> > advanced audio codec in FFmpeg a few months ago. >> > Iam not saying that will happen, i am just saying there was a >> > discussion about it. And that iam in principle interrested in >> > working on this. Its possible i will not have enough time ... >> > >> >> I would strongly prefer for it to be kept around as well. >> >> Otherwise it creates precedence to throw out codecs if they're >> not popular enough, and we're known for being able to play >> most formats ever created. >> > > IMO there is a big difference between a game codec and an experimental > codec that hasn't come out of ffmpeg > We offer support for it. Someone must have used it. I'm sure there are less used game codecs we support than Sonic. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-29 13:30 ` Lynne @ 2024-02-29 14:44 ` Vittorio Giovara 2024-03-01 1:13 ` Michael Niedermayer 2024-03-01 18:59 ` Anton Khirnov 1 sibling, 1 reply; 26+ messages in thread From: Vittorio Giovara @ 2024-02-29 14:44 UTC (permalink / raw) To: FFmpeg development discussions and patches On Thu, Feb 29, 2024 at 2:31 PM Lynne <dev@lynne.ee> wrote: > Feb 29, 2024, 02:50 by vittorio.giovara@gmail.com: > > > On Wed, Feb 28, 2024 at 11:13 PM Lynne <dev@lynne.ee> wrote: > > > >> Feb 28, 2024, 14:29 by michael@niedermayer.cc: > >> > >> > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > >> > > >> >> This was an experimental/research codec of which ffmpeg is the only > >> >> encoder and decoder, > >> >> > >> > > >> > > >> >> development has stalled > >> >> > >> > > >> > Thats not true, there was private dicussion making sonic the most > >> > advanced audio codec in FFmpeg a few months ago. > >> > Iam not saying that will happen, i am just saying there was a > >> > discussion about it. And that iam in principle interrested in > >> > working on this. Its possible i will not have enough time ... > >> > > >> > >> I would strongly prefer for it to be kept around as well. > >> > >> Otherwise it creates precedence to throw out codecs if they're > >> not popular enough, and we're known for being able to play > >> most formats ever created. > >> > > > > IMO there is a big difference between a game codec and an experimental > > codec that hasn't come out of ffmpeg > > > > We offer support for it. Someone must have used it. > I'm sure there are less used game codecs we support than Sonic. > the point here is that game codecs are part of digital preservation and and effort against digital obsolescence an "experimental codec" that nobody (read: a very limited amount of users) used except ffmpeg devs as playground does not warrant it being in the codebase (but rather a branch or personal fork) IMO -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-29 14:44 ` Vittorio Giovara @ 2024-03-01 1:13 ` Michael Niedermayer 2024-03-10 19:45 ` Leo Izen 0 siblings, 1 reply; 26+ messages in thread From: Michael Niedermayer @ 2024-03-01 1:13 UTC (permalink / raw) To: FFmpeg development discussions and patches [-- Attachment #1.1: Type: text/plain, Size: 2326 bytes --] On Thu, Feb 29, 2024 at 03:44:46PM +0100, Vittorio Giovara wrote: > On Thu, Feb 29, 2024 at 2:31 PM Lynne <dev@lynne.ee> wrote: > > > Feb 29, 2024, 02:50 by vittorio.giovara@gmail.com: > > > > > On Wed, Feb 28, 2024 at 11:13 PM Lynne <dev@lynne.ee> wrote: > > > > > >> Feb 28, 2024, 14:29 by michael@niedermayer.cc: > > >> > > >> > On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > > >> > > > >> >> This was an experimental/research codec of which ffmpeg is the only > > >> >> encoder and decoder, > > >> >> > > >> > > > >> > > > >> >> development has stalled > > >> >> > > >> > > > >> > Thats not true, there was private dicussion making sonic the most > > >> > advanced audio codec in FFmpeg a few months ago. > > >> > Iam not saying that will happen, i am just saying there was a > > >> > discussion about it. And that iam in principle interrested in > > >> > working on this. Its possible i will not have enough time ... > > >> > > > >> > > >> I would strongly prefer for it to be kept around as well. > > >> > > >> Otherwise it creates precedence to throw out codecs if they're > > >> not popular enough, and we're known for being able to play > > >> most formats ever created. > > >> > > > > > > IMO there is a big difference between a game codec and an experimental > > > codec that hasn't come out of ffmpeg > > > > > > > We offer support for it. Someone must have used it. > > I'm sure there are less used game codecs we support than Sonic. > > > > the point here is that game codecs are part of digital preservation and and > effort against digital obsolescence > an "experimental codec" that nobody (read: a very limited amount of users) Every codec we develop is experimental and used by nobody then by nobody outside ffmpeg and if we dont allow this then we can never create a new codec. FFv1 would not exist if we could not have added it at ta time noone used it. FFv1 would not have become widely used if it was in someones personal repository and main FFmpeg did not support it thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] [-- Attachment #2: Type: text/plain, Size: 251 bytes --] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-03-01 1:13 ` Michael Niedermayer @ 2024-03-10 19:45 ` Leo Izen 0 siblings, 0 replies; 26+ messages in thread From: Leo Izen @ 2024-03-10 19:45 UTC (permalink / raw) To: ffmpeg-devel [-- Attachment #1.1.1: Type: text/plain, Size: 648 bytes --] On 2/29/24 20:13, Michael Niedermayer wrote: > > Every codec we develop is experimental and used by nobody > then by nobody outside ffmpeg > and if we dont allow this then we can never create a new codec. > > FFv1 would not exist if we could not have added it at ta time > noone used it. FFv1 would not have become widely used if it was in > someones personal repository and main FFmpeg did not support it > > thx > This is true, but also the code hasn't been touched in more than ten years, which makes it a bit different than, say, ffv1 which was actively developed for a while and still is. - Leo Izen (Traneptora) [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 236 bytes --] [-- Attachment #2: Type: text/plain, Size: 251 bytes --] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-29 13:30 ` Lynne 2024-02-29 14:44 ` Vittorio Giovara @ 2024-03-01 18:59 ` Anton Khirnov 2024-03-01 19:03 ` Nicolas George 2024-03-01 19:41 ` Lynne 1 sibling, 2 replies; 26+ messages in thread From: Anton Khirnov @ 2024-03-01 18:59 UTC (permalink / raw) To: FFmpeg development discussions and patches Quoting Lynne (2024-02-29 14:30:55) > We offer support for it. Someone must have used it. > I'm sure there are less used game codecs we support than Sonic. [citation needed] Is there any evidence that it was used for anything other than development and testing? That anyone has any actual samples in it they'd like to play? -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-03-01 18:59 ` Anton Khirnov @ 2024-03-01 19:03 ` Nicolas George 2024-03-01 19:41 ` Lynne 1 sibling, 0 replies; 26+ messages in thread From: Nicolas George @ 2024-03-01 19:03 UTC (permalink / raw) To: FFmpeg development discussions and patches Anton Khirnov (12024-03-01): > Is there any evidence that it was used for anything other than > development and testing? That anyone has any actual samples in it they'd > like to play? Wrong question. The burden of proof is on whoever wants to remove, not on the status quo. And good luck proving nobody in the whole world ever chose to try this codec and kept the file. Maybe they are not even subscribed to this list right now. I know, shocking! -- 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-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-03-01 18:59 ` Anton Khirnov 2024-03-01 19:03 ` Nicolas George @ 2024-03-01 19:41 ` Lynne 2024-03-01 20:33 ` Anton Khirnov 1 sibling, 1 reply; 26+ messages in thread From: Lynne @ 2024-03-01 19:41 UTC (permalink / raw) To: FFmpeg development discussions and patches Mar 1, 2024, 19:59 by anton@khirnov.net: > Quoting Lynne (2024-02-29 14:30:55) > >> We offer support for it. Someone must have used it. >> I'm sure there are less used game codecs we support than Sonic. >> > > [citation needed] > > Is there any evidence that it was used for anything other than > development and testing? That anyone has any actual samples in it they'd > like to play? > There's always the possibility that someone encoded samples years ago and deleted the originals. Same as with Snow. My only concern is that this sets a sensitive precedent to get rid of old codec code with low weight under unclear conditions. Where do we draw the line? SMPTE? ISO/IEC standardization? IETF? AOM? Having *a* spec (Sonic doesn't, but neither did FFv1 until a few years ago)? A single company pushing for it many years ago with no spec, like SpeedHQ, or the many niche lossless/intra-only codecs? Or simply having one single implementation in FFmpeg, and no spec at all, and having an experimental flag, and no activity for a very long amount of time? If it's the last case, or simply being a one-off, I can agree with deprecating and remove it next bump. But if the developer thinks they will have time and have motivation to work on it in the future, I think we should leave it at just deprecation plus disabling building the encoder by default, until the issue is brought up again at say, after the next version bump. After all, CELT started out more than 10 years before Opus was standardized, and its EC code has made it all the way to AV2 despite its core remaining visibly similar over the years. And FFv1 was used as an inspiration for FLIC, which went on to become JPEG-XL. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-03-01 19:41 ` Lynne @ 2024-03-01 20:33 ` Anton Khirnov 2024-03-01 21:34 ` Lynne 0 siblings, 1 reply; 26+ messages in thread From: Anton Khirnov @ 2024-03-01 20:33 UTC (permalink / raw) To: FFmpeg development discussions and patches Quoting Lynne (2024-03-01 20:41:53) > Mar 1, 2024, 19:59 by anton@khirnov.net: > > > Quoting Lynne (2024-02-29 14:30:55) > > > >> We offer support for it. Someone must have used it. > >> I'm sure there are less used game codecs we support than Sonic. > >> > > > > [citation needed] > > > > Is there any evidence that it was used for anything other than > > development and testing? That anyone has any actual samples in it they'd > > like to play? > > > > There's always the possibility that someone encoded samples years > ago and deleted the originals. Same as with Snow. > > My only concern is that this sets a sensitive precedent to get rid of > old codec code with low weight under unclear conditions. Where do > we draw the line? > SMPTE? ISO/IEC standardization? IETF? AOM? > Having *a* spec (Sonic doesn't, but neither did FFv1 until a few years > ago)? > A single company pushing for it many years ago with no spec, > like SpeedHQ, or the many niche lossless/intra-only codecs? > > Or simply having one single implementation in FFmpeg, and no spec at all, > and having an experimental flag, and no activity for a very long amount of time? I'd draw the line somewhere around what I said above - some evidence that it was used "seriously". > If it's the last case, or simply being a one-off, I can agree with deprecating > and remove it next bump. But if the developer thinks they will have time and > have motivation to work on it in the future, I think we should leave it at just > deprecation plus disabling building the encoder by default, until the issue is > brought up again at say, after the next version bump. > After all, CELT started out more than 10 years before Opus was standardized, > and its EC code has made it all the way to AV2 despite its core remaining > visibly similar over the years. And FFv1 was used as an inspiration for FLIC, > which went on to become JPEG-XL. Sure, but there was active interest in all of these. I see no active interest in Sonic. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-03-01 20:33 ` Anton Khirnov @ 2024-03-01 21:34 ` Lynne 2024-03-02 13:33 ` Vittorio Giovara 0 siblings, 1 reply; 26+ messages in thread From: Lynne @ 2024-03-01 21:34 UTC (permalink / raw) To: FFmpeg development discussions and patches Mar 1, 2024, 21:33 by anton@khirnov.net: > Quoting Lynne (2024-03-01 20:41:53) > >> Mar 1, 2024, 19:59 by anton@khirnov.net: >> >> > Quoting Lynne (2024-02-29 14:30:55) >> > >> >> We offer support for it. Someone must have used it. >> >> I'm sure there are less used game codecs we support than Sonic. >> >> >> > >> > [citation needed] >> > >> > Is there any evidence that it was used for anything other than >> > development and testing? That anyone has any actual samples in it they'd >> > like to play? >> > >> >> There's always the possibility that someone encoded samples years >> ago and deleted the originals. Same as with Snow. >> >> My only concern is that this sets a sensitive precedent to get rid of >> old codec code with low weight under unclear conditions. Where do >> we draw the line? >> SMPTE? ISO/IEC standardization? IETF? AOM? >> Having *a* spec (Sonic doesn't, but neither did FFv1 until a few years >> ago)? >> A single company pushing for it many years ago with no spec, >> like SpeedHQ, or the many niche lossless/intra-only codecs? >> >> Or simply having one single implementation in FFmpeg, and no spec at all, >> and having an experimental flag, and no activity for a very long amount of time? >> > > I'd draw the line somewhere around what I said above - some evidence > that it was used "seriously". > That is something I cannot agree with - it cuts off 70% of all codecs we support, and zeroes out any potential chance of any codecs being developed by us. >> If it's the last case, or simply being a one-off, I can agree with deprecating >> and remove it next bump. But if the developer thinks they will have time and >> have motivation to work on it in the future, I think we should leave it at just >> deprecation plus disabling building the encoder by default, until the issue is >> brought up again at say, after the next version bump. >> After all, CELT started out more than 10 years before Opus was standardized, >> and its EC code has made it all the way to AV2 despite its core remaining >> visibly similar over the years. And FFv1 was used as an inspiration for FLIC, >> which went on to become JPEG-XL. >> > > Sure, but there was active interest in all of these. I see no active > interest in Sonic. > No one had any interest in CELT for years until it was used in Mumble, or Speex initially, or FLIC, as it they were not competitive enough on its own, and Vorbis, or Opus for the first few years. The developer has said there's interest in continuing to work on it in the future. I don't see why we shouldn't give him a chance to work on it for a bit longer before we bring it up again for removal. It's a simple codec with no oddities like self-modifying assembly, codec to demuxer to codec avpriv interaction or special API user considerations. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-03-01 21:34 ` Lynne @ 2024-03-02 13:33 ` Vittorio Giovara 0 siblings, 0 replies; 26+ messages in thread From: Vittorio Giovara @ 2024-03-02 13:33 UTC (permalink / raw) To: FFmpeg development discussions and patches On Fri, Mar 1, 2024 at 10:34 PM Lynne <dev@lynne.ee> wrote: > >> If it's the last case, or simply being a one-off, I can agree with > deprecating > >> and remove it next bump. But if the developer thinks they will have > time and > >> have motivation to work on it in the future, I think we should leave it > at just > >> deprecation plus disabling building the encoder by default, until the > issue is > >> brought up again at say, after the next version bump. > >> After all, CELT started out more than 10 years before Opus was > standardized, > >> and its EC code has made it all the way to AV2 despite its core > remaining > >> visibly similar over the years. And FFv1 was used as an inspiration for > FLIC, > >> which went on to become JPEG-XL. > >> > > > > Sure, but there was active interest in all of these. I see no active > > interest in Sonic. > > > > No one had any interest in CELT for years until it was used in Mumble, > or Speex initially, or FLIC, as it they were not competitive enough on its > own, > and Vorbis, or Opus for the first few years. > There is nothing stopping developers to work on their own fork and release the codec when ready, or at least there is moderate interest The developer has said there's interest in continuing to work on it > in the future. > The developer expressed interest in literally everything in ffmpeg, there needs to be a threshold in what is reasonably expected to be worked on in a lifetime. I don't see why we shouldn't give him a chance to work on it for > a bit longer before we bring it up again for removal. > Because people had 10 years to work on it a bit longer and they didn't. Claiming interest only because there is an active removal process is not very healthy for the codebase (or the community). -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio 2024-02-28 12:56 ` [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio J. Dekker 2024-02-28 13:23 ` Andreas Rheinhardt 2024-02-28 13:29 ` Michael Niedermayer @ 2024-03-01 20:14 ` Tomas Härdin 2 siblings, 0 replies; 26+ messages in thread From: Tomas Härdin @ 2024-03-01 20:14 UTC (permalink / raw) To: FFmpeg development discussions and patches ons 2024-02-28 klockan 13:56 +0100 skrev J. Dekker: > This was an experimental/research codec of which ffmpeg is the only > encoder and decoder, development has stalled and these files don't > exist > in the wild. > > Signed-off-by: J. Dekker <jdek@itanimul.li> > --- > Changelog | 1 + > configure | 3 - > libavcodec/Makefile | 3 - > libavcodec/allcodecs.c | 3 - > libavcodec/codec_desc.c | 14 - > libavcodec/sonic.c | 1125 ------------------------------------- > -- > 6 files changed, 1 insertion(+), 1148 deletions(-) > delete mode 100644 libavcodec/sonic.c +1, modulo some technical points like not removing CodeIDs /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [FFmpeg-devel] [PATCH 1/2] MAINTAINERS: remove inactive developer 2024-02-28 12:56 [FFmpeg-devel] [PATCH 1/2] MAINTAINERS: remove inactive developer J. Dekker 2024-02-28 12:56 ` [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio J. Dekker @ 2024-02-28 14:38 ` Vittorio Giovara 1 sibling, 0 replies; 26+ messages in thread From: Vittorio Giovara @ 2024-02-28 14:38 UTC (permalink / raw) To: FFmpeg development discussions and patches On Wed, Feb 28, 2024 at 1:56 PM J. Dekker <jdek@itanimul.li> wrote: > Inactive since 2007. > > Signed-off-by: J. Dekker <jdek@itanimul.li> > --- > MAINTAINERS | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > lgtm -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2024-03-10 19:46 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-02-28 12:56 [FFmpeg-devel] [PATCH 1/2] MAINTAINERS: remove inactive developer J. Dekker 2024-02-28 12:56 ` [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio J. Dekker 2024-02-28 13:23 ` Andreas Rheinhardt 2024-02-28 13:29 ` Michael Niedermayer 2024-02-28 13:31 ` J. Dekker 2024-02-28 13:41 ` Nicolas George 2024-02-28 13:57 ` Vittorio Giovara 2024-02-28 14:08 ` J. Dekker 2024-02-28 17:55 ` James Almer 2024-02-28 18:36 ` Jean-Baptiste Kempf 2024-03-10 13:12 ` Alexander Strasser via ffmpeg-devel 2024-02-28 20:23 ` Rémi Denis-Courmont 2024-02-28 22:13 ` Lynne 2024-02-29 1:50 ` Vittorio Giovara 2024-02-29 13:30 ` Lynne 2024-02-29 14:44 ` Vittorio Giovara 2024-03-01 1:13 ` Michael Niedermayer 2024-03-10 19:45 ` Leo Izen 2024-03-01 18:59 ` Anton Khirnov 2024-03-01 19:03 ` Nicolas George 2024-03-01 19:41 ` Lynne 2024-03-01 20:33 ` Anton Khirnov 2024-03-01 21:34 ` Lynne 2024-03-02 13:33 ` Vittorio Giovara 2024-03-01 20:14 ` Tomas Härdin 2024-02-28 14:38 ` [FFmpeg-devel] [PATCH 1/2] MAINTAINERS: remove inactive developer Vittorio Giovara
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git