Quoting Marth64 (2024-07-04 02:29:47)
> Signed-off-by: Marth64
> ---
> libavformat/dvdvideodec.c | 2 --
> 1 file changed, 2 deletions(-)
Looks trivially ok, will push
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffm
I understand why. Should ffprobe’s closed_caption field just be removed
then? The feature doesn’t work.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmp
Quoting Marth64 (2024-07-05 07:25:52)
> Signed-off-by: Marth64
> ---
> libavformat/avformat.c | 5 +
> libavformat/avformat.h | 7 +++
> 2 files changed, 12 insertions(+)
Strong no.
Internal properties are internal, we should do less exposing of them,
not more.
--
Anton Khirnov
___
Signed-off-by: Marth64
---
doc/APIchanges | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index ac7953a49c..80285d432d 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
API chan
My bad, sending correct version update for lavf now.
___
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 "unsubscri
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 do not consider 200kb '
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 floats which are a lot m
With the patchset and with RCWT demuxer as validation, the source
mp3ac325-4864-small.ts is confirmed to have eia_608 bytes.
Signed-off-by: Marth64
---
tests/ref/fate/ts-demux | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/ref/fate/ts-demux b/tests/ref/fate/ts-demux
in
Fixes the closed_captions and other properties fields emitted via
ffprobe's outputs.
Signed-off-by: Marth64
---
fftools/ffprobe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 71d1ffc21f..ed2edcd638 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ff
Signed-off-by: Marth64
---
doc/APIchanges | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index ac7953a49c..3d2039647b 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
API chan
Signed-off-by: Marth64
---
libavformat/avformat.c | 5 +
libavformat/avformat.h | 7 +++
2 files changed, 12 insertions(+)
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 140fb5b6aa..35eb0f3b62 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -850,6
After avformat_find_stream_info() calls codec_close(), the
properties are not copied in the newly created skeleton context
returned by codec_close(). This breaks display of the properties
when viewing stream information afterward e.g. via av_dump_format().
Copy the old properties over, thus fixing
At some point after 4.4.2, the internal properties of AVCodecContext
which revealed useful information (Closed Captions, Film Grain, etc.)
stopped being printed in av_dump_format() and was fixed to its
default value (0) in ffprobe.
For example, ffprobe emits a stream level field "closed_captions"
Fixes: CID1604400 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/loco.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/loco.c b/libavcodec/loco.c
index b1294a97980..4aba1eb9c52 100644
--- a/libavcodec/
Fixes: CID1604416 Unchecked return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/leaddec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/leaddec.c b/libavcodec/leaddec.c
index 947c7275bec..2f5152c2261 100644
--- a/li
Found by reviewing code related to CID1604365 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/pixlet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pixlet.c b/libavcodec/pixlet.c
index 6b6e39f2757..e9c5
Fixes: CID1604356 Overflowed constant
Fixes: CID1604573 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/imm4.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavcodec/imm4.c b/libavcodec/imm4.c
index 3a4ad
Fixes: CID1604552 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/motion_est.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/motion_est.c b/libavcodec/motion_est.c
index 554fc9780e2..e4f17fb2d86 100644
--- a
This is more a style fix than a bugfix (CID1604392 Overflowed constant)
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/iff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/iff.c b/libavcodec/iff.c
index 4b3e8e0c21e..13010b4
Fixes: CID1604429 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/mlpenc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
index 67e0e109aa0..06670de456e 100644
--- a/liba
Fixes: CID1604375 Out-of-bounds read
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/me_cmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/me_cmp.c b/libavcodec/me_cmp.c
index 592ee760840..f3e2f2482ef 100644
--- a/libavcodec/m
Found while reviewing CID1608712 Explicit null dereferenced
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/hw_base_encode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
in
Fixes: CID1604495 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/loco.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/loco.c b/libavcodec/loco.c
index 4aba1eb9c52..d73d8fa88bb 100644
--- a/libavcodec/loco.c
+++ b/libavco
Found by code review related to CID1604563 Overflowed return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/golomb.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
index 9f60fe03976..742334978d5 100644
---
Found while reviewing code related to CID1604409 Overflowed return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/golomb.h | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
index 164c2583b6c..9f60fe03976 1
Found by code review related to CID1604386 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/dxv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
index 7c873a3e922..ba23222727f 100644
-
Fixes: CID1604394 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/cri.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/cri.c b/libavcodec/cri.c
index 7b9a350967a..6932bb67456 100644
--- a/libavcodec/cri.c
+++ b/libavcode
Fixes: CID1604490 Overflowed constant
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/xsubdec.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavcodec/xsubdec.c b/libavcodec/xsubdec.c
index db7873593c8..6be4c18b0b5 100644
--
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?
> ---
> tests/fate/filter-audio.mak | 4 +++-
> 1 file changed, 3 insertions(+), 1 dele
This allows applications to preferentially select OpenMAX IL codecs
over software-only codecs using the standard AV_CODEC_CAP_HARDWARE
capability flag rather than requiring custom codec-specific logic.
Signed-off-by: Cameron Gutman
---
libavcodec/omx.c | 4 ++--
1 file changed, 2 insertions(+),
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 floats which are a lot more
precise than sse ones, for example, so it's best to crea
On Wed, 3 Jul 2024, Steven Liu wrote:
Martin Storsjö 于2024年7月3日周三 04:46写道：
On Wed, 26 Jun 2024, Martin Storsjö wrote:
> Previously, vs->start_pos was never 0 here, unless using the
> -hls_segment_size option, which wasn't allowed for SEGMENT_TYPE_FMP4.
> Therefore, this if statement was prac
On Thu, 4 Jul 2024, 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
---
tests/fate/filter-audio.mak | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/fate/filter-audio.
On Thu, Jul 4, 2024 at 10:12 PM Nicolas George wrote:
> Paul B Mahol (12024-07-04):
> > Superior only for you, no GUI users use text widgets for non-text.
>
> Users prefer an application that works now, even if its with a text
> widget, to an application that does not work now and might work when
Paul B Mahol (12024-07-04):
> Superior only for you, no GUI users use text widgets for non-text.
Users prefer an application that works now, even if its with a text
widget, to an application that does not work now and might work when
updated.
This is getting nowhere, so end of this for me.
--
On Thu, Jul 4, 2024 at 9:49 PM Nicolas George wrote:
> Paul B Mahol (12024-07-04):
> > Application vendor will issue new free-update with handling for newly
> > introduced AVOption type.
>
> So you mean your users have tu update your application to have it handle
> new types in more recent FFmpeg
Paul B Mahol (12024-07-04):
> Application vendor will issue new free-update with handling for newly
> introduced AVOption type.
So you mean your users have tu update your application to have it handle
new types in more recent FFmpeg?
How do they do if you moved to another project and do not updat
On Thu, Jul 4, 2024 at 9:33 PM Nicolas George wrote:
> Paul B Mahol (12024-07-04):
> > Nobody sane uses text manipulation in GUIs.
>
> Then how would you do it?
>
> } else if (opt->type == AV_OPT_TYPE_COLOR) {
> create_color_picker_widget(opt);
> } else if (opt->ty
Paul B Mahol (12024-07-04):
> Nobody sane uses text manipulation in GUIs.
Then how would you do it?
} else if (opt->type == AV_OPT_TYPE_COLOR) {
create_color_picker_widget(opt);
} else if (opt->type == AV_OPT_TYPE_DATE) {
create_calendar_widget(opt)
Quoting Martin Storsjö (2024-07-04 10:10:31)
> ---
> tests/fate/filter-audio.mak | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
> index 8120620afe..cf6065b93f 100644
> --- a/tests/fate/filter-audio.mak
> +++ b/tests/fate/filter-a
Filter output is not bitexact.
---
Reference file at https://up.khirnov.net/7r.pcm, please put it in
filter-reference/atempo.pcm
---
tests/fate/filter-audio.mak | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index cf
On Thu, Jul 4, 2024 at 8:34 PM Nicolas George wrote:
> Paul B Mahol (12024-07-04):
> > Modern humanoids use GUI interfaces and there text interface is reserved
> > only for actual text - STRING AVOptions and some aliases for other
> > AVOptions types.
>
> GUI can only exist for types that are kno
Paul B Mahol (12024-07-04):
> Modern humanoids use GUI interfaces and there text interface is reserved
> only for actual text - STRING AVOptions and some aliases for other
> AVOptions types.
GUI can only exist for types that are known by the application or the
GUI toolkit it uses. If you are using
On Thu, Jul 04, 2024 at 07:59:10PM +0200, Niklas Haas wrote:
> On Thu, 04 Jul 2024 19:56:56 +0200 Niklas Haas wrote:
> > On Thu, 04 Jul 2024 16:24:24 +0100 Andrew Sayers
> > wrote:
> > > On Thu, Jul 04, 2024 at 04:30:57PM +0200, Niklas Haas wrote:
> > > > From: Niklas Haas
> > > >
> > > > Base
On Thu, 04 Jul 2024 19:56:56 +0200 Niklas Haas wrote:
> On Thu, 04 Jul 2024 16:24:24 +0100 Andrew Sayers
> wrote:
> > On Thu, Jul 04, 2024 at 04:30:57PM +0200, Niklas Haas wrote:
> > > From: Niklas Haas
> > >
> > > Based on my best understanding of what they do, given the source code.
> > > --
Signed-off-by: James Almer
---
tests/fate/filter-video.mak| 4 +-
tests/ref/fate/filter-tiltandshift-422 | 55 ++
tests/ref/fate/filter-tiltandshift-444 | 55 ++
3 files changed, 113 insertions(+), 1 deletion(-)
create mode 100644 test
Fixes ticket #10950.
Signed-off-by: James Almer
---
libavfilter/vf_tiltandshift.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_tiltandshift.c b/libavfilter/vf_tiltandshift.c
index 85cce84fc3..b49a713339 100644
--- a/libavfilter/vf_tiltandshift.c
+++
On Thu, 04 Jul 2024 16:24:24 +0100 Andrew Sayers
wrote:
> On Thu, Jul 04, 2024 at 04:30:57PM +0200, Niklas Haas wrote:
> > From: Niklas Haas
> >
> > Based on my best understanding of what they do, given the source code.
> > ---
> > libswscale/swscale.h | 28 ++--
> > 1
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 basically broken (it breaks fmod() function and other code usin
Le torstaina 4. heinäkuuta 2024, 19.26.19 EEST Sean McGovern a écrit :
> Is that correlated with the comment above re: len? Or is it more general
> that I should unroll until I've exhausted the available vector registers?
You should unroll if it improves bandwidth.
--
レミ・デニ-クールモン
http://www.reml
> NG reply:
> > Paul B Mahol (12024-07-04):
> > 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 relevant for re
Hi Rémi,
First of all, thanks for the review.
On Thu, Jul 4, 2024, 07:15 Rémi Denis-Courmont wrote:
>
>
> Le 4 juillet 2024 04:23:30 GMT+03:00, Sean McGovern
> a écrit :
> >RaptorCS POWER9 (8c4t) @ 2.2GHz:
> >flac_wasted_32_c: 50.1
> >flac_wasted_32_vsx: 17.3
> >---
> > libavcodec/flacdsp.c
This is a continuation of last year's version of this filter patch, see also
https://ffmpeg.org/pipermail/ffmpeg-devel/2023-January/305517.html
It includes a fix in one of the stride variables and some cleanup in order
to adhere even more to the FFmpeg coding guidelines.
Christian Helmrich
Fr
Tested and working fine. It would be nice if you could add the default
values to the documentation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg
On Thu, Jul 04, 2024 at 04:30:57PM +0200, Niklas Haas wrote:
> From: Niklas Haas
>
> Based on my best understanding of what they do, given the source code.
> ---
> libswscale/swscale.h | 28 ++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/libswsc
Paul B Mahol (12024-07-04):
> 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 relevant for recent array options
> exte
On Thu, Jul 4, 2024 at 1:54 PM Niklas Haas wrote:
> From: Niklas Haas
>
> Shockingly, there isn't currently _any_ filter for overriding this.
> ---
> doc/filters.texi | 17 +
> libavfilter/vf_setparams.c | 19 ---
> 2 files changed, 33 insertions(+), 3
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 Jun 2024 at 16:07, Paul B Mahol wrote:
> >>
> >>> On Tue, Jun 25, 2024 at 2:47 PM Dennis Mungai
> wrote:
> >>>
>
On Thu, Jul 4, 2024 at 4:54 PM James Almer wrote:
> On 7/4/2024 11:44 AM, 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,
>
> av_o
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 Jun 2024 at 16:07, Paul B Mahol wrote:
On Tue, Jun 25, 2024 at 2:47 PM Dennis Mungai wrote:
On Sun, 28 Jun 2020 at 16:59, James Almer wrote:
On 6/27/2020 7:54 AM, Paul B Mahol wr
On 7/4/2024 11:44 AM, 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,
av_opt_{get,set,eval}_{int,double,etc}?
inefficient, and slow. This bec
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 relevant for recent array options
extension for which av_opt_ptr() hack does n
Changes since v1:
- Added commit relaxing the chr_v_pos value range in swscale to account
for the existence of 4:1:1 / 4:1:0 content.
- Fix the chroma location calculation for 4:1:1 / 4:1:0, including in
interlaced mode.
- Made the old (more granular) fields override the new one, rather than
From: Niklas Haas
Replace the manually specified chroma location by one using standard
notation, arbitrarily "bottomleft" as it is a less common path.
Required if we want to phase out the use of manual chroma locations.
---
tests/fate/filter-video.mak | 2 +-
tests/ref/fate/filter-scalec
From: Niklas Haas
---
libavfilter/vf_zscale.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 45f1bd25ce..dd0d1b7f46 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -108,11 +108,6 @@ typedef struct ZScaleContex
From: Niklas Haas
The current logic hard-coded a check for v_sub == 1. We can extend this
logic slightly to cover the case of interlaced 4:1:0 (which has v_sub ==
2).
Here is a diagram explaining this scenario (with center-siting):
a a a a a a a a
b b b b b b b b
From: Niklas Haas
Currently, this just functions as a more principled and user-friendly
replacement for the (undocumented and hard to use) *_chr_pos fields.
However, the goal is to automatically infer these values from the input
frames' chroma location, and deprecate the manual use of *_chr_pos
From: Niklas Haas
The current logic only fixes it when the user does not explicitly
specify the chroma location. However, this does not make a lot of sense.
Since there is no way to specify this property per-field, it effectively
*prevents* the user from being able to correctly scale interlaced f
From: Niklas Haas
When dealing with 4x subsampling ratios (log2 == 2), such as can arise
with 4:1:1 or 4:1:0, a value range of 512 is not enough to cover the
range of possible scenarios.
For example, bottom-sited chroma in 4:1:0 would require an offset of 768
(three luma rows). Simply double the
From: Niklas Haas
Shockingly, there isn't currently _any_ filter for overriding this.
---
doc/filters.texi | 17 +
libavfilter/vf_setparams.c | 19 ---
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
in
From: Niklas Haas
Based on my best understanding of what they do, given the source code.
---
libswscale/swscale.h | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/libswscale/swscale.h b/libswscale/swscale.h
index 9d4612aaf3..e22931cab4 100644
---
On Thu, 04 Jul 2024 13:52:00 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> Currently, this just functions as a more principled and user-friendly
> replacement for the (undocumented and hard to use) *_chr_pos fields.
>
> However, the goal is to automatically infer these values from the input
From: Niklas Haas
Replace the manually specified chroma location by one using standard
notation, arbitrarily "bottomleft" as it is a less common path.
Required if we want to phase out the use of manual chroma locations.
---
tests/fate/filter-video.mak | 2 +-
tests/ref/fate/filter-scalec
From: Niklas Haas
---
libavfilter/vf_zscale.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 45f1bd25ce..dd0d1b7f46 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -108,11 +108,6 @@ typedef struct ZScaleContex
From: Niklas Haas
Currently, this just functions as a more principled and user-friendly
replacement for the (undocumented and hard to use) *_chr_pos fields.
However, the goal is to automatically infer these values from the input
frames' chroma location, and deprecate the manual use of *_chr_pos
From: Niklas Haas
The current logic only fixes it when the user does not explicitly
specify the chroma location. However, this does not make a lot of sense.
Since there is no way to specify this property per-field, it effectively
*prevents* the user from being able to correctly scale interlaced f
From: Niklas Haas
Based on my best understanding of what they do, given the source code.
---
libswscale/swscale.h | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/libswscale/swscale.h b/libswscale/swscale.h
index 9d4612aaf3..e22931cab4 100644
---
From: Niklas Haas
Shockingly, there isn't currently _any_ filter for overriding this.
---
doc/filters.texi | 17 +
libavfilter/vf_setparams.c | 19 ---
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
in
Le 4 juillet 2024 04:23:30 GMT+03:00, Sean McGovern a
écrit :
>RaptorCS POWER9 (8c4t) @ 2.2GHz:
>flac_wasted_32_c: 50.1
>flac_wasted_32_vsx: 17.3
>---
> libavcodec/flacdsp.c | 2 ++
> libavcodec/flacdsp.h | 1 +
> libavcodec/ppc/Makefile | 2 ++
> libavcodec/ppc/flacdsp_
On 2024-07-04 04:14 am, Vittorio Giovara wrote:
On Wed, Jul 3, 2024 at 9:29 PM Gyan Doshi wrote:
On 2024-07-02 10:45 am, Gyan Doshi wrote:
---
doc/filters.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 0ff7c14
On Wed, 3 Jul 2024, Rajiv Harlalka wrote:
ffmpeg | branch: master | Rajiv Harlalka | Thu Mar
21 13:53:29 2024 +0530| [fc446eea05b9bc7de9a3c6b56dae8255bb5c5b5d] | committer: Anton
Khirnov
tests/fate/filter-audio.mak: add test for atempo audio filter
Signed-off-by: Rajiv Harlalka
Signed-off-
Every function in yuv2rgb_template.c is only compiled exactly
once, so detemplatize it.
---
libswscale/x86/yuv2rgb.c | 167 +-
libswscale/x86/yuv2rgb_template.c | 188 --
2 files changed, 162 insertions(+), 193 deletions(-)
delete mode
This seems to have had an use in the past, but it is now defined
unconditionally.
---
libswscale/swscale_internal.h | 2 --
libswscale/utils.c| 4
libswscale/x86/swscale.c | 2 --
libswscale/x86/swscale_template.c | 20
libswscale/x86/yuv2r
---
tests/fate/filter-audio.mak | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 8120620afe..cf6065b93f 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -413,6 +413,7 @@ fate-filter-hdcd-s32p: CMP = one
84 matches
Mail list logo
