No, I strongly disagree.
Marking a vital encoder as libx265 that thousands of people rely on as
"experimental" after more than 10 years since its inclusion doesn't make any
sense and would make more harm than good.
Besides, the experimental flag is supposed to be used to indicate that the
imple
On 2024-10-17 20:23 +0200, Marvin Scholz wrote:
> The way the linked list of images was freed caused a
> use after free, by accessing pic->next after pic was
> already freed.
>
> Regression from 48a1a12968345bf673db1e1cbb5c64bd3529c50c
>
> Fix CID1633236
> ---
> libavcodec/hw_base_encode.c | 6 +++
On 2024-10-15 21:24 +0200, Anton Khirnov wrote:
> Quoting Alexander Strasser via ffmpeg-devel (2024-10-15 21:05:54)
> > Still that functionality is useful
>
> How is it useful? It gives you no actionable information.
Seems this was just applied already.
FTR and FWIW it was us
Thank you for the prompt response.
The primary reason for removing Blowfish from our codebase is to comply with
modern security guidelines and industry standards that discourage the use of
outdated cryptographic algorithms, like Blowfish, due to their vulnerabilities.
Given that av_blowfish* is
On 2024-10-14 17:52 +0200, Michael Niedermayer wrote:
> On Mon, Oct 14, 2024 at 01:36:46PM +0200, Anton Khirnov wrote:
> > ---
> > fftools/opt_common.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/fftools/opt_common.c b/fftools/opt_common.c
> > index 021ed75272
From: Eugene Zemtsov
It's AVPacketSideDataType, not AVFrameSideDataType.
Bug: https://issues.chromium.org/issues/374797732
Change-Id: If75702c6d639ca63827cc3370477de00544d3c0f
Reviewed-on:
https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/5950926
Reviewed-by: Ted (Chromiu
Thanks !
On Wed, Oct 30, 2024, at 14:34, Zhao Zhili wrote:
>> On Oct 30, 2024, at 21:19, Thomas Guillem via ffmpeg-devel
>> wrote:
>>
>> Happy monthly anniversary to my not very interesting patch.
>>
>> FYI, OpenSuse applied it for their ffmpeg b
[AMD Official Use Only - AMD Internal Distribution Only]
> Why yet another crappy hardware API? There is a million of those.
> Why yet another crappy special snowflake hardware decoder? We have more of
> those than we want (which is 0).
>
> As Mark has also previously commented, the hwcontext impl
Any feedback?
On Thu, Oct 24, 2024 at 6:54 PM wrote:
> From: Eugene Zemtsov
>
> Bug: https://issues.chromium.org/issues/372994341
> Change-Id: I695d625717c078ed6f84f44e58c34da858af4d3b
> Reviewed-on:
> https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/5958151
> Reviewed-b
Any feedback?
On Thu, Oct 24, 2024 at 6:52 PM wrote:
> From: Eugene Zemtsov
>
> It's AVPacketSideDataType, not AVFrameSideDataType.
>
> Bug: https://issues.chromium.org/issues/374797732
> Change-Id: If75702c6d639ca63827cc3370477de00544d3c0f
> Reviewed-on:
> https://chromium-review.googlesource.
Happy monthly anniversary to my not very interesting patch.
FYI, OpenSuse applied it for their ffmpeg build...
On Mon, Oct 14, 2024, at 10:54, Thomas Guillem via ffmpeg-devel wrote:
> Ping.
>
> On Mon, Oct 7, 2024, at 17:43, Thomas Guillem via ffmpeg-devel wrote:
>> Fixes the f
On Monday, November 11th, 2024 at 3:12 AM, Rémi Denis-Courmont
wrote:
> > I recently read a news article about impressive AVX-512 optimizations
> > of Motion Compensation functions and I'd like to learn more.
> > Unfortunately, the article merely linked the post on X, which
> > included a screen
On Mon, Nov 11, 2024 at 5:31 PM compn wrote:
>
> On Mon, 11 Nov 2024 17:00:42 +
> Derek Buitenhuis wrote:
>
> > This only convinces me further that it this whole setup ins't for for
> > purpose, and is being run by people who have no concept of actual
> > security. This is totally insane.
>
>
In order to reproduce the problem you need to compile with warnings as
errors and "enum-conversion" warning enabled.
This is the what clang complains about:
../../third_party/ffmpeg/libavcodec/decode.c:1469:60: error: implicit
conversion from enumeration type 'const enum AVPacketSideDataType' to
d
Am 07.11.24 um 19:55 schrieb Ronald S. Bultje:
Hi,
You raise good questions that certainly deserve further exploration, in
fact I'd be deeply supportive of such discussions. However...
On Sat, Nov 2, 2024 at 7:56 PM Michael Niedermayer
wrote:
That said, I find the discussions about such key
Dear ffmpeg developers,
I recently read a news article about impressive AVX-512 optimizations
of Motion Compensation functions and I'd like to learn more.
Unfortunately, the article merely linked the post on X, which
included a screenshot and little else.
https://x.com/FFmpeg/status/1852542388851
On Tue, 22 Oct 2024, 07:25 Michael Niedermayer,
wrote:
> On Mon, Oct 21, 2024 at 07:32:20PM +0200, AndreaMastroberti wrote:
> > ---
> > doc/filters.texi | 14 +++
> > libavfilter/ssim.h| 6 +
> > libavfilter/version.h | 4 +-
> > libavfilter/vf_ssim.c | 277
On Monday, November 11th, 2024 at 12:09 PM, compn wrote:
> are you trying to say that ffmpeg should take down the tweet?
I only provided my observations (with the caveat that I'm still potentially
lacking context). What anyone might want to do about it isn't for me to say.
If you'd like to che
From: Eugene Zemtsov
Bug: https://issues.chromium.org/issues/372994341
Change-Id: I695d625717c078ed6f84f44e58c34da858af4d3b
Reviewed-on:
https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/5958151
Reviewed-by: Dale Curtis
---
libavformat/mov.c | 2 ++
1 file changed, 2 ins
On Tue, 12 Nov 2024, 21:03 Michael Niedermayer,
wrote:
> On Tue, Nov 12, 2024 at 05:32:40PM +, Derek Buitenhuis wrote:
> > On 11/12/2024 5:07 PM, James Almer wrote:
> > > I personally don't agree with giving the domain/trademark to the
> general
> > > assembly, as some have argued. It's just
On Wed, 13 Nov 2024, 00:10 Michael Niedermayer,
wrote:
> Hi
>
> On Tue, Nov 12, 2024 at 10:38:09PM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> > On Tue, 12 Nov 2024, 21:03 Michael Niedermayer,
> > wrote:
> >
> > > On Tue, Nov 12, 2024 at 05:32:40PM +0
On Thu, Oct 31, 2024 at 6:54 PM Dmitrii Ovchinnikov
wrote:
>
> If there are no comments, I plan to merge this patch at the end of the
> week. I will update the title and description to match the current version
> of the patch.
IMO patches like this playing with sleep() are completely
unacceptable
On Tue, 12 Nov 2024, 04:07 compn, wrote:
> haven't seen arpi in a while so remove his root authorized key + remove
> him from maintainers. maybe he'll come back?
>
> anyone know how to contact tim nicholson? his mails are
> bouncing. https://uk.linkedin.com/in/tim-nicholson-7a2a3963
This is all
From: nihil-admirari <[email protected]>
Fixes build issue for Win32 targets
---
libavcodec/vulkan_encode_h264.c | 2 +-
libavcodec/vulkan_encode_h265.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vulkan_encode_h264.c b/libavcod
From: nihil-admirari <[email protected]>
Fixes build issue for Win32 targets
---
libavcodec/vulkan_encode_h264.c | 2 +-
libavcodec/vulkan_encode_h265.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vulkan_encode_h264.c b/libavcod
On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov wrote:
>
> Quoting Antoni Bizoń (2024-09-23 10:09:51)
> > I understand that the r_frame_rate is the lowest framerate with which
> > all timestamps can be represented accurately. And I know it is just a
> > guess. But why did the logic behind the calcul
On Mon, Sep 23, 2024 at 8:56 PM Anton Khirnov wrote:
>
> Quoting Kieran Kunhya via ffmpeg-devel (2024-09-23 21:30:09)
> > > On Mon, Sep 23, 2024 at 4:45 PM Kieran Kunhya via ffmpeg-devel
> > > wrote:
> > >>
> > >> On Mon, Sep 23, 2024 at 3:27 PM
> On Mon, Sep 23, 2024 at 4:45 PM Kieran Kunhya via ffmpeg-devel
> wrote:
>>
>> On Mon, Sep 23, 2024 at 3:27 PM Anton Khirnov wrote:
>> >
>> > Quoting Antoni Bizoń (2024-09-23 10:09:51)
>> > > I understand that the r_frame_rate is the lowest f
+1 for Rózsa Péter
Best regards, Reto
> On 24 Sep 2024, at 21:09, martin schitter wrote:
>
> sorry -- I had the impression, that physics count, but in the field of
> mathematics and computer sciences I would definitely vote for:
>
> "peters" (https://en.wikipedia.org/wiki/R%C3%B3zsa_P%C3%A9te
Am 20.09.24 um 02:50 schrieb Martin Schitter:
Because I'm now waiting for one week that someone finally puts my
contributed DNxUncompressed sample files to the Fate sample repo
(see:
https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-September/333471.html),
[...]
I see a v6 version not yet o
More info: Series of patches to align the implementation of aom_film_grain.c
with the AOM specification.
First time committing. Suggestions very welcome.
Signed-off-by: Andrew Segall mailto:[email protected]>>
---
libavcodec/aom_film_grain.c | 12
1 file changed, 12 insertions(+)
Details: Add support for the apply_grain_flag. This allows the film grain
process to be enabled/disabled for different display properties.
On 9/8/24, 12:06 AM, "Andrew Segall" mailto:[email protected]>> wrote:
Signed-off-by: Andrew Segall mailto:[email protected]>>
---
libavcodec/aom_film_g
Details: Limit selection of the film grain parameters to (only) those received
in the current message.
Signed-off-by: Andrew Segall mailto:[email protected]>>
---
libavcodec/aom_film_grain.c | 7 +++
libavutil/film_grain_params.h | 5 +
2 files changed, 12 insertions(+)
diff --git a/liba
On 9/20/24, 12:15 AM, "ffmpeg-devel on behalf of Lynne via ffmpeg-devel"
mailto:[email protected]> on
behalf of [email protected] <mailto:[email protected]>> wrote:
CAUTION: This email originated from outside of the organization. Do no
cf. https://trac.ffmpeg.org/ticket/11013
On Mon, Sep 30, 2024, at 10:27, Thomas Guillem via ffmpeg-devel wrote:
> Fixes the following assert:
>
> [7f1df83d17e0] vaapi generic error:
> avcodec_get_hw_frames_parameters failed: -22
> Assertion p_dst->hwaccel_threadsafe
Hello FFmpeg developers,
We are using FFmpeg libraries and DLLs in our project and are currently in the
process of removing Blowfish-related components from our codebase. During this
cleanup, we noticed that Blowfish is also present in libavutil within FFmpeg.
I would like to inquire if it is sa
On Fri, 8 Nov 2024, 06:07 Vittorio Giovara,
wrote:
> On Thu, Nov 7, 2024 at 1:03 PM Michael Niedermayer >
> wrote:
>
> > Hi all
> >
> > On Thu, Nov 07, 2024 at 12:11:49AM +0100, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > Should libpostproc be split out into a seperate source repository
Hi,
I also request reimbursement for this years GSoC summit.
My costs included:
903,91 EUR Flight (BER to SFO)
248,71 EUR Hotel
-
1152,62 EUR Total
=
Which is around 1230 USD for me and around 690 USD for Frank and in
tot
Hi,
I also request reimbursement for this years GSoC summit.
My costs included:
903,91 EUR Flight (BER to SFO)
248,71 EUR Hotel
-
1152,62 EUR Total
=
Which is around 1230 USD for me and around 690 USD for Frank and in
tot
This version is basically
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=10105
applied with a 3-way merge, squashed into a single commit,
with an added NULL check added at the end of
`ogg_finish_header`.
---
libavformat/flac_picture.c | 133 +++
libavformat/flac_pi
Hi,
I also request reimbursement for this years GSoC summit.
My costs included:
903,91 EUR Flight (BER to SFO)
248,71 EUR Hotel
-
1152,62 EUR Total
=
Which is around 1230 USD for me and around 690 USD for Frank and in
tot
On 15.11.24 19:52, Thilo Borgmann via ffmpeg-devel wrote:
Am 21.06.24 um 13:52 schrieb Anton Khirnov:
Quoting Thilo Borgmann via ffmpeg-devel (2024-06-21 12:43:17)
From: Thilo Borgmann via ffmpeg-devel
---
libavcodec/webp.c | 50 +--
1 file
Hi,
On Monday, November 25th, 2024 at 2:29 AM, Chris Hodges
wrote:
> Hi Anton (sorry for the PM),
>
> > Your mailer mangled the newlines in the patch. Consider a different
> > mailer or sending it as an attachment.
>
>
> Thanks for the info, had sent it with Thunderbird. Resending it as
> at
On Sun, 24 Nov 2024, 19:09 Michael Niedermayer,
wrote:
> Hi Kieran
>
> I think this is off topic for this thread, but i will reply with adjusted
> Subject and as a new thread
>
> On Sun, Nov 24, 2024 at 02:58:29PM +0000, Kieran Kunhya via ffmpeg-devel
> wrote:
> >
On Sun, 24 Nov 2024, 19:09 Michael Niedermayer,
wrote:
> And i hear almost everyone at VDD are old man. FFmpeg cannot be run by
> just old man. There is a need for young people and need for new ideas.
Then stop blocking a move to Gitlab based on false concerns of paranoia.
Using a mailing list
avcodec_get_hw_frames_parameters(), called by the user from get_format,
is allocating ctx->internal->hwaccel_priv_data. But the hardware
decoding setup may fail on the user side and it may fallback to software
decoding. In that case, ctx->internal->hwaccel_priv_data is still
allocated but not used
This patch is an alternative to the patch "avcodec: add
avcodec_reset_hw_frames_parameters():
On Fri, Nov 29, 2024, at 09:34, Thomas Guillem via ffmpeg-devel wrote:
> avcodec_get_hw_frames_parameters(), called by the user from get_format,
> is allocating ctx->internal->hwaccel_p
Or you can check the alternative patch: "avcodec/pthread_frame: rework assert"
On Thu, Nov 28, 2024, at 16:57, Thomas Guillem via ffmpeg-devel wrote:
> usage example:
>
> AVBufferRef *hwframes_ref;
> int ret = avcodec_get_hw_frames_parameters
avcodec_get_hw_frames_parameters(), called by the user from get_format,
is allocating ctx->internal->hwaccel_priv_data. But the hardware
decoding setup may fail on the user side and it may fallback to software
decoding. In that case, ctx->internal->hwaccel_priv_data is still
allocated but not used
Sorry for the spam. "avcodec: uninit hwaccel in case of software decoder" is a
better version.
On Fri, Nov 29, 2024, at 09:37, Thomas Guillem via ffmpeg-devel wrote:
> This patch is an alternative to the patch "avcodec: add
> avcodec_reset_hw_frames_parameters():
>
>
On Wed, 27 Nov 2024, 16:56 Michael Niedermayer,
wrote:
> Hi Kieran
>
> On Wed, Nov 27, 2024 at 12:01:03AM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> > On Tue, 26 Nov 2024, 23:32 Michael Niedermayer,
> > wrote:
> >
> > > Signed-off-by: Michael Nied
usage example:
AVBufferRef *hwframes_ref;
int ret = avcodec_get_hw_frames_parameters(ctx, hwdev_ref, hwfmt,
&hwframes_ref);
...
ret = av_hwframe_ctx_init(hwframes_ref);
if (ret < 0)
{
av_buffer_unref(&hwframes_ref);
*subject*
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-May/328600.html
___
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
[email protected] w
On 16.11.2024 19:46, Tom Vaughan wrote:
Any further details you or others could provide to help the x265 dev team
resolve the issue would be appreciated.
Can you share your steps to reproduce this issue? What parameters were changed?
Max CTU size?
Is this documentation inadequate?
https://x2
Am 17.08.24 um 01:11 schrieb Michael Niedermayer:
Fixes:
70991/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WEBP_fuzzer-5544067620995072
Fixes: use of uninintailized value
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Mi
Am 21.06.24 um 13:52 schrieb Anton Khirnov:
Quoting Thilo Borgmann via ffmpeg-devel (2024-06-21 12:43:17)
From: Thilo Borgmann via ffmpeg-devel
---
libavcodec/webp.c | 50 +--
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a
Am 12.07.24 um 01:34 schrieb Michael Niedermayer:
not sure this is possible
Fixes: CID1604446 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavformat/webpenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Should be ok if tested.
-
On Sun, 17 Nov 2024, 10:03 Anton Khirnov, wrote:
> Quoting Michael Niedermayer (2024-11-17 01:42:20)
> > I think this would work better than TC or nothing process.
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/developer.texi | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff
On Sun, Nov 24, 2024 at 12:23 PM Michael Niedermayer
wrote:
>
> Hi Remi
>
> On Sat, Nov 23, 2024 at 05:16:10PM +0100, Rémi Denis-Courmont wrote:
> >
> >
> > Le 23 novembre 2024 14:12:19 GMT+01:00, Michael Niedermayer
> > a écrit :
> > >Signed-off-by: Michael Niedermayer
> > >---
> > > doc/commu
unauthorized access to Honeywell systems.
Please use proper judgment and caution when opening attachments, clicking
links, scanning QR codes, or responding.
On 22/11/2024 15:07, Kumar, Rahul via ffmpeg-devel wrote:
> I am experiencing a crash in Niagara Workbench when streaming video with the
>
On Tue, 26 Nov 2024, 23:32 Michael Niedermayer,
wrote:
> Signed-off-by: Michael Niedermayer
> ---
> doc/infra.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/doc/infra.txt b/doc/infra.txt
> index 08dcf04c307..71ad7a7db02 100644
> --- a/doc/infra.txt
> +++ b/do
This reverts commit e206e72b83a0e512e21694a43af4df2b53f6d045.
---
tests/fate/cover-art.mak | 6 ++--
tests/fate/image.mak | 4 +--
tests/fate/lavf-image.mak | 5 +--
tests/fate/lavf-video.mak | 4 +--
tests/fate/mov.mak
Sometimes deps (external from FFmpeg) can cause different results
either because of bugs or because of drop in replacements.
This feature of alternate reference files should only be used
where absolutely necessary because other solutions are not
feasible in practice. Maintaining two reference file
This is a fixed up version of the series I sent before.
This worked for me on Ubuntu 20.04 but probably will break
with older zlib versions as Hendrik pointed out in the
previous thread. Either we must update zlib on affected
FATE clients or add more .alt files to them as well.
We could also go t
In commit bce5855afb25d318e090c2e6c16117f065458356 we avoided the
problem by using compression level 0. That fixed the problem, but
introduced a problem with older versioins of original zlib. This
caused differences 2 or more fate tests depending on the zlib version
used. See e.g. zlib commit 8ba39
When a stream has ALF filtering enabled but not CC-ALF, the CC-ALF set indexes
alf->ctb_cc_idc are being read uninitialized during ALF filtering.
This change initializes alf->ctb_cc_idc whenever ALF is enabled.
Ref. https://trac.ffmpeg.org/ticket/11325
---
libavcodec/vvc/ctu.c | 2 +-
1 file c
Hi,
Am 17.05.24 um 15:49 schrieb Michael Niedermayer:
Hi all
Before this is forgotten again, better start some dicsussion too early than too
late
I propose that if we have the oppertunity again next year to receive a grant
from STF. That we use it to fund:
[...]
the trac page for the STF 20
On Wed, 20 Nov 2024, 20:36 James Almer, wrote:
> On 11/20/2024 5:03 PM, Michael Niedermayer wrote:
> > On Tue, Nov 19, 2024 at 07:00:47PM -0500, Vittorio Giovara wrote:
> >> On Tue, Nov 19, 2024 at 6:23 PM Michael Niedermayer <
> [email protected]>
> >> wrote:
> >>
> >>> Signed-off-by: Micha
Hi Martin!
On 2024-11-07 11:36 +0200, Martin Storsjö wrote:
> If running tests with "make -j fate", the execution will stop
> after the first failing test. To get an overview of the whole
> test suite, one rather would run "make -k -j fate", which then
> again buries the results about what tests a
Introduced in commit 98698ed3c24bfd0b1e6e6db943b5f25f6046cee7
Fixes: CID1635788 CID1635789
Signed-off-by: Alexander Strasser
---
Just picked this up because of Coverity.
Not sure how to verify/test this change, but it seems plausible.
Alexander
libavcodec/cbs_h266_syntax_template.c | 2 +-
Hi Michael,
Are you able to document the differences between source.ffmpeg.org and
git.ffmpeg.org?
Why does one resolve to telepoint and one to VideoLAN? What is the
purpose of having two CNAMEs?
https://git.ffmpeg.org currently goes to a 403 Forbidden "You don't
have permission to access this re
> - a s337m decoder: it includes a resampler: output and input sample_rate
> are the same, sync is always correct. It would be possible to implement
> a full pcm fallback, but currently only a silence/pcm fallback is
> provided. A 'passthrough' option is also provided and would make it
> possible t
On Thu, Dec 5, 2024 at 2:29 PM Nicolas Gaullier
wrote:
>
> >De : Kieran Kunhya
> >Envoyé : mercredi 4 décembre 2024 23:06
> >
> >> - a s337m decoder: it includes a resampler: output and input sample_rate
> >> are the same, sync is always correct. It would be possible to implement
> >> a full pcm
On Thu, Dec 5, 2024 at 5:04 PM Michael Niedermayer
wrote:
>
> Hi Kieran
>
> On Wed, Dec 04, 2024 at 09:51:23PM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> > Hi Michael,
> >
> > Are you able to document the differences between source.ffmpeg.org and
>
Nuo Mi wrote:
> This will introduce two writes for all blocks, even if there is no CC ALF.
How about checking the sps_ccalf_enabled_flag in ff_vvc_alf_filter?
That makes sense too, but I'd think you'd need to check both
sps_ccalf_enabled_flag and the slice header
sh_alf_cc_cb_enabled_flag/sh_alf
Ping.
On Fri, Nov 29, 2024, at 11:44, Thomas Guillem via ffmpeg-devel wrote:
> avcodec_get_hw_frames_parameters(), called by the user from get_format,
> is allocating ctx->internal->hwaccel_priv_data. But the hardware
> decoding setup may fail on the user side and it may fallb
On 2024-12-04 16:07 +0200, Martin Storsjö wrote:
> On Sun, 1 Dec 2024, Alexander Strasser via ffmpeg-devel wrote:
[...]
> >
> > Would it be better to use the same description as int fate.texi ?
>
> Sure, I can add that extra parenthesis.
Thanks.
[...]
> > > +fate
Hi Leo!
On 2024-12-01 09:20 -0500, Leo Izen wrote:
> The PNGv3 Specification Draft [1] has changed the capitalization
> of mDCV and cLLI chunks (formerly mDCv and cLLi). This patch updates
> FFmpeg to work with the new chunk names while retaining decode-side
> compatibility with files created usin
On 2024-11-28 15:29 +0100, Anton Khirnov wrote:
>
> the current Technical Committee (TC) was elected on 2023-12-05 and its
> mandate lasts for one year, so we should hold a new election soon. If
> there are no unforeseen circumstances, I would like to start the vote on
> Monday 2024-12-09.
>
> As a
On 2024-12-08 12:36 +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> src/template_head2 | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/template_head2 b/src/template_head2
> index 0394ace..51da347 100644
> --- a/src/template_head2
> +++ b/src/template_he
On Tue, Dec 24, 2024 at 9:59 PM Marth64 wrote:
>
> After support was added for DVB 0502 Closed Caption coding,
What is "DVB 0502"?
Kieran
___
ffmpeg-devel mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubsc
>
> +In recent years, a significant number of developers contributing to the
> project are employed by companies,
> +unlike in the past. These employees are often compensated for specific
> tasks, and the voting rights,
> +much like the copyrights, can typically be controlled by their employers.
>
Using dynamic inputs to support the additional plugins seemed
preferable over seperate filters. For backwards compatibility, all
frame properties are copied from the first input, adjusting only
the necessary ones for multiple inputs.
Signed-off-by: Stefan Breunig
---
doc/filters.texi
The filter test exercises the timeline editing and uses a filter
which depends on the time parameter.
Signed-off-by: Stefan Breunig
---
tests/fate/filter-video.mak | 9 +
tests/ref/fate/filter-frei0r-filter | 10 ++
tests/ref/fate/filter-frei0r-source | 10 ++
3
av_frame_copy doesn't copy the input's PTS property, which resulted
in the frei0r filter always receiving the same (non-sensical) time.
For example, this results in a static distortion, when it should be
changing over time:
ffmpeg -filter_complex "testsrc2=s=342x142:d=5,frei0r=distort0r" out.mp4
The frei0r API expects the time in seconds, but was given it in
milliseconds. The bug might exist since 41f1d3a (~14 years ago),
but plugins depending on the time are unwatchable without this
patch. For example:
ffmpeg -filter_complex "testsrc2=d=5,frei0r=distort0r" out.mp4
Signed-off-by: Stefan
On Wed, Jan 1, 2025 at 11:10 PM compn wrote:
>
> On Tue, 31 Dec 2024 17:28:31 +, Kieran Kunhya via ffmpeg-devel
> wrote:
>
> > I personally don't want any control (I am not in GA or CC), I want the
> > people to control FFmpeg.
>
> iirc someone wanted, to
On 2024-12-28 12:56 +0100, Alexander Strasser via ffmpeg-devel wrote:
> On 2024-12-27 08:13 -0500, Leo Izen wrote:
[...]
> >
> > I did a bit of testing and I believe the issue is >=, specifically, it's
> > being interpreted as a redirect-out to a file named "=&q
On 2025-01-06 05:22 +0100, Michael Niedermayer wrote:
> Fixes: crash
>
> Found-by: Elias Myllymäki
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/vf_grayworld.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_grayworld.c b/libavfilter/vf_gray
Hi Jonathan!
On 2025-01-05 04:26 -0500, Jonathan Baudanza wrote:
>
>
> On Tue, Nov 26, 2024, at 1:35 AM, [email protected] wrote:
> >
> > This patch replaces av_rescale, which operates on int64_t, with
> > ff_parse_ntp_time, which operates on uint65_t. This will give the correct
> > values for times
On 2025-01-07 14:18 -0500, Leo Izen wrote:
> Fix the incorrect capitalization of the project name in a comment.
> The project is named FFmpeg, not FFMpeg.
>
> Signed-off-by: Leo Izen
> Reported-by: NyanMaths
> ---
> libavformat/ipfsgateway.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-
On 2025-01-07 10:55 -0300, James Almer wrote:
> Should reduce memory usage as well as remove code duplication.
>
> Signed-off-by: James Almer
> ---
> libavformat/isom.h | 15 +-
> libavformat/mov.c| 579 ---
> tests/ref/fate/quickdraw | 2 +-
>
Hi Ronald,
hi Michael,
hi all!
On 2025-01-07 22:32 +0100, Michael Niedermayer wrote:
> Hi Ronald
>
> On Tue, Jan 07, 2025 at 01:30:36PM -0500, Ronald S. Bultje wrote:
> > On Tue, Jan 7, 2025 at 7:02 AM Michael Niedermayer
> > wrote:
> >
> > > Hi Ronald
> > >
> > > On Mon, Jan 06, 2025 at 09:38:2
On 2025-01-07 00:23 +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> doc/faq.texi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/doc/faq.texi b/doc/faq.texi
> index 54c3fbb41fe..70002a8156d 100644
> --- a/doc/faq.texi
> +++ b/doc/faq.texi
> @@ -702,
On 2025-01-07 20:13 -0500, Leo Izen wrote:
> It should be more clear what this flag is indicating with a more
> verbose comment documenting it.
>
> Signed-off-by: Leo Izen
> ---
> libavutil/frame.h | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/frame.h b
On Mon, Dec 30, 2024 at 4:58 PM Michael Niedermayer
wrote:
But in an attempt to remove the grand prize and motive behind this.
> I will never give any power related to FFmpeg to people who continue with
> attacks/harrassment/accusations.
> (more clearly, any future democratication will exclude th
On Mon, Dec 30, 2024 at 4:58 PM Michael Niedermayer
wrote:
> But in an attempt to remove the grand prize and motive behind this.
> I will never give any power related to FFmpeg to people who continue with
> attacks/harrassment/accusations.
> (more clearly, any future democratication will exclude t
On Sun, Nov 10, 2024 at 11:53 PM Michael Niedermayer
wrote:
>
> Hi
>
> I have been given recordings of VDD by the Reconnaissance General Bureau.
> (didnt listen to all yet)
>
> IIUC there was a talk where it was suggested (by kieran?) to have some
> assembly langauge course on FFmpeg github. IMO t
>
>
> On the ffmpeg side, development continued like before, with much less
> strife on the mailing-list. And almost every day, Michael would merge
> the changes in libav into ffmpeg. That was a tremendous work and I do
> not know how Michael managed to keep on top of it for years. We made a
> coll
Am 24.12.24 um 11:35 schrieb Lingyi Kong:
fix for https://trac.ffmpeg.org/ticket/11360
A new fate test case is added to validate the fix, the smaple file is located
at https://trac.ffmpeg.org/attachment/ticket/11360/slice2_field_aurora4.264.
Uploaded. You can send requests for future file u
1801 - 1900 of 3424 matches
Mail list logo
