On Fri, Jul 5, 2024 at 11:34 PM Michael Niedermayer
wrote:
> > /**
> > * The exact interpretation of these quality presets depends on the backend
> > * used, but the backend-invariant common settings are derived as follows:
> > */
> > enum AVScaleQuality {
> > AV_SCALE_ULTRAFAST = 1, /* no
On Fri, Jul 05, 2024 at 08:31:17PM +0200, Niklas Haas wrote:
> On Wed, 03 Jul 2024 15:25:58 +0200 Niklas Haas wrote:
> > On Tue, 02 Jul 2024 15:27:00 +0200 Niklas Haas wrote:
> >
> > > 1. Is this a good idea, or too confusing / complex to be worth the gain?
> > >Specifically, I am worried a
On 6/1/2024 8:24 AM, Kacper Michajlow wrote:
On Wed, 29 May 2024 at 23:47, James Almer wrote:
Signed-off-by: James Almer
---
libavformat/matroskadec.c | 53 +++
1 file changed, 43 insertions(+), 10 deletions(-)
diff --git a/libavformat/matroskadec.c b/l
T-Head C908:
h264_biweight2_8_c:65.2
h264_biweight2_8_rvv_i32: 24.0
h264_biweight4_8_c: 135.2
h264_biweight4_8_rvv_i32: 48.0
h264_biweight8_8_c: 231.5
h264_biweight8_8_rvv_i32: 104.7
h264_biweight16_8_c: 454.0
h264_biweight16_8_rvv_i32: 93.7
SpacemiT X60:
h264_biweight2_
On Fri, Jul 5, 2024 at 10:09 PM Michael Niedermayer
wrote:
> On Thu, Jul 04, 2024 at 04:44:39PM +0200, Paul B Mahol wrote:
> > The AVOptions state is extremely ugly.
> >
> > It is insane to request from library users to convert non-strings option
> > values from/to strings to be able to read/chan
On Wed, Jul 03, 2024 at 02:49:57AM +0200, Lynne via ffmpeg-devel wrote:
> On 01/07/2024 01:12, Michael Niedermayer wrote:
> > Fixes: CID1605475 Logically dead code
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/aac/aacdec_usac.c | 3 ---
>
On Fri, Jul 5, 2024 at 9:38 PM Michael Niedermayer
wrote:
> On Fri, Mar 08, 2024 at 07:06:17AM +, Anton Khirnov wrote:
> > ffmpeg | branch: master | Anton Khirnov | Thu Feb
> 8 08:50:18 2024 +0100| [efe447877811f2f14f814e80ce71383e2f056f36] |
> committer: Anton Khirnov
> >
> > lavu/opt: add
On Thu, Jul 04, 2024 at 04:44:39PM +0200, Paul B Mahol wrote:
> The AVOptions state is extremely ugly.
>
> It is insane to request from library users to convert non-strings option
> values from/to strings to be able to read/change them, it is ugly,
> inefficient, and slow. This becomes more releva
On Fri, Mar 08, 2024 at 07:06:17AM +, Anton Khirnov wrote:
> ffmpeg | branch: master | Anton Khirnov | Thu Feb 8
> 08:50:18 2024 +0100| [efe447877811f2f14f814e80ce71383e2f056f36] | committer:
> Anton Khirnov
>
> lavu/opt: add array options
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.g
On Fri, Jul 5, 2024 at 5:11 PM TADANO Tokumei wrote:
>
> On 2024/07/05 0:03, Paul B Mahol wrote:
> > On Thu, Jul 4, 2024 at 4:48 PM TADANO Tokumei
> wrote:
> >
> >>
> >> On 2024/06/25 22:27, Paul B Mahol wrote:
> >>> On Tue, Jun 25, 2024 at 3:17 PM Dennis Mungai
> wrote:
> >>>
> On Tue, 25
Anton Khirnov:
> Quoting Andreas Rheinhardt (2024-07-05 02:00:35)
>> Anton Khirnov:
>>> Filter output is not bitexact.
>>> ---
>>> Reference file at https://up.khirnov.net/7r.pcm, please put it in
>>> filter-reference/atempo.pcm
>>
>> Why is the test not shortened to avoid such a huge file?
>
> I
On Wed, 03 Jul 2024 15:25:58 +0200 Niklas Haas wrote:
> On Tue, 02 Jul 2024 15:27:00 +0200 Niklas Haas wrote:
>
> > 1. Is this a good idea, or too confusing / complex to be worth the gain?
> >Specifically, I am worried about confusion arising due to differences
> >in behavior, and imple
There are two implementations here:
- a generic scalable one processing one column at a time,
- a specialised processing one (fixed-size) row at a time.
Unsurprisingly, the generic one works out better with smaller widths.
With larger widths, the gains from filling vectors are outweighed by
the ex
>From aa824368fc020e052905fc1a651477d2880281d5 Mon Sep 17 00:00:00 2001
From: vckt
Date: Fri, 5 Jul 2024 18:51:32 +0530
Subject: [PATCH] avformat/hls: Fixed incorrect behaviour of default setting,
added autoselect and forced
In absence of defualt in var_stream_map, it was setting default=yes on
On 7/5/2024 2:18 PM, Martin Storsjö wrote:
On Fri, 5 Jul 2024, James Almer wrote:
On 7/5/2024 2:38 AM, Anton Khirnov wrote:
Quoting James Almer (2024-07-04 22:45:28)
On 7/4/2024 4:04 PM, Anton Khirnov wrote:
Filter output is not bitexact.
---
Reference file at https://up.khirnov.net/7r.pcm,
On Fri, 5 Jul 2024, James Almer wrote:
On 7/5/2024 2:38 AM, Anton Khirnov wrote:
Quoting James Almer (2024-07-04 22:45:28)
On 7/4/2024 4:04 PM, Anton Khirnov wrote:
Filter output is not bitexact.
---
Reference file at https://up.khirnov.net/7r.pcm, please put it in
filter-reference/atempo.pcm
On 7/5/2024 2:38 AM, Anton Khirnov wrote:
Quoting James Almer (2024-07-04 22:45:28)
On 7/4/2024 4:04 PM, Anton Khirnov wrote:
Filter output is not bitexact.
---
Reference file at https://up.khirnov.net/7r.pcm, please put it in
filter-reference/atempo.pcm
How did you create it? x86_32 uses x87
On 7/5/2024 7:42 AM, Anton Khirnov wrote:
And av_stream_get_codec_timebase().
They were both added for ffmpeg CLI, which no longer calls either of
them. Furthermore the notion of "internal stream timing info" that needs
to be transferred with a special magic API function is fundamentally
flawed
>From d4e321aa71b2b0dd8fc6d94e39cfa870d7ffa3ba Mon Sep 17 00:00:00 2001
From: vckt
Date: Fri, 5 Jul 2024 18:51:32 +0530
Subject: [PATCH] avformat/hls: Fixed incorrect behaviour of default setting,
added autoselect and forced
In absence of defualt in var_stream_map, it was setting default=yes on
In absence of defualt in var_stream_map, it was setting default=yes on
every stream,
but according to RFC8216 4.3.4.1 only one stream in a default group may
have that.
Additionally added support for autoselect=yes/no, whose presence
combined with default
means that it MUST be YES. Similarly for
In absence of default in var_stream_map, it was setting default=yes on
every stream,
but according to RFC8216 4.3.4.1 only one stream in a default group may
have that.
Additionally added support for autoselect=yes/no, whose presence
combined with default
means that it MUST be YES. Similarly for
Signed-off-by: Michael Niedermayer
---
tools/coverity.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tools/coverity.c b/tools/coverity.c
index 19a132a9767..541e108238d 100644
--- a/tools/coverity.c
+++ b/tools/coverity.c
@@ -31,6 +31,17 @@
#define NULL (void *)0
+t
Quoting Andreas Rheinhardt (2024-07-03 16:49:55)
> asivery via ffmpeg-devel:
> > I'm sending the patch again, so that it is correctly rebased on the current
> > master.
> > Here are the two sample files required by the FATE test:
> > https://0x0.st/Xaw2.aea/boxboy333_house_music_multitrack.aea
> >
Stop trying to invent some "framerate-based" timebase when there is no
reason to think the stream is CFR at all.
---
fftools/ffmpeg_mux_init.c| 7 +--
tests/fate/ffmpeg.mak| 2 +-
tests/ref/fate/copy-trac4914-avi | 4 ++--
3 files changed, 4 insertions(+), 9 deletions(-)
d
And av_stream_get_codec_timebase().
They were both added for ffmpeg CLI, which no longer calls either of
them. Furthermore the notion of "internal stream timing info" that needs
to be transferred with a special magic API function is fundamentally
flawed and should be removed.
---
doc/APIchanges
Will be useful in following commit.
---
fftools/ffmpeg_dec.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c
index 70de151301..c2bcf784b0 100644
--- a/fftools/ffmpeg_dec.c
+++ b/fftools/ffmpeg_dec.c
@@ -260,6 +260,10
Hi,
On Thu, Jul 4, 2024 at 7:52 PM Mario Hros wrote:
> It is possible that removal would be faster, though I haven't benchmarked
> that. I think that Kodi only uses this function for UI textures, so nothing
> performance-intensive. My main point was that the current MMX code without
> EMMS is
> On Jun 28, 2024, at 12:46, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> configure use "-Wl,-framework,foo" and "-framework foo" to specify
> dependencies on Apple frameworks. These two styles essentially do
> the same thing when build ffmpeg. However, they do make difference
> when generate p
28 matches
Mail list logo
