On Ma, 2023-12-18 at 06:51 +, Xiang, Haihao wrote:
> On Do, 2023-12-07 at 17:59 +0100, Anton Khirnov wrote:
> > Quoting Timo Rothenpieler (2023-12-06 13:26:51)
> > > On 06/12/2023 07:51, Xiang, Haihao wrote:
> > > > On Di, 2023-12-05 at 12:47 +0100, Timo Rothenpieler wrote:
> > > > > On
>> From: Tong Wu
>>
>> This implementation is based on D3D12 Video Encoding Spec:
>> https://microsoft.github.io/DirectX-Specs/d3d/D3D12VideoEncoding.html
>>
>> Sample command line for transcoding:
>> ffmpeg.exe -hwaccel d3d12va -hwaccel_output_format d3d12 -i input.mp4
>> -c:v hevc_d3d12va
From: Haihao Xiang
The default method is changed to CQP
Signed-off-by: Haihao Xiang
---
Changelog | 1 +
doc/encoders.texi | 7 +++--
libavcodec/qsvenc.c | 59 +++
libavcodec/qsvenc_av1.c | 2 +-
libavcodec/qsvenc_h264.c
From: Tong Wu
This implementation is based on D3D12 Video Encoding Spec:
https://microsoft.github.io/DirectX-Specs/d3d/D3D12VideoEncoding.html
Sample command line for transcoding:
ffmpeg.exe -hwaccel d3d12va -hwaccel_output_format d3d12 -i input.mp4
-c:v hevc_d3d12va output.mp4
Signed-off-by:
From: Tong Wu
Signed-off-by: Tong Wu
---
Changelog | 1 +
1 file changed, 1 insertion(+)
diff --git a/Changelog b/Changelog
index c5fb21d198..6923c451c5 100644
--- a/Changelog
+++ b/Changelog
@@ -24,6 +24,7 @@ version :
- ffmpeg CLI options may now be used as -/opt , which is equivalent
From: Tong Wu
Flags field is added to support diffferent resource creation.
Signed-off-by: Tong Wu
---
doc/APIchanges| 3 +++
libavutil/hwcontext_d3d12va.c | 2 +-
libavutil/hwcontext_d3d12va.h | 8
libavutil/version.h | 2 +-
4 files changed, 13
From: Tong Wu
Get constraints and set recon frame format can be shared with other HW
encoder such as D3D12. Extract this part as a new function to base
layer.
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 58 +
libavcodec/hw_base_encode.h | 2 ++
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 54 +
libavcodec/hw_base_encode.h | 3 +++
libavcodec/vaapi_encode.c | 52 +++
3 files changed, 61 insertions(+), 48 deletions(-)
diff --git
From: Tong Wu
VAAPI and D3D12VA can share rate control configuration codes. Hence, it
can be moved to base layer for simplification.
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c| 151
libavcodec/hw_base_encode.h| 34 ++
libavcodec/vaapi_encode.c
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 40 +
libavcodec/hw_base_encode.h | 3 +++
libavcodec/vaapi_encode.c | 44 ++---
3 files changed, 45 insertions(+), 42 deletions(-)
diff --git
From: Tong Wu
When allocating the VAAPIEncodePicture, pic->input_surface can be
initialized right in the place. This movement simplifies the send_frame
logic and is the preparation for moving vaapi_encode_send_frame to the base
layer.
Signed-off-by: Tong Wu
---
libavcodec/vaapi_encode.c | 8
Le 7 février 2024 23:19:41 GMT+02:00, James Almer a écrit :
>On 2/7/2024 6:10 PM, Cosmin Stejerean via ffmpeg-devel wrote:
>>
>>
>>> On Feb 7, 2024, at 11:27 AM, Lynne wrote:
>>>
>
> As a compromise, we could start requiring C11 now, and C17 in 7.1.
> Or does anyone still care
Hi,
On Wed, Feb 7, 2024 at 8:04 AM Dariusz Marcinkiewicz via ffmpeg-devel
wrote:
>
> This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx.
>
For the subject use '(libavcodec|avcodec|lavc)/libvpxenc: ...' to
better document what is being changed. See the history of the file for
examples.
Hi all,
Below is a proposal for creating a proposal to the STF -- I offered to
Michael to help, and here we are.
The objective, as I understand it, is to unlock funds for individuals
that are interested in contributing to the FFMPEG codebase, subject to
the STF criteria [1].
The suggested
On Thu, Feb 8, 2024 at 6:55 AM Kieran Kunhya wrote:
> On Wed, 7 Feb 2024 at 22:06, Paul B Mahol wrote:
>
> > On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya wrote:
> >
> > > $subj
> > >
> > > As discussed at FOSDEM.
> > >
> >
> > Author of this patch above is forced to FUZZ this decoder until
>
Hello,
On Thu, 8 Feb 2024, at 01:36, Cosmin Stejerean via ffmpeg-devel wrote:
>> There were simply no objections to moving to C11.
>> The C17 plan came about later because it has important bugfixes.
>> It doesn't really matter as compilers backported the new behaviour to C11
>> (or rather, they
On Wo, 2024-01-31 at 02:26 +, Xiang, Haihao wrote:
> On Di, 2024-01-30 at 19:07 +, Mark Thompson wrote:
> > On 30/01/2024 06:30, Xiang, Haihao wrote:
> > > On Ma, 2024-01-29 at 21:58 +, Mark Thompson wrote:
> > > > On 26/01/2024 07:25, Xiang, Haihao wrote:
> > > > > On Wo, 2023-12-20
On Wed, Feb 07, 2024 at 08:08:34AM -0500, Ronald S. Bultje wrote:
> Hi Michael,
>
> On Wed, Feb 7, 2024 at 7:58 AM Michael Niedermayer
> wrote:
>
> > Theres the person writing a SoW for work he wants to do.
> > Theres the person who accepts the SoW in FFmpeg
> > Theres the person who passes
On 2/7/2024 10:27 PM, Leo Izen wrote:
On 2/7/24 13:56, Andreas Rheinhardt wrote:
Leo Izen:
On 1/23/24 14:22, Michael Niedermayer wrote:
Hi all
As it was a little difficult for me to not loose track of what is
blocking a release. I suggest that for all release blocking issues
open a ticket
On 2/7/24 13:56, Andreas Rheinhardt wrote:
Leo Izen:
On 1/23/24 14:22, Michael Niedermayer wrote:
Hi all
As it was a little difficult for me to not loose track of what is
blocking a release. I suggest that for all release blocking issues
open a ticket and set Blocking to 7.0
that way this:
Andreas Rheinhardt:
> AVCodec.pix_fmts is only intended for encoders (decoders use
> the get_format callback to let the user choose a pix fmt).
> So remove them for the decoders for which this is possible
> without further complications; keep them for now in the codecs
> that actually use them (by
> On Feb 7, 2024, at 1:48 PM, Lynne wrote:
>
> Feb 7, 2024, 22:11 by ffmpeg-devel@ffmpeg.org:
>
>>
>>
>>> On Feb 7, 2024, at 11:27 AM, Lynne wrote:
>>>
>
> As a compromise, we could start requiring C11 now, and C17 in 7.1.
> Or does anyone still care about compilers without
On Tue, Feb 06, 2024 at 02:57:53AM -0800, Connor Worley wrote:
[...]
> new file mode 100644
> index 00..0b38b34c5c
> --- /dev/null
> +++ b/libavutil/tests/hashtable.c
> @@ -0,0 +1,108 @@
> +/*
> + * Generic hashtable tests
> + * Copyright (C) 2024 Connor Worley
> + *
> + * This file is
On Wed, 7 Feb 2024 at 22:06, Paul B Mahol wrote:
> On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya wrote:
>
> > $subj
> >
> > As discussed at FOSDEM.
> >
>
> Author of this patch above is forced to FUZZ this decoder until
> experimental flag is removed.
>
Sure, I will set some fuzzers up over
On 07.02.2024 16:04, Andreas Rheinhardt wrote:
Signed-off-by: Andreas Rheinhardt
---
libavcodec/nvdec.c | 2 +-
libavcodec/nvdec.h | 2 +-
libavcodec/nvdec_av1.c | 4 ++--
libavcodec/nvdec_h264.c | 4 ++--
libavcodec/nvdec_hevc.c | 4 ++--
5 files changed, 8 insertions(+), 8
On Wed, Feb 7, 2024 at 6:40 PM Vittorio Giovara
wrote:
> On Wed, Feb 7, 2024 at 6:38 PM Nicolas George wrote:
>
> > Anton Khirnov (12024-02-07):
> > > ...so they are precisely broken by design.
> >
> > Words words words.
> >
> > Words to try and hide that something used to work for people and
On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya wrote:
> $subj
>
> As discussed at FOSDEM.
>
Author of this patch above is forced to FUZZ this decoder until
experimental flag is removed.
>
> Kieran
> ___
> ffmpeg-devel mailing list
>
Feb 7, 2024, 22:11 by ffmpeg-devel@ffmpeg.org:
>
>
>> On Feb 7, 2024, at 11:27 AM, Lynne wrote:
>>
As a compromise, we could start requiring C11 now, and C17 in 7.1.
Or does anyone still care about compilers without even c11 support?
>>>
>>> How about C11 now and C17 in a
On 2/7/2024 6:10 PM, Cosmin Stejerean via ffmpeg-devel wrote:
On Feb 7, 2024, at 11:27 AM, Lynne wrote:
As a compromise, we could start requiring C11 now, and C17 in 7.1.
Or does anyone still care about compilers without even c11 support?
How about C11 now and C17 in a year with ffmpeg
$subj
As discussed at FOSDEM.
Kieran
0001-vvcdec-Mark-as-experimental.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
> On Feb 7, 2024, at 11:27 AM, Lynne wrote:
>
>>>
>>> As a compromise, we could start requiring C11 now, and C17 in 7.1.
>>> Or does anyone still care about compilers without even c11 support?
>>>
>>
>> How about C11 now and C17 in a year with ffmpeg 8?
>>
>
> Do you have setups and
On Wed, Feb 07, 2024 at 02:01:35PM -0500, Leo Izen wrote:
> On 2/6/24 16:23, Michael Niedermayer wrote:
> > Its true anyone of 2000 people could block a patch. This is not neccessary
> > for the argument at all though.
>
> I don't think this is really a fair statement to make. We have lots of
>
Feb 7, 2024, 19:52 by ffmpeg-devel@ffmpeg.org:
>
>
>> On Feb 7, 2024, at 1:55 AM, Anton Khirnov wrote:
>>
>> As a compromise, we could start requiring C11 now, and C17 in 7.1.
>> Or does anyone still care about compilers without even c11 support?
>>
>
> How about C11 now and C17 in a year with
Leo Izen:
> On 1/23/24 14:22, Michael Niedermayer wrote:
>> Hi all
>>
>> As it was a little difficult for me to not loose track of what is
>> blocking a release. I suggest that for all release blocking issues
>> open a ticket and set Blocking to 7.0
>> that way this:
>>
Marth64:
> Sorry for the quick follow-up to v6, I wanted to get this update out now
> hopefully
> before v6 is actually reviewed. v7 fixes a few documentation typos, options
> descriptions,
> and log messages: nothing major. I also flattened this out to be a 2-patch set
> with subtitle palette
> On Jan 23, 2024, at 11:22 AM, Michael Niedermayer
> wrote:
>
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
> * data loss
> * privacy issues
> * anything the commuity agrees should be in the release
Can we get the
> On Feb 7, 2024, at 1:55 AM, Anton Khirnov wrote:
>
> As a compromise, we could start requiring C11 now, and C17 in 7.1.
> Or does anyone still care about compilers without even c11 support?
How about C11 now and C17 in a year with ffmpeg 8?
- Cosmin
On 1/23/24 14:22, Michael Niedermayer wrote:
Hi all
As it was a little difficult for me to not loose track of what is
blocking a release. I suggest that for all release blocking issues
open a ticket and set Blocking to 7.0
that way this:
https://trac.ffmpeg.org/query?blocking=~7.0
or for the
Thank you, Andreas. This was very helpful. I will clean it up this evening.
On Wed, Feb 7, 2024 at 12:07 Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Marth64:
> > DVD subtitle palettes, which are natively YUV, are currently carried as
> > a hex string in their respective
Marth64:
> DVD subtitle palettes, which are natively YUV, are currently carried as
> a hex string in their respective subtitle streams and have
> no concept of colorspace tagging. In fact, the convention is to convert
> them to RGB prior to storage. Common players will only render
> the palettes
On Wed, Feb 7, 2024 at 6:38 PM Nicolas George wrote:
> Anton Khirnov (12024-02-07):
> > ...so they are precisely broken by design.
>
> Words words words.
>
> Words to try and hide that something used to work for people and now you
> are done with it it no longer works.
>
> Exactly the kind of
Anton Khirnov (12024-02-07):
> ...so they are precisely broken by design.
Words words words.
Words to try and hide that something used to work for people and now you
are done with it it no longer works.
Exactly the kind of attitude that killed libav, killing FFmpeg now.
--
Nicolas George
Hi,
On Wed, Feb 7, 2024 at 9:44 AM Michael Niedermayer
wrote:
> [..] i see as only options left to either do a quick vote on
> the finished Coverity bug fixing SoW, so a simple "is this text ok", and if
> yes nothing anyone says later can create another problem.
>
That seems reasonable.
Quoting Stefano Sabatini (2024-02-05 01:02:20)
> This implies a misunderstanding of what these components are. If
> they are broken with ffmpeg.c this is not a good reason to remove
> them (ffmpeg.c is not the only user).
They are broken with _any_ caller that happens to call libavformat from
a
Quoting Devin Heitmueller (2024-02-07 17:15:30)
> On Wed, Feb 7, 2024 at 4:50 AM Anton Khirnov wrote:
> > Not to mention anonymous unions were standardized in C11 and widely
> > available for many years (possibly decades) before that, so it's hardly
> > a 'latest whizbang feature'.
>
> Yeah, I
Hello Anton,
On Wed, Feb 7, 2024 at 4:50 AM Anton Khirnov wrote:
> > Now I know that developers *LOVE* to use the latest whizbang language
> > features,
>
> Could we please not have these kinds of caricatures in here? It's not
> helpful.
Permit me to rephrase:
In my 25+ years of experience as
This exposes VP8E_SET_SCREEN_CONTENT_MODE option from libvpx.
Changes since v1:
- Put the new param initialzation in the right place,
- Account for cases when the encoder's output is queued up.
Co-authored-by: Erik Språng
Signed-off-by: Dariusz Marcinkiewicz
---
doc/encoders.texi | 7
Signed-off-by: Andreas Rheinhardt
---
libavcodec/nvdec.c | 2 +-
libavcodec/nvdec.h | 2 +-
libavcodec/nvdec_av1.c | 4 ++--
libavcodec/nvdec_h264.c | 4 ++--
libavcodec/nvdec_hevc.c | 4 ++--
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/nvdec.c
On Wed, Feb 7, 2024 at 6:00 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Wu Jianhua:
> >> 发件人: ffmpeg-devel 代表 Andreas
> Rheinhardt
> >> 发送时间: 2024年2月5日 4:06
> >> 收件人: ffmpeg-devel@ffmpeg.org
> >> 主题: Re: [FFmpeg-devel] [PATCH] avcodec/x86/vvc/vvcdsp_init: fix
> unresolved
Hi,
On 1/23/2024 7:22 PM, Michael Niedermayer wrote:
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
> * data loss
> * privacy issues
> * anything the commuity agrees should be in the release
We discussed it at FOSDEM,
On Wed, Feb 07, 2024 at 08:08:34AM -0500, Ronald S. Bultje wrote:
> Hi Michael,
>
> On Wed, Feb 7, 2024 at 7:58 AM Michael Niedermayer
> wrote:
>
> > Theres the person writing a SoW for work he wants to do.
> > Theres the person who accepts the SoW in FFmpeg
> > Theres the person who passes
On Wed, 7 Feb 2024 at 03:47, Lynne wrote:
>
> Feb 7, 2024, 03:11 by kaspe...@gmail.com:
>
> > Drop per frame decode messages to AV_LOG_TRACE level.
> >
> > Signed-off-by: Kacper Michajłow
> > ---
> > libavcodec/vulkan_av1.c | 2 +-
> > libavcodec/vulkan_h264.c | 2 +-
> >
Feb 6, 2024, 12:14 by one...@gmail.com:
> Please push this ASAP, my all private projects depends on it.
>
Pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
On 1/25/2024 1:23 PM, James Almer wrote:
On 1/25/2024 10:43 AM, James Almer wrote:
After this is committed, it will be open ABI season for a few weeks,
but no
longer than a month. So if you want to do some cleaning (like removing
avpriv_
functions, or moving field offsets from public strucs
Le 7 février 2024 14:16:51 GMT+02:00, Nicolas George a écrit :
>Paul B Mahol (12024-02-06):
>> If this is again about SDR, go ahead, merge it. I no longer care.
>
>You should care. But you should care by being FOR it, not AGAINST.
>
>The people who oppose SDR are the same libav people who are
Hi Michael,
On Wed, Feb 7, 2024 at 7:58 AM Michael Niedermayer
wrote:
> Theres the person writing a SoW for work he wants to do.
> Theres the person who accepts the SoW in FFmpeg
> Theres the person who passes accepted SoW on to SPI/STF
>
> Iam sadly involved in more than one role here.
>
I
On Tue, Feb 06, 2024 at 08:38:13PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Feb 6, 2024 at 6:04 PM Michael Niedermayer
> wrote:
>
> > I think you should sign a SoW that has "Merged in git master" as a
> > Deliverable
> >
>
> I already did. It was fine.
of course its fine 9 out of 10
Signed-off-by: James Almer
---
tests/fate/mov.mak | 2 +-
tests/ref/fate/mov-heic-demux-still-image-multiple-items | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 4850c8aa94..1be7a0d15a
Export each tile as its own stream, and the grid information as a Stream Group
of type TILE_GRID.
This also enables exporting other stream items like thumbnails, which may be
present in non tiled HEIF images too. For those, the primary stream will be
tagged with the default disposition.
Based on
This will be used to support tiled image formats like HEIF.
Signed-off-by: James Almer
---
libavformat/avformat.c | 5 +++
libavformat/avformat.h | 100 +
libavformat/dump.c | 29
libavformat/options.c | 32 +
4 files
Paul B Mahol (12024-02-06):
> If this is again about SDR, go ahead, merge it. I no longer care.
You should care. But you should care by being FOR it, not AGAINST.
The people who oppose SDR are the same libav people who are disgusting
you and me and others away from the project with their
Anton Khirnov (12024-02-07):
> For instance? What do these devices support that e.g. NUT does not?
Returning the latency of the device.
> neither should we try.
This is the libav mindset we do not want in FFmpeg.
--
Nicolas George
___
ffmpeg-devel
test -z is a binary operator.
Signed-off-by: Andreas Rheinhardt
---
tests/fate-run.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 8efb1586b8..9257fb368b 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -243,7
It works until move or resize the window.
yes, that's right. I didn't notice because I didn't try to move or resize the
window.
My point is: Removing SDL would break many examples that can be found in the
internet.
Michael
___
ffmpeg-devel
Quoting Marton Balint (2024-02-04 11:11:12)
> > The 'pipe:' output can be used with a real video player such as mpv, vlc, or
> > even ffplay. For cases where the user was an application using the API they
> > should supply their own renderer.
>
> Yeah, but I never liked when people piped
Connor Worley:
> Signed-off-by: Connor Worley
> ---
> libavutil/Makefile | 2 +
> libavutil/hashtable.c | 183
> libavutil/hashtable.h | 47 +
> libavutil/tests/hashtable.c | 108 +
> 4 files changed, 340
Wu Jianhua:
>> 发件人: ffmpeg-devel 代表 Andreas Rheinhardt
>>
>> 发送时间: 2024年2月5日 4:06
>> 收件人: ffmpeg-devel@ffmpeg.org
>> 主题: Re: [FFmpeg-devel] [PATCH] avcodec/x86/vvc/vvcdsp_init: fix unresolved
>> external symbol on ARCH_X86_32
>>
>> toq...@outlook.com:
>>> From: Wu Jianhua
>>>
>>>
Quoting Michael Niedermayer (2024-02-05 21:45:10)
> On Mon, Feb 05, 2024 at 09:31:45PM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-02-05 21:27:27)
> > > please wait a bit with applying this so we understand better what it
> > > affects
> >
> > Sure, but I'd like it to go in
Quoting Niklas Haas (2024-02-05 21:55:04)
> On Mon, 05 Feb 2024 21:31:45 +0100 Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-02-05 21:27:27)
> > > please wait a bit with applying this so we understand better what it
> > > affects
> >
> > Sure, but I'd like it to go in before 7.0.
>
Quoting Devin Heitmueller (2024-02-05 21:40:43)
> On Mon, Feb 5, 2024 at 3:31 PM Anton Khirnov wrote:
> >
> > Quoting Devin Heitmueller (2024-02-05 21:13:22)
> > > On Mon, Feb 5, 2024 at 2:59 PM Anton Khirnov wrote:
> > > >
> > > > It should be available in all relevant modern compilers and will
Andreas Rheinhardt 于2024年2月5日周一 20:04写道：
> toq...@outlook.com:
> > From: Wu Jianhua
> >
> > Signed-off-by: Wu Jianhua
> > ---
> > libavcodec/x86/vvc/vvcdsp_init.c | 78
> > 1 file changed, 40 insertions(+), 38 deletions(-)
> >
> > diff --git
> On Feb 7, 2024, at 04:51, Michael Koch wrote:
>
> I didn't notice any problems with -f sdl2. I just tested again with Windows
> 11 and the latest FFmpeg build from Gyan, just 2 days old.
>
> ffmpeg -re -f lavfi -i testsrc2=s=800x600 -t 10 -f sdl2 -
>
> Works without any problems.
It
72 matches
Mail list logo
