On Fri, 1 Dec 2023, Rémi Denis-Courmont wrote:
Le 30 novembre 2023 23:13:59 GMT+02:00, "Martin Storsjö" a
écrit :
On Thu, 30 Nov 2023, Rémi Denis-Courmont wrote:
In other words, is publishing on the FATE website worth making the
tests coverage and/or the build time worse?
By making the t
Le 30 novembre 2023 23:13:59 GMT+02:00, "Martin Storsjö" a
écrit :
>On Thu, 30 Nov 2023, Rémi Denis-Courmont wrote:
>
>> You can already test it properly as things stand, and reporting is trivial,
>> just not to the FATE website. The question is whether this is worth adding
>> to FATE.
>
>Mor
Hi,
On Thu, Nov 30, 2023 at 2:43 PM Paul B Mahol wrote:
> But how you could refactor code if one filter shares nothing with another
> filter code?
>
> Its not possible. You all seem to not understand problem at all.
I get that this patch swaps the libebur128 loudness computation with
the f_ebur1
On Thu, Nov 30, 2023 at 11:20 PM Kyle Swanson wrote:
> Hi,
>
> On Thu, Nov 30, 2023 at 1:36 PM Paul B Mahol wrote:
> >
> > Loudnorm filter is big pile of hacks, I wanted to move forward and I
> > improved it.
> >
> > I received nothing in return just some politics talks.
> >
> > I will apply thi
Hi,
On Thu, Nov 30, 2023 at 1:36 PM Paul B Mahol wrote:
>
> Loudnorm filter is big pile of hacks, I wanted to move forward and I
> improved it.
>
> I received nothing in return just some politics talks.
>
> I will apply this soon unless technical comments arise.
>
> Why would I spend on this more
On Thu, Nov 30, 2023 at 8:39 PM Kyle Swanson wrote:
> Hi,
>
> On Thu, Nov 30, 2023 at 6:11 AM Paul B Mahol wrote:
> >
> > I tested this a lot, and its great move forward.
> >
> > Make more useful testing and review next time, I'm sure you are quite
> > capable person.
>
> Paul, I agree with Anto
On Thu, Nov 30, 2023 at 12:01:25AM +, Cosmin Stejerean via ffmpeg-devel
wrote:
>
>
> > On Nov 29, 2023, at 3:14 PM, Michael Niedermayer
> > wrote:
> >
> > If you give Jerry a weight of 10 and give Tom a weight of 9, that means
> > you prefer Jerry over Tom because 10 > 9
> > If you give S
On Thu, 30 Nov 2023, Rémi Denis-Courmont wrote:
You can already test it properly as things stand, and reporting is trivial,
just not to the FATE website. The question is whether this is worth adding to
FATE.
More public test coverage is better than less, isn't it?
In other words, is publishi
On Thu, Nov 30, 2023 at 02:34:59PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-11-30 14:08:26)
> > On Sat, Nov 25, 2023 at 09:32:06PM +0100, Anton Khirnov wrote:
> > > Change the main loop and every component (demuxers, decoders, filters,
> > > encoders, muxers) to use the previ
On 2023-11-30 00:14 +0100, Michael Niedermayer wrote:
> On Tue, Nov 28, 2023 at 02:23:13PM +0100, Anton Khirnov wrote:
> > For the record, I've edited the vote description to make it more clear.
> > It now looks like this:
> >
> > Five people from the list below will become the members of the Tech
Okay, I splited and attached
Rémi Denis-Courmont 于2023年11月30日周四 23:31写道：
> Le tiistaina 28. marraskuuta 2023, 18.59.38 EET flow gg a écrit :
> >
>
> Since nobody else commented, I shall note that you should probably split
> the
> underlying lavc changes into a separate preliminary patch.
>
>
Hi,
On Thu, Nov 30, 2023 at 6:11 AM Paul B Mahol wrote:
>
> I tested this a lot, and its great move forward.
>
> Make more useful testing and review next time, I'm sure you are quite
> capable person.
Paul, I agree with Anton. Refactoring the code (i.e. changing filter
behavior) and combining it
Le torstaina 30. marraskuuta 2023, 18.28.39 EET Martin Storsjö a écrit :
> On Thu, 30 Nov 2023, Rémi Denis-Courmont wrote:
> > Le torstaina 30. marraskuuta 2023, 17.34.31 EET Martin Storsjö a écrit :
> >> Yeah, I wouldn't reuse an existing build here. For the setup I have in
> >> mind, one build do
On Nov 30, 2023, at 04:37, Thomas Mundt wrote:
Am Do., 30. Nov. 2023 um 01:23 Uhr schrieb Cosmin Stejerean via ffmpeg-devel
mailto:ffmpeg-devel@ffmpeg.org> >:
From: Cosmin Stejerean mailto:cos...@cosmin.at> >
Fixes #10688
Signed-off-by: Cosmin Stejerean mailto:cos...@cosmin.at> >
---
libavf
On Thu, 30 Nov 2023, Rémi Denis-Courmont wrote:
Le torstaina 30. marraskuuta 2023, 17.34.31 EET Martin Storsjö a écrit :
Yeah, I wouldn't reuse an existing build here. For the setup I have in
mind, one build doesn't take too horribly long (either on an old desktop
x86 machine, or a moderate aar
Le torstaina 30. marraskuuta 2023, 17.34.31 EET Martin Storsjö a écrit :
> Yeah, I wouldn't reuse an existing build here. For the setup I have in
> mind, one build doesn't take too horribly long (either on an old desktop
> x86 machine, or a moderate aarch64 server) - so it's not ideal but not a
> d
From: Zhao Zhili
'encoder' can be audio or video encoder.
---
doc/examples/transcode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/examples/transcode.c b/doc/examples/transcode.c
index ed6ac9fa03..a544ec0340 100644
--- a/doc/examples/transcode.c
+++ b/doc/examples/tra
Le tiistaina 28. marraskuuta 2023, 16.21.55 EET Michael Niedermayer a écrit :
> On Tue, Nov 28, 2023 at 09:27:08AM +0200, Rémi Denis-Courmont wrote:
> > Le 28 novembre 2023 01:22:14 GMT+02:00, Michael Niedermayer
a écrit :
> > >On Mon, Nov 27, 2023 at 05:46:40PM +0200, Rémi Denis-Courmont wrote:
> On Nov 30, 2023, at 03:07, Tomas Härdin wrote:
>
> tor 2023-11-30 klockan 01:49 +0100 skrev Stefano Sabatini:
>> This is meant to introduce functionality to handle QR codes.
>
> Why?
>
The why seems to be answered below the section you quoted in the original email
> QR codes are robust to
On Thu, 30 Nov 2023, Rémi Denis-Courmont wrote:
Le 27 novembre 2023 23:55:18 GMT+02:00, "Martin Storsjö" a
écrit :
On Mon, 27 Nov 2023, Rémi Denis-Courmont wrote:
Le maanantaina 27. marraskuuta 2023, 14.31.18 EET Martin Storsjö a écrit :
This can be useful if doing testing of uncommon CPU
Le tiistaina 28. marraskuuta 2023, 18.59.38 EET flow gg a écrit :
>
Since nobody else commented, I shall note that you should probably split the
underlying lavc changes into a separate preliminary patch.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
f
Quoting James Almer (2023-11-30 15:27:49)
>
> But this is the only boolean field.
For now. Who's to say there will not be more in the future.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ff
Le 27 novembre 2023 23:55:18 GMT+02:00, "Martin Storsjö" a
écrit :
>On Mon, 27 Nov 2023, Rémi Denis-Courmont wrote:
>
>> Le maanantaina 27. marraskuuta 2023, 14.31.18 EET Martin Storsjö a écrit :
>>> This can be useful if doing testing of uncommon CPU extensions by
>>> running tests with QEMU (
On Thu, Nov 30, 2023 at 2:57 PM Anton Khirnov wrote:
> Quoting Paul B Mahol (2023-11-30 15:01:23)
> > On Thu, Nov 30, 2023 at 2:47 PM Anton Khirnov wrote:
> >
> > > Quoting Paul B Mahol (2023-11-30 13:48:16)
> > > > On Thu, Nov 30, 2023 at 12:43 PM Anton Khirnov
> > > wrote:
> > > >
> > > > > Q
Quoting Paul B Mahol (2023-11-30 15:01:23)
> On Thu, Nov 30, 2023 at 2:47 PM Anton Khirnov wrote:
>
> > Quoting Paul B Mahol (2023-11-30 13:48:16)
> > > On Thu, Nov 30, 2023 at 12:43 PM Anton Khirnov
> > wrote:
> > >
> > > > Quoting Paul B Mahol (2023-11-28 17:51:14)
> > > > > Major change: loud
On Thu, Nov 30, 2023 at 2:47 PM Anton Khirnov wrote:
> Quoting Paul B Mahol (2023-11-30 13:48:16)
> > On Thu, Nov 30, 2023 at 12:43 PM Anton Khirnov
> wrote:
> >
> > > Quoting Paul B Mahol (2023-11-28 17:51:14)
> > > > Major change: loudnorm no longer returns oversampled audio at 192000
> Hz
> >
Quoting Paul B Mahol (2023-11-30 13:48:16)
> On Thu, Nov 30, 2023 at 12:43 PM Anton Khirnov wrote:
>
> > Quoting Paul B Mahol (2023-11-28 17:51:14)
> > > Major change: loudnorm no longer returns oversampled audio at 192000 Hz
> > > when doing dynamic processing.
> > > Oversampled audio is only us
Quoting Michael Niedermayer (2023-11-30 14:08:26)
> On Sat, Nov 25, 2023 at 09:32:06PM +0100, Anton Khirnov wrote:
> > Change the main loop and every component (demuxers, decoders, filters,
> > encoders, muxers) to use the previously added transcode scheduler. Every
> > instance of every such compo
On 11/30/2023 7:39 AM, Anton Khirnov wrote:
av_dynarray2_add_nofree
This is getting ridiculous. Do we really need 4 separate dynarray_add
functions? Wouldn't a single one with a flags argument do the job?
Maybe, but i just wanted a av_dynarray2_add() that would not free the
array on failure,
On 11/30/2023 7:40 AM, Anton Khirnov wrote:
add get_leb()
Do you expect people to understand what this means?
Will add "Read an unsigned integer coded as a variable number of
little-endian bytes".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
On Sat, Nov 25, 2023 at 09:32:06PM +0100, Anton Khirnov wrote:
> Change the main loop and every component (demuxers, decoders, filters,
> encoders, muxers) to use the previously added transcode scheduler. Every
> instance of every such component was already running in a separate
> thread, but now t
Probably ok
___
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".
On Thu, Nov 30, 2023 at 11:40 AM Anton Khirnov wrote:
> > add get_leb()
>
> Do you expect people to understand what this means?
>
get_leb() : get little-endian bits.
> --
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> h
On Thu, Nov 30, 2023 at 12:43 PM Anton Khirnov wrote:
> Quoting Paul B Mahol (2023-11-28 17:51:14)
> > Major change: loudnorm no longer returns oversampled audio at 192000 Hz
> > when doing dynamic processing.
> > Oversampled audio is only used for true peak finding now.
> > This was trivial impr
Am Do., 30. Nov. 2023 um 01:23 Uhr schrieb Cosmin Stejerean via
ffmpeg-devel :
> From: Cosmin Stejerean
>
> Fixes #10688
>
> Signed-off-by: Cosmin Stejerean
> ---
> libavfilter/vf_bwdif.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/vf_bwdi
Fixes: Out of array read
Fixes: global-buffer-overflow-AV1
Found-by: "Leonelli, Matteo"
Tested-by: "Wang, Fei W"
Reviewed-by: "Wang, Fei W"
Signed-off-by: Michael Niedermayer
---
libavcodec/av1dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/av1dec.c b/liba
Quoting Alfred Wingate via ffmpeg-devel (2023-11-14 14:26:47)
> Opaque parameters were previously added to the original definition of
> ff_nv12ToUV, leading to gcc noticing a type mismatch with -Wlto-type-mismatch.
>
> https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/f2de911818fbd7e73343803626b697f
Tomas Härdin (12023-11-30):
> Why?
Why not?
--
Nicolas George
___
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 subj
Quoting Michael Riedl (2023-11-15 13:40:45)
> Add av1_parser to av1_decoder to fix undefined reference to
> 'ff_av1_framerate'.
This is wrong, rather you should add av1_parse.o to
OBJS-$(CONFIG_AV1_DECODER) in libavcodec/Makefile
--
Anton Khirnov
___
Quoting Paul B Mahol (2023-11-28 17:51:14)
> Major change: loudnorm no longer returns oversampled audio at 192000 Hz
> when doing dynamic processing.
> Oversampled audio is only used for true peak finding now.
> This was trivial improvement as possible with ebur128 code.
> Minor changes: numerous s
On Thu, Nov 30, 2023 at 12:07 PM Tomas Härdin wrote:
> tor 2023-11-30 klockan 01:49 +0100 skrev Stefano Sabatini:
> > This is meant to introduce functionality to handle QR codes.
>
> Why?
>
For such trivial functionality using external library is unacceptable.
>
> /Tomas
>
tor 2023-11-30 klockan 01:49 +0100 skrev Stefano Sabatini:
> This is meant to introduce functionality to handle QR codes.
Why?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe,
On Mon, 27 Nov 2023, Martin Storsjö wrote:
Anyway, the concrete case I'm considering, is that we've got AArch64 code
merged, that uses the I8MM extensions. We don't have any FATE configuration
that continuously test that. Whenever there are patches, I do spin up a cloud
instance that supports
Quoting James Almer (2023-11-26 02:28:53)
> diff --git a/libavutil/iamf.h b/libavutil/iamf.h
> new file mode 100644
> index 00..1f4919efdb
> --- /dev/null
> +++ b/libavutil/iamf.h
> +enum AVIAMFAudioElementType {
> +AV_IAMF_AUDIO_ELEMENT_TYPE_CHANNEL,
> +AV_IAMF_AUDIO_ELEMENT_TYPE_S
The idea itself looks good to me, but the patch is corrupted.
Regarding the patch:
1)
>>// Keyframe overrides previous assignment.
It might be better instead of:
setting the frame type -> if key frame then overwrite
to do:
check for key frame and if it's not, set other PICTURE_TYPE
to avoid unnece
> add get_leb()
Do you expect people to understand what this means?
--
Anton Khirnov
___
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...
> av_dynarray2_add_nofree
This is getting ridiculous. Do we really need 4 separate dynarray_add
functions? Wouldn't a single one with a flags argument do the job?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
Fixes #10650
---
libavcodec/dvdsubenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dvdsubenc.c b/libavcodec/dvdsubenc.c
index d272b57675..06c2cf5e5a 100644
--- a/libavcodec/dvdsubenc.c
+++ b/libavcodec/dvdsubenc.c
@@ -376,7 +376,8 @@ static int encode_dvd_subt
Quoting Thilo Borgmann via ffmpeg-devel (2023-11-29 13:22:11)
>
>
> On 28.11.23 21:30, Derek Buitenhuis wrote:
> > On 11/28/2023 3:50 PM, Anton Khirnov wrote:
> >> Calling things generically bad is the opposite of helpful.
> > I cannot offer help on making a paragraph that I don't fully
> > under
Quoting Derek Buitenhuis (2023-11-28 21:30:12)
> On 11/28/2023 3:50 PM, Anton Khirnov wrote:
> > Calling things generically bad is the opposite of helpful.
>
> I cannot offer help on making a paragraph that I don't fully
> understand become more comprehensible, as that would require
> I understand
50 matches
Mail list logo
