Sorry for the previous post.
FFmpeg 7.1 as well as the latest development branch do not compile:
In function 'vaapi_encode_h264_init_picture_params':
libavcodec/vaapi_encode_h264.c:470:9: error: 'ctx' undeclared
>From 8e7d30b20d7ef62c4e637d650507672fc10bc5b4 Mon Sep 17 00:00:00 2001
From: =?U
X-TEXT: /tmp/0001.patch
FFmpeg 7.1 as well as the latest development branch do not compile:
In function 'vaapi_encode_h264_init_picture_params':
libavcodec/vaapi_encode_h264.c:470:9: error: 'ctx' undeclared
___
ffmpeg-devel mailing list
ffmpeg-devel
On Wed, Oct 2, 2024 at 12:31 AM James Almer wrote:
> On 10/1/2024 10:54 AM, Nuo Mi wrote:
> > We still need several refactors to improve the current VVC decoder's
> performance,
> > which will frequently break the API/ABI. To mitigate this, we've copied
> the executor from
> > avutil to avcodec.
For 4K/8K video processing, it's possible to have over 1,000 tasks pending on
the executor.
In such cases, O(n) and O(log(n)) insertion times are too costly.
Reducing this to O(1) will significantly decrease the time spent in critical
sections
clip
Due to the nature of multithreading, using a "ready check" mechanism may
introduce a deadlock. For example:
Suppose all tasks have been submitted to the executor, and the last thread
checks the entire list and finds
no ready tasks. It then goes to sleep, waiting for a new task. However, for
som
We still need several refactors to improve the current VVC decoder's
performance,
which will frequently break the API/ABI. To mitigate this, we've copied the
executor from
avutil to avcodec. Once the API/ABI is stable, we will move this class back to
avutil
---
libavcodec/Makefile | 1 +
Hello,
I attached the .patch so hopefully this is easier for you to apply. The
patch itself isn't very impressive, but is intended to be the first of a
series of contributions to generate uncompressed MP4 video. I'm hoping to
spark interest and receive some guidance on this task moving forward.
O
On Tue, Oct 01, 2024 at 07:51:30PM +, Kumar, Rahul via ffmpeg-devel wrote:
> 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
On 10/1/2024 7:56 AM, Anton Khirnov wrote:
Quoting James Almer (2024-09-30 23:28:13)
Complements 76eb3e5ff3a35eff01dd71aca82efcda50c4441f.
Signed-off-by: James Almer
---
libavformat/isom.h | 2 ++
libavformat/mov.c | 27 ---
2 files changed, 26 insertions(+), 3 de
This fixes corner cases (requires version 4 or a spec update)
Fixes: Ticket5548
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1.c| 21 +
libavcodec/ffv1.h| 1 +
libavcodec/ffv1dec.c | 8
libavcodec/ffv1enc.c | 2 +-
Fixes: Ticket5548
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1.c| 7 +++
libavcodec/ffv1.h| 1 +
libavcodec/ffv1enc.c | 4
3 files changed, 12 insertions(+)
diff --git a/libavcodec/ffv1.c b/libavcodec/ffv1.c
index 56a36e479fc..2b8564c
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/ffv1enc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 266ef13b247..94d9830e07b 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
On Sun, Sep 29, 2024 at 09:02:29AM -0300, James Almer wrote:
> Also, add sws_flags matching other similar tests while at it.
>
> Signed-off-by: James Almer
> ---
> tests/fate/vcodec.mak | 9 +
> tests/ref/vsynth/vsynth1-ffv1-2pass10 | 8
> tests/ref/vsynt
tis 2024-10-01 klockan 08:48 -0600 skrev Devon Sookhoo:
> Hello, I'm implementing ISO/IEC 23001-17:2024 (MPEGs uncompressed
> codec)
> and am looking for an FFmpeg developer to review/approve my
> contributions.
It's easier if you attach the patch normally so people can download and
apply it
/Tom
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
Quoting Leo Izen (2024-10-01 18:36:37)
> EXIF is basically an IFD, or a tiff directory, that contains a list of
> tags. Each tag has a type, which may also be IFD.
>
> How would you recommend I go about doing this in a way that works with
> frame side data, which as far as I understand has to be
On Tue, Oct 01, 2024 at 03:11:25AM +0200, Michael Niedermayer wrote:
> "Fixes" Ticket7063
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/ffv1enc.c | 5 +
> 1 file changed, 5 insertions(+)
will apply
[...]
--
Michael GnuPG fingerprint: 9FF
fre 2024-09-27 klockan 15:22 +0200 skrev Tomas Härdin:
> I'll push patches 1, 4 and 5 in a few days.
Pushed
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
Unless explode is requested.
Signed-off-by: James Almer
---
libavformat/mov.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4377e7..bec834023c 100644
--- a/libavformat/mov.c
+++ b/libavf
Quoting Leo Izen (2024-09-16 16:43:42)
> This patch centralizes much of the EXIF parsing and handling code for
> libavcodec, and delegates its own AVFrameSideData type to containing
> the buffer that holds EXIF metadata. This patch also adds exposes the
> exif parsing routing so it can be called by
> On Oct 1, 2024, at 14:55, Nuo Mi wrote:
>
> We still need several refactors to improve the current VVC decoder's
> performance,
> which will frequently break the API/ABI. To mitigate this, we've copied the
> executor from
> avutil to avcodec. Once the API/ABI is stable, we will move this c
On 10/1/24 7:36 AM, Anton Khirnov wrote:
Quoting James Almer (2024-09-30 01:01:39)
On 9/16/2024 11:43 AM, Leo Izen wrote:
I've made some changes to the last EXIF overhaul patch I sent,
notably I fixed up some bugs and added MakerNote parsing, so it
should not corrupt MakerNotes that are inside
---
libavfilter/f_drawgraph.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavfilter/f_drawgraph.c b/libavfilter/f_drawgraph.c
index 7c6a83be7d..24288a1175 100644
--- a/libavfilter/f_drawgraph.c
+++ b/libavfilter/f_drawgraph.c
@@ -127,9 +127,10 @@ static av_col
Signed-off-by: James Almer
---
tests/fate/mov.mak | 6 +++
tests/ref/fate/mov-heic-demux-clap-irot-imir | 47
2 files changed, 53 insertions(+)
create mode 100644 tests/ref/fate/mov-heic-demux-clap-irot-imir
diff --git a/tests/fate/mov.mak b/tests
Quoting James Almer (2024-09-30 01:01:39)
> On 9/16/2024 11:43 AM, Leo Izen wrote:
> > I've made some changes to the last EXIF overhaul patch I sent,
> > notably I fixed up some bugs and added MakerNote parsing, so it
> > should not corrupt MakerNotes that are inside TIFF files.
> >
> > MakerNote
---
libavfilter/buffersrc.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index 3d679cad53..bdf8b14451 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -439,9 +439,11 @@ static av_
On 1 Oct 2024, at 9:51, Lynne via ffmpeg-devel wrote:
> On 01/10/2024 08:55, Nuo Mi wrote:
>> We still need several refactors to improve the current VVC decoder's
>> performance,
>> which will frequently break the API/ABI. To mitigate this, we've copied the
>> executor from
>> avutil to avcod
On 01/10/2024 09:51, Lynne via ffmpeg-devel wrote:
On 01/10/2024 08:55, Nuo Mi wrote:
We still need several refactors to improve the current VVC decoder's
performance,
which will frequently break the API/ABI. To mitigate this, we've
copied the executor from
avutil to avcodec. Once the API/ABI i
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index c8fb49a7a4..d178ef59dc 100755
--- a/configure
+++ b/configure
@@ -6460,7 +6460,7 @@ EOF
for program in $x86asmexe nasm yasm; do
probe_x86asm $program && break
---
doc/mailing-list-faq.texi | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/doc/mailing-list-faq.texi b/doc/mailing-list-faq.texi
index e10d92a5fc..00af959b78 100644
--- a/doc/mailing-list-faq.texi
+++ b/doc/mailing-list-faq.texi
@@ -69,10 +69,7 @@ ffmpeg-devel mailing li
On 01/10/2024 08:55, Nuo Mi wrote:
We still need several refactors to improve the current VVC decoder's
performance,
which will frequently break the API/ABI. To mitigate this, we've copied the
executor from
avutil to avcodec. Once the API/ABI is stable, we will move this class back to
avutil
-
Hello, I'm implementing ISO/IEC 23001-17:2024 (MPEGs uncompressed codec)
and am looking for an FFmpeg developer to review/approve my contributions.
I started by writing the uncC box:
On Tue, Sep 24, 2024 at 2:51 PM Devon Sookhoo https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>>
wrote:
>* From 5
The configure change suggests installing nasm/yasm in addition to suggesting
the --disable-x86asm flag.
I also made a word change to better describe --disable-x86asm's affect on the
build.
The doc/mailing-list-faq change removes the line that says one can simply email
ffmpeg-user-requ...@ffmpeg.
---
libavfilter/src_avsynctest.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavfilter/src_avsynctest.c b/libavfilter/src_avsynctest.c
index f78cdd1dec..c46281c72b 100644
--- a/libavfilter/src_avsynctest.c
+++ b/libavfilter/src_avsynctest.c
@@
---
libavfilter/stack_internal.c | 2 +-
libavfilter/vf_stack_qsv.c | 17 ++---
libavfilter/vf_stack_vaapi.c | 13 -
3 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/libavfilter/stack_internal.c b/libavfilter/stack_internal.c
index b473fa982d..fcec119bac
Also, drop redundant calls that also happen implicitly in generic code.
---
libavfilter/f_ebur128.c | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index f71c230b45..8760c74f78 100644
--- a/libav
It achieves the same effect as ff_default_query_formats(), which gets
called implicitly.
---
libavfilter/f_streamselect.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/libavfilter/f_streamselect.c b/libavfilter/f_streamselect.c
index 4ff4e856ea..2afd22d4a3 100644
--- a
---
libavfilter/f_graphmonitor.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavfilter/f_graphmonitor.c b/libavfilter/f_graphmonitor.c
index 0ed1085610..453d1e82de 100644
--- a/libavfilter/f_graphmonitor.c
+++ b/libavfilter/f_graphmonitor.c
@@ -146,9 +146,10 @
Options are set before init, so that is the appropriate place to
validate them.
---
libavfilter/buffersink.c | 60 +++-
1 file changed, 35 insertions(+), 25 deletions(-)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 0cfac2abd5..95cb6057
We still need several refactors to improve the current VVC decoder's
performance,
which will frequently break the API/ABI. To mitigate this, we've copied the
executor from
avutil to avcodec. Once the API/ABI is stable, we will move this class back to
avutil
---
libavcodec/Makefile | 1 +
On Sat, Sep 14, 2024 at 8:59 AM Lynne via ffmpeg-devel
wrote:
>
> Unlike H264/H265, AV1 contains no fields to crop encoded output
> to specific sizes.
> AMD's hardware cannot handle encoding of unaligned dimensions for
> AV1, hence it codes 1920x1080 as 1920x1088.
>
> Add side data to crop the out
On 10/1/2024 10:54 AM, Nuo Mi wrote:
We still need several refactors to improve the current VVC decoder's
performance,
which will frequently break the API/ABI. To mitigate this, we've copied the
executor from
avutil to avcodec. Once the API/ABI is stable, we will move this class back to
avutil
Due to the nature of multithreading, using a "ready check" mechanism may
introduce a deadlock. For example:
Suppose all tasks have been submitted to the executor, and the last thread
checks the entire list and finds
no ready tasks. It then goes to sleep, waiting for a new task. However, for
som
---
libavfilter/buffersink.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 0eded68b55..b0bcc26432 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -367,
Quoting James Almer (2024-09-30 23:28:13)
> Complements 76eb3e5ff3a35eff01dd71aca82efcda50c4441f.
>
> Signed-off-by: James Almer
> ---
> libavformat/isom.h | 2 ++
> libavformat/mov.c | 27 ---
> 2 files changed, 26 insertions(+), 3 deletions(-)
Do we have samples for
---
libavfilter/qrencode.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavfilter/qrencode.c b/libavfilter/qrencode.c
index dae169b57f..d3f55013d3 100644
--- a/libavfilter/qrencode.c
+++ b/libavfilter/qrencode.c
@@ -671,7 +671,9 @@ static int request_fram
That is the more appropriate place for it than query_formats().
---
libavfilter/buffersrc.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index b5682006f0..3d679cad53 100644
--- a/libavfilter/buffersrc.c
+++ b/
---
libavfilter/vsrc_testsrc.c | 47 +++---
1 file changed, 29 insertions(+), 18 deletions(-)
diff --git a/libavfilter/vsrc_testsrc.c b/libavfilter/vsrc_testsrc.c
index f14e36a95b..b004d2d0e0 100644
--- a/libavfilter/vsrc_testsrc.c
+++ b/libavfilter/vsrc_testsrc.c
---
libavfilter/src_movie.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
index e7817c7ee7..65091b65f0 100644
--- a/libavfilter/src_movie.c
+++ b/libavfilter/src_movie.c
@@ -411,34 +411,36 @@ static
That is a more appropriate place for this, and will also be useful in
future commits.
---
libavfilter/buffersink.c | 75 ++--
1 file changed, 42 insertions(+), 33 deletions(-)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 95cb605712..0e
---
libavfilter/vaf_spectrumsynth.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/libavfilter/vaf_spectrumsynth.c b/libavfilter/vaf_spectrumsynth.c
index a62151aa4f..c8d3525b7b 100644
--- a/libavfilter/vaf_spectrumsynth.c
+++ b/libavfilter/vaf_spe
Also, drop redundant calls that also happen implicitly in generic code.
---
libavfilter/f_select.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
index ba0ae31f1b..744fef6906 100644
--- a/libavfilter/f_select.c
++
For 4K/8K video processing, it's possible to have over 1,000 tasks pending on
the executor.
In such cases, O(n) and O(log(n)) insertion times are too costly.
Reducing this to O(1) will significantly decrease the time spent in critical
sections
clip
On Tue, Oct 1, 2024 at 6:16 PM Zhao Zhili wrote:
>
>
> > On Oct 1, 2024, at 14:55, Nuo Mi wrote:
> >
> > We still need several refactors to improve the current VVC decoder's
> performance,
> > which will frequently break the API/ABI. To mitigate this, we've copied
> the executor from
> > avutil
On Sat, Oct 07, 2023 at 02:14:42AM +0200, Michael Niedermayer wrote:
> We always write minimal slices, the size calculation is wrong in some
> corner cases but as its always 1x1 (minus1) we can for now just hard-code it
>
> This helps with ticket 5548
>
> Signed-off-by: Michael Niedermayer
> ---
On Fri, 27 Sep 2024, Cameron Gutman wrote:
On Thu, Sep 26, 2024 at 4:25 PM Martin Storsjö wrote:
From: Jan Ekström
Use AV1DecContext's current_obu to access the original OBUs, and
feed them to videotoolbox, rather than the bare slice data passed
via decode_slice.
This requires a small addi
56 matches
Mail list logo
