Romain Beauxis via ffmpeg-devel writes:
> I understand the benefit of using higher order APIs borrowed from C++ but,
> to fully make your case I think it'd be important to know: is it possible
> to use STL and avoid linking with libstc++?
I'm new to the list, so forgive me f
PR #20854 opened by Lynne
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20854
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20854.patch
Decoders have to manually check if the frame size has changed, and call
ff_get_format if it has. H.264, HEVC, and most decoders did this, but this wa
PR #20855 opened by michaelni
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20855
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20855.patch
>From 5ccb2c9934615db1d55a7a62dda551c4d02c6fd6 Mon Sep 17 00:00:00 2001
From: Michael Niedermayer
Date: Fri, 7 Nov 2025 01:47:40 +0100
Subject:
PR #20860 opened by mkver
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20860
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20860.patch
Using unsigned for fps more natural since the corresponding AVTimecode field
is unsigned and fixes a -Wformat-truncation warning from GCC 16:
in case
PR #20866 opened by mkver
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20866
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20866.patch
>From 41631b48d2392f83130c734b26f7c9fdb8415f5a Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Sat, 8 Nov 2025 17:02:13 +0100
Subject: [PATC
PR #20867 opened by toots
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20867
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20867.patch
>From f3a114f7dea9f31888dc9deb39bbe5ee5e808c0c Mon Sep 17 00:00:00 2001
From: Romain Beauxis
Date: Sat, 8 Nov 2025 10:19:30 -0600
Subject: [PATCH 1/
PR #20869 opened by frankplow
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20869
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20869.patch
Previously, we set s->slice_initialized to 0 to prevent other slice segments
from depending on this slice segment only if hls_slice_header failed
PR #20868 opened by toots
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20868
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20868.patch
This fixes PTS/DTS discontinuity on sequentialized ogg streams.
>From 9656eb8a9a0f10b28b95ca35f98ad165e5e3c41a Mon Sep 17 00:00:00 2001
From: Romai
PR #20870 opened by averne
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20870
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20870.patch
The qScale syntax element has a maximum value of 512, which would overflow the
16-bit store from the VLD shader in extreme cases.
This fixes that ed
PR #20871 opened by drobinator
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20871
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20871.patch
The AVFoundation audio callback may outpace avf_read_packet, causing the
previous single-buffer storage (current_audio_frame) to be overwritten
b
PR #20872 opened by michaelni
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20872
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20872.patch
Fixes: use of uninitialized memory
Fixes:
439878388/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_DEC_fuzzer-5635866203848704
Found-
PR #20859 opened by caifan
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20859
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20859.patch
ensure formatted timecode string fits in AV_TIMECODE_STR_SIZE,
eliminates -Wformat-truncation compiler warning.
Signed-off-by: caifan3
>From 7301
PR #20858 opened by caifan
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20858
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20858.patch
add av_assert0() for chapter_time and chapter_number,
ensure buffer size is sufficient to hold formatted strings,
eliminate -Wformat-truncation warni
PR #20857 opened by caifan
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20857
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20857.patch
GCC with -Wformat-truncation warns that writing the transport string with
snprintf may result in truncation, as up to 4095 bytes from '%s'
are writt
Thanks for reviewing and applying the patch. Apologies for the incorrect
commit message , I appreciate you correcting it. Thanks again
On Fri, 7 Nov 2025 at 22:14, Michael Niedermayer via ffmpeg-devel <
[email protected]> wrote:
> Hi Reaxx
>
> On Fri, Nov 07, 2025 at 0
Hi Michael,
Yes, the commit message LGTM , Thank you for the detailed explanation and
for taking the time to review this thoroughly. I appreciate your patience.
On Fri, 7 Nov 2025 at 22:39, Michael Niedermayer via ffmpeg-devel <
[email protected]> wrote:
> Hi
>
> On Fri,
PR #20862 opened by Lynne
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20862
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20862.patch
This commit adds a few utilities, and fixes decoding of streams where the frame
size changes.
>From a09e8c5ac07c68b6cc8f8a85a2a7063909e7ec8b Mon Se
PR #20863 opened by Lynne
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20863
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20863.patch
This just lets them actually be used in swscale and vf_colorspace.
>From 7e9039e3e472567e8fb3df3ee89861f9915ee5a5 Mon Sep 17 00:00:00 2001
From: Lyn
This patch fixes an out-of-bounds read in the RV60 decoder where qp can
reach 65, exceeding the rv60_qp_to_idx[64] array bounds. The previous fix
(61cbcaf93f) only covered intra frames. This adds validation at the source
for all frame types.
0001-avcodec-rv60dec-add-upper-bound-check-for-qp.patch
PR #20864 opened by thomasdullien
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20864
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20864.patch
For transparency: I am experimenting with an AI-assisted patch process, where
the AI agent attempts to help
root-cause analyze a crash by mea
PR #20891 opened by cancername
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20891
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20891.patch
ff_sws_pixel_type_size uses size in bytes, not bits, but
ff_sws_pixel_type_to_uint assumes size in bits. ff_sws_pixel_type_to_uint is
never cal
PR #20903 opened by breunigs
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20903
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20903.patch
av_frame_copy doesn't copy the input's PTS property, which resulted
in the frei0r filter always receiving the same static time.
Example that has a
On 2025-11-12 16:04, Michael Niedermayer via ffmpeg-devel wrote:
This was suggested to me.
Allowing only donations to a 501(c)(3) restricts both donators as well
as developers
This style of donation page has worked well for other projects.
I agree we have had issues with limited scope of
On 2025-11-11 15:15, Michael Niedermayer via ffmpeg-devel wrote:
Hello everyone
We have been contacted by Microsoft.
Whats your oppinion about putting one or both the current community
builds, that we link
to, on the Microsoft store?
its better for people to get ffmpeg direct from
On 2025-11-08 00:34, Thomas Dullien via ffmpeg-devel wrote:
What's the best way to submit these patches? There is the bug tracker,
there is this
mailing list - what's the best way to contribute them?
Cheers,
Thomas
the best way is whatever you prefer.
https://code.ffmpeg.org/FFm
On 2025-10-13 01:32, Nicolas George via ffmpeg-devel wrote:
Hi. I just went to the new archive for this mailing-list.
Is it just me or does it suck?
mailman 3 is open source. send them some patches to make it better :)
-compn
___
ffmpeg-devel
Hi all,
I hope this message finds you well.
My name is Yunfei Zhou, and I am a Software Development Engineer at Alibaba
DAMO Academy, where I focus on video coding and decoding optimization.
We are currently exploring vectorization optimizations for HEVC decoding using
the RISC-V Vector Extension
PR #20900 opened by usepgp
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20900
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20900.patch
A chromium fuzzer identified this potential UB int overflow.
>From d55c6e8a2c49319eb779ec795fdd657cbc524fc7 Mon Sep 17 00:00:00 2001
From: Ted Meye
PR #20894 opened by michaelni
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20894
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20894.patch
No testcase, its unknown if this is a real issue
Reported-by: Peter Teoh
Signed-off-by: Michael Niedermayer
>From 67eea3903e440bf1162423b
PR #20895 opened by chenhao
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20895
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20895.patch
In the YUV420 format, a single pair of UV values produces two RGB pixels.
Because of this, cases with an odd dstw value do not need to be considere
PR #20897 opened by damitha
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20897
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20897.patch
Addressing the fact that first frame has a LCT when global palette is used for
pal8.
issue: [#20896](https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/2
PR #20911 opened by mkver
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20911
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20911.patch
This flag does nothing since the deactivation of
the dsp_mask field of AVCodecContext in
commits 9ae6ba288368be42dbd77613e07255d38bbba40e and
9ae6ba28
PR #20909 opened by mkver
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20909
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20909.patch
>From 92fe3d96e6f9a3b169a3edcdb48ecdc543ba862e Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Sun, 9 Nov 2025 17:06:46 +0100
Subject: [PATC
Hello, I am using Vulkan hardware accelerated video decoding and I am setting
up the AVVulkanFramesContext myself.
However when "VkImageCreateFlags img_flags" is unset, a default set of flags
(including VK_IMAGE_CREATE_ALIAS_BIT and others) is applied.
(https://github.com/FFmpeg/FFmpeg/blob/6cdd2
On 2025-11-13 06:50, Timo Rothenpieler via ffmpeg-devel wrote:
On 13/11/2025 04:06, Michael Niedermayer via ffmpeg-devel wrote:
Hi Kieran
On Wed, Nov 12, 2025 at 12:09:00AM -0800, Kieran Kunhya via
ffmpeg-devel wrote:
On Mon, 10 Nov 2025, 19:00 Michael Niedermayer via ffmpeg-devel, <
ffm
Hi, I was curious on learning more about VVC and wasm within the
ffmpeg project and would like some guidance on where to find the docs
and references to go through
I am simply trying to get my hands dirty with a past GSoC project to
get the feel of working on the source code (hopefully to understa
being good at writing it. And if I may ask, what exactly are the
current drawbacks of the current C implementation?
Thank you for taking your time to answer my questions.
On Thu, Nov 13, 2025 at 11:13 PM Frank Plowman via ffmpeg-devel
wrote:
>
> On 13/11/2025 16:46, Sidd via ffmpeg-devel
Ok I misunderstood about the decoder part.
Sorry I am new to mailing lists am not sure what top-posting means, if
I have not abided by any rules I do apologize and will refrain from
doing so
On Thu, Nov 13, 2025 at 11:40 PM Frank Plowman via ffmpeg-devel
wrote:
>
> On 13/11/2025 17:56, Si
PR #20914 opened by colekas
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20914
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20914.patch
>From a81dd03e1d494911f30a67609d6c848a40dd25c7 Mon Sep 17 00:00:00 2001
From: Chris Olekas
Date: Wed, 20 Aug 2025 11:03:30 -0400
Subject: [PATCH 1
PR #20918 opened by mkver
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20918
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20918.patch
The ProresDSPContext already contains the idct_permutation.
Seems like the raw code has been branched of before February (before
deee2fb52d4ae0fe2a0
PR #20919 opened by brad
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20919
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20919.patch
Co-authored-by: Sebastien Marie
>From c6926060a98f335e069c3e631b96cc4e0b8e758e Mon Sep 17 00:00:00 2001
From: Brad Smith
Date: Fri, 14 Nov 2025 05:
PR #20912 opened by mkver
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20912
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20912.patch
This reverts commit 62184be5486ec06d6976c20931b30738c8e83fd8.
It includes a private header (lavu/mutex.h) in a public header
(hwcontext_amf.h).
>Fro
The film_write_packet() function reads encoded_buf_size from packet
data via AV_RB24() and uses it in a modulo operation without validation.
When the data contains zeros at this position, it causes division by zero.
Add validation to return AVERROR_INVALIDDATA when encoded_buf_size is zero.
Signe
PR #20922 opened by Shubin123
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20922
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20922.patch
The film_write_packet() function reads encoded_buf_size from packet
data via AV_RB24() and uses it in a modulo operation without validation.
When
---
发件人：Rémi Denis-Courmont via ffmpeg-devel
发送时间：2025年11月14日(周五) 22:22
收件人：FFmpeg development discussions and patches
抄 送："[email protected]"; "Rémi
Denis-Courmont"
主 题：[FFmpeg-devel] Re: [Question]Inquiry Regarding RISC-V RVV Optimization for
HEVC Decoding i
I have been going through some code and found a couple of FIXME's that
mention the section of code to be "slow" and I was just curious since
I am relatively new to most kinds of profiling, how do you evaluate
this and if anybody were to come up with a patch for this, how can
they reliably show spee
PR #20941 opened by Lynne
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20941
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20941.patch
>From ac98c3e731bccf35480a3bddebc930627cd2d482 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Sat, 20 May 2023 16:09:22 +0200
Subject: [PATCH] aacdec: a
On 2025-11-16 07:59, Michael Niedermayer via ffmpeg-devel wrote:
On Sun, Nov 16, 2025 at 04:12:00PM +0100, Michael Niedermayer via
ffmpeg-devel wrote:
On Sun, Nov 16, 2025 at 01:56:49PM +, Kieran Kunhya via
ffmpeg-devel wrote:
> On Sun, 16 Nov 2025, 05:04 Michael Niedermayer via ffm
PR #20936 opened by Lynne
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20936
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20936.patch
This commit implements support for decoding of MPEG Surround data
(USAC-flavoured).
I'm raising funds and resources to build a rocket capable of str
PR #20946 opened by anthonybajoua
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20946
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20946.patch
Currently, when there is a file that is muxed in fragmented mode with flags
`frag_keyframe+delay_moov+empty_moov+dash` the second track's len
The film_write_packet() function reads encoded_buf_size from packet
data via AV_RB24() and uses it in a modulo operation without validation.
When the data contains zeros at this position, it causes division by zero.
Add validation to return AVERROR_INVALIDDATA when encoded_buf_size is zero.
Signe
PR #20934 opened by mkver
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20934
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20934.patch
>From 76eef407bf5fa62e129352d2c460b57e6a5fc759 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Mon, 17 Nov 2025 00:05:16 +0100
Subject: [PAT
PR #20932 opened by mkver
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20932
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20932.patch
>From a7102ce7ed9e6c0a8c61a92eb8e66b4260057adb Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Sat, 15 Nov 2025 16:18:16 +0100
Subject: [PAT
PR #20933 opened by nots1dd
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20933
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20933.patch
>From what I understand, we only need to be moving N bytes as window_size
- s->hop_size after inverse fft to the buffer for overlap. Currently the
c
PR: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20933
On Sun, Nov 16, 2025 at 4:19 PM nots1dd wrote:
>
> From what I understand, we only need to be moving N bytes as window_size
> - s->hop_size after inverse fft to the buffer for overlap. Currently the
> compiler throws a warning regarding possib
PR #20942 opened by mkver
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20942
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20942.patch
>From fd5fbb41ccaf846a3dc1742ba65dfe6714a543aa Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Mon, 17 Nov 2025 15:35:38 +0100
Subject: [PAT
>From what I understand, we only need to be moving N bytes as window_size
- s->hop_size after inverse fft to the buffer for overlap. Currently the
compiler throws a warning regarding possible overflow and this patch
fixs it.
---
libavfilter/af_afftfilt.c | 3 ++-
1 file changed, 2 insertions(+), 1
Also I am a bit confused what happens after a maintainer accepts or is
satisfied with this patch (as I am unable to commit anything to my
fork on code.ffmpeg.org) so any help on this would be great (it is my
first time if it wasnt obvious enough)
On Sun, Nov 16, 2025 at 4:19 PM nots1dd wrote:
>
>
PR #20951 opened by HecaiYuan
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20951
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20951.patch
This wrapper performs runtime dispatch to SIMD-optimized functions and
falls back to a C implementation for unsupported block heights.
>From 3d5
PR #20961 opened by toots
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20961
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20961.patch
>From ade83020b43d572b4b9f1d1c821fe9f558d31768 Mon Sep 17 00:00:00 2001
From: Romain Beauxis
Date: Tue, 18 Nov 2025 16:58:59 -0600
Subject: [PATCH]
PR #20958 opened by ddesouza
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20958
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20958.patch
This is the revised version of PR #20562, according to the comments from @haasn
and @mkver.
>From a14bccc09b9af29672c141a447999fd3d99a1ba1 Mon
PR #20959 opened by mux47
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20959
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20959.patch
Avoid calling ff_opus_parse_packet() on flush (buf_size == 0)
Fixes spurious 'Error parsing Opus packet header' in complete-frames mode at
EOF.
Relat
PR #20966 opened by jchw
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20966
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20966.patch
Photoshop documents can contain additional "auxiliary" channels that don't take
part in layer compositing, therefore, using the channel count to deter
Currently, libsvtav1 does not send pass number or stat buffer to SVT-AV1, which
means that 2-pass encoding is not possible using FFMPEG;
if a user wants to do 2-pass encoding using SVT-AV1, they have to use
SvtAv1EncApp.
This patch adds 2-pass encoding support to libsvtav1 using the stats buffers
From 8b62312d794ecb66cc1a8dbe4933fca0d725057b Mon Sep 17 00:00:00 2001
From: Andrea Mastroberti <[email protected]>
Date: Fri, 17 May 2024 00:29:01 +0200
Subject: [PATCH] avfilter/smartblur: Added alpha layer support
---
doc/filters.texi | 20 +-
libavfilter/version.h
> On May 14, 2024, at 9:28 AM, Lynne via ffmpeg-devel
> wrote:
>
> On 14/05/2024 17:09, Christian Bartnik wrote:
>> From: Thomas Siedel
>> Add external decoder VVdeC for H266/VVC decoding.
>> Register new decoder libvvdec.
>> Add libvvdec to wrap the v
Hi,
On Wed, May 15, 2024 at 11:11 PM Aaron Thompson via ffmpeg-devel
wrote:
>
> The value was being parsed as base 4, so the value "4" was invalid and
> would result in ts_layering_mode being set to 0.
>
> Signed-off-by: Aaron Thompson
> ---
> libavcodec/libvpxen
> On May 18, 2024, at 7:04 AM, Nuo Mi wrote:
>
> This happened many years ago. See the discussion here:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/[email protected]/#60589
> Now that we have an internal vvc decoder, we can focus on improving it.
> As for the en
On 17.05.24 16:43, Ronald S. Bultje wrote:
Hi,
On Fri, May 17, 2024 at 9:50 AM Michael Niedermayer
wrote:
* Fund professional real live presence on multimedia / FOSS / buisness
related
events. we already refund individuals but i think we are lacking on the
organizational
side. We shou
[...]
* Fund administrative / maintainance work (one example is the mailman upgrade
that is needed
with the next OS upgrade on one of our servers (this is not as trivial as one
might
expect). Another example here may be some git related tools if we find
something that
theres a broad co
Hi,
There are a couple of files in samples.ffmpeg.org with invalid
permissions, rsync is not able to read those:
/V-codecs/UCOD/noextradata/CLV1_tony.mov
/V-codecs/UCOD/noextradata/freddie2.mov
/V-codecs/UCOD/noextradata/pittc.mov
/V-codecs/UCOD/noextradata/smilla_cv.mov
/ffmpeg-bugs/trac/
On May 18, 2024, at 10:48 PM, Rémi Denis-Courmont wrote:
Le 18 mai 2024 21:55:04 GMT+03:00, Cosmin Stejerean via ffmpeg-devel
mailto:[email protected]> > a écrit :
On May 18, 2024, at 7:04 AM, Nuo Mi mailto:[email protected]> > wrote:
This happened many years ago. See th
Trying again with better formatting, hopefully
> On May 18, 2024, at 10:48 PM, Rémi Denis-Courmont wrote:
>
> Hi,
>
> Le 18 mai 2024 21:55:04 GMT+03:00, Cosmin Stejerean via ffmpeg-devel
> a écrit :
>>
>>
>>> On May 18, 2024, at 7:04 AM, Nuo Mi wrote
> On May 20, 2024, at 11:03 AM, Rémi Denis-Courmont wrote:
>
> Le maanantaina 20. toukokuuta 2024, 19.33.43 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>
>> hwaccel decoding seems somewhat orthogonal
>
> How exactly will that work then? Either vvdec
> On May 20, 2024, at 12:01 PM, Rémi Denis-Courmont wrote:
>
> Le maanantaina 20. toukokuuta 2024, 21.39.18 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>> The same way using FDK-AAC as a decoder works, if you want to use it as the
>> *AAC decoder you have to
> On May 20, 2024, at 1:05 PM, Rémi Denis-Courmont wrote:
>
> Le maanantaina 20. toukokuuta 2024, 22.33.45 EEST Cosmin Stejerean via ffmpeg-
> devel a écrit :
>>> And again, you can't expect users to select decoders manually. If vvdec is
>>> the
>>&
From: Cosmin Stejerean
It looks like the el_bitdepth_minus8 value in the header can also encode
ext_mapping_idc in the upper 8 bits.
Samples having a non-zero ext_mapping_idc fail validation currently because the
value returned is out of range. This bypasses this by currently ignoring the
ext_ma
From: Cosmin Stejerean
Co-authored-by: Amir Naghdinezhad
Signed-off-by: Cosmin Stejerean
---
libavcodec/libsvtav1.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 3b41f5a39e..1eda63200c 100644
--- a/libavcodec/libsvtav1.c
+
> On May 20, 2024, at 09:12, Marvin Scholz wrote:
>
> Fix #10884
> ---
> libavutil/hwcontext_videotoolbox.c | 54 +-
> 1 file changed, 38 insertions(+), 16 deletions(-)
>
> diff --git a/libavutil/hwcontext_videotoolbox.c
> b/libavutil/hwcontext_videotoolbox.c
> ind
> On May 20, 2024, at 6:17 PM, Cosmin Stejerean via ffmpeg-devel
> wrote:
>
> From: Cosmin Stejerean
>
> Co-authored-by: Amir Naghdinezhad
> Signed-off-by: Cosmin Stejerean
> ---
> libavcodec/libsvtav1.c | 10 ++
> 1 file changed, 10 insertions(+)
From: Cosmin Stejerean
not all clients support metadata compression, make this an option and off by
default until we can verify output.
vdr_dm_metadata_changed = 0 case fails the DV verifier so force this to true
for now until we can determine the correct output format for this case.
---
liba
On Tue, May 21, 2024 at 2:33 PM J. Dekker wrote:
> @@ -338,8 +338,9 @@ typedef struct CheckasmPerf {
> uint64_t tsum = 0;\
> int ti, tcount = 0;\
> uint64_t t = 0; \
> +const uint64_t truns = bench_runs;\
> checkasm_set_signal_handler
> On May 21, 2024, at 3:21 AM, Niklas Haas wrote:
>
> On Tue, 21 May 2024 01:17:32 + Cosmin Stejerean via ffmpeg-devel
> wrote:
>> From: Cosmin Stejerean
>>
>> It looks like the el_bitdepth_minus8 value in the header can also encode
>>
Hi,
[...]
Tests mostly work for me. There are a few images (that I reported
earlier) that give:
thanks for testing!
Canvas change detected. The output will be damaged. Use -threads 1
to try decoding with best effort.
They don't animate without that option and with it render incorrectly.
From: Cosmin Stejerean
These two fields are coded together into a single 16 bit integer with upper 8
bits for ext_mapping_idc and lower 8 bits for el_bit_depth_minus8.
Furthermore ext_mapping_idc has two components, upper 3 bits and lower 5 bits.
---
libavcodec/dovi_rpudec.c | 7 ++-
libav
On 20.05.24 20:51, Rémi Denis-Courmont wrote:
Le sunnuntaina 19. toukokuuta 2024, 14.29.43 EEST Thilo Borgmann via ffmpeg-
devel a écrit :
[...]
* Fund administrative / maintainance work (one example is the mailman
upgrade that is needed>>
with the next OS upgrade on one of our s
> From: Dennis Sädtler via ffmpeg-devel
I wonder what happened here, did I make a mistake when submitting the
original patch to the ML so the actual commit author name/email got
lost?
Should be the same as the signed-off section based on the repo I
submitted it from:
https://github.com/der
> On May 21, 2024, at 11:48 AM, Dennis Sädtler via ffmpeg-devel
> wrote:
>
>> From: Dennis Sädtler via ffmpeg-devel
>
> I wonder what happened here, did I make a mistake when submitting the
> original patch to the ML so the actual commit author name/email got
> lo
> On May 21, 2024, at 11:54 AM, Cosmin Stejerean via ffmpeg-devel
> wrote:
>
>
> However I've found a workaround. By setting my git send-email from to just
> "[email protected] <mailto:[email protected]>" rather than "Cosmin Stejerean
> mailto:
> On May 21, 2024, at 11:54 AM, Cosmin Stejerean via ffmpeg-devel
> wrote:
>
>
> However I've found a workaround. By setting my git send-email from to just
> "[email protected] <mailto:[email protected]>" rather than "Cosmin Stejerean
> mailto:
On 21.05.24 21:42, Rémi Denis-Courmont wrote:
Le tiistaina 21. toukokuuta 2024, 21.43.44 EEST Thilo Borgmann via ffmpeg-devel
a écrit :
Same as above about that we should and STF would.
Especially since no corporate interest usually pays anyone for these
tasks
Sadly true, but...
(in case
On 21.05.24 21:43, Rémi Denis-Courmont wrote:
Le tiistaina 21. toukokuuta 2024, 22.42.00 EEST Rémi Denis-Courmont a écrit :
And "I hope you realise that you are arguing for" Intel, Loongson, etc.
employees to stop reviewing patches.
P.S.: And FFlabs too, since it is a for-profit company.
S
On Tue, 14 May 2024 19:07:59 -0700
Philip Langdale via ffmpeg-devel wrote:
> On Wed, 15 May 2024 01:36:43 +0530
> [email protected] wrote:
>
> > From: llyyr
> >
> > ab77b878f1 attempted to fix the issue of broken packets being sent
> > to the decode
> On May 21, 2024, at 9:19 PM, Andreas Rheinhardt
> wrote:
>
> Cosmin Stejerean via ffmpeg-devel:
>> From: Cosmin Stejerean
>>
>> These two fields are coded together into a single 16 bit integer with upper 8
>> bits for ext_mapping_idc and
From: Cosmin Stejerean
---
libavutil/dovi_meta.h | 2 ++
libavutil/version.h | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
index e10332f8d7..e168075a24 100644
--- a/libavutil/dovi_meta.h
+++ b/libavutil/dovi_meta.h
@@ -91,6
From: Cosmin Stejerean
These two fields are coded together into a single 16 bit integer with upper 8
bits for ext_mapping_idc and lower 8 bits for el_bit_depth_minus8.
Furthermore ext_mapping_idc has two components, upper 3 bits and lower 5 bits.
---
libavcodec/dovi_rpudec.c | 7 ++-
libavc
From: Cosmin Stejerean
Some DolbyVision samples fail to parse currently due to mis-reading the
el_bit_depth_minus8 field. Upon investigation it seems that the RPU syntax has
been extended in an as of yet undocumented way by adding ext_mapping_idc and
coding it together with el_bit_depth_minus8 to
On Wed, 22 May 2024 11:10:31 -0400
"Ronald S. Bultje" wrote:
> Hi,
>
> On Wed, May 22, 2024 at 10:36 AM Hendrik Leppkes
> wrote:
>
> > On Thu, Feb 29, 2024 at 7:19 AM llyyr wrote:
> > >
> > > segmentation.update_map is never reset to 0 on a new frame, and
> > > retains the value from the pr
On Tue, May 21, 2024 at 9:50 AM Thilo Borgmann via ffmpeg-devel
wrote:
>
> Hi,
>
> [...]
> >>> Tests mostly work for me. There are a few images (that I reported
> >>> earlier) that give:
> >>
> >> thanks for testing!
> >>
> &g
> On May 21, 2024, at 3:19 AM, Niklas Haas wrote:
>
> On Tue, 21 May 2024 04:03:43 + Cosmin Stejerean via ffmpeg-devel
> wrote:
>>
>> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
>> index dec74ebecd..c6104f5522 100644
>> --- a/libavc
901 - 1000 of 3389 matches
Mail list logo
