James Almer:
> Deprecate AVStream.side_data and its helpers in favor of the AVStream's
> codecpar.side_data.
>
> This will considerably simplify the propagation of global side data to
> decoders
> and from encoders. Instead of having to do it inside packets, it will be
> available during init().
Unused since 81cc0e13455baa5e6547df40dc5961d415d6fcd2.
Signed-off-by: Andreas Rheinhardt
---
Will apply this today.
libavfilter/vulkan_filter.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavfilter/vulkan_filter.c b/libavfilter/vulkan_filter.c
index f3f40465be..c77415d1be 100644
---
Forgotten after af6e232ccf8db2341361f02852017aac48772950.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vdpau_vc1.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vdpau_vc1.c b/libavcodec/vdpau_vc1.c
index 4e5ee14428..0eacc4477d 100644
---
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegpicture.c | 2 --
libavcodec/mpegvideo_dec.c | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index 44c4c8fe93..f859f163a6 100644
--- a/libavcodec/mpegpicture.c
+++
Since at least commit c954cf1e1b766a0d1992d5be0a8be0055a8e1a6a
(adding ff_encode_alloc_frame()), a large part of ff_alloc_picture()
is completely separate for the two callers. Move the caller-specific
parts out to the callers.
Signed-off-by: Andreas Rheinhardt
---
I know that the name
It is unnecessary in case of user-supplied frames, because
it happens directly after a av_frame_ref() with the same
src and dst.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
ff_alloc_picture() performs two tasks: a) In most instances,
it allocates frame buffers and b) it allocates certain
auxiliary buffers.
The exception to a) is the case when the encoder can reuse
user-supplied frames. And for these frames the auxiliary buffers
are unused, because this frame will
None of the mpegvideo encoders support anything but coded frames;
and if this were to change, it is unclear whether they would need
the adjustment here. So remove it.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 13 -
1 file changed, 13 deletions(-)
diff --git
The frame is immediately reset in the ff_mpeg_unref_picture()
call below.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index c06fdd08fe..9e28304554 100644
---
Only entries 0..max_b_frames are ever used.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 1e0aed8db9..c06fdd08fe 100644
---
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 3b6386e144..1e0aed8db9 100644
--- a/libavcodec/mpegvideo_enc.c
+++
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 09b8348ae7..3b6386e144 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 84 +++---
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 3be6c1f928..09b8348ae7 100644
---
In case "!direct" we are not reusing the input buffers
(due to e.g. insufficient alignment), but allocating
new ones. These of course do not alias with the ones
provided by the user, so these checks are always-false.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 6 --
1
mpegvideo_enc uses a fixed-size array of Pictures; a slot is
considered taken if the Picture's AVFrame is set.
When an error happens after a slot has been taken, this Picture
has typically not been reset and is therefore not usable for
future requests. The code aborts when one runs out of slots
Andreas Rheinhardt:
> It is only used by encoders; this unfortunately necessitated
> to add separate allocations to the SVQ1 encoder which uses
> motion estimation without being a full member of mpegvideo.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/mpegvideo.c | 5 +
>
Vittorio Giovara:
> On Tue, Oct 3, 2023 at 12:03 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/rv10.c | 21 +
>> 1 file changed, 5 insertions(+), 16 deletions(-)
>>
>> diff --git
Addresses the issue reported in ticket #4609.
Signed-off-by: Andreas Rheinhardt
---
libavformat/webpenc.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/libavformat/webpenc.c b/libavformat/webpenc.c
index b3f5bdc9b5..fb0cca3922 100644
---
On Tue, Oct 3, 2023 at 12:03 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/rv10.c | 21 +
> 1 file changed, 5 insertions(+), 16 deletions(-)
>
> diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
> index
On date Wednesday 2023-09-06 01:15:22 +0200, Stefano Sabatini wrote:
> On date Friday 2023-09-01 15:43:36 +0200, Stefano Sabatini wrote:
> > Also, avoid spurious end-of-line after side data entries, and improve
> > rendering of compact output, by adding an indication of the side data
> > type for
In data Sunday 2023-10-01 14:18:22 +0100, Derek Buitenhuis ha scritto:
> On 9/29/2023 7:18 AM, Stefano Sabatini wrote:
> > Once this is approved, follow instructions here to generate a refund
> > request:
> > https://www.spi-inc.org/treasurer/reimbursement-form/
>
> One note: One step says to
On Thu, Oct 5, 2023 at 10:36 AM Vittorio Giovara
wrote:
>
>
> On Wed, Oct 4, 2023 at 12:40 PM Vignesh Venkatasubramanian via
> ffmpeg-devel wrote:
>
>> They are similar to AVIF images (both use the HEIF container).
>> The only additional work needed is to parse the hvcC box and put
>> it in the
On Thu, Oct 5, 2023 at 10:58 AM Andreas Rheinhardt
wrote:
>
> Vignesh Venkat via ffmpeg-devel:
> > On Tue, Oct 3, 2023 at 9:40 PM Vittorio Giovara
> > wrote:
> >>
> >>
> >>
> >> On Wed, Oct 4, 2023 at 12:02 AM Vignesh Venkat via ffmpeg-devel
> >> wrote:
> >>>
> >>> On Tue, Oct 3, 2023 at 6:32
Sep 30, 2023, 18:57 by ffmpeg-devel@ffmpeg.org:
> Some clips (i.e. SLIST_B_Sony_9) will use PPS 0 and 8, before PPS 1-7.
> vulkan_hevc expects {sps,pps,vps}_list to be filled in order, which
> causes PPS 8 to not be added to the Vulkan session params when it is
> being used by a picture.
>
> This
Oct 5, 2023, 23:28 by ffmpeg-devel@ffmpeg.org:
> On Thu, 5 Oct 2023 23:26:38 +0200 (CEST)
> Lynne wrote:
>
>> This fixes filtering on Nvidia.
>>
>> Patch attached.
>>
>
> Tested locally. Filtering works and vulkan validation passes.
>
> Ship it!
>
Thanks, tested everywhere I could think of.
On Thu, 5 Oct 2023 23:26:38 +0200 (CEST)
Lynne wrote:
> This fixes filtering on Nvidia.
>
> Patch attached.
>
Tested locally. Filtering works and vulkan validation passes.
Ship it!
--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
This fixes filtering on Nvidia.
Patch attached.
>From 2ea0d50049bae792477c53780b3cfd0e3863d914 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Thu, 5 Oct 2023 20:25:33 +0200
Subject: [PATCH] hwcontext_vulkan: properly support STORAGE usage for
mutliplane images
Fixes multiplane support on Nvidia.
Hi,
Removal of deprecated libvmaf filter options. These options have been
deprecated since 3d29724c008d8f27fecf85757152789b074e8ef9 (Jan 23,
2022). Patch attached.
Thanks,
Kyle
0001-avfilter-libvmaf-remove-deprecated-options.patch
Description: Binary data
Hi,
On Wed, Oct 4, 2023 at 5:05 PM Vignesh Venkat wrote:
> On Wed, Oct 4, 2023 at 10:23 AM Ronald S. Bultje
> wrote:
> >
> > Hi,
> >
> > On Tue, Oct 3, 2023 at 6:53 PM Vignesh Venkatasubramanian via
> ffmpeg-devel wrote:
> >>
> >> SVT-AV1 does not support requesting keyframes at arbitrary
Rémi Denis-Courmont (12023-10-05):
> He has made no secret that he does not _want_ to be in the same team. A few
> months ago, he told several people here to (and I quote) "go fork
> [themselves]".
Honesty would have involved quoting the “if” before that.
--
Nicolas George
signature.asc
Le torstaina 5. lokakuuta 2023, 21.33.16 EEST Michael Niedermayer a écrit :
> Hi Vittorio
>
> On Thu, Oct 05, 2023 at 01:32:11PM -0400, Vittorio Giovara wrote:
> > On Thu, Oct 5, 2023 at 8:55 AM Nicolas George wrote:
> > > Anton Khirnov (12023-10-04):
> > > > It is IMO perfectly reasonable to
Fixes: signed integer overflow: 1496950099 + 728014168 cannot be represented in
type 'int'
Fixes:
62667/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEGB_fuzzer-6511785170305024
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Fixes: Assertion n>0 && n<=25 failed at libavcodec/get_bits.h:375
Fixes:
62618/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-5145745046765568
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael
Fixes: Assertion n>0 && n<=25 failed at libavcodec/get_bits.h:375
Fixes:
62617/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5156555663998976
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
Fixes: Assertion pkt->stream_index < (unsigned)s->nb_streams && "Invalid stream
index.\n" failed at libavformat/demux.c:617
Fixes:
62498/clusterfuzz-testcase-minimized-ffmpeg_dem_USM_fuzzer-4734740995112960
Found-by: continuous fuzzing process
Fixes: signed integer overflow: -2146469728 - 1488954 cannot be represented in
type 'int'
Fixes:
62490/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BONK_fuzzer-5612782399389696
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Vittorio Giovara (12023-10-05):
> There is a lot of content on the web that exemplifies that in professional
> environments:
Well, good thing FFmpeg is not a professional environment.
--
Nicolas George
signature.asc
Description: PGP signature
___
Hi Vittorio
On Thu, Oct 05, 2023 at 01:32:11PM -0400, Vittorio Giovara wrote:
> On Thu, Oct 5, 2023 at 8:55 AM Nicolas George wrote:
>
> > Anton Khirnov (12023-10-04):
> > > It is IMO perfectly reasonable to wonder why does someone who does not
> > > agree with the basic rules participate in
Vignesh Venkat via ffmpeg-devel:
> On Tue, Oct 3, 2023 at 9:40 PM Vittorio Giovara
> wrote:
>>
>>
>>
>> On Wed, Oct 4, 2023 at 12:02 AM Vignesh Venkat via ffmpeg-devel
>> wrote:
>>>
>>> On Tue, Oct 3, 2023 at 6:32 PM Vittorio Giovara
>>> wrote:
On Tue, Oct 3, 2023 at 8:30 PM Steven
On Wed, Oct 4, 2023 at 12:40 PM Vignesh Venkatasubramanian via ffmpeg-devel
wrote:
> They are similar to AVIF images (both use the HEIF container).
> The only additional work needed is to parse the hvcC box and put
> it in the extradata.
>
> With this patch applied, ffmpeg (when built with an
Oct 5, 2023, 14:24 by derek.buitenh...@gmail.com:
> On 10/3/2023 5:07 AM, Lynne wrote:
>
>> Despite this being a standard MDCT-based codec with a frame size of 1024,
>> hence a delay of 1024 samples at the start, all major encoders, excluding
>> faac and FFmpeg, use 2048 samples of padding.
>>
>
On Thu, Oct 5, 2023 at 8:55 AM Nicolas George wrote:
> Anton Khirnov (12023-10-04):
> > It is IMO perfectly reasonable to wonder why does someone who does not
> > agree with the basic rules participate in the project.
>
> Or you could have given the issue just two more seconds of thought and
>
> On Oct 4, 2023, at 7:37 PM, Lynne wrote:
>
> 2048 is just more widely encountered. I'm posting these patches
> to get an opinion:
> - do we cut nothing at all (currently)
> - do we cut 1024 (required by the standard/algorithm, and currently what our
> AAC ENcoder outputs)
> - do we cut
---
libavcodec/exrdsp.c| 4 +++-
libavcodec/exrdsp.h| 1 +
libavcodec/riscv/Makefile | 2 ++
libavcodec/riscv/exrdsp_init.c | 38 ++
libavcodec/riscv/exrdsp_rvv.S | 38 ++
5 files changed, 82
Le keskiviikkona 4. lokakuuta 2023, 22.51.10 EEST Rémi Denis-Courmont a écrit
:
> +vwmul.vv v12, v16, v28
> +vwmul.vv v8, v16, v24
> +// vwnmsac.vv does _not_ exist so multiply & subtract separately
> +vwmul.vv v4, v20, v24
> +vwmacc.vv v8, v20, v28
Anton Khirnov (12023-10-04):
> It is IMO perfectly reasonable to wonder why does someone who does not
> agree with the basic rules participate in the project.
Or you could have given the issue just two more seconds of thought and
realized that FFmpeg is a software project rather than a Nomic
This is simpler implementation-wise (it avoids an almost-always-false
check in read_packet and decreases sizeof(MatroskaTrack) by about 2/3)
and makes the side-data available directly after read_header.
It also fixes the Matroska analog of ticket #10602: If a Matroska track
has a palette, said
On 10/3/2023 5:07 AM, Lynne wrote:
> Despite this being a standard MDCT-based codec with a frame size of 1024,
> hence a delay of 1024 samples at the start, all major encoders, excluding
> faac and FFmpeg, use 2048 samples of padding.
Apple's uses 2112.
- Derek
Léon Spaans 于2023年10月5日 周四15:15写道：
> According to Patchwork the patch results in 2 "Failed to apply" warnings
> for contexts "yinshiyou/configure_loongarch64" and "andriy/configure_x86".
>
> This is not something I saw in the `make fate` output.
>
> Is there something I should know allowing me to
According to Patchwork the patch results in 2 "Failed to apply" warnings
for contexts "yinshiyou/configure_loongarch64" and "andriy/configure_x86".
This is not something I saw in the `make fate` output.
Is there something I should know allowing me to fix this? Or can this be
ignored?
50 matches
Mail list logo
