[FFmpeg-devel] [PATCH 1/6] hwcontext_vulkan: add support for AV_PIX_FMT_GBRP12/14/16

--- libavcodec/ffv1enc_vulkan.c | 7 +-- libavcodec/vulkan/ffv1_enc_rct.comp | 6 +++--- libavutil/hwcontext_vulkan.c| 9 +++-- libavutil/vulkan.c | 6 +- 4 files changed, 20 insertions(+), 8 deletions(-) diff --git a/libavcodec/ffv1enc_vulkan.c b/liba

[FFmpeg-devel] [PATCH 2/6] hwcontext_vulkan: add support for AV_PIX_FMT_GRAY10/12/14

--- libavutil/hwcontext_vulkan.c | 3 +++ libavutil/vulkan.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c index 539b83cc91..7f5a74dd38 100644 --- a/libavutil/hwcontext_vulkan.c +++ b/libavutil/hwcontext_vulkan.c @@ -3

[FFmpeg-devel] [PATCH 6/6] ffv1enc_vulkan: switch to receive_packet

This allows the encoder to fully saturate all queues the GPU has, giving a good 10% in certain cases and resolutions. This also improves error resilience if an allocation fails, and properly cleans up after itself if it does. --- libavcodec/ffv1enc_vulkan.c | 421 ++--

[FFmpeg-devel] [PATCH 5/6] ffv1enc_vulkan: remove arbitrary limitation of the number of slices

--- libavcodec/ffv1enc_vulkan.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/libavcodec/ffv1enc_vulkan.c b/libavcodec/ffv1enc_vulkan.c index 7021f27572..12e95d1cb5 100644 --- a/libavcodec/ffv1enc_vulkan.c +++ b/libavcodec/ffv1enc_vulkan.c @@ -1388,13 +13

[FFmpeg-devel] [PATCH 4/6] vulkan: only apply shortcut for next context selection if selection has a submission

--- libavutil/vulkan.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c index 790f2e5aa4..591f85bbf1 100644 --- a/libavutil/vulkan.c +++ b/libavutil/vulkan.c @@ -494,7 +494,8 @@ FFVkExecContext *ff_vk_exec_get(FFVulkanContext *s, FFVkEx

[FFmpeg-devel] [PATCH 3/6] vulkan: add opaque field to execution contexts

Helps keep track of what dispatch happened where. --- libavutil/vulkan.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavutil/vulkan.h b/libavutil/vulkan.h index 9b46a279ca..ec20d1ef56 100644 --- a/libavutil/vulkan.h +++ b/libavutil/vulkan.h @@ -121,6 +121,9 @@ typedef struct FFVkExecC

Re: [FFmpeg-devel] ID3v2 demuxer

Hi On Fri, Nov 22, 2024 at 03:50:18PM +0100, Anton Khirnov wrote: > Quoting Tomas Härdin (2024-11-22 10:51:21) > > Hi all > > > > So after looking at options for how to better deal with ID3v2 I'm > > leaning towards creating a demuxer for it. I'm writing this before > > going any further with it

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: list csp.c and csp.h maintainers

On Fri, Nov 22, 2024 at 12:00:43PM -0500, Leo Izen wrote: > Ronald S. Bultje wrote most of the code before there was a refactor > and condense (which I mostly wrote). As such, listing both him and myself > as maintainers of csp.h and csp.h, which previously had no maintainer > listed at all (after

Re: [FFmpeg-devel] [PATCH 6/6] ffv1enc_vulkan: switch to receive_packet

On 11/23/24 23:10, Jerome Martinez wrote: Le 23/11/2024 à 20:58, Lynne via ffmpeg-devel a écrit : This allows the encoder to fully saturate all queues the GPU has, giving a good 10% in certain cases and resolutions. Using a RTX 4070: +50% (!!!) with 2K 10-bit content. +17% with 4K 16-bit con

Re: [FFmpeg-devel] [PATCH v8 04/10] swscale/internal: expose sws_init_single_context() internally

On Thu, Nov 21, 2024 at 02:19:26PM +0100, Niklas Haas wrote: > From: Niklas Haas > > Used by the graph API swscale wrapper, for now. > > Sponsored-by: Sovereign Tech Fund > Signed-off-by: Niklas Haas > --- > libswscale/swscale_internal.h | 3 +++ > libswscale/utils.c| 8 >

Re: [FFmpeg-devel] [PATCH] avformat/libssh: fix credential variables typo

Will push in 24-48h ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7 06/12] swscale: organize and better document flags

On Thu, Nov 21, 2024 at 01:06:20PM +0100, Niklas Haas wrote: > On Thu, 21 Nov 2024 01:26:36 +0100 Michael Niedermayer > wrote: > > Hi > > > > > > On Sat, Nov 16, 2024 at 12:25:01PM +0100, Niklas Haas wrote: > > > From: Niklas Haas > > > > > > Group them into an enum rather than random #defines,

Re: [FFmpeg-devel] [PATCH v8 05/10] swscale/graph: add new high-level scaler dispatch mechanism

On Thu, Nov 21, 2024 at 02:19:27PM +0100, Niklas Haas wrote: > From: Niklas Haas > > This interface has been designed from the ground up to serve as a new > framework for dispatching various scaling operations at a high level. This > will eventually replace the old ad-hoc system of using cascaded

Re: [FFmpeg-devel] [PATCH v8 08/10] tests/swscale: add a benchmarking mode

On Thu, Nov 21, 2024 at 02:19:30PM +0100, Niklas Haas wrote: > From: Niklas Haas > > With the ability to set the thread count as well. This benchmark includes > the constant overhead of context initialization. > > Sponsored-by: Sovereign Tech Fund > Signed-off-by: Niklas Haas > --- > libswscal

Re: [FFmpeg-devel] [PATCH v8 07/10] tests/swscale: rewrite on top of new API

On Thu, Nov 21, 2024 at 02:19:29PM +0100, Niklas Haas wrote: > From: Niklas Haas > > This rewrite cleans up the code to use AVFrames and the new swscale API. The > log format has also been simplified and expanded to account for the new > options. (Not yet implemented) > > The self testing code p

Re: [FFmpeg-devel] [PATCH v8 06/10] swscale: introduce new, dynamic scaling API

On Thu, Nov 21, 2024 at 02:19:28PM +0100, Niklas Haas wrote: > From: Niklas Haas > > As part of a larger, ongoing effort to modernize and partially rewrite > libswscale, it was decided and generally agreed upon to introduce a new > public API for libswscale. This API is designed to be less statef

Re: [FFmpeg-devel] [PATCH v8 09/10] avfilter/vf_scale: switch to new swscale API

On Thu, Nov 21, 2024 at 02:19:31PM +0100, Niklas Haas wrote: > From: Niklas Haas > > Most logic from this filter has been co-opted into swscale itself, > allowing the resulting filter to be substantially simpler as it no > longer has to worry about context initialization, interlacing, etc. > > S

Re: [FFmpeg-devel] [PATCH 6/6] ffv1enc_vulkan: switch to receive_packet

Le 23/11/2024 à 20:58, Lynne via ffmpeg-devel a écrit : This allows the encoder to fully saturate all queues the GPU has, giving a good 10% in certain cases and resolutions. Using a RTX 4070: +50% (!!!) with 2K 10-bit content. +17% with 4K 16-bit content. Also the speed with 2K content is now

Re: [FFmpeg-devel] [PATCH v8 10/10] fixup graph.c

On Thu, 21 Nov 2024 14:19:32 +0100 Niklas Haas wrote: > From: Niklas Haas > > --- > libswscale/graph.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libswscale/graph.c b/libswscale/graph.c > index cadb5954af..ee9d9847a9 100644 > --- a/libswscale/graph.c > +++ b/libsw

Re: [FFmpeg-devel] [PATCH] swscale/ppc: disable YUV2RGB AltiVec acceleration

Hi Sean On Fri, Nov 22, 2024 at 05:31:39PM -0500, Sean McGovern wrote: > Hi, > > > On Tue, Nov 19, 2024, 00:06 Sean McGovern wrote: > > > The FATE test 'checkasm-sw_yuv2rgb' currently fails on this platform, > > in both little- and big-endian configurations. > > > > Disable it by default. > >

[FFmpeg-devel] [PATCH 2/2] doc/community: Add a standard set of rules for reporting and handling mailing list issues

Signed-off-by: Michael Niedermayer --- doc/community.texi | 4 1 file changed, 4 insertions(+) diff --git a/doc/community.texi b/doc/community.texi index 8c24faef95e..072cc5b90fd 100644 --- a/doc/community.texi +++ b/doc/community.texi @@ -176,6 +176,10 @@ Constructive Criticism Only: Offer

[FFmpeg-devel] [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists

Signed-off-by: Michael Niedermayer --- doc/community.texi | 14 ++ 1 file changed, 14 insertions(+) diff --git a/doc/community.texi b/doc/community.texi index 97a49f15ede..8c24faef95e 100644 --- a/doc/community.texi +++ b/doc/community.texi @@ -162,6 +162,20 @@ Looking at issues from

Re: [FFmpeg-devel] [PATCH 2/2] doc/community: Add a standard set of rules for reporting and handling mailing list issues

Hi, On Sat, Nov 23, 2024 at 8:12 AM Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > doc/community.texi | 4 > [..] > +Moderators’ Authority: Moderators have the final say on rule enforcement. > Non-compliance may result in warnings, moderated posts, or removal from

[FFmpeg-devel] [PATCH 2/2] fftools/ffmpeg_sched: signal the main thread when a task fails

Avoids a useless -stats_period wait before exiting. Reported-by: names_are_hard --- fftools/ffmpeg_sched.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c index 318ec44b73..6a58661a5c 100644 --- a/fftools/ff

[FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg_sched: rename mux_done_{lock, cond} into finish_*

Their semantics will be changed in the following commit to not be limited to muxing. --- fftools/ffmpeg_sched.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c index b8ed8ae3f8..318ec44b73 100644 --- a/f

Re: [FFmpeg-devel] [PATCH] [RFC] [GA Vote required] Code of Conduct change re step down requests

Hi Vittorio On Sat, Nov 23, 2024 at 02:41:34AM -0500, Vittorio Giovara wrote: > On Fri, Nov 22, 2024 at 7:49 PM Michael Niedermayer > wrote: > > > On Fri, Nov 22, 2024 at 09:41:02AM -1000, compn wrote: > > > Hello, > > > > > > as the CoC rules over the GA, then the GA probably has to vote on thi

Re: [FFmpeg-devel] [PATCH] Use AVBufferPool in MOV

Hi Arnaud, On Fri, Nov 22, 2024 at 1:08 PM Arnaud Masserann wrote: > - Should the pools be per-stream (in MOVStreamContext) or per file (in > MOVContext) ? > I'm assuming the per-stream is because their bitrates (and packet sizes) will typically be substantially different. For example, video wi

Re: [FFmpeg-devel] [PATCH 2/2] doc/community: Add a standard set of rules for reporting and handling mailing list issues

Hi Ronald On Sat, Nov 23, 2024 at 08:56:50AM -0500, Ronald S. Bultje wrote: > Hi, > > On Sat, Nov 23, 2024 at 8:12 AM Michael Niedermayer > wrote: > > > Signed-off-by: Michael Niedermayer > > --- > > doc/community.texi | 4 > > [..] > > > +Moderators’ Authority: Moderators have the final

Re: [FFmpeg-devel] [PATCH 1/2] doc/community: Add a standard set of rules for software development mailing lists

Le 23 novembre 2024 14:12:19 GMT+01:00, Michael Niedermayer a écrit : >Signed-off-by: Michael Niedermayer >--- > doc/community.texi | 14 ++ > 1 file changed, 14 insertions(+) > >diff --git a/doc/community.texi b/doc/community.texi >index 97a49f15ede..8c24faef95e 100644 >--- a/doc/c

Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg_sched: rename mux_done_{lock, cond} into finish_*

Le 23 novembre 2024 10:18:01 GMT+02:00, Anton Khirnov a écrit : >Their semantics will be changed in the following commit to not be >limited to muxing. >--- > fftools/ffmpeg_sched.c | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) Both LGTM.

[FFmpeg-devel] [PATCH 6/8] avcodec/vvcdec: misc, reformat inter_data()

--- libavcodec/vvc/ctu.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c index 6c0c52b836..a32abdeb62 100644 --- a/libavcodec/vvc/ctu.c +++ b/libavcodec/vvc/ctu.c @@ -1779,7 +1779,7 @@ static int inter_data(VVCLocalContext *lc)

[FFmpeg-devel] [PATCH 7/8] avcodec/vvcdec: schedule next stage only if the current stage reports no error

If the current stage reports an error, some variables may not be correctly initialized. Scheduling the next stage could lead to the use of uninitialized variables. --- libavcodec/vvc/thread.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/vvc/thread.c b/libavco

[FFmpeg-devel] [PATCH 3/8] avcodec/cbs_h266: improve readability in subpicture parser

--- libavcodec/cbs_h266_syntax_template.c | 102 +- 1 file changed, 50 insertions(+), 52 deletions(-) diff --git a/libavcodec/cbs_h266_syntax_template.c b/libavcodec/cbs_h266_syntax_template.c index 8abd3d1ba7..fd42734166 100644 --- a/libavcodec/cbs_h266_syntax_template.c

[FFmpeg-devel] [PATCH 8/8] avcodec/vvcdec: return error if CTU size > 128

The v3 spec reserves CTU size 256. Currently, we use an uint8_t* table to hold cb_width and cb_height. If a CTU size of 256 is not split, cb_width and cb_height will overflow to 0. To avoid switching to uint16_t, rejecting CTU size 256 provides a simple solution. --- libavcodec/vvc/ps.c | 6

[FFmpeg-devel] [PATCH 4/8] avcodec/cbs_h266: stricter validation for subpicture's max width and height

Co-authored-by: Frank Plowman --- libavcodec/cbs_h266_syntax_template.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/cbs_h266_syntax_template.c b/libavcodec/cbs_h266_syntax_template.c index fd42734166..43def9220f 100644 --- a/libavcodec/cbs_h266_syntax_t

[FFmpeg-devel] [PATCH 1/8] avcodec/cbs_h266: check subpicture slices number

According to section 6.3.3, 'Spatial or component-wise partitionings,' Subpictures must cover the entire picture. Therefore, the total number of subpicture slices should equal the number of picture slices Co-authored-by: Frank Plowman --- libavcodec/cbs_h266_syntax_template.c | 5 - 1 file

[FFmpeg-devel] [PATCH 2/8] avcodec/vvcdec: ensure every CTU belongs to a slice

According to section 6.3.3 "Spatial or component-wise partitionings," CTUs should fully cover slices with no overlaps, gaps, or additions. No overlaps are ensured by task_init_parse. No gaps and no additions are ensured by this patch. Co-authored-by: Frank Plowman --- libavcodec/vvc/thread.c | 7

[FFmpeg-devel] [PATCH 5/8] avcodec/vvcdec: inter_data, check the return value from hls_merge_data

Reported-by: Frank Plowman --- libavcodec/vvc/ctu.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c index 1e06119cfd..6c0c52b836 100644 --- a/libavcodec/vvc/ctu.c +++ b/libavcodec/vvc/ctu.c @@ -1778,13 +1778,16 @@ static int inte

Re: [FFmpeg-devel] [PATCH] Update MAINTAINERS

Hi Vittorio On Fri, Nov 22, 2024 at 10:35:05AM -0500, Vittorio Giovara wrote: > On Thu, Nov 21, 2024 at 8:00 PM Michael Niedermayer > wrote: > > > On Thu, Nov 21, 2024 at 04:56:09PM -0500, Vittorio Giovara wrote: > > > On Wed, Nov 20, 2024 at 8:51 PM Michael Niedermayer < > > mich...@niedermayer