February 2024 - ffmpeg-devel - lists.ffmpeg.org

[PATCH 1/2] avformat/mov: rename avif fields to heif
by James Almer 13 Apr '24

13 Apr '24

They are no longer avif specific. Signed-off-by: James Almer <jamrial(a)gmail.com> --- libavformat/isom.h | 4 ++-- libavformat/mov.c | 28 ++++++++++++++-------------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/libavformat/isom.h b/libavformat/isom.h index b30b9da65e..90c4fb5530 100644 --- a/libavformat/isom.h +++ b/libavformat/isom.h @@ -325,8 +325,8 @@ typedef struct MOVContext { int item_id; int extent_length; int64_t extent_offset; - } *avif_info; - int avif_info_size; + } *heif_info; + int heif_info_size; int64_t hvcC_offset; int hvcC_size; int interleaved_read; diff --git a/libavformat/mov.c b/libavformat/mov.c index c6398d6d81..12e82c66a9 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -4916,15 +4916,15 @@ static int mov_read_custom(MOVContext *c, AVIOContext *pb, MOVAtom atom) return ret; } -static int avif_add_stream(MOVContext *c, int item_id) +static int heif_add_stream(MOVContext *c, int item_id) { MOVStreamContext *sc; AVStream *st; int item_index = -1; if (c->fc->nb_streams) return AVERROR_INVALIDDATA; - for (int i = 0; i < c->avif_info_size; i++) - if (c->avif_info[i].item_id == item_id) { + for (int i = 0; i < c->heif_info_size; i++) + if (c->heif_info[i].item_id == item_id) { item_index = i; break; } @@ -4987,8 +4987,8 @@ static int avif_add_stream(MOVContext *c, int item_id) sc->stts_data[0].count = 1; // Not used for still images. But needed by mov_build_index. sc->stts_data[0].duration = 0; - sc->sample_sizes[0] = c->avif_info[item_index].extent_length; - sc->chunk_offsets[0] = c->avif_info[item_index].extent_offset; + sc->sample_sizes[0] = c->heif_info[item_index].extent_length; + sc->chunk_offsets[0] = c->heif_info[item_index].extent_offset; mov_build_index(c, st); return 0; @@ -5013,7 +5013,7 @@ static int mov_read_meta(MOVContext *c, AVIOContext *pb, MOVAtom atom) if (c->is_still_picture_avif) { int ret; // Add a stream for the YUV planes (primary item). - if ((ret = avif_add_stream(c, c->primary_item_id)) < 0) + if ((ret = heif_add_stream(c, c->primary_item_id)) < 0) return ret; // For still AVIF images, the meta box contains all the // necessary information that would generally be provided by the @@ -7820,7 +7820,7 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb, MOVAtom atom) return 0; } - if (c->avif_info) { + if (c->heif_info) { av_log(c->fc, AV_LOG_INFO, "Duplicate iloc box found\n"); return 0; } @@ -7841,16 +7841,16 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb, MOVAtom atom) } item_count = (version < 2) ? avio_rb16(pb) : avio_rb32(pb); - c->avif_info = av_malloc_array(item_count, sizeof(*c->avif_info)); - if (!c->avif_info) + c->heif_info = av_malloc_array(item_count, sizeof(*c->heif_info)); + if (!c->heif_info) return AVERROR(ENOMEM); - c->avif_info_size = item_count; + c->heif_info_size = item_count; for (int i = 0; i < item_count; i++) { int item_id = (version < 2) ? avio_rb16(pb) : avio_rb32(pb); if (avio_feof(pb)) return AVERROR_INVALIDDATA; - c->avif_info[i].item_id = item_id; + c->heif_info[i].item_id = item_id; if (version > 0) avio_rb16(pb); // construction_method. @@ -7867,8 +7867,8 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb, MOVAtom atom) if (rb_size(pb, &extent_offset, offset_size) < 0 || rb_size(pb, &extent_length, length_size) < 0) return AVERROR_INVALIDDATA; - c->avif_info[i].extent_length = extent_length; - c->avif_info[i].extent_offset = base_offset + extent_offset; + c->heif_info[i].extent_length = extent_length; + c->heif_info[i].extent_offset = base_offset + extent_offset; } } @@ -8502,7 +8502,7 @@ static int mov_read_close(AVFormatContext *s) av_freep(&mov->aes_decrypt); av_freep(&mov->chapter_tracks); - av_freep(&mov->avif_info); + av_freep(&mov->heif_info); return 0; } -- 2.43.0

3 7

Sovereign Tech Fund
by Michael Niedermayer 12 Apr '24

12 Apr '24

Hi all We are offered to apply for a sponsorship of FFmpeg by the Sovereign Tech Fund (STF). Please read the following to get a better understanding what STF is about: (In short it is about maintenance and sustainability, not features) https://www.sovereigntechfund.de/programs/applications As some probably already know, Thilo has worked with STF to work out many details of this. SPI will handle the financials for FFmpeg. Everyone willing to benefit from this sponsorship must not be a US sanctioned entity or in a US sanctioned country. And must sign a contractor agreement and simplified SoW with SPI. "A SOW purpose is to protect the contracted from doing a work and not getting paid, and to protect the contractor from paying for a work which wasn't wanted" At this point, what we need is a list of Projects so we can submit an application to STF at or before 12th Feb. (at the 14th they have a meeting and will review our submission) What STF told us, they need ATM is: - A scope of work for the project to defined before hand for the upcoming review and eventually a contract. It doesn’t have to be tied to specific people. - The contract STF will sign with SPI will be a service agreement based on that SOW and milestones. Payment of invoices will be contingent and after delivery (aka performance) of agreed upon milestones. My suggestion is that we create a Trac WIKI page similar to the ideas page for GSoC. On that page everyone can add a project idea. The requirement is that 1. it must fit in the goals and mission and all of STF 2. it must be about FFmpeg (IIUC non coding tasks are ok) 3. it must have a developer willing to do the work and a monetary amount as well as a expected time frame. Of course these don't need to be added at the same time you can add an idea and someone else can add herself as person doing the work. But for consideration it needs to contain all parts 4. The developer doing the work must be qualified. An easy way to ensure this, is that (s)he has at least 100 authored commits in FFmpeg. According to STF, April 1st is a possible start date for the work and STF would also like to know if the work will be finished in 2024 or 2025 for their budget. the SoW can be for example: "do X by date Y to receive Z", but according to SPI it can also be "only tasks X are eligible, invoices should be sent by date Y, and payment will not exceed the budget Z" "Ideally, it should also mention the parameters for how much each thing done is worth — eg. If you're paying for hours or for tasks, and how much — as the SOW is supposed to give the contracted person means to know how much they'll be paid for what they do." "SOW should also note that if no valid tasks are performed, no payment will be made." Next step. For each Project suggestion from the wiki page we will send a mail to the ML with a copy and paste of the project suggestion. Once an apparent consensus is reached. This is the communities opportunity to object or approve the suggestion. Anyone can call for a formal vote of the GA here too if they do not want to object/approve in public. But i hope we can avoid that overhead. All suggested project ideas will then be submitted to STF We have never done STF before so there likely will be some surprises and we may need to adjust in case we hit any issues. and I also didn't expect to be involved in this but i don't want to stand around and have the opportunity for FFmpeg lost There can be no late objections here to any project suggestions. Objections must be before a project suggestion is submitted to STF, objections after that cannot be considered! Also once the person doing the work reaches the agreed milestone. She will submit an invoice with stefano and my help to SPI/STF. (in the unlikely case of a dispute on reaching a milestone it would be decided by the technical committee if the milestone has been reached from FFmpegs point of view) Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them.

16 122

FFmpeg TC input needed
by Gyan Doshi 12 Apr '24

12 Apr '24

Issue: Patch: avcodec/s302m: enable non-PCM decoding URL: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240127103854.9971-1-ffm… The issue needing resolution is whether the patch should be added to the existing s302m decoder or should that decoder be removed and all old and new patched features inlined into the mpeg-ts demuxer. Summary: SMPTE ST 302 specifies for carriage of LPCM media in MPEG-TS. SMPTE ST 337 enables this for non-PCM codecs. The payload has a custom layout so it can't be directly processed hence lavc/s302m decodes the packet data to yield LPCM media. But it can only deal at present with LPCM payloads, meaning that non-PCM payloads need to be exported to a raw bytestream format and then decoded in a 2nd step, which prohibits direct transcoding of live/streaming inputs. This patch corrects the identification process for non-PCM payloads, reformats the payload and then carries out in-place decoding by calling a nested decoder similar to the ftr or imm5 decoders in lavc. In the v1 patch review, Andreas, in response to the proposed doc entry describing the feature capability of multiple or differing payloads in a s302m stream, suggested[1] that s302m should be a bitstream filter instead, but I did not see that as an actionable suggestion as he immediately listed the bsf limitations preventing the possibility. I also had not seen an actual sample of s302m with multiple embedded streams. Kieran also observed[2] that he had not seen such a stream in the wild. So the added features of this patch, wherever they are ultimately located, shall not yield more than one media stream. Anton suggested[3] that the decoder should instead be a demuxer. I saw no other objections to the architecture of the patch. I posted the v2 patch, incorporating some changes suggested by Andreas, 4 days later. This had gone uncommented for over two weeks when I posted a notice stating an intention to push. Anton posted[4] a new objection that "If it dynamically generates nested decoders, then it's not a proper codec in our model". This new objection is not connected to multiple streams but only to a codec 'model' that I don't see described anywhere and which contradicts the implementations of multiple decoders with a nested decoder, including the ftr and imm5 decoders, which are most similar in design to the patched s302m decoder. Anton later on mentioned[5] that nested decoders are "a constant source of issues". However, I didn't find anything on trac reporting an issue with the nested decoders of ftr and imm5 nor anything on ffmpeg-devel-ml or ffmpeg-user-ml. Nothing in their commit history either points to architectural bugs. These decoders have been around for 6 years among themselves. The testing of the patched s302m decoder over the past month by myself, an OTT provider and others shows no issues either. Finally, Anton speculates[6] that the burden of fixes will likely fall upon him. In none of his objections, till the time of writing, did I see specific concerns with the patch. There are some limitations in shifting this decoder wholesale to inside the MPEG-TS demuxer. A s302m stream may contain some non-media payload accompanying non-PCM media i.e. S-ADM metadata. At present, I have neither the samples nor the specification needed in order to locate and extract or parse this metadata. Formatting the payload data inside the demuxer will lead to irrevocable loss of such metadata if present. However, a decoder patch allows simultaneuous output of both a decoded stream alongside a copied stream. The end-user can then do with the raw data whatever they wish. Ultimately, s302m is specified an an elementary stream inside a MPEG-TS container. Its internal handling is better left to a dedicated module like a decoder. A bitstream filter might be a better fit if s302m streams with multiple media payloads ever start appearing - none have, so far - but for single media payloads, a decoder remains the best place. Regards, Gyan [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320119.html [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320321.html [3]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320258.html [4]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321514.html [5]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321523.html [6]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321539.html

5 10

[PATCH v4 0/4] Fix some active sequences in subtitles
by Oneric 06 Apr '24

06 Apr '24

Changes from v3: - None. Just rebased ontop of master to allow Patchwork to properly process the series now that 99d33cc661fbd04e8657831 was merged. Changes from v2: - rebased ontop of the recently pushed eol normalisation. As a result no more CRLFs in here and Patchwork should be happy - added a fourth cosmetic commit adjusting explicit linebreaks to the new normalisation Changes from v1: - ff_ass_bprint_text_event now only inserts a word-joiner if there isn’t already one anyway - added a third commit improving the handling of curly brackets for standard ASS renderers Oneric (4): avcodec/webvttdec: honour bidi marks avcodec/{ass,webvttdec}: fix handling of backslashes avcodec/{ass,webvttdec}: more portable curly brace escapes avocdec/ass: simplify linebreaks libavcodec/ass.c | 47 +++++++++++++++++++++++--------------- libavcodec/webvttdec.c | 4 ++-- tests/ref/fate/sub-webvtt | 2 +- tests/ref/fate/sub-webvtt2 | 2 +- 4 files changed, 33 insertions(+), 22 deletions(-) -- 2.39.2

3 18

[PATCH 1/2] avcodec: add YUV color space metadata to AVCodec
by Niklas Haas 03 Apr '24

03 Apr '24

From: Niklas Haas <git(a)haasn.dev> This is motivated primarily by a desire for YUVJ removal, which will require signalling the supported color ranges as part of the codec capabilities. But since we're adding YUV range, we might as well add the YUV color matrix as well - since some codecs (e.g. VP8, JPEG) only support certain values. I decided to preserve the ambiguous and misleading "color_spaces" name, for symmetry with AVFrame.colorspace. (Though this would IMO be better called "color_matrix" or "color_system") I also decided to omit the other AVColor* fields for now, because vf_scale cannot handle auto-conversion between primaries/transfer/etc. There is little value in adding metadata we cannot do anything with, and no harm in extending the API again in the future. In theory, vf_scale can handle conversion between chroma locations, but also the signalling for this is annoying, so I'll defer it to a future commit. --- doc/APIchanges | 3 +++ libavcodec/codec.h | 6 ++++++ libavcodec/version.h | 2 +- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index 1f5724324a..7849ce47d9 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09 API changes, most recent first: +2024-02-xx - xxxxxxxxxx - lavc 60.40.100 - avcodec.h + Add AVCodec.color_ranges and AVCodec.color_spaces. + 2024-02-04 - xxxxxxxxxx - lavc 60.39.100 - packet.h Add AV_PKT_DATA_AMBIENT_VIEWING_ENVIRONMENT. diff --git a/libavcodec/codec.h b/libavcodec/codec.h index 8034f1a53c..8bd678de7a 100644 --- a/libavcodec/codec.h +++ b/libavcodec/codec.h @@ -235,6 +235,12 @@ typedef struct AVCodec { * Array of supported channel layouts, terminated with a zeroed layout. */ const AVChannelLayout *ch_layouts; + + /** + * Array of supported YUV color formats. Ignored for RGB/Gray formats. + */ + const enum AVColorRange *color_ranges; ///< terminated by AVCOL_RANGE_UNSPECIFIED + const enum AVColorSpace *color_spaces; ///< terminated by AVCOL_SPC_UNSPECIFIED } AVCodec; /** diff --git a/libavcodec/version.h b/libavcodec/version.h index f2f14eaed1..19f3f4a272 100644 --- a/libavcodec/version.h +++ b/libavcodec/version.h @@ -29,7 +29,7 @@ #include "version_major.h" -#define LIBAVCODEC_VERSION_MINOR 39 +#define LIBAVCODEC_VERSION_MINOR 40 #define LIBAVCODEC_VERSION_MICRO 100 #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \ -- 2.43.0

2 12

[PATCH 1/3] avcodec/vvc/vvcdec: Do not submit frames without VVCFrameThread
by Michael Niedermayer 02 Apr '24

02 Apr '24

Such frames will crash when pthread functions are called on the NULL pointer Fixes: member access within null pointer of type 'VVCFrameThread' (aka 'struct VVCFrameThread') Fixes: 65160/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4665241535119360 (partly) Fixes: 65636/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5394745824182272 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael(a)niedermayer.cc> --- libavcodec/vvc/vvcdec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/vvc/vvcdec.c b/libavcodec/vvc/vvcdec.c index 540a05f8cf4..2fa6aa46d9b 100644 --- a/libavcodec/vvc/vvcdec.c +++ b/libavcodec/vvc/vvcdec.c @@ -910,6 +910,9 @@ static int vvc_decode_frame(AVCodecContext *avctx, AVFrame *output, if (ret < 0) return ret; + if (!fc->ft) + return avpkt->size; + ret = submit_frame(s, fc, output, got_output); if (ret < 0) return ret; -- 2.17.1

4 14

[RFC] clarifying the TC conflict of interest rule
by Anton Khirnov 01 Apr '24

01 Apr '24

Hi, in the 'avcodec/s302m: enable non-PCM decoding' thread it became apparent that there is wide disagreement about the interpretation of this line in the TC rules: > If the disagreement involves a member of the TC, that member should > recuse themselves from the decision. The word 'involves' in it can be intepreted a variety of very different ways, to apply to TC members who e.g.: 1) authored the changes that are being objected to 2) are objecting to the changes 3) have any opinion on the changes, either positive or negative 4) have previously voiced an opinion that would apply to the changes 5) authored the code that is being modified 6) have a financial or other similar interest in a specific outcome of the disagreement I believe the best way to address this is to make the rule more explicit, so I propose that people with an opinion on the matter submit their preferred wording, and then we can have the GA vote on it. Cheers, -- Anton Khirnov

12 90

FFmpeg at NAB 2024
by Thilo Borgmann 31 Mar '24

31 Mar '24

Hi, FFmpeg will have a booth at the next NAB from April 14th to 17th 2024 in Las Vegas [1]! We reiceived an anonymous corporate sponsorship for the booth, so there are no costs for the FFmpeg project to it (and no obligations, of course). Any FFmpeg developer is welcome to join in and man the booth with me, especially any developers based in the US or other american countries! Share with us your broken workflows, unfulfilled requirements, ideas for enhancements and after show drinks at W4232 [2]! -Thilo [1] https://cloud.e.nabshow.com/2024/ [2] https://nab24.mapyourshow.com/8_0/exhview/?hallID=W&selectedBooth=W4232

6 10

[PATCH] libavformat/flac_picture: Don't return AVERROR_INVALIDDATA for errors with flac picture mimetype
by Will Cassella 28 Mar '24

28 Mar '24

In the case where the FLAC picture MIME type is not understood, fail to parse the picture silently rather than return AVERROR_INVALIDDATA. This originated from a bug reported in Chromium: https://crbug.com/1052821 Signed-off-by: Will Cassella <cassew(a)google.com> --- libavformat/flac_picture.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/libavformat/flac_picture.c b/libavformat/flac_picture.c index b33fee75b4..1acad9b251 100644 --- a/libavformat/flac_picture.c +++ b/libavformat/flac_picture.c @@ -68,8 +68,6 @@ int ff_flac_parse_picture(AVFormatContext *s, uint8_t **bufp, int buf_size, if (len <= 0 || len >= sizeof(mimetype)) { av_log(s, AV_LOG_ERROR, "Could not read mimetype from an attached " "picture.\n"); - if (s->error_recognition & AV_EF_EXPLODE) - return AVERROR_INVALIDDATA; return 0; } if (len + 24 > bytestream2_get_bytes_left(&g)) { @@ -91,8 +89,6 @@ int ff_flac_parse_picture(AVFormatContext *s, uint8_t **bufp, int buf_size, if (id == AV_CODEC_ID_NONE) { av_log(s, AV_LOG_ERROR, "Unknown attached picture mimetype: %s.\n", mimetype); - if (s->error_recognition & AV_EF_EXPLODE) - return AVERROR_INVALIDDATA; return 0; } -- 2.37.2.789.g6183377224-goog

5 6

[PATCH] avfilter/vf_signature: Dont crash on no frames
by Michael Niedermayer 27 Mar '24

27 Mar '24

Signed-off-by: Michael Niedermayer <michael(a)niedermayer.cc> --- libavfilter/vf_signature.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavfilter/vf_signature.c b/libavfilter/vf_signature.c index 4896e8f2c11..53ed413a4ce 100644 --- a/libavfilter/vf_signature.c +++ b/libavfilter/vf_signature.c @@ -384,6 +384,9 @@ static int xml_export(AVFilterContext *ctx, StreamContext *sc, const char* filen FILE* f; unsigned int pot3[5] = { 3*3*3*3, 3*3*3, 3*3, 3, 1 }; + if (!sc->coarseend->last) + return AVERROR(EINVAL); // No frames ? + f = avpriv_fopen_utf8(filename, "w"); if (!f) { int err = AVERROR(EINVAL); -- 2.17.1

1 1