July 2025 - ffmpeg-devel - lists.ffmpeg.org

Re: [FFmpeg-devel] Revert "avformat/tls_openssl: properly get new BIO index"
by Nicolas George 02 Aug '25

02 Aug '25

Kacper Michajłow (HE12025-07-30): > > Note that BIO_get_new_index() can only be used 127 times before it > > returns an error. > > We cannot call it repeatedly, because it will fail eventually. > > To my understanding the index is not needed in our use and we could > safely use BIO_TYPE_NONE. Documentation states: > > > type can be set to either BIO_TYPE_NONE or via BIO_get_new_index() if > > a unique type is required for searching (See BIO_find_type(3)) > > We don't use any search related functions. This should never have reached the commit message. -- Nicolas George

5 11

Recommendations to facilitation patch reviews on forgejo/ML?
by Romain Beauxis 02 Aug '25

02 Aug '25

Hi all, Are there any recommendations on how to best get attention to some patches/changes? With the introduction of the new forgejo workflow (which I personally welcome!), I am wondering how casual contributors like myself should approach the task of finding reviewers. So far, I am aware of the following: * Contact a listed MAINTAINER if they are still active * Get attention on the Mailing List. * Ping people on IRC * Forgejo? The advantage of the ML for this problem is that all patches are visible to all subscribers. But, for Forgejo, it seems very easy to have PRs fall through the cracks. The only thing that I can think of at the moment is to assign to people that have been active in reviewing other PRs. Is there a better suggested way? Should the ML be used to advertise PRs up for review? For a practical reference, here's my situation: while working on fixing ogg muxer/demuxer, I have had success getting some response from a general standpoint but I have never found someone committed to working on the ogg subset of the project and the listed MAINTAINER does not seem active anymore. I understand that ogg is an old container but it is still the standard container for a lot of online streaming and ffmpeg is the default implementation for most browsers reading (and more). It seems like it should be in the interest of the project to improve its support? The patch in question is here: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20026 Or here on the ML: https://ffmpeg.org/pipermail/ffmpeg-devel/2025-June/344442.html The larger context is a rewrite of the ogg/demuxer when working with sequential streams to: * Remove stream packet headers from the demuxer (as suggested by Lynne) * Fix PTS/DTS discontinuity. Subsequent ogg logical stream currently reset the PTS/DTS counter which is a problem. * Support copy-only repackaging of sequentialized ogg streams. Any advice would be welcome. Thanks! -- Romain

4 9

(no subject)
by Niklas Haas 02 Aug '25

02 Aug '25

Changes since v1: - Correctly implement alpha mode tagging for JPEG XL - Set correct alpha mode for OpenEXR (which is always premultiplied) - Ensure -alpha_mode specified on the command line correctly propagates - Print out a warning when overriding the alpha mode explicitly Includes an unrelated fix for -chroma_sample_location also being ignored, since the fix for that was adjacent to the fix for the alpha mode field. Submitting this for re-evaluation. I decided in the end not to include full negotiation for the alpha mode, primarily because there is no filter currently existing that only handles one or the other. The only thing that represents a source of incompatibility is the codec itself, but that already errors out with a clearly defined error message when requesting an incompatible alpha mode - and I think the explicit fix (i.e. user inserts the corresponding (un)premultiply filter) is bettter than an implicit conversion, due to the potential for loss of information as well as breaking workflows that rely on additive blending (which only works for premultiplied alpha and thus cannot be converted - even explicitly). If the error message is really bothersome, we could add a small routine inside libavcodec for applying the unpremultiplication directly, but this would IMO be a layering violation. (Not to mention duplicating code)

4 37

[IMPORTANT] AI written TLS Code in WHIP patch
by Kieran Kunhya 02 Aug '25

02 Aug '25

Hello, It seem there is strong evidence that AI wrote TLS code as part of the WHIP patch. It goes without saying why this is bad. Further discussion here: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20053 This patch was pushed without ML review. I think this code should be removed before the FFmpeg release. I include TC in this email for that reason. Regards, Kieran Kunhya

7 7

[PATCH] avcodec/sanm: Checks related to negative left/top
by Michael Niedermayer 01 Aug '25

01 Aug '25

Fixes: 423673969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SANM_fuzzer-5466731806261248 Fixes: out of array access CC: Manuel Lauss <manuel.lauss(a)gmail.com> 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/sanm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c index 617b977ab70..d345f588463 100644 --- a/libavcodec/sanm.c +++ b/libavcodec/sanm.c @@ -1654,7 +1654,7 @@ static int process_frame_obj(SANMVideoContext *ctx, GetByteContext *gb) bytestream2_skip(gb, 2); parm2 = bytestream2_get_le16u(gb); - if (w < 1 || h < 1 || w > 800 || h > 600 || left > 800 || top > 600) { + if (w < 1 || h < 1 || w > 800 || h > 600 || left > 800 || top > 600 || left + w <= 0 || top + h <= 0) { av_log(ctx->avctx, AV_LOG_WARNING, "ignoring invalid fobj dimensions: c%d %d %d @ %d %d\n", codec, w, h, left, top); @@ -1715,7 +1715,7 @@ static int process_frame_obj(SANMVideoContext *ctx, GetByteContext *gb) } } } else { - if (((left + w > ctx->width) || (top + h > ctx->height)) && fsc) { + if (((left + w > ctx->width) || (top + h > ctx->height)) && (fsc || codec == 20)) { /* correct unexpected overly large frames: this happens * for instance with The Dig's sq1.san video: it has a few * (all black) 640x480 frames halfway in, while the rest is @@ -1775,11 +1775,11 @@ static int process_frame_obj(SANMVideoContext *ctx, GetByteContext *gb) if ((w == ctx->width) && (h == ctx->height)) { memcpy(ctx->fbuf, ctx->frm0, ctx->fbuf_size); } else { - uint8_t *dst = (uint8_t *)ctx->fbuf + left + top * ctx->pitch; const uint8_t *src = (uint8_t *)ctx->frm0; const int cw = FFMIN(w, ctx->width - left); const int ch = FFMIN(h, ctx->height - top); if ((cw > 0) && (ch > 0) && (left >= 0) && (top >= 0)) { + uint8_t *dst = (uint8_t *)ctx->fbuf + left + top * ctx->pitch; for (int i = 0; i < ch; i++) { memcpy(dst, src, cw); dst += ctx->pitch; -- 2.50.1

2 3

[PATCH] web: announce code.ffmpeg.org
by Lynne 01 Aug '25

01 Aug '25

--- src/contact | 11 +++++++++++ src/index | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+) diff --git a/src/contact b/src/contact index 6943d06..8a59864 100644 --- a/src/contact +++ b/src/contact @@ -1,3 +1,14 @@ +<div class="well"> + <h3 id="Contributions"> + <i class="fa fa-pencil"></i> + Contributions</h3> + <div style="color: white"> + <p> + To contribute to FFmpeg, login or sign up for an account on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>. + The main repository of the project is <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg">code.ffmpeg.org/FFmpeg/FFmpeg</a>. + </p> + </div> +</div>  <div class="well"> <div class="row"> diff --git a/src/index b/src/index index 52829e1..1f45dec 100644 --- a/src/index +++ b/src/index @@ -35,6 +35,58 @@ News </h1> + <h3 id="forge">July 22nd, 2025, Modernization of contributions</h3> + <p> + The project is modernizing its contribution methods and switching to a software forge. + <p> + </p> + We have setup a platform on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>. The new process + features continuous integration on all commits and merge requests, labelling for categorization, + conflict resolution, and logging in via OpenID or Github. + </p> + <p> + The main repository will become <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg">code.ffmpeg.org/FFmpeg/FFmpeg</a>, + with all others being mirrored to it. + Users are encouraged to begin using it, effective now. + </p> + <p> + Mailing lists have supported our development for + <span title="with a total of 346,615 emails since April 2005">nearly 25 years</span>, + but as more and more contributors started to become involved, the ratio of merged patches to total mails begun + <span title="perhaps just correlation">falling</span>. Mailing lists became a source of friction, + with discussions frequently stalling and uncategorized noise drowning out patches by bumping them down in inboxes. + </p> + <p> + Although <a href="https://patch.ffmpeg.org/">patchwork.ffmpeg.org</a> was set up to track submissions, + it was less than reliable, with many patches and mails slipping though. Since its activation exactly + 9 years ago, it recorded 54,476 patches, with 53,650 patches having the state of not archived. + In comparison, the mailing list has had a total of 150,736 emails during the same time period. + </p> + <p> + Additionally, new users have frequently encountered difficulties with mailing list development. + From finding out the correct SMTP login details, configuring git send-email, new email security + mechanisms interfering with mailing list operations, and finally not having a comfortable workflow + to review patches. + </p> + <p> + After years of discussions, and a vote, we officially announce the new platform, + <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>, running <a href="https://forgejo.org/">Forgejo</a>. + Documentation will be updated to reflect the change. + </p> + <p> + Mailing lists will continue to be monitored, and used for project discussions and other topics + better discussed elsewhere, but traffic and noise should become significantly reduced over time. + </p> + <p> + Bugs/issues will be accepted on <a href="https://code.ffmpeg.org/">code.ffmpeg.org</a>, alongside + with <a href="https://trac.ffmpeg.org/">trac.ffmpeg.org</a> for the time being. + </p> + <p> + We are also hoping that this will significantly reduce the amount of unmerged patches. + If you submitted a patch which received no replies or conclusion, we apologize, and you are encouraged + to resubmit it on the new platform. + </p> + <h3 id="pr7.1">September 30th, 2024, FFmpeg 7.1 <span title="Rózsa Péter">"Péter"</span></h3> <p> <a href="download.html#release_7.1">FFmpeg 7.1 "Péter"</a>, a new -- 2.50.0

13 50

hwcontext_vulkan: transfer exclusive images to correct queue family in drm->vulkan mapping
by vytskalt 01 Aug '25

01 Aug '25

From: vytskalt <vytskalt(a)protonmail.com> VK_QUEUE_FAMILY_IGNORED is only valid when the image is in CONCURRENT sharing mode. When there is only one queue family it's in the EXCLUSIVE sharing mode and the dst queue family must match it. Fixes validation error during drm->vulkan frame mapping: "pDependencyInfo->pImageMemoryBarriers[0] has srcQueueFamilyIndex 4294967294 (VK_QUEUE_FAMILY_EXTERNAL) and dstQueueFamilyIndex 4294967295 (VK_QUEUE_FAMILY_IGNORED). The command buffer's command pool is associated with family index 0. Source or destination queue family must match queue family associated with the command buffer's command pool." Signed-off-by: vytskalt <vytskalt(a)protonmail.com> --- libavutil/hwcontext_vulkan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c index 894bc3dae1..6d7df3e619 100644 --- a/libavutil/hwcontext_vulkan.c +++ b/libavutil/hwcontext_vulkan.c @@ -3417,7 +3417,7 @@ static int vulkan_map_from_drm_frame_sync(AVHWFramesContext *hwfc, AVFrame *dst, ((flags & AV_HWFRAME_MAP_WRITE) ? VK_ACCESS_2_SHADER_STORAGE_WRITE_BIT : 0x0), VK_IMAGE_LAYOUT_GENERAL, - VK_QUEUE_FAMILY_IGNORED); + p->nb_img_qfs > 1 ? VK_QUEUE_FAMILY_IGNORED : p->img_qfs[0]); vk->CmdPipelineBarrier2(cmd_buf, &(VkDependencyInfo) { .sType = VK_STRUCTURE_TYPE_DEPENDENCY_INFO, -- 2.49.0

1 0

[flac] Fix integer-overflow in flac_lpc_33_c
by Dale Curtis 31 Jul '25

31 Jul '25

This fix copies a couple of casts from surrounding functions. See https://crbug.com/432528781 for stack trace details. Signed-off-by: Dale Curtis <dalecurtis(a)chromium.org>

2 5

[PATCH] avformat/mov: don't unnecesarely replace extradata with the same one
by James Almer 31 Jul '25

31 Jul '25

If the first STSC entry refers to the first extradata buffer, then don't bother replacing the output stream's extradata as it's already set to it. Signed-off-by: James Almer <jamrial(a)gmail.com> --- libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 7f88ec8220..a3e1aa2933 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -10667,7 +10667,7 @@ static int mov_read_header(AVFormatContext *s) fix_timescale(mov, sc); /* Set the primary extradata based on the first Sample. */ - if (sc->stsc_count && sc->extradata_size && !sc->iamf) { + if (sc->stsc_count && sc->extradata_size && sc->stsc_data[0].id != 1 && !sc->iamf) { sc->last_stsd_index = sc->stsc_data[0].id - 1; av_freep(&st->codecpar->extradata); st->codecpar->extradata_size = sc->extradata_size[sc->last_stsd_index]; -- 2.50.1

1 0

Bounce on Luca Abeni from MAINTENERS
by Peter Enderborg 31 Jul '25

31 Jul '25

I get bouces saying that the user does not exist. Have have send patch, but no maintainer.

3 2