Le 2 mai 2024 21:38:13 GMT+03:00, "Ronald S. Bultje" a
écrit :
>Hi,
>
>On Thu, May 2, 2024 at 1:44 PM Vittorio Giovara
>wrote:
>
>> I believe the path forward would be designing a system that can accommodate
>> both workflows
>>
>
>I agree with this.
I vehemently disagree with this.
Unless
Le 2 mai 2024 22:32:16 GMT+03:00, "Ondřej Fiala" a écrit :
>On Thu May 2, 2024 at 4:38 PM CEST, Rémi Denis-Courmont wrote:
>> Le torstaina 2. toukokuuta 2024, 17.25.06 EEST Ondřej Fiala a écrit :
>> > On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote:
>> > > I don't use Gmail, and
于2024年4月26日周五 20:21写道：
>
> From: huheng
>
> rename old inline yuv2yuvX to yuv2yuv_X, to avoid conflicts with
> the names of standalone asm functions. When ffmpeg is compiled with
> --disable-x86asm, using the scale function will cause the video to
> be blurred. The reason is that when
On Thu, May 02, 2024 at 11:01:02PM +0200, Marton Balint wrote:
[...]
> If we add a new FATE file for every fixed file or workflow, the amount of
> FATE samples (and the time fate will run) will increase significantly, I am
> not sure that is intended. In this case, I could only craft an MXF file,
Hi
On Thu, May 02, 2024 at 11:23:13PM +0200, Marton Balint wrote:
[...]
> surely some users depend on it behaving in a certain
> way...
who ?
I dont think you should assume something without evidence
especially for framecrc, which isnt that usefull except for
testing the output is changed vs
On Wed, May 01, 2024 at 09:56:53PM -0300, James Almer wrote:
> On 5/1/2024 9:41 PM, Michael Niedermayer wrote:
> > Fixes: CID1544265 Logically dead code
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/av1dec.c | 8
> > 1 file
On Thu, May 02, 2024 at 08:58:17AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: CID1439654 Untrusted pointer read
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/cbs_jpeg.c | 4 ++--
> > 1 file changed, 2
On Thu, May 02, 2024 at 10:28:36AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: CID1492867 Unchecked return value
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/avs3_parser.c | 4 +++-
> > 1 file changed, 3
On Thu, May 02, 2024 at 11:34:48PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Thu, May 02, 2024 at 09:12:36AM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> Fixes: CID1596605 Uninitialized scalar variable
> >>>
> >>> Sponsored-by: Sovereign Tech Fund
> >>>
Signed-off-by: Andreas Rheinhardt
---
libavformat/movenc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index b4c1db2774..f907f67752 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1244,8 +1244,7 @@ static int
Michael Niedermayer:
> On Thu, May 02, 2024 at 09:12:36AM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> Fixes: CID1596605 Uninitialized scalar variable
>>>
>>> Sponsored-by: Sovereign Tech Fund
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> libavcodec/av1dec.c | 2 +-
>>> 1
Fixes Coverity issue #1596735.
Signed-off-by: Andreas Rheinhardt
---
libavformat/movenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index e9bbfd67cf..b4c1db2774 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1221,6
On Thu, May 02, 2024 at 10:25:24AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: CID1506708 Unchecked return value
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/avs2_parser.c | 4 +++-
> > 1 file changed, 3
On Thu, May 02, 2024 at 09:12:36AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: CID1596605 Uninitialized scalar variable
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/av1dec.c | 2 +-
> > 1 file changed, 1
On 5/2/2024 6:23 PM, Marton Balint wrote:
On Wed, 1 May 2024, Michael Niedermayer wrote:
This allows detecting issues in side data related code, same as what
framecrc does for before already for packet data itself.
This basically reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e57.
Can you
On Mon, 29 Apr 2024, Tomas Härdin wrote:
mån 2024-04-15 klockan 21:34 +0200 skrev Marton Balint:
Commit ed49391961999f028e0bc55767d0eef6eeb15e49 started rejecting
negative
index segment edit rates to avoid negative av_rescale parameters.
There are two
problems with this:
1) there is already
On 01/05/2024 19:38, Dmitrii Ovchinnikov wrote:
> Adds hwcontext_amf, which allows to use shared AMF
> context for the encoder, decoder and AMF-based filters,
> without copy to the host memory.
> It will also allow you to use some optimizations in
> the interaction of components (for example, SAV)
On 2 May 2024, at 21:32, Ondřej Fiala wrote:
> On Thu May 2, 2024 at 4:38 PM CEST, Rémi Denis-Courmont wrote:
>> Le torstaina 2. toukokuuta 2024, 17.25.06 EEST Ondřej Fiala a écrit :
>>> On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote:
I don't use Gmail, and using email for
On 01/05/2024 19:38, Dmitrii Ovchinnikov wrote:
> From: Evgeny Pavlov
>
> Added AMF based h264, hevc, av1 decoders.
> Co-authored-by: Dmitrii Ovchinnikov
> v2: added encoder reinitialisation
> ---
> libavcodec/Makefile| 7 +-
> libavcodec/allcodecs.c | 3 +
> libavcodec/amfdec.c|
On Wed, May 01, 2024 at 08:38:01PM +0200, Dmitrii Ovchinnikov wrote:
> From: Evgeny Pavlov
>
> Added AMF based h264, hevc, av1 decoders.
> Co-authored-by: Dmitrii Ovchinnikov
> v2: added encoder reinitialisation
> ---
> libavcodec/Makefile| 7 +-
> libavcodec/allcodecs.c | 3 +
>
On Thu May 2, 2024 at 7:44 PM CEST, Vittorio Giovara wrote:
> On Thu, May 2, 2024 at 10:35 AM Ondřej Fiala wrote:
> > > [...]
> > You will get similar selection bias anywhere else. Even if you handled
> > such a conversation on a discussion site, the technology powering such
> > site will
On 28/04/2024 08:39, Xiang, Haihao wrote:
> From: Haihao Xiang
>
> Add AVQSVFramesContext.info and update the description.
>
> Signed-off-by: Haihao Xiang
> ---
> doc/APIchanges| 3 +++
> libavutil/hwcontext_qsv.c | 4 ++--
> libavutil/hwcontext_qsv.h | 28
On Thu May 2, 2024 at 4:38 PM CEST, Rémi Denis-Courmont wrote:
> Le torstaina 2. toukokuuta 2024, 17.25.06 EEST Ondřej Fiala a écrit :
> > On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote:
> > > I don't use Gmail, and using email for review still sucks. No matter how
> > > you slice
Hi,
On Thu, May 2, 2024 at 1:44 PM Vittorio Giovara
wrote:
> I believe the path forward would be designing a system that can accommodate
> both workflows
>
I agree with this.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 5/2/2024 12:16 PM, Andreas Rheinhardt wrote:
James Almer:
The total allocated size for types is arch dependent, so instead calculate a
checksum of the fields only.
Signed-off-by: James Almer
---
Depends on "[PATCH v3] avformat/framecrcenc: compute the checksum for side data"
On 5/2/2024 6:48 AM, Andreas Rheinhardt wrote:
Before 0f8763fbea4e8816cd54c2a481d4c048fec58394, av1_frame_ref()
and update_reference_list() could fail and therefore needed to
be checked, which incidentally set ret. This is no longer happening,
leading to a potential use of an uninitialized value
Le keskiviikkona 17. huhtikuuta 2024, 21.01.37 EEST Ramiro Polla a écrit :
> Reviewed-by: Martin Storsjö
> ---
> tests/checkasm/Makefile | 1 +
> tests/checkasm/checkasm.c | 3 ++
> tests/checkasm/checkasm.h | 1 +
> tests/checkasm/fdctdsp.c | 68 +++
>
On Thu, May 2, 2024 at 10:35 AM Ondřej Fiala wrote:
> On Thu May 2, 2024 at 4:20 PM CEST, Kieran Kunhya wrote:
> > > [...]
> > I feel it's a huge selection bias to have arguments about Gitlab vs
> Mailing
> > list handled on a mailing list.
> >
> > [...]
> You will get similar selection bias
> On May 2, 2024, at 9:35 AM, Zhao Zhili wrote:
>
> I know a developer which have contributed to FFmpeg and stop doing so after
> losing his git-send-email environment.
I'm not surprised, getting git-send-email to work can be fairly daunting.
First you have to know enough about secure SMTP to
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ondřej Fiala
> Sent: 2024年5月2日 22:25
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
>
> On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote:
> > Le 30 avril
On Wed, Apr 24, 2024 at 10:10 AM J. Dekker wrote:
>
> Signed-off-by: J. Dekker
> ---
> tests/checkasm/h264dsp.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
> index 0f484e3f43..5cb646ae49 100644
> ---
Le keskiviikkona 24. huhtikuuta 2024, 17.09.44 EEST J. Dekker a écrit :
> Signed-off-by: J. Dekker
> ---
> tests/checkasm/h264dsp.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
> index 0f484e3f43..5cb646ae49
Le keskiviikkona 24. huhtikuuta 2024, 17.09.43 EEST J. Dekker a écrit :
> Signed-off-by: J. Dekker
> ---
> libavfilter/riscv/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/riscv/Makefile b/libavfilter/riscv/Makefile
> index
Sorry, this is because a 'bpp == 8' was missed. It has been fixed in this
link
Rémi Denis-Courmont 于2024年5月2日周四 22:11写道：
> Le tiistaina 30. huhtikuuta 2024, 2.36.22 EEST flow gg a écrit :
> > updated it in the reply and https://github.com/hleft/FFmpeg/tree/vp8vp9
>
> VP9 checkasm does not pass
James Almer:
> The total allocated size for types is arch dependent, so instead calculate a
> checksum of the fields only.
>
> Signed-off-by: James Almer
> ---
> Depends on "[PATCH v3] avformat/framecrcenc: compute the checksum for side
> data"
>
> libavformat/framecrcenc.c | 76
The total allocated size for types is arch dependent, so instead calculate a
checksum of the fields only.
Signed-off-by: James Almer
---
Depends on "[PATCH v3] avformat/framecrcenc: compute the checksum for side data"
libavformat/framecrcenc.c | 76 ---
1
Le torstaina 2. toukokuuta 2024, 17.25.06 EEST Ondřej Fiala a écrit :
> On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote:
> > Le 30 avril 2024 22:15:10 GMT+03:00, "Ondřej Fiala" a
écrit :
> > >On Tue Apr 30, 2024 at 9:06 PM CEST, Hendrik Leppkes wrote:
> > >> I will take the
On Thu May 2, 2024 at 4:20 PM CEST, Kieran Kunhya wrote:
> > [...]
> I feel it's a huge selection bias to have arguments about Gitlab vs Mailing
> list handled on a mailing list.
>
> [...]
You will get similar selection bias anywhere else. Even if you handled
such a conversation on a discussion
On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote:
> Le 30 avril 2024 22:15:10 GMT+03:00, "Ondřej Fiala" a
> écrit :
> >On Tue Apr 30, 2024 at 9:06 PM CEST, Hendrik Leppkes wrote:
> >> I will take the replacement instead, thanks. Email is archaic. The
> >> entire point is to get away
Sent from my mobile device
On Thu, 2 May 2024, 15:54 Ondřej Fiala, wrote:
> On Wed May 1, 2024 at 1:01 AM CEST, Andrew Sayers wrote:
> > On Tue, Apr 30, 2024 at 09:05:05PM +0200, Ondřej Fiala wrote:
> > > [...]
> >
> > IMHO, GitHub have improved that user experience significantly in recent
>
Le tiistaina 30. huhtikuuta 2024, 2.36.22 EEST flow gg a écrit :
> updated it in the reply and https://github.com/hleft/FFmpeg/tree/vp8vp9
VP9 checkasm does not pass on that branch.
> Rémi Denis-Courmont 于2024年4月30日周二 01:57写道：
>
> > Le perjantaina 22. maaliskuuta 2024, 8.02.38 EEST flow gg a
On Wed May 1, 2024 at 1:01 AM CEST, Andrew Sayers wrote:
> On Tue, Apr 30, 2024 at 09:05:05PM +0200, Ondřej Fiala wrote:
> > [...]
>
> IMHO, GitHub have improved that user experience significantly in recent years.
> Yes you're still making a fork and pushing it, but the experience is more like
>
> On May 2, 2024, at 21:27, Andrew Sayers wrote:
>
> On Thu, May 02, 2024 at 09:00:42PM +0800, Zhao Zhili wrote:
>>
>>
>>> On May 2, 2024, at 19:01, Lynne wrote:
>>>
>>> Apr 29, 2024, 11:24 by ffmpeg-de...@pileofstuff.org:
>>>
Some headings needed to be rewritten to accomodate the
On Thu, May 02, 2024 at 09:00:42PM +0800, Zhao Zhili wrote:
>
>
> > On May 2, 2024, at 19:01, Lynne wrote:
> >
> > Apr 29, 2024, 11:24 by ffmpeg-de...@pileofstuff.org:
> >
> >> Some headings needed to be rewritten to accomodate the text,
> >> (hopefully) without changing the meaning.
> >> ---
> On May 2, 2024, at 19:01, Lynne wrote:
>
> Apr 29, 2024, 11:24 by ffmpeg-de...@pileofstuff.org:
>
>> Some headings needed to be rewritten to accomodate the text,
>> (hopefully) without changing the meaning.
>> ---
>> libavcodec/aac/aacdec.h| 2 +-
>> libavcodec/aacenc.h
James Almer:
> On 5/2/2024 6:05 AM, Andreas Rheinhardt wrote:
>> Hendrik Leppkes:
>>> On Thu, May 2, 2024 at 10:22 AM Andreas Rheinhardt
>>> wrote:
Before 0f8763fbea4e8816cd54c2a481d4c048fec58394, av1_frame_ref()
and update_reference_list() could fail and therefore needed to
On 5/2/2024 6:05 AM, Andreas Rheinhardt wrote:
Hendrik Leppkes:
On Thu, May 2, 2024 at 10:22 AM Andreas Rheinhardt
wrote:
Before 0f8763fbea4e8816cd54c2a481d4c048fec58394, av1_frame_ref()
and update_reference_list() could fail and therefore needed to
be checked, which incidentally set ret.
On Thu, May 02, 2024 at 01:01:43PM +0200, Lynne wrote:
> Apr 29, 2024, 11:24 by ffmpeg-de...@pileofstuff.org:
>
> > Some headings needed to be rewritten to accomodate the text,
> > (hopefully) without changing the meaning.
> > ---
> > libavcodec/aac/aacdec.h| 2 +-
> >
Apr 29, 2024, 11:24 by ffmpeg-de...@pileofstuff.org:
> Some headings needed to be rewritten to accomodate the text,
> (hopefully) without changing the meaning.
> ---
> libavcodec/aac/aacdec.h| 2 +-
> libavcodec/aacenc.h| 2 +-
> libavcodec/ac3enc.h|
On 01/05/2024 18:52, Ville Syrjälä wrote:
[...]
So those should be cherry-picked to the next 6.1 release (assuming
there will be one). Both cherry-pick cleanly, and afterwards the
leak is gone from the 6.1 branch as well.
From the release/6.1 branch it seems that a 6.1.2 release has been
On Thu, 11 Apr 2024 00:09:05 +0200 Michael Niedermayer
wrote:
> On Mon, Apr 08, 2024 at 11:55:02PM +0200, Niklas Haas wrote:
> > On Mon, 08 Apr 2024 22:18:33 +0200 Michael Niedermayer
> > wrote:
> > > On Fri, Apr 05, 2024 at 08:57:11PM +0200, Niklas Haas wrote:
> > > > From: Niklas Haas
> > >
On Wed, 24 Apr 2024 12:51:55 +0200 Niklas Haas wrote:
> As discussed in my previous series for fixing scale2ref[1], this filter
> is fundamentally broken, and the only real fix would be to switch to
> activate(), or ideally FFFrameSync.
>
> [1]
On Fri, 26 Apr 2024 16:29:03 -0300 James Almer wrote:
> On 4/26/2024 9:27 AM, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > Many filters modify certain aspects of frame data, e.g. through resizing
> > (vf_*scale* family), color volume mapping (vf_lut*, vf_tonemap*), or
> > possibly others.
>
On Mon, Apr 29, 2024 at 10:10:35AM +0100, Andrew Sayers wrote:
>
> I've also gone through the code looking for edge cases we haven't covered.
> Here are some questions trying to prompt an "oh yeah I forgot to mention
> that"-type answer. Anything where the answer is more like "that should
>
Before 0f8763fbea4e8816cd54c2a481d4c048fec58394, av1_frame_ref()
and update_reference_list() could fail and therefore needed to
be checked, which incidentally set ret. This is no longer happening,
leading to a potential use of an uninitialized value which is
also the subject of Coverity ticket
Hendrik Leppkes:
> On Thu, May 2, 2024 at 10:22 AM Andreas Rheinhardt
> wrote:
>>
>> Before 0f8763fbea4e8816cd54c2a481d4c048fec58394, av1_frame_ref()
>> and update_reference_list() could fail and therefore needed to
>> be checked, which incidentally set ret. This is no longer happening,
>>
On Thu, May 2, 2024 at 10:22 AM Andreas Rheinhardt
wrote:
>
> Before 0f8763fbea4e8816cd54c2a481d4c048fec58394, av1_frame_ref()
> and update_reference_list() could fail and therefore needed to
> be checked, which incidentally set ret. This is no longer happening,
> leading to a potential use of an
May 2, 2024, 10:04 by ovchinnikov.dmit...@gmail.com:
> >>Is there a reason to add this code in now?
> DX12 and Vulkan native encoders will expose less features compare to AMF,
> at least in foreseeable feature. The missing features include low latency,
> PreAnalysis including look-ahead etc.
>
Michael Niedermayer:
> Fixes: CID1492867 Unchecked return value
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/avs3_parser.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/avs3_parser.c
Michael Niedermayer:
> Fixes: CID1506708 Unchecked return value
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/avs2_parser.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/avs2_parser.c
Before 0f8763fbea4e8816cd54c2a481d4c048fec58394, av1_frame_ref()
and update_reference_list() could fail and therefore needed to
be checked, which incidentally set ret. This is no longer happening,
leading to a potential use of an uninitialized value which is
also the subject of Coverity ticket
>>Is there a reason to add this code in now?
DX12 and Vulkan native encoders will expose less features compare to AMF,
at least in foreseeable feature. The missing features include low latency,
PreAnalysis including look-ahead etc. AMF context on Windows allows fully
enable SAV - ability to
Michael Niedermayer:
> Fixes: CID1596605 Uninitialized scalar variable
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/av1dec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
>
Michael Niedermayer:
> Fixes: CID1439654 Untrusted pointer read
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/cbs_jpeg.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
>
64 matches
Mail list logo
