[FFmpeg-devel] [PATCH v3] avcodec/ffv1dec: Don't set ThreadFrame properties, fix race
Each FFV1 slice has its own SAR and picture structure encoded;
when a slice header was parsed, the relevant fields of a ThreadFrame's
AVFrame were directly set based upon the parsed values. This is
a data race in case slice threading is in use because of the concurrent
writes. In case of frame threading, it is also a data race because
the writes happen after ff_thread_finish_setup(), so that the reads
performed by ff_thread_ref_frame() are unsynchronized with the writes
performed when parsing the header.
This commit fixes these issues by not writing to the ThreadFrame at all;
instead the raw data is read into the each SliceContext first; after
decoding the current frame and creating the actual output frame these
values are compared to each other. If they are valid and coincide, the
derived value is written directly to the output frame, not to the
ThreadFrame, thereby avoiding data races; in case they are not valid
or inconsistent the most commonly used valid value is used instead.
This fixes most FFV1 FATE-tests completely when using slice threading;
the exceptions are fate-vsynth3-ffv1, vsynth3-ffv1-v3-yuv420p and
vsynth3-ffv1-v3-yuv422p10. (In these tests the partitioning into slices
does not honour chroma subsampling; as a result, chroma pixels at slice
borders get set by more than one thread without any synchronization.)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ffv1.h| 4 ++
libavcodec/ffv1dec.c | 130 ---
2 files changed, 114 insertions(+), 20 deletions(-)
diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
index ac80fa85ce..f640d5a710 100644
--- a/libavcodec/ffv1.h
+++ b/libavcodec/ffv1.h
@@ -91,6 +91,8 @@ typedef struct FFV1Context {
struct FFV1Context *fsrc;
AVFrame *cur;
+int picture_structure;
+AVRational sample_aspect_ratio;
int plane_count;
int ac; ///< 1=range coder <-> 0=golomb rice
int ac_byte_count; ///< number of bytes used for AC
coding
@@ -132,6 +134,8 @@ typedef struct FFV1Context {
int slice_coding_mode;
int slice_rct_by_coef;
int slice_rct_ry_coef;
+
+AVRational slice_sample_aspect_ratios[MAX_SLICES];
} FFV1Context;
int ff_ffv1_common_init(AVCodecContext *avctx);
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 201630167d..8a8ab90b2b 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -167,7 +167,7 @@ static int decode_slice_header(const FFV1Context *f,
FFV1Context *fs)
{
RangeCoder *c = >c;
uint8_t state[CONTEXT_SIZE];
-unsigned ps, i, context_count;
+unsigned i, context_count;
memset(state, 128, sizeof(state));
av_assert0(f->version > 2);
@@ -205,25 +205,17 @@ static int decode_slice_header(const FFV1Context *f,
FFV1Context *fs)
p->context_count = context_count;
}
-ps = get_symbol(c, state, 0);
-if (ps == 1) {
-f->cur->interlaced_frame = 1;
-f->cur->top_field_first = 1;
-} else if (ps == 2) {
-f->cur->interlaced_frame = 1;
-f->cur->top_field_first = 0;
-} else if (ps == 3) {
-f->cur->interlaced_frame = 0;
-}
-f->cur->sample_aspect_ratio.num = get_symbol(c, state, 0);
-f->cur->sample_aspect_ratio.den = get_symbol(c, state, 0);
-
-if (av_image_check_sar(f->width, f->height,
- f->cur->sample_aspect_ratio) < 0) {
+fs->picture_structure = get_symbol(c, state, 0);
+fs->sample_aspect_ratio.num = get_symbol(c, state, 0);
+fs->sample_aspect_ratio.den = get_symbol(c, state, 0);
+/* Num or den being zero means unknown for FFV1; our unknown is 0 / 1. */
+if (fs->sample_aspect_ratio.num == 0 || fs->sample_aspect_ratio.den == 0) {
+fs->sample_aspect_ratio = (AVRational) { 0, 1 };
+} else if (av_image_check_sar(f->width, f->height,
+ fs->sample_aspect_ratio) < 0) {
av_log(f->avctx, AV_LOG_WARNING, "ignoring invalid SAR: %u/%u\n",
- f->cur->sample_aspect_ratio.num,
- f->cur->sample_aspect_ratio.den);
-f->cur->sample_aspect_ratio = (AVRational){ 0, 1 };
+ fs->sample_aspect_ratio.num, fs->sample_aspect_ratio.den);
+fs->sample_aspect_ratio = (AVRational) { 0, 0 };
}
if (fs->version > 3) {
@@ -251,6 +243,9 @@ static int decode_slice(AVCodecContext *c, void *arg)
AVFrame * const p = f->cur;
int i, si;
+fs->picture_structure = 0;
+fs->sample_aspect_ratio = (AVRational){ 0, 0 };
+
for( si=0; fs != f->slice_context[si]; si ++)
;
@@ -831,6 +826,28 @@ static av_cold int decode_init(AVCodecContext *avctx)
return 0;
}
+/* Macro to simplify comparisons of the rational values we deal with here.
+ * get_symbol() ensures that these fit into 32bits, so that one can just
+ * compare them in 64bits; they are also actually unsigned, so cast to that.
+ * Notice that av_image_check_sar()
Re: [FFmpeg-devel] [PATCH 1/5] lavfi/graphdump: add plain listing output
Nicolas George:
> Signed-off-by: Nicolas George
> ---
> libavfilter/avfilter.h | 5 ++-
> libavfilter/graphdump.c | 79 +++--
> 2 files changed, 80 insertions(+), 4 deletions(-)
>
>
> Unchanged since last summer.
> The last patch is what this is needed for.
>
>
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index b105dc3159..b338766609 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -1153,7 +1153,10 @@ int avfilter_graph_queue_command(AVFilterGraph *graph,
> const char *target, const
> * Dump a graph into a human-readable string representation.
> *
> * @param graphthe graph to dump
> - * @param options formatting options; currently ignored
> + * @param options formatting options; can be NULL, empty
> + * or "f=aa" for clumsy ascii-art drawing,
> + * or "f=tech" for plain listing;
> + * other values silently ignored
> * @return a string, or NULL in case of memory allocation failure;
> * the string must be freed using av_free
> */
> diff --git a/libavfilter/graphdump.c b/libavfilter/graphdump.c
> index cf8914b558..80dbccc66a 100644
> --- a/libavfilter/graphdump.c
> +++ b/libavfilter/graphdump.c
> @@ -27,6 +27,9 @@
> #include "avfilter.h"
> #include "internal.h"
>
> +#define FORMAT_AA 0
> +#define FORMAT_TECH 1
> +
> static int print_link_prop(AVBPrint *buf, AVFilterLink *link)
> {
> const char *format;
> @@ -60,7 +63,51 @@ static int print_link_prop(AVBPrint *buf, AVFilterLink
> *link)
> return buf->len;
> }
>
> -static void avfilter_graph_dump_to_buf(AVBPrint *buf, AVFilterGraph *graph)
The name of avfilter_graph_dump_to_buf makes it seem as if this were a
public function due to its prefix. Given that you already change the
signature, you already change every occurence of
avfilter_graph_dump_to_buf. So could you also rename it to a name more
befitting of a static function?
> +static inline const char *fcname(const AVFilterContext *filter)
> +{
> +return filter->name ? filter->name : "";
> +}
> +
> +static void dump_tech(AVBPrint *buf, AVFilterGraph *graph)
> +{
> +unsigned i, j;
> +
> +for (i = 0; i < graph->nb_filters; i++) {
> +AVFilterContext *filter = graph->filters[i];
> +
> +if (i)
> +av_bprintf(buf, "\n");
> +av_bprintf(buf, "Filter: %s (%s)\n", fcname(filter),
> filter->filter->name);
> +
> +for (j = 0; j < filter->nb_inputs; j++) {
> +AVFilterPad *pad = >input_pads[j];
> +AVFilterLink *link = filter->inputs[j];
> +AVFilterPad *ppad = link->srcpad;
> +AVFilterContext *peer = link->src;
> +
> +av_bprintf(buf, " in %d: %s ← %s.%d:%s ",
> + j, pad->name,
> + fcname(peer), FF_OUTLINK_IDX(link), ppad->name);
> +print_link_prop(buf, link);
> +av_bprintf(buf, "\n");
> +}
> +
> +for (j = 0; j < filter->nb_outputs; j++) {
> +AVFilterPad *pad = >output_pads[j];
> +AVFilterLink *link = filter->outputs[j];
> +AVFilterPad *ppad = link->dstpad;
> +AVFilterContext *peer = link->dst;
> +
> +av_bprintf(buf, " out %d: %s → %s.%d:%s ",
> + j, pad->name,
> + fcname(peer), FF_INLINK_IDX(link), ppad->name);
> +print_link_prop(buf, link);
> +av_bprintf(buf, "\n");
> +}
> +}
> +}
> +
> +static void dump_ascii_art(AVBPrint *buf, AVFilterGraph *graph)
> {
> unsigned i, j, x, e;
>
> @@ -152,17 +199,43 @@ static void avfilter_graph_dump_to_buf(AVBPrint *buf,
> AVFilterGraph *graph)
> }
> }
>
> +static void avfilter_graph_dump_to_buf(AVBPrint *buf, AVFilterGraph *graph,
> const char *options)
> +{
> +unsigned format = FORMAT_AA;
> +
> +/* For a very long time, options was ignored.
> + Having a string for that task was a mistake, but it is not important.
> + It is not worth a proper parsing.
> + */
> +if (options && *options) {
> +if (!strcmp("f=aa", options)) {
> +format = FORMAT_AA;
> +} else if (!strcmp("f=tech", options)) {
> +format = FORMAT_TECH;
> +}
> +/* ignore other values */
> +}
> +switch (format) {
> +case FORMAT_AA:
> +dump_ascii_art(buf, graph);
> +break;
> +case FORMAT_TECH:
> +dump_tech(buf, graph);
> +break;
> +}
> +}
> +
> char *avfilter_graph_dump(AVFilterGraph *graph, const char *options)
> {
> AVBPrint buf;
> char *dump = NULL;
>
> av_bprint_init(, 0, AV_BPRINT_SIZE_COUNT_ONLY);
> -avfilter_graph_dump_to_buf(, graph);
> +avfilter_graph_dump_to_buf(, graph, options);
> dump = av_malloc(buf.len + 1);
> if (!dump)
> return NULL;
> av_bprint_init_for_buffer(, dump, buf.len + 1);
> -
Re: [FFmpeg-devel] [PATCH v2] avcodec/ffv1dec: Don't set ThreadFrame properties, fix race
On Thu, Mar 03, 2022 at 08:55:08AM +0100, Andreas Rheinhardt wrote:
> Each FFV1 slice has its own SAR and picture structure encoded;
> when a slice header was parsed, the relevant fields of a ThreadFrame's
> AVFrame were directly set based upon the parsed values. This is
> a data race in case slice threading is in use because of the concurrent
> writes. In case of frame threading, it is also a data race because
> the writes happen after ff_thread_finish_setup(), so that the reads
> performed by ff_thread_ref_frame() are unsynchronized with the writes
> performed when parsing the header.
>
> This commit fixes these issues by not writing to the ThreadFrame at all;
> instead the raw data is read into the each SliceContext first; after
> decoding the current frame and creating the actual output frame these
> values are compared to each other. If they are valid and coincide, the
> derived value is written directly to the output frame, not to the
> ThreadFrame, thereby avoiding data races; in case they are not valid
> or inconsistent the most commonly used valid value is used instead.
>
> This fixes most FFV1 FATE-tests completely when using slice threading;
> the exceptions are fate-vsynth3-ffv1, vsynth3-ffv1-v3-yuv420p and
> vsynth3-ffv1-v3-yuv422p10. (In these tests the partitioning into slices
> does not honour chroma subsampling; as a result, chroma pixels at slice
> borders get set by more than one thread without any synchronization.)
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/ffv1.h| 4 ++
> libavcodec/ffv1dec.c | 119 +++
> 2 files changed, 103 insertions(+), 20 deletions(-)
>
> diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
> index ac80fa85ce..f640d5a710 100644
> --- a/libavcodec/ffv1.h
> +++ b/libavcodec/ffv1.h
> @@ -91,6 +91,8 @@ typedef struct FFV1Context {
> struct FFV1Context *fsrc;
>
> AVFrame *cur;
> +int picture_structure;
> +AVRational sample_aspect_ratio;
> int plane_count;
> int ac; ///< 1=range coder <-> 0=golomb rice
> int ac_byte_count; ///< number of bytes used for AC
> coding
> @@ -132,6 +134,8 @@ typedef struct FFV1Context {
> int slice_coding_mode;
> int slice_rct_by_coef;
> int slice_rct_ry_coef;
> +
> +AVRational slice_sample_aspect_ratios[MAX_SLICES];
> } FFV1Context;
>
> int ff_ffv1_common_init(AVCodecContext *avctx);
> diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
> index 201630167d..bda8a5a2f1 100644
> --- a/libavcodec/ffv1dec.c
> +++ b/libavcodec/ffv1dec.c
> @@ -167,7 +167,7 @@ static int decode_slice_header(const FFV1Context *f,
> FFV1Context *fs)
> {
> RangeCoder *c = >c;
> uint8_t state[CONTEXT_SIZE];
> -unsigned ps, i, context_count;
> +unsigned i, context_count;
> memset(state, 128, sizeof(state));
>
> av_assert0(f->version > 2);
> @@ -205,25 +205,17 @@ static int decode_slice_header(const FFV1Context *f,
> FFV1Context *fs)
> p->context_count = context_count;
> }
>
> -ps = get_symbol(c, state, 0);
> -if (ps == 1) {
> -f->cur->interlaced_frame = 1;
> -f->cur->top_field_first = 1;
> -} else if (ps == 2) {
> -f->cur->interlaced_frame = 1;
> -f->cur->top_field_first = 0;
> -} else if (ps == 3) {
> -f->cur->interlaced_frame = 0;
> -}
> -f->cur->sample_aspect_ratio.num = get_symbol(c, state, 0);
> -f->cur->sample_aspect_ratio.den = get_symbol(c, state, 0);
> -
> -if (av_image_check_sar(f->width, f->height,
> - f->cur->sample_aspect_ratio) < 0) {
> +fs->picture_structure = get_symbol(c, state, 0);
> +fs->sample_aspect_ratio.num = get_symbol(c, state, 0);
> +fs->sample_aspect_ratio.den = get_symbol(c, state, 0);
> +/* Num or den being zero means unknown for FFV1; our unknown is 0 / 1. */
0/0 is unknown in FFV1, 0/1 and 1/0 are treated as unknown because thats
the only reasonable thing one really could do if they are encountered
> +if (fs->sample_aspect_ratio.num == 0 || fs->sample_aspect_ratio.den ==
> 0) {
> +fs->sample_aspect_ratio = (AVRational) { 0, 1 };
> +} else if (av_image_check_sar(f->width, f->height,
> + fs->sample_aspect_ratio) < 0) {
> av_log(f->avctx, AV_LOG_WARNING, "ignoring invalid SAR: %u/%u\n",
> - f->cur->sample_aspect_ratio.num,
> - f->cur->sample_aspect_ratio.den);
> -f->cur->sample_aspect_ratio = (AVRational){ 0, 1 };
> + fs->sample_aspect_ratio.num, fs->sample_aspect_ratio.den);
> +fs->sample_aspect_ratio = (AVRational) { 0, 0 };
> }
>
> if (fs->version > 3) {
> @@ -251,6 +243,9 @@ static int decode_slice(AVCodecContext *c, void *arg)
> AVFrame * const p = f->cur;
> int i, si;
>
> +fs->picture_structure = 0;
> +fs->sample_aspect_ratio = (AVRational){ 0, 0
[FFmpeg-devel] [PATCH] avformat/mov: Add support for still image AVIF parsing
Add support for parsing AVIF still images. This patches supports
AVIF still images that have exactly 1 item (i.e.) no alpha channel.
Essentially, we will have to parse the "iloc" box and populate
the mov index.
With this patch, we can decode still AVIF images like so:
ffmpeg -i image.avif image.png
Partially fixes trac ticket #7621
Signed-off-by: Vignesh Venkatasubramanian
---
libavformat/isom.h | 1 +
libavformat/mov.c | 142 +
2 files changed, 143 insertions(+)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 625dea8421..cc0a8e1ca9 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -306,6 +306,7 @@ typedef struct MOVContext {
int have_read_mfra_size;
uint32_t mfra_size;
uint32_t max_stts_delta;
+int is_still_picture_avif;
} MOVContext;
int ff_mp4_read_descr_len(AVIOContext *pb);
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 68b6d7f075..d260024e47 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1126,6 +1126,7 @@ static int mov_read_ftyp(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
c->isom = 1;
av_log(c->fc, AV_LOG_DEBUG, "ISO: File Type Major Brand: %.4s\n",(char
*));
av_dict_set(>fc->metadata, "major_brand", type, 0);
+c->is_still_picture_avif = !strncmp(type, "avif", 4);
minor_ver = avio_rb32(pb); /* minor version */
av_dict_set_int(>fc->metadata, "minor_version", minor_ver, 0);
@@ -7173,6 +7174,146 @@ cleanup:
return ret;
}
+static int rb_size(AVIOContext *pb, uint64_t* value, int size)
+{
+if (size == 0) {
+*value = 0;
+} else if (size == 1) {
+*value = avio_r8(pb);
+} else if (size == 2) {
+*value = avio_rb16(pb);
+} else if (size == 4) {
+*value = avio_rb32(pb);
+} else if (size == 8) {
+*value = avio_rb64(pb);
+} else {
+return -1;
+}
+return size;
+}
+
+static int mov_read_iloc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+int version, offset_size, length_size, base_offset_size, index_size;
+int item_count, extent_count;
+uint64_t base_offset, extent_offset, extent_length;
+int i, j;
+uint8_t value;
+AVStream *st;
+MOVStreamContext *sc;
+
+if (!c->is_still_picture_avif) {
+// * For non-avif, we simply ignore the iloc box.
+// * For animated avif, we don't care about the iloc box as all the
+// necessary information can be found in the moov box.
+return 0;
+}
+
+if (c->fc->nb_streams != 0) {
+av_log(c->fc, AV_LOG_INFO, "Duplicate iloc box found\n");
+return 0;
+}
+
+st = avformat_new_stream(c->fc, NULL);
+if (!st) return AVERROR(ENOMEM);
+st->id = c->fc->nb_streams;
+sc = av_mallocz(sizeof(MOVStreamContext));
+if (!sc) return AVERROR(ENOMEM);
+
+st->priv_data = sc;
+st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
+st->codecpar->codec_id = AV_CODEC_ID_AV1;
+sc->ffindex = st->index;
+c->trak_index = st->index;
+st->avg_frame_rate.num = st->avg_frame_rate.den = 1;
+st->time_base.num = st->time_base.den = 1;
+st->nb_frames = 1;
+sc->time_scale = 1;
+sc = st->priv_data;
+sc->pb = c->fc->pb;
+sc->pb_is_copied = 1;
+
+version = avio_r8(pb);
+avio_rb24(pb); // flags.
+
+value = avio_r8(pb);
+offset_size = (value >> 4) & 0xF;
+length_size = value & 0xF;
+value = avio_r8(pb);
+base_offset_size = (value >> 4) & 0xF;
+index_size = (version == 0) ? 0 : (value & 0xF);
+if (index_size != 0) {
+return AVERROR_PATCHWELCOME;
+}
+item_count = (version < 2) ? avio_rb16(pb) : avio_rb32(pb);
+if (item_count > 1) {
+// For still AVIF images, we only support one item. Second item will
+// generally be found for AVIF images with alpha channel. We don't
+// support them as of now.
+return AVERROR_PATCHWELCOME;
+}
+
+// Populate the necessary fields used by mov_build_index.
+sc->stsc_count = item_count;
+sc->stsc_data = av_malloc_array(item_count, sizeof(*sc->stsc_data));
+if (!sc->stsc_data) {
+return AVERROR(ENOMEM);
+}
+sc->stsc_data[0].first = 1;
+sc->stsc_data[0].count = 1;
+sc->stsc_data[0].id = 1;
+sc->chunk_count = item_count;
+sc->chunk_offsets = av_malloc_array(item_count,
sizeof(*sc->chunk_offsets));
+if (!sc->chunk_offsets) {
+return AVERROR(ENOMEM);
+}
+sc->sample_count = item_count;
+sc->sample_sizes = av_malloc_array(item_count, sizeof(*sc->sample_sizes));
+if (!sc->sample_sizes) {
+return AVERROR(ENOMEM);
+}
+sc->stts_count = item_count;
+sc->stts_data = av_malloc_array(item_count, sizeof(*sc->stts_data));
+if (!sc->stts_data) {
+return AVERROR(ENOMEM);
+}
+sc->stts_data[0].count = 1;
+sc->stts_data[0].duration = 0; // Not used for still images. But needed
by mov_build_index.
+
+for (i =
Re: [FFmpeg-devel] [PATCH] avfilter/split: switch to activate()
On 3/3/22, Nicolas George wrote: > Paul B Mahol (12022-03-01): >> Signed-off-by: Paul B Mahol >> --- >> >> Fix possible hangs if (a)split filter is used in graph and one of outputs >> ends >> earlier than others. >> Then filter may never receive EOF from input provided by (a)split filter. >> >> See ticket #9152 for commands how to reproduce issue. > > I am trying to reproduce the issue, and I notice it hangs with sine.mp3 > but not with sine.wav (my build did not have a MP3 encoder), and I find > it very strange, even with the current code. Please let me look into it > closer; but if you have an idea about why MP3 input behaves different > than WAV please let me know. It is caused by number of sample per frame. I tested actually with -f lavfi -i sine only. And patch resolves issue. ___ 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 3/3] avformat/movenc: Add support for AVIF muxing
On Thu, Mar 3, 2022 at 11:46 AM James Almer wrote:
>
>
>
> On 3/3/2022 4:20 PM, Vignesh Venkatasubramanian wrote:
> > On Thu, Mar 3, 2022 at 7:36 AM James Almer wrote:
> >>
> >> On 2/22/2022 6:43 PM, Vignesh Venkatasubramanian wrote:
> >>> Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
> >>>
> >>> AVIF Specifiation: https://aomediacodec.github.io/av1-avif
> >>>
> >>> Sample usage for still image:
> >>> ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
> >>>
> >>> Sample usage for animated AVIF image:
> >>> ffmpeg -i video.mp4 animated.avif
> >>>
> >>> We can re-use any of the AV1 encoding options that will make
> >>> sense for image encoding (like bitrate, tiles, encoding speed,
> >>> etc).
> >>>
> >>> The files generated by this muxer has been verified to be valid
> >>> AVIF files by the following:
> >>> 1) Displays on Chrome (both still and animated images).
> >>> 2) Displays on Firefox (only still images, firefox does not support
> >>> animated AVIF yet).
> >>> 3) Verfied to be valid by Compliance Warden:
> >>> https://github.com/gpac/ComplianceWarden
> >>>
> >>> Fixes the encoder/muxer part of Trac Ticket #7621
> >>>
> >>> Signed-off-by: Vignesh Venkatasubramanian
> >>> ---
> >>>configure| 1 +
> >>>libavformat/allformats.c | 1 +
> >>>libavformat/movenc.c | 300 +++
> >>>libavformat/movenc.h | 5 +
> >>>4 files changed, 282 insertions(+), 25 deletions(-)
> >>
> >> With a single frame i get no errors in that compliance tool, but when i
> >> encode an animated AVIF i get the following:
> >>
> >> [heif][Rule #12] Error: CodingConstraintsBox ('ccst') shall be present once
> >> [heif][Rule #28] Error: Wrong arity for boxes { ccst } in parents { avc1
> >> avc2 avc3 avc4 hev1 hev2 hvc1 hvc2 av01 }: expected in range [1-1], found 0
> >> [heif][Rule #31] Error: 'msf1' brand: this file shall conform to HEIF
> >> (section 7.2)
> >> [heif][Rule #31] Error: 'msf1' brand: 'iso8' shall be present among the
> >> compatible brands array
> >> [heif][Rule #32] Error: 'mif1' brand: this file shall conform to HEIF
> >> section 6, check the other errors for details
> >> [heif][Rule #33] Error: 'msf1' brand: this file shall conform to HEIF
> >> section 7, check the other errors for details
> >>
> >> All but one of these should be solved by writing a ccst box after the
> >> av1C box in the sample entry. The missing one should be solved by
> >> writing the iso8 compatible brand.
> >>
> >> The ccst box looks like it would need some bitstream information, so
> >> either you parse the packets to get it, or just hardcode sane defaults,
> >> considering it's used as a hint and it's not required for demuxing.
> >
> > I recently fixed these errors in libavif [1][2] (the reference AVIF
> > encoder). I was hoping to have a follow-up patch since i already
> > uploaded the existing patches. Since you have pointed this out now, i
> > have included the fix in this patch itself. The new patch will now
> > write the iso8 compatible brand and the ccst box with sane default
> > values. The file produced is now identical to the file produced by
> > libavif in terms of box structure.
> >
> > Also, notice that the compliance tool still shows the following error
> > for animated avif:
> >
> > [avif][Rule #3] Warning: [ItemId=1] still_picture flag set to 0
> > [avif][Rule #4] Warning: [ItemId=1] reduced_still_picture_header flag set
> > to 0
> >
> > I believe these are incorrect since it does not make sense to set
> > these flag to 0 for animated avif sequences. These warnings also show
> > up with files produced by libavif. So it is okay to ignore them. I
> > will file an issue with the compliance tool separately.
>
> The compliance tool uses the 1.0.0 revision of the spec, and what you
> mentioned was removed in the current unfinished draft:
> https://github.com/AOMediaCodec/av1-avif/pull/112
>
> I assume the tool will be updated once a new revision is released, so
> yes, we can ignore them.
>
> >
> > Please take another look, thanks!
>
> I noticed that using -still-picture 1 and passing more than one frame to
> the libaom encoder will succeed, despite you setting enccfg.g_limit to
> 1, and encode every frame as key frames.
> I'd expect the encoder would error out if you try to feed it more
> frames. Is it a libaom bug?
>
Hmm yeah it seems like libaom only uses the value to set the
still-picture sequence header values in 1-pass mode. I think in a way
it may be useful for us to be able to use AVIF output with the image2
muxer. For example, something like:
ffmpeg -i video.mp4 -still-picture 1 -c:v libaom-av1 -an -f image2
image-%02d.avif
This command does not work as of now, but I have some follow-up
patches to make the image2 muxer work with AVIF images.
> >
> > [1] https://github.com/AOMediaCodec/libavif/pull/855
> > [2] https://github.com/AOMediaCodec/libavif/pull/856
> >> ___
Re: [FFmpeg-devel] Too many project ideas in GSOC 2022 FFmpeg
On 3/1/22, Michael Koch wrote: >> We have 0 project ideas on our gsoc 2022 page >> well we have 2 now as i copied my two from last year >> If you have an idea, please add it! > > Might it be possible to integrate LibRaw into FFmpeg? > https://www.libraw.org/ > > This could also solve the problem that import of DNG images doesn't work in > FFmpeg. Importing works fine, and mpv displays correct colors. > > Michael > > ___ > 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".
Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing
On 3/3/2022 4:20 PM, Vignesh Venkatasubramanian wrote:
On Thu, Mar 3, 2022 at 7:36 AM James Almer wrote:
On 2/22/2022 6:43 PM, Vignesh Venkatasubramanian wrote:
Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
AVIF Specifiation: https://aomediacodec.github.io/av1-avif
Sample usage for still image:
ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
Sample usage for animated AVIF image:
ffmpeg -i video.mp4 animated.avif
We can re-use any of the AV1 encoding options that will make
sense for image encoding (like bitrate, tiles, encoding speed,
etc).
The files generated by this muxer has been verified to be valid
AVIF files by the following:
1) Displays on Chrome (both still and animated images).
2) Displays on Firefox (only still images, firefox does not support
animated AVIF yet).
3) Verfied to be valid by Compliance Warden:
https://github.com/gpac/ComplianceWarden
Fixes the encoder/muxer part of Trac Ticket #7621
Signed-off-by: Vignesh Venkatasubramanian
---
configure| 1 +
libavformat/allformats.c | 1 +
libavformat/movenc.c | 300 +++
libavformat/movenc.h | 5 +
4 files changed, 282 insertions(+), 25 deletions(-)
With a single frame i get no errors in that compliance tool, but when i
encode an animated AVIF i get the following:
[heif][Rule #12] Error: CodingConstraintsBox ('ccst') shall be present once
[heif][Rule #28] Error: Wrong arity for boxes { ccst } in parents { avc1
avc2 avc3 avc4 hev1 hev2 hvc1 hvc2 av01 }: expected in range [1-1], found 0
[heif][Rule #31] Error: 'msf1' brand: this file shall conform to HEIF
(section 7.2)
[heif][Rule #31] Error: 'msf1' brand: 'iso8' shall be present among the
compatible brands array
[heif][Rule #32] Error: 'mif1' brand: this file shall conform to HEIF
section 6, check the other errors for details
[heif][Rule #33] Error: 'msf1' brand: this file shall conform to HEIF
section 7, check the other errors for details
All but one of these should be solved by writing a ccst box after the
av1C box in the sample entry. The missing one should be solved by
writing the iso8 compatible brand.
The ccst box looks like it would need some bitstream information, so
either you parse the packets to get it, or just hardcode sane defaults,
considering it's used as a hint and it's not required for demuxing.
I recently fixed these errors in libavif [1][2] (the reference AVIF
encoder). I was hoping to have a follow-up patch since i already
uploaded the existing patches. Since you have pointed this out now, i
have included the fix in this patch itself. The new patch will now
write the iso8 compatible brand and the ccst box with sane default
values. The file produced is now identical to the file produced by
libavif in terms of box structure.
Also, notice that the compliance tool still shows the following error
for animated avif:
[avif][Rule #3] Warning: [ItemId=1] still_picture flag set to 0
[avif][Rule #4] Warning: [ItemId=1] reduced_still_picture_header flag set to 0
I believe these are incorrect since it does not make sense to set
these flag to 0 for animated avif sequences. These warnings also show
up with files produced by libavif. So it is okay to ignore them. I
will file an issue with the compliance tool separately.
The compliance tool uses the 1.0.0 revision of the spec, and what you
mentioned was removed in the current unfinished draft:
https://github.com/AOMediaCodec/av1-avif/pull/112
I assume the tool will be updated once a new revision is released, so
yes, we can ignore them.
Please take another look, thanks!
I noticed that using -still-picture 1 and passing more than one frame to
the libaom encoder will succeed, despite you setting enccfg.g_limit to
1, and encode every frame as key frames.
I'd expect the encoder would error out if you try to feed it more
frames. Is it a libaom bug?
[1] https://github.com/AOMediaCodec/libavif/pull/855
[2] https://github.com/AOMediaCodec/libavif/pull/856
___
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".
Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing
On Thu, Mar 3, 2022 at 7:36 AM James Almer wrote:
>
> On 2/22/2022 6:43 PM, Vignesh Venkatasubramanian wrote:
> > Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
> >
> > AVIF Specifiation: https://aomediacodec.github.io/av1-avif
> >
> > Sample usage for still image:
> > ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
> >
> > Sample usage for animated AVIF image:
> > ffmpeg -i video.mp4 animated.avif
> >
> > We can re-use any of the AV1 encoding options that will make
> > sense for image encoding (like bitrate, tiles, encoding speed,
> > etc).
> >
> > The files generated by this muxer has been verified to be valid
> > AVIF files by the following:
> > 1) Displays on Chrome (both still and animated images).
> > 2) Displays on Firefox (only still images, firefox does not support
> > animated AVIF yet).
> > 3) Verfied to be valid by Compliance Warden:
> > https://github.com/gpac/ComplianceWarden
> >
> > Fixes the encoder/muxer part of Trac Ticket #7621
> >
> > Signed-off-by: Vignesh Venkatasubramanian
> > ---
> > configure| 1 +
> > libavformat/allformats.c | 1 +
> > libavformat/movenc.c | 300 +++
> > libavformat/movenc.h | 5 +
> > 4 files changed, 282 insertions(+), 25 deletions(-)
>
> With a single frame i get no errors in that compliance tool, but when i
> encode an animated AVIF i get the following:
>
> [heif][Rule #12] Error: CodingConstraintsBox ('ccst') shall be present once
> [heif][Rule #28] Error: Wrong arity for boxes { ccst } in parents { avc1
> avc2 avc3 avc4 hev1 hev2 hvc1 hvc2 av01 }: expected in range [1-1], found 0
> [heif][Rule #31] Error: 'msf1' brand: this file shall conform to HEIF
> (section 7.2)
> [heif][Rule #31] Error: 'msf1' brand: 'iso8' shall be present among the
> compatible brands array
> [heif][Rule #32] Error: 'mif1' brand: this file shall conform to HEIF
> section 6, check the other errors for details
> [heif][Rule #33] Error: 'msf1' brand: this file shall conform to HEIF
> section 7, check the other errors for details
>
> All but one of these should be solved by writing a ccst box after the
> av1C box in the sample entry. The missing one should be solved by
> writing the iso8 compatible brand.
>
> The ccst box looks like it would need some bitstream information, so
> either you parse the packets to get it, or just hardcode sane defaults,
> considering it's used as a hint and it's not required for demuxing.
I recently fixed these errors in libavif [1][2] (the reference AVIF
encoder). I was hoping to have a follow-up patch since i already
uploaded the existing patches. Since you have pointed this out now, i
have included the fix in this patch itself. The new patch will now
write the iso8 compatible brand and the ccst box with sane default
values. The file produced is now identical to the file produced by
libavif in terms of box structure.
Also, notice that the compliance tool still shows the following error
for animated avif:
[avif][Rule #3] Warning: [ItemId=1] still_picture flag set to 0
[avif][Rule #4] Warning: [ItemId=1] reduced_still_picture_header flag set to 0
I believe these are incorrect since it does not make sense to set
these flag to 0 for animated avif sequences. These warnings also show
up with files produced by libavif. So it is okay to ignore them. I
will file an issue with the compliance tool separately.
Please take another look, thanks!
[1] https://github.com/AOMediaCodec/libavif/pull/855
[2] https://github.com/AOMediaCodec/libavif/pull/856
> ___
> 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".
--
Vignesh
___
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 3/3] avformat/movenc: Add support for AVIF muxing
Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
AVIF Specifiation: https://aomediacodec.github.io/av1-avif
Sample usage for still image:
ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
Sample usage for animated AVIF image:
ffmpeg -i video.mp4 animated.avif
We can re-use any of the AV1 encoding options that will make
sense for image encoding (like bitrate, tiles, encoding speed,
etc).
The files generated by this muxer has been verified to be valid
AVIF files by the following:
1) Displays on Chrome (both still and animated images).
2) Displays on Firefox (only still images, firefox does not support
animated AVIF yet).
3) Verfied to be valid by Compliance Warden:
https://github.com/gpac/ComplianceWarden
Fixes the encoder/muxer part of Trac Ticket #7621
Signed-off-by: Vignesh Venkatasubramanian
---
configure| 1 +
libavformat/allformats.c | 1 +
libavformat/movenc.c | 323 ---
libavformat/movenc.h | 5 +
4 files changed, 305 insertions(+), 25 deletions(-)
diff --git a/configure b/configure
index 8c69ab0c86..6d7020e96b 100755
--- a/configure
+++ b/configure
@@ -3390,6 +3390,7 @@ asf_stream_muxer_select="asf_muxer"
av1_demuxer_select="av1_frame_merge_bsf av1_parser"
avi_demuxer_select="riffdec exif"
avi_muxer_select="riffenc"
+avif_muxer_select="mov_muxer"
caf_demuxer_select="iso_media"
caf_muxer_select="iso_media"
dash_muxer_select="mp4_muxer"
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index d066a7745b..400c17afbd 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -81,6 +81,7 @@ extern const AVOutputFormat ff_au_muxer;
extern const AVInputFormat ff_av1_demuxer;
extern const AVInputFormat ff_avi_demuxer;
extern const AVOutputFormat ff_avi_muxer;
+extern const AVOutputFormat ff_avif_muxer;
extern const AVInputFormat ff_avisynth_demuxer;
extern const AVOutputFormat ff_avm2_muxer;
extern const AVInputFormat ff_avr_demuxer;
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 1a746a67fd..504403ab0b 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1303,7 +1303,7 @@ static int mov_write_av1c_tag(AVIOContext *pb, MOVTrack
*track)
avio_wb32(pb, 0);
ffio_wfourcc(pb, "av1C");
-ff_isom_write_av1c(pb, track->vos_data, track->vos_len, 1);
+ff_isom_write_av1c(pb, track->vos_data, track->vos_len, track->mode !=
MODE_AVIF);
return update_size(pb, pos);
}
@@ -2004,12 +2004,13 @@ static int mov_write_colr_tag(AVIOContext *pb, MOVTrack
*track, int prefer_icc)
}
}
-/* We should only ever be called by MOV or MP4. */
-av_assert0(track->mode == MODE_MOV || track->mode == MODE_MP4);
+/* We should only ever be called for MOV, MP4 and AVIF. */
+av_assert0(track->mode == MODE_MOV || track->mode == MODE_MP4 ||
+ track->mode == MODE_AVIF);
avio_wb32(pb, 0); /* size */
ffio_wfourcc(pb, "colr");
-if (track->mode == MODE_MP4)
+if (track->mode == MODE_MP4 || track->mode == MODE_AVIF)
ffio_wfourcc(pb, "nclx");
else
ffio_wfourcc(pb, "nclc");
@@ -2019,7 +2020,7 @@ static int mov_write_colr_tag(AVIOContext *pb, MOVTrack
*track, int prefer_icc)
avio_wb16(pb, track->par->color_primaries);
avio_wb16(pb, track->par->color_trc);
avio_wb16(pb, track->par->color_space);
-if (track->mode == MODE_MP4) {
+if (track->mode == MODE_MP4 || track->mode == MODE_AVIF) {
int full_range = track->par->color_range == AVCOL_RANGE_JPEG;
avio_w8(pb, full_range << 7);
}
@@ -2085,7 +2086,7 @@ static void find_compressor(char * compressor_name, int
len, MOVTrack *track)
|| (track->par->width == 1440 && track->par->height == 1080)
|| (track->par->width == 1920 && track->par->height == 1080);
-if (track->mode == MODE_MOV &&
+if ((track->mode == MODE_AVIF || track->mode == MODE_MOV) &&
(encoder = av_dict_get(track->st->metadata, "encoder", NULL, 0))) {
av_strlcpy(compressor_name, encoder->value, 32);
} else if (track->par->codec_id == AV_CODEC_ID_MPEG2VIDEO && xdcam_res) {
@@ -2106,6 +2107,25 @@ static void find_compressor(char * compressor_name, int
len, MOVTrack *track)
}
}
+static int mov_write_ccst_tag(AVIOContext *pb)
+{
+int64_t pos = avio_tell(pb);
+// Write sane defaults:
+// all_ref_pics_intra = 0 : all samples can use any type of reference.
+// intra_pred_used = 1 : intra prediction may or may not be used.
+// max_ref_per_pic = 15 : reserved value to indicate that any number of
+//reference images can be used.
+uint8_t ccstValue = (0 << 7) | /* all_ref_pics_intra */
+(1 << 6) | /* intra_pred_used */
+(15 << 2); /* max_ref_per_pic */
+avio_wb32(pb, 0); /* size */
+ffio_wfourcc(pb, "ccst");
+avio_wb32(pb, 0); /* Version &
Re: [FFmpeg-devel] [PATCH 5/5] tests: add coverage for libavfilter's format negotiation
James Almer (12022-03-03): > No need to add a fate-libavfilter-negotiation target until there are more > such tests. Thanks for the review. I know these targets are not necessary, but I want them. I do intend to write more tests: >> This is not to be the only test, I intend to cover all the logic in >> pick_format() and the logic in swap_*(). And having submodule-specific fate targets is convenient even if there are only one test. Please read the code assuming there are several tests, including tests using aresample rather than scale. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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 5/5] tests: add coverage for libavfilter's format negotiation
On 3/2/2022 3:40 PM, Nicolas George wrote: diff --git a/tests/fate/libavfilter.mak b/tests/fate/libavfilter.mak new file mode 100644 index 00..692f1d4960 --- /dev/null +++ b/tests/fate/libavfilter.mak @@ -0,0 +1,9 @@ +# avfiltergraph.c : pick_format() : video / don't lose alpha +FATE_LIBAVFILTER_NEGOTIATION_VIDEO += fate-libavfilter-negotiation-alpha +fate-libavfilter-negotiation-alpha: CMD = lavfi_dump testsrc2=d=0,format=rgba,scale,format=yuv444p/yuva444p + +FATE_LIBAVFILTER-$(call ALLYES, TESTSRC2_FILTER FORMAT_FILTER SCALE_FILTER) += $(FATE_LIBAVFILTER_NEGOTIATION_VIDEO) + +fate-libavfilter: $(FATE_LIBAVFILTER) $(FATE_LIBAVFILTER-yes) +fate-libavfilter-negotiation: $(FATE_LIBAVFILTER_NEGOTIATION) $(FATE_LIBAVFILTER_NEGOTIATION-yes) +FATE_FFMPEG += $(FATE_LIBAVFILTER-yes) This can be simplified as such: # avfiltergraph.c : pick_format() : video / don't lose alpha FATE_LIBAVFILTER-$(call ALLYES, TESTSRC2_FILTER FORMAT_FILTER SCALE_FILTER) += fate-libavfilter-negotiation-alpha fate-libavfilter-negotiation-alpha: CMD = lavfi_dump testsrc2=d=0,format=rgba,scale,format=yuv444p/yuva444p fate-libavfilter: $(FATE_LIBAVFILTER-yes) FATE_FFMPEG += $(FATE_LIBAVFILTER-yes) No need to add a fate-libavfilter-negotiation target until there are more such tests. ___ 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] avfilter/split: switch to activate()
Paul B Mahol (12022-03-01): > Signed-off-by: Paul B Mahol > --- > > Fix possible hangs if (a)split filter is used in graph and one of outputs ends > earlier than others. > Then filter may never receive EOF from input provided by (a)split filter. > > See ticket #9152 for commands how to reproduce issue. I am trying to reproduce the issue, and I notice it hangs with sine.mp3 but not with sine.wav (my build did not have a MP3 encoder), and I find it very strange, even with the current code. Please let me look into it closer; but if you have an idea about why MP3 input behaves different than WAV please let me know. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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 5/5] tests: add coverage for libavfilter's format negotiation
On 3/2/22, Nicolas George wrote:
> Signed-off-by: Nicolas George
> ---
> tests/Makefile | 1 +
> tests/fate-run.sh| 4
> tests/fate/libavfilter.mak | 9 +
> tests/ref/fate/libavfilter-negotiation-alpha | 20
> 4 files changed, 34 insertions(+)
> create mode 100644 tests/fate/libavfilter.mak
> create mode 100644 tests/ref/fate/libavfilter-negotiation-alpha
>
>
> This is not to be the only test, I intend to cover all the logic in
> pick_format() and the logic in swap_*().
>
> But I would rather have you have a quick look at the makefile hackery
> before writing too many tests that would need changing.
>
>
> diff --git a/tests/Makefile b/tests/Makefile
> index c4c31ae871..2bff4b339d 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -157,6 +157,7 @@ include $(SRC_PATH)/tests/fate/imf.mak
> include $(SRC_PATH)/tests/fate/indeo.mak
> include $(SRC_PATH)/tests/fate/libavcodec.mak
> include $(SRC_PATH)/tests/fate/libavdevice.mak
> +include $(SRC_PATH)/tests/fate/libavfilter.mak
> include $(SRC_PATH)/tests/fate/libavformat.mak
> include $(SRC_PATH)/tests/fate/libavutil.mak
> include $(SRC_PATH)/tests/fate/libswresample.mak
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index fbfc0a925d..82d40f5ebc 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -509,6 +509,10 @@ venc_data(){
> run tools/venc_data_dump${EXECSUF} ${file} ${stream} ${frames}
> ${threads} ${thread_type}
> }
>
> +lavfi_dump(){
> +run ffmpeg${PROGSUF}${EXECSUF} -lavfi_dump -lavfi "$@" -f null -
> +}
> +
> null(){
> :
> }
> diff --git a/tests/fate/libavfilter.mak b/tests/fate/libavfilter.mak
> new file mode 100644
> index 00..692f1d4960
> --- /dev/null
> +++ b/tests/fate/libavfilter.mak
> @@ -0,0 +1,9 @@
> +# avfiltergraph.c : pick_format() : video / don't lose alpha
> +FATE_LIBAVFILTER_NEGOTIATION_VIDEO += fate-libavfilter-negotiation-alpha
> +fate-libavfilter-negotiation-alpha: CMD = lavfi_dump
> testsrc2=d=0,format=rgba,scale,format=yuv444p/yuva444p
> +
> +FATE_LIBAVFILTER-$(call ALLYES, TESTSRC2_FILTER FORMAT_FILTER SCALE_FILTER)
> += $(FATE_LIBAVFILTER_NEGOTIATION_VIDEO)
> +
> +fate-libavfilter: $(FATE_LIBAVFILTER) $(FATE_LIBAVFILTER-yes)
> +fate-libavfilter-negotiation: $(FATE_LIBAVFILTER_NEGOTIATION)
> $(FATE_LIBAVFILTER_NEGOTIATION-yes)
> +FATE_FFMPEG += $(FATE_LIBAVFILTER-yes)
> diff --git a/tests/ref/fate/libavfilter-negotiation-alpha
> b/tests/ref/fate/libavfilter-negotiation-alpha
> new file mode 100644
> index 00..00175f65cb
> --- /dev/null
> +++ b/tests/ref/fate/libavfilter-negotiation-alpha
> @@ -0,0 +1,20 @@
> +Dump of complex filter graph #0:
> +
> +Filter: Parsed_testsrc2_0 (testsrc2)
> + out 0: default → Parsed_format_1.0:default [320x240 1:1 rgba]
> +
> +Filter: Parsed_format_1 (format)
> + in 0: default ← Parsed_testsrc2_0.0:default [320x240 1:1 rgba]
> + out 0: default → Parsed_scale_2.0:default [320x240 1:1 rgba]
> +
> +Filter: Parsed_scale_2 (scale)
> + in 0: default ← Parsed_format_1.0:default [320x240 1:1 rgba]
> + out 0: default → Parsed_format_3.0:default [320x240 1:1 yuva444p]
> +
> +Filter: Parsed_format_3 (format)
> + in 0: default ← Parsed_scale_2.0:default [320x240 1:1 yuva444p]
> + out 0: default → out_0_0.0:default [320x240 1:1 yuva444p]
> +
> +Filter: out_0_0 (buffersink)
> + in 0: default ← Parsed_format_3.0:default [320x240 1:1 yuva444p]
> +
> --
> 2.34.1
>
Changes in this set seems logical and useful.
___
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] avcodec/ac3dec: Check expacc
On 11/3/16, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/ac3dec.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
> index a95c204..499971a 100644
> --- a/libavcodec/ac3dec.c
> +++ b/libavcodec/ac3dec.c
> @@ -426,6 +426,10 @@ static int decode_exponents(AC3DecodeContext *s,
> group_size = exp_strategy + (exp_strategy == EXP_D45);
> for (grp = 0, i = 0; grp < ngrps; grp++) {
> expacc = get_bits(gbc, 7);
> +if (expacc >= 125) {
> +av_log(s->avctx, AV_LOG_ERROR, "expacc %d is out-of-range\n",
> expacc);
> +return AVERROR_INVALIDDATA;
> +}
> dexp[i++] = ungroup_3_in_7_bits_tab[expacc][0];
> dexp[i++] = ungroup_3_in_7_bits_tab[expacc][1];
> dexp[i++] = ungroup_3_in_7_bits_tab[expacc][2];
> --
Please revert this ASAP. It breaks decoding valid files.
___
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] avfilter: add aspectraldn audio filter
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/af_aspectraldn.c | 440 +++
libavfilter/allfilters.c | 1 +
3 files changed, 442 insertions(+)
create mode 100644 libavfilter/af_aspectraldn.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 9f0e5de532..35e7977741 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -96,6 +96,7 @@ OBJS-$(CONFIG_ASETTB_FILTER) += settb.o
OBJS-$(CONFIG_ASHOWINFO_FILTER) += af_ashowinfo.o
OBJS-$(CONFIG_ASIDEDATA_FILTER) += f_sidedata.o
OBJS-$(CONFIG_ASOFTCLIP_FILTER) += af_asoftclip.o
+OBJS-$(CONFIG_ASPECTRALDN_FILTER)+= af_aspectraldn.o
OBJS-$(CONFIG_ASPECTRALSTATS_FILTER) += af_aspectralstats.o
OBJS-$(CONFIG_ASPLIT_FILTER) += split.o
OBJS-$(CONFIG_ASR_FILTER)+= af_asr.o
diff --git a/libavfilter/af_aspectraldn.c b/libavfilter/af_aspectraldn.c
new file mode 100644
index 00..0a9c98deb6
--- /dev/null
+++ b/libavfilter/af_aspectraldn.c
@@ -0,0 +1,440 @@
+/*
+ * Copyright (c) 2022 The FFmpeg Project
+ *
+ * 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
+
+#include "libavutil/avstring.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
+#include "libavutil/tx.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "formats.h"
+#include "filters.h"
+#include "window_func.h"
+
+enum OutModes {
+IN_MODE,
+OUT_MODE,
+NOISE_MODE,
+NB_MODES
+};
+
+typedef struct AudioSpectralDenoiseContext
+{
+const AVClass *class;
+
+float std_thresh;
+float reduction;
+float overlap;
+float smooth_freq;
+int stationary;
+int fft_factor;
+int fft_size;
+int win_size;
+int win_func;
+int output_mode;
+int sample_advance;
+
+AVFrame *fft_in;
+AVFrame *fft_out;
+AVFrame *sig_db;
+AVFrame *sig_mask;
+AVFrame *temp;
+AVFrame *winframe;
+
+AVTXContext **fft, **ifft;
+av_tx_fn tx_fn, itx_fn;
+
+float *window;
+float smooth_freq_a[3];
+float smooth_freq_b[3];
+
+int channels;
+} AudioSpectralDenoiseContext;
+
+#define OFFSET(x) offsetof(AudioSpectralDenoiseContext, x)
+#define AF AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+#define AFR
AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_RUNTIME_PARAM
+
+static const AVOption aspectraldn_options[] = {
+{ "stdthr", "set the standard threshold", OFFSET(std_thresh),
AV_OPT_TYPE_FLOAT, {.dbl = 0.0}, -1, 30, AFR },
+{ "reduction", "set the noise reduction", OFFSET(reduction),
AV_OPT_TYPE_FLOAT, {.dbl = 0.9}, 0, 1, AFR },
+{ "smoothf", "set the freq smooth for mask",OFFSET(smooth_freq),
AV_OPT_TYPE_FLOAT, {.dbl = 0.01}, 0, 1, AF },
+{ "stationary", "use stationary reduction", OFFSET(stationary),
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, AFR },
+{ "fft_factor", "set the fft factor", OFFSET(fft_factor),
AV_OPT_TYPE_INT,{.i64 = 1}, 1, 8, AF },
+{ "win_size", "set the window size",OFFSET(win_size),
AV_OPT_TYPE_INT,{.i64 = 2048},128,8192,AF },
+WIN_FUNC_OPTION("win_func", OFFSET(win_func), AF,
WFUNC_HANNING),
+{ "overlap", "set the window overlap", OFFSET(overlap),
AV_OPT_TYPE_FLOAT, {.dbl = .75}, 0, 1, AF },
+{ "output", "set the output mode", OFFSET(output_mode),
AV_OPT_TYPE_INT,{.i64 = OUT_MODE}, 0, NB_MODES-1, AFR, "mode" },
+{ "input", "input",0,
AV_OPT_TYPE_CONST, {.i64 = IN_MODE}, 0, 0, AFR, "mode" },
+{ "i", "input",0,
AV_OPT_TYPE_CONST, {.i64 = IN_MODE}, 0, 0, AFR, "mode" },
+{ "output", "output", 0,
AV_OPT_TYPE_CONST, {.i64 = OUT_MODE}, 0, 0, AFR, "mode" },
+{ "o", "output", 0,
AV_OPT_TYPE_CONST, {.i64 = OUT_MODE}, 0, 0, AFR, "mode" },
+{ "noise", "noise",0,
AV_OPT_TYPE_CONST, {.i64 = NOISE_MODE},0, 0, AFR, "mode" },
+{ "n", "noise",
Re: [FFmpeg-devel] [PATCH] avfilter/framepool: remove superfluous pallete buffer allocation
On 3/3/22, James Almer wrote:
> av_image_fill_plane_sizes() already sets sizes[1] to AVPALETTE_SIZE.
> Should fix memory leaks.
ok
>
> Signed-off-by: James Almer
> ---
> Sorry for not noticing this before.
>
> libavfilter/framepool.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/libavfilter/framepool.c b/libavfilter/framepool.c
> index 96bfe46319..1990902666 100644
> --- a/libavfilter/framepool.c
> +++ b/libavfilter/framepool.c
> @@ -56,13 +56,9 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
> (*alloc)(size_t size),
> {
> int i, ret;
> FFFramePool *pool;
> -const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(format);
> ptrdiff_t linesizes[4];
> size_t sizes[4];
>
> -if (!desc)
> -return NULL;
> -
> pool = av_mallocz(sizeof(FFFramePool));
> if (!pool)
> return NULL;
> @@ -108,12 +104,6 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
> (*alloc)(size_t size),
> goto fail;
> }
>
> -if (desc->flags & AV_PIX_FMT_FLAG_PAL) {
> -pool->pools[1] = av_buffer_pool_init(AVPALETTE_SIZE, alloc);
> -if (!pool->pools[1])
> -goto fail;
> -}
> -
> return pool;
>
> fail:
> --
> 2.35.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".
>
___
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] avfilter/framepool: remove superfluous pallete buffer allocation
av_image_fill_plane_sizes() already sets sizes[1] to AVPALETTE_SIZE.
Should fix memory leaks.
Signed-off-by: James Almer
---
Sorry for not noticing this before.
libavfilter/framepool.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/libavfilter/framepool.c b/libavfilter/framepool.c
index 96bfe46319..1990902666 100644
--- a/libavfilter/framepool.c
+++ b/libavfilter/framepool.c
@@ -56,13 +56,9 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
(*alloc)(size_t size),
{
int i, ret;
FFFramePool *pool;
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(format);
ptrdiff_t linesizes[4];
size_t sizes[4];
-if (!desc)
-return NULL;
-
pool = av_mallocz(sizeof(FFFramePool));
if (!pool)
return NULL;
@@ -108,12 +104,6 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
(*alloc)(size_t size),
goto fail;
}
-if (desc->flags & AV_PIX_FMT_FLAG_PAL) {
-pool->pools[1] = av_buffer_pool_init(AVPALETTE_SIZE, alloc);
-if (!pool->pools[1])
-goto fail;
-}
-
return pool;
fail:
--
2.35.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] avfilter/framepool: use av_image_fill_plane_sizes() to calculate pool sizes
On 3/3/2022 1:46 PM, Paul B Mahol wrote:
On 3/3/22, James Almer wrote:
On 3/3/2022 10:56 AM, Paul B Mahol wrote:
On 3/3/22, James Almer wrote:
On 3/1/2022 11:23 AM, James Almer wrote:
Signed-off-by: James Almer
---
libavfilter/framepool.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavfilter/framepool.c b/libavfilter/framepool.c
index 5b510c9af9..cf6a1d0ea0 100644
--- a/libavfilter/framepool.c
+++ b/libavfilter/framepool.c
@@ -57,6 +57,8 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
(*alloc)(size_t size),
int i, ret;
FFFramePool *pool;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(format);
+ptrdiff_t linesizes[4];
+size_t sizes[4];
if (!desc)
return NULL;
@@ -89,13 +91,19 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
(*alloc)(size_t size),
}
}
-for (i = 0; i < 4 && pool->linesize[i]; i++) {
-int h = pool->height;
-if (i == 1 || i == 2)
-h = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
+for (i = 0; i < 4; i++)
+linesizes[i] = pool->linesize[i];
-pool->pools[i] = av_buffer_pool_init(pool->linesize[i] * h +
align,
- alloc);
+if (av_image_fill_plane_sizes(sizes, pool->format,
+ FFALIGN(pool->height, align),
+ linesizes) < 0) {
+goto fail;
+}
+
+for (i = 0; i < 4 && sizes[i]; i++) {
+if (sizes[i] > SIZE_MAX - align)
+goto fail;
+pool->pools[i] = av_buffer_pool_init(sizes[i] + align, alloc);
if (!pool->pools[i])
goto fail;
}
Ping. I can also remove the height padding if preferred.
It does not work. No?
It doesn't fix the mpeg encoder issue with yuv422p streams and 64 stride
alignment, no, but it's not strictly about that either. It's a
simplification using existing helpers.
Ok, if you need it.
Applied without the vertical padding, to not change the behavior your
introduced in 17a59a634c.
___
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] avfilter/framepool: use av_image_fill_plane_sizes() to calculate pool sizes
On 3/3/22, James Almer wrote:
>
>
> On 3/3/2022 10:56 AM, Paul B Mahol wrote:
>> On 3/3/22, James Almer wrote:
>>>
>>>
>>> On 3/1/2022 11:23 AM, James Almer wrote:
Signed-off-by: James Almer
---
libavfilter/framepool.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavfilter/framepool.c b/libavfilter/framepool.c
index 5b510c9af9..cf6a1d0ea0 100644
--- a/libavfilter/framepool.c
+++ b/libavfilter/framepool.c
@@ -57,6 +57,8 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
(*alloc)(size_t size),
int i, ret;
FFFramePool *pool;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(format);
+ptrdiff_t linesizes[4];
+size_t sizes[4];
if (!desc)
return NULL;
@@ -89,13 +91,19 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
(*alloc)(size_t size),
}
}
-for (i = 0; i < 4 && pool->linesize[i]; i++) {
-int h = pool->height;
-if (i == 1 || i == 2)
-h = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
+for (i = 0; i < 4; i++)
+linesizes[i] = pool->linesize[i];
-pool->pools[i] = av_buffer_pool_init(pool->linesize[i] * h +
align,
- alloc);
+if (av_image_fill_plane_sizes(sizes, pool->format,
+ FFALIGN(pool->height, align),
+ linesizes) < 0) {
+goto fail;
+}
+
+for (i = 0; i < 4 && sizes[i]; i++) {
+if (sizes[i] > SIZE_MAX - align)
+goto fail;
+pool->pools[i] = av_buffer_pool_init(sizes[i] + align, alloc);
if (!pool->pools[i])
goto fail;
}
>>>
>>> Ping. I can also remove the height padding if preferred.
>>
>> It does not work. No?
>
> It doesn't fix the mpeg encoder issue with yuv422p streams and 64 stride
> alignment, no, but it's not strictly about that either. It's a
> simplification using existing helpers.
Ok, if you need it.
>
>>
>>> ___
>>> 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 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 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.cTimo
Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: Add support for AVIF muxing
On 2/22/2022 6:43 PM, Vignesh Venkatasubramanian wrote:
Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
AVIF Specifiation: https://aomediacodec.github.io/av1-avif
Sample usage for still image:
ffmpeg -i image.png -c:v libaom-av1 -avif-image 1 image.avif
Sample usage for animated AVIF image:
ffmpeg -i video.mp4 animated.avif
We can re-use any of the AV1 encoding options that will make
sense for image encoding (like bitrate, tiles, encoding speed,
etc).
The files generated by this muxer has been verified to be valid
AVIF files by the following:
1) Displays on Chrome (both still and animated images).
2) Displays on Firefox (only still images, firefox does not support
animated AVIF yet).
3) Verfied to be valid by Compliance Warden:
https://github.com/gpac/ComplianceWarden
Fixes the encoder/muxer part of Trac Ticket #7621
Signed-off-by: Vignesh Venkatasubramanian
---
configure| 1 +
libavformat/allformats.c | 1 +
libavformat/movenc.c | 300 +++
libavformat/movenc.h | 5 +
4 files changed, 282 insertions(+), 25 deletions(-)
With a single frame i get no errors in that compliance tool, but when i
encode an animated AVIF i get the following:
[heif][Rule #12] Error: CodingConstraintsBox ('ccst') shall be present once
[heif][Rule #28] Error: Wrong arity for boxes { ccst } in parents { avc1
avc2 avc3 avc4 hev1 hev2 hvc1 hvc2 av01 }: expected in range [1-1], found 0
[heif][Rule #31] Error: 'msf1' brand: this file shall conform to HEIF
(section 7.2)
[heif][Rule #31] Error: 'msf1' brand: 'iso8' shall be present among the
compatible brands array
[heif][Rule #32] Error: 'mif1' brand: this file shall conform to HEIF
section 6, check the other errors for details
[heif][Rule #33] Error: 'msf1' brand: this file shall conform to HEIF
section 7, check the other errors for details
All but one of these should be solved by writing a ccst box after the
av1C box in the sample entry. The missing one should be solved by
writing the iso8 compatible brand.
The ccst box looks like it would need some bitstream information, so
either you parse the packets to get it, or just hardcode sane defaults,
considering it's used as a hint and it's not required for demuxing.
___
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 v8 1/1] avformat: Add IPFS protocol support.
On Tue, Mar 1, 2022 at 11:01 PM Michael Niedermayer wrote: > On Mon, Feb 28, 2022 at 02:09:15PM +0100, Tomas Härdin wrote: > > sön 2022-02-27 klockan 15:29 +0100 skrev Mark Gaiser: > > > Ping 2 > > > > > > I'd really like to get this merged! > > > This kinda blocks me right now from proceeding with IPFS integration > > > in > > > Kodi, MPV and VLC. Implementations in those (who rely on ffmpeg) are > > > significantly easier once this patch is finally landed in ffmpeg. > > > > I'd like to hear at least one other dev chime in on this one > > what exactly are you not sure about ? > what exactly needs a 2nd look ? > My assumption. In general just a second look by someone other than Tomas. And, as he was skeptical about this patch at first, likely another opinion if this makes sense to add in ffmpeg. To me it does very much but i'm biased :) In an effort to get this patch done, I'm adding the people to the CC that have commented on the earlier versions (v0, 1 and 2) of this patch. @Michael or Thomas, if no reply is here in the next 2 days, could this be merged? As I assume no reply after this much pinging and raising awareness means an implicit OK. > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The real ebay dictionary, page 1 > "Used only once"- "Some unspecified defect prevented a second use" > "In good condition" - "Can be repaird by experienced expert" > "As is" - "You wouldnt want it even if you were payed for it, if you knew > ..." > ___ > 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".
Re: [FFmpeg-devel] [RFC v2] avdevice: lock to minor version of avformat
Diederick C. Niehorster: > Hi Andreas, > > On Mon, Jan 3, 2022 at 12:03 PM Diederick C. Niehorster > wrote: > >> Hi Andreas, >> >> Thanks for the comments! >> >> On Mon, Jan 3, 2022 at 11:02 AM Andreas Rheinhardt >> wrote: >>> >>> Diederick Niehorster: As per discussion on the list ( https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281513.html, see especially >> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281586.html), to resolve the the unholy ABI-relationship between libavdevice and libavformat and allow easier working on the part of the avdevice API that lives in avformat, lock avdevice to a specific major and minor version of avformat. Signed-off-by: Diederick Niehorster --- >>> >>> 1. If this patch intends to make it illegal to use libavdevice together >>> with libavformat with a different minor version than it was compiled >>> against, then the most basic requirement of this is to actually properly >>> document it and not add stuff that might cause linking failure if used >>> in a way that runs afoul of your undocumented new requirements. >> >> Absolutely, documentation is required. Should that be in (amongst >> local to the function in the header)? >> > > I want to prepare a next version to get this discussion going. Where should > i document that it is illegal to use libavdevice together with libavformat > with a different minor version? > The versioning documentation starting on line 47 in /libavutil/avutil.h? > That would be the best place for it if one wanted to to lock all the library versions together; but you only want to do it for lavf<->lavd. Then the proper place would be in some avdevice header (naturally version.h, but who reads that header?) with references in avutil.h as well as some avformat header (naturally version.h, but who reads that). - 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".
Re: [FFmpeg-devel] [PATCH] avfilter/framepool: use av_image_fill_plane_sizes() to calculate pool sizes
On 3/3/2022 10:56 AM, Paul B Mahol wrote:
On 3/3/22, James Almer wrote:
On 3/1/2022 11:23 AM, James Almer wrote:
Signed-off-by: James Almer
---
libavfilter/framepool.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavfilter/framepool.c b/libavfilter/framepool.c
index 5b510c9af9..cf6a1d0ea0 100644
--- a/libavfilter/framepool.c
+++ b/libavfilter/framepool.c
@@ -57,6 +57,8 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
(*alloc)(size_t size),
int i, ret;
FFFramePool *pool;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(format);
+ptrdiff_t linesizes[4];
+size_t sizes[4];
if (!desc)
return NULL;
@@ -89,13 +91,19 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
(*alloc)(size_t size),
}
}
-for (i = 0; i < 4 && pool->linesize[i]; i++) {
-int h = pool->height;
-if (i == 1 || i == 2)
-h = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
+for (i = 0; i < 4; i++)
+linesizes[i] = pool->linesize[i];
-pool->pools[i] = av_buffer_pool_init(pool->linesize[i] * h +
align,
- alloc);
+if (av_image_fill_plane_sizes(sizes, pool->format,
+ FFALIGN(pool->height, align),
+ linesizes) < 0) {
+goto fail;
+}
+
+for (i = 0; i < 4 && sizes[i]; i++) {
+if (sizes[i] > SIZE_MAX - align)
+goto fail;
+pool->pools[i] = av_buffer_pool_init(sizes[i] + align, alloc);
if (!pool->pools[i])
goto fail;
}
Ping. I can also remove the height padding if preferred.
It does not work. No?
It doesn't fix the mpeg encoder issue with yuv422p streams and 64 stride
alignment, no, but it's not strictly about that either. It's a
simplification using existing helpers.
___
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 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] avfilter/framepool: use av_image_fill_plane_sizes() to calculate pool sizes
On 3/3/22, James Almer wrote:
>
>
> On 3/1/2022 11:23 AM, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavfilter/framepool.c | 20 ++--
>> 1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/libavfilter/framepool.c b/libavfilter/framepool.c
>> index 5b510c9af9..cf6a1d0ea0 100644
>> --- a/libavfilter/framepool.c
>> +++ b/libavfilter/framepool.c
>> @@ -57,6 +57,8 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
>> (*alloc)(size_t size),
>> int i, ret;
>> FFFramePool *pool;
>> const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(format);
>> +ptrdiff_t linesizes[4];
>> +size_t sizes[4];
>>
>> if (!desc)
>> return NULL;
>> @@ -89,13 +91,19 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
>> (*alloc)(size_t size),
>> }
>> }
>>
>> -for (i = 0; i < 4 && pool->linesize[i]; i++) {
>> -int h = pool->height;
>> -if (i == 1 || i == 2)
>> -h = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
>> +for (i = 0; i < 4; i++)
>> +linesizes[i] = pool->linesize[i];
>>
>> -pool->pools[i] = av_buffer_pool_init(pool->linesize[i] * h +
>> align,
>> - alloc);
>> +if (av_image_fill_plane_sizes(sizes, pool->format,
>> + FFALIGN(pool->height, align),
>> + linesizes) < 0) {
>> +goto fail;
>> +}
>> +
>> +for (i = 0; i < 4 && sizes[i]; i++) {
>> +if (sizes[i] > SIZE_MAX - align)
>> +goto fail;
>> +pool->pools[i] = av_buffer_pool_init(sizes[i] + align, alloc);
>> if (!pool->pools[i])
>> goto fail;
>> }
>
> Ping. I can also remove the height padding if preferred.
It does not work. No?
> ___
> 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".
Re: [FFmpeg-devel] [PATCH] avfilter/framepool: use av_image_fill_plane_sizes() to calculate pool sizes
On 3/1/2022 11:23 AM, James Almer wrote:
Signed-off-by: James Almer
---
libavfilter/framepool.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavfilter/framepool.c b/libavfilter/framepool.c
index 5b510c9af9..cf6a1d0ea0 100644
--- a/libavfilter/framepool.c
+++ b/libavfilter/framepool.c
@@ -57,6 +57,8 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
(*alloc)(size_t size),
int i, ret;
FFFramePool *pool;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(format);
+ptrdiff_t linesizes[4];
+size_t sizes[4];
if (!desc)
return NULL;
@@ -89,13 +91,19 @@ FFFramePool *ff_frame_pool_video_init(AVBufferRef*
(*alloc)(size_t size),
}
}
-for (i = 0; i < 4 && pool->linesize[i]; i++) {
-int h = pool->height;
-if (i == 1 || i == 2)
-h = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
+for (i = 0; i < 4; i++)
+linesizes[i] = pool->linesize[i];
-pool->pools[i] = av_buffer_pool_init(pool->linesize[i] * h + align,
- alloc);
+if (av_image_fill_plane_sizes(sizes, pool->format,
+ FFALIGN(pool->height, align),
+ linesizes) < 0) {
+goto fail;
+}
+
+for (i = 0; i < 4 && sizes[i]; i++) {
+if (sizes[i] > SIZE_MAX - align)
+goto fail;
+pool->pools[i] = av_buffer_pool_init(sizes[i] + align, alloc);
if (!pool->pools[i])
goto fail;
}
Ping. I can also remove the height padding if preferred.
___
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] [FFmpeg-cvslog] avfilter/vf_tpad: if there is no frame to clone return early
On 2/28/22, Thierry Foucu wrote:
> On Sun, Feb 27, 2022 at 3:54 AM Paul B Mahol wrote:
>
>> On Fri, Feb 25, 2022 at 10:08 PM Thierry Foucu wrote:
>>
>> > On Thu, Feb 24, 2022 at 11:50 PM Paul B Mahol wrote:
>> >
>> > > On Thu, Feb 24, 2022 at 11:21 PM Thierry Foucu
>> wrote:
>> > >
>> > > > On Thu, Feb 24, 2022 at 2:19 PM Thierry Foucu
>> > wrote:
>> > > >
>> > > > >
>> > > > >
>> > > > > On Thu, Feb 24, 2022 at 1:50 PM Paul B Mahol
>> > wrote:
>> > > > >
>> > > > >> On Thu, Feb 24, 2022 at 10:36 PM Thierry Foucu
>> > > > >>
>> > > > wrote:
>> > > > >>
>> > > > >> > On Thu, Feb 24, 2022 at 1:28 PM Paul B Mahol
>> > > > >> >
>> > > > wrote:
>> > > > >> >
>> > > > >> > > On Thu, Feb 24, 2022 at 10:12 PM Thierry Foucu <
>> > tfo...@gmail.com>
>> > > > >> wrote:
>> > > > >> > >
>> > > > >> > > > On Thu, Feb 24, 2022 at 12:30 PM Paul B Mahol <
>> > g...@videolan.org
>> > > >
>> > > > >> > wrote:
>> > > > >> > > >
>> > > > >> > > > > ffmpeg | branch: master | Paul B Mahol
>> > > > >> > > > >
>> |
>> > > Thu
>> > > > >> Feb
>> > > > >> > 24
>> > > > >> > > > > 20:32:41 2022 +0100|
>> > > [3715f2f8643695940582ce040b7a052cccfb9db2]
>> > > > |
>> > > > >> > > > > committer: Paul B Mahol
>> > > > >> > > > >
>> > > > >> > > > > avfilter/vf_tpad: if there is no frame to clone return
>> early
>> > > > >> > > > >
>> > > > >> > > > > >
>> > > > >> > > > >
>> > > > >> > > >
>> > > > >> > >
>> > > > >> >
>> > > > >>
>> > > >
>> > >
>> >
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=3715f2f8643695940582ce040b7a052cccfb9db2
>> > > > >> > > > > ---
>> > > > >> > > > >
>> > > > >> > > > > libavfilter/vf_tpad.c | 5 +
>> > > > >> > > > > 1 file changed, 5 insertions(+)
>> > > > >> > > > >
>> > > > >> > > > > diff --git a/libavfilter/vf_tpad.c
>> > > > >> > > > > b/libavfilter/vf_tpad.c
>> > > > >> > > > > index e5acece1e4..120dbcb4d3 100644
>> > > > >> > > > > --- a/libavfilter/vf_tpad.c
>> > > > >> > > > > +++ b/libavfilter/vf_tpad.c
>> > > > >> > > > > @@ -148,6 +148,11 @@ static int activate(AVFilterContext
>> > *ctx)
>> > > > >> > > > >frame->data,
>> frame->linesize,
>> > > > >> > > > >0, 0, frame->width,
>> > > > frame->height);
>> > > > >> > > > > } else if (s->stop_mode == 1) {
>> > > > >> > > > > +if (!s->cache_stop) {
>> > > > >> > > > > +s->pad_stop = 0;
>> > > > >> > > > > +ff_outlink_set_status(outlink,
>> AVERROR_EOF,
>> > > > >> s->pts);
>> > > > >> > > > > +return 0;
>> > > > >> > > > > +}
>> > > > >> > > > > frame = av_frame_clone(s->cache_stop);
>> > > > >> > > > > if (!frame)
>> > > > >> > > > > return AVERROR(ENOMEM);
>> > > > >> > > > >
>> > > > >> > > > >
>> > > > >> > > > The problem with this solution is that the tpad will then
>> not
>> > do
>> > > > >> what
>> > > > >> > we
>> > > > >> > > > are expecting, which is padding video track, and the
>> > > > >> > > > output
>> > file
>> > > > >> will
>> > > > >> > not
>> > > > >> > > > have the desired duration.
>> > > > >> > > > Will it not be better to just output black frame (aka
>> > stop_mode
>> > > ==
>> > > > >> 0) ,
>> > > > >> > > > something like that?
>> > > > >> > > >
>> > > > >> > >
>> > > > >> > > I doubt that, clone is clone, there is no point in padding
>> > stream
>> > > > that
>> > > > >> > have
>> > > > >> > > no frames at all.
>> > > > >> > >
>> > > > >> > >
>> > > > >> > >
>> > > > >> > The sample I forwarded to JB has video frames. The problem was
>> > that
>> > > > >> there
>> > > > >> > was a re-init of the filter chain after a resolution change
>> > > > >> > and
>> > > after
>> > > > >> the
>> > > > >> > re-init, there were no frames but got frames before the
>> > > > >> > re-init.
>> > > > >> > I will understand for a media file which has NEVER received a
>> > video
>> > > > >> frame
>> > > > >> > and in this case, this is the correct solution.
>> > > > >> >
>> > > > >>
>> > > > >> Hmm, so you encode output with resolution change, why not use
>> scale
>> > > > filter
>> > > > >> as first filter and then no resolution ever change for rest of
>> > graph?
>> > > > >> Adding support for resolution changes to all filters is very
>> > > > >> time
>> > > > >> consuming
>> > > > >> task and I see no real benefit in doing that now.
>> > > > >>
>> > > > >
>> > > > > We do have the scale filter in front of the tpad filter. Here is
>> the
>> > > > > filter chain we are using
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> idet=1.04:1.5,yadif=0:-1:1,scale=+528:+864:flags=bicubic,setsar=1,fps=fps=16.601,tpad=stop_mode=clone:stop_duration=2808ms
>> > > > >
>> > > >
>> > >
>> > > Is this just increasing size instead of setting constant one?
>> > >
>> >
>> > Nope. It will just scale the video to 528x864
>> >
>>
>> Then why filter is still reinited then?
>> Looks like serious bug to me.
>>
>
> Here is the verbose log when running ffmpeg
Re: [FFmpeg-devel] [PATCH v5 1/2] libavcodec: Added DFPWM1a codec
On 3/3/22, Paul B Mahol wrote: > On 2/27/22, 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. >> >> 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 >> >> > > > Please move channel check to init. > Also check for possible overflows when multiplying with 8 the packet->size. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org
Re: [FFmpeg-devel] [PATCH v5 1/2] libavcodec: Added DFPWM1a codec
On 2/27/22, 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. > > 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 > > Please move channel check to init. ___ 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] libavfilter: vf_scale: Properly take in->color_range into account
On Thu, Mar 3, 2022 at 1:07 PM Martin Storsjö wrote: > While swscale can be reconfigured with sws_setColorspaceDetails, > the in/out ranges also need to be set before calling > sws_init_context, otherwise the initialization might choose > fastpaths that don't take the ranges into account. > > Therefore, look at in->color_range too, when deciding on whether > the scaler needs to be reconfigured. > > Add a new member variable for keeping track of this, for being > able to differentiate between whether the scale filter parameter > "in_range" has been set (which should override whatever the input > frame has set) or whether it has been configured based on the > latest frame (which should trigger reconfiguring the scaler if > the input frame ranges change). > > Signed-off-by: Martin Storsjö > --- > Tested by me to resolve https://trac.ffmpeg.org/ticket/9576. Thanks Martin! All the best, Dee ___ 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] libavfilter: vf_scale: Properly take in->color_range into account
While swscale can be reconfigured with sws_setColorspaceDetails,
the in/out ranges also need to be set before calling
sws_init_context, otherwise the initialization might choose
fastpaths that don't take the ranges into account.
Therefore, look at in->color_range too, when deciding on whether
the scaler needs to be reconfigured.
Add a new member variable for keeping track of this, for being
able to differentiate between whether the scale filter parameter
"in_range" has been set (which should override whatever the input
frame has set) or whether it has been configured based on the
latest frame (which should trigger reconfiguring the scaler if
the input frame ranges change).
Signed-off-by: Martin Storsjö
---
To test this (without risking running many conflicting swscale
filters in one filter pipeline), we'd need to be able to tag
the incoming raw yuv data with colorspace and range without setting
the in_color_matrix and in_range options on the scale filter.
When using the rawvideo demuxer, the pixel format is set via the
ffmpeg -pix_fmt option, but there's no corresponding option for
setting color matrix or range for it.
---
libavfilter/vf_scale.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 44f85cb019..996f7aaa5b 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -138,6 +138,7 @@ typedef struct ScaleContext {
char *out_color_matrix;
int in_range;
+int in_frame_range;
int out_range;
int out_h_chr_pos;
@@ -322,6 +323,8 @@ static av_cold int init_dict(AVFilterContext *ctx,
AVDictionary **opts)
scale->opts = *opts;
*opts = NULL;
+scale->in_frame_range = AVCOL_RANGE_UNSPECIFIED;
+
return 0;
}
@@ -544,6 +547,9 @@ static int config_props(AVFilterLink *outlink)
if (scale->in_range != AVCOL_RANGE_UNSPECIFIED)
av_opt_set_int(s, "src_range",
scale->in_range == AVCOL_RANGE_JPEG, 0);
+else if (scale->in_frame_range != AVCOL_RANGE_UNSPECIFIED)
+av_opt_set_int(s, "src_range",
+ scale->in_frame_range == AVCOL_RANGE_JPEG, 0);
if (scale->out_range != AVCOL_RANGE_UNSPECIFIED)
av_opt_set_int(s, "dst_range",
scale->out_range == AVCOL_RANGE_JPEG, 0);
@@ -690,6 +696,13 @@ static int scale_frame(AVFilterLink *link, AVFrame *in,
AVFrame **frame_out)
in->sample_aspect_ratio.den !=
link->sample_aspect_ratio.den ||
in->sample_aspect_ratio.num !=
link->sample_aspect_ratio.num;
+if (in->color_range != AVCOL_RANGE_UNSPECIFIED &&
+scale->in_range == AVCOL_RANGE_UNSPECIFIED &&
+in->color_range != scale->in_frame_range) {
+scale->in_frame_range = in->color_range;
+frame_changed = 1;
+}
+
if (scale->eval_mode == EVAL_MODE_FRAME || frame_changed) {
unsigned vars_w[VARS_NB] = { 0 }, vars_h[VARS_NB] = { 0 };
--
2.32.0 (Apple Git-132)
___
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] [RFC v2] avdevice: lock to minor version of avformat
Hi Andreas, On Mon, Jan 3, 2022 at 12:03 PM Diederick C. Niehorster wrote: > Hi Andreas, > > Thanks for the comments! > > On Mon, Jan 3, 2022 at 11:02 AM Andreas Rheinhardt > wrote: > > > > Diederick Niehorster: > > > As per discussion on the list ( > > > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281513.html, see > > > especially > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281586.html), > > > to resolve the the unholy ABI-relationship between libavdevice and > > > libavformat and allow easier working on the part of the avdevice API > > > that lives in avformat, lock avdevice to a specific major and minor > > > version of avformat. > > > > > > Signed-off-by: Diederick Niehorster > > > --- > > > > 1. If this patch intends to make it illegal to use libavdevice together > > with libavformat with a different minor version than it was compiled > > against, then the most basic requirement of this is to actually properly > > document it and not add stuff that might cause linking failure if used > > in a way that runs afoul of your undocumented new requirements. > > Absolutely, documentation is required. Should that be in (amongst > local to the function in the header)? > I want to prepare a next version to get this discussion going. Where should i document that it is illegal to use libavdevice together with libavformat with a different minor version? The versioning documentation starting on line 47 in /libavutil/avutil.h? All the best, Dee ___ 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] avcodec/mpegvideo_enc: remove direct=1 support
On 3/2/22, Michael Niedermayer wrote:
> On Wed, Mar 02, 2022 at 08:11:18PM +0100, Paul B Mahol wrote:
>> On 3/2/22, Michael Niedermayer wrote:
>> > On Wed, Mar 02, 2022 at 12:38:05PM +0100, Paul B Mahol wrote:
>> >> It seems it does not work properly.
>> >>
>> >> Signed-off-by: Paul B Mahol
>> >> ---
>> >> libavcodec/mpegvideo_enc.c | 23 +++
>> >> 1 file changed, 3 insertions(+), 20 deletions(-)
>> >
>> > if iam not mistaken, that requires the whole image to be copied
>> > one extra time
>> > i think before doing that it should be understood
>> > where the problem is
>> > and why that is the better solution to fixing it and not doing
>> > that extra copy
>> >
>> > of course i may be missing something
>> >
>>
>> Yea, If you manage to trigger that path, I'm all ears.
>
> thats a fair request
>
> i tried
> --- a/libavcodec/mpegvideo_enc.c
> +++ b/libavcodec/mpegvideo_enc.c
> @@ -1065,6 +1065,7 @@ static int load_input_picture(MpegEncContext *s, const
> AVFrame *pic_arg)
> pic->reference = 3;
>
> if (direct) {
> +av_log(0,0, "direct mode\n");
> if ((ret = av_frame_ref(pic->f, pic_arg)) < 0)
> return ret;
> }
>
> with
> ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -t 1 test.avi
>
> and that gives me:
> direct mode
> Last message repeated 23 times
>
> so it seems the code is used
Same happens if filtering is used?
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Observe your enemies, for they first find out your faults. -- Antisthenes
>
___
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".
