On date Tuesday 2024-07-02 10:17:26 +0200, Paul B Mahol wrote:
> No need for query function.
> This implementation is so blatantly slow and inefficient that is not useful.
> Source filters should use .activate instead.
> Many more other issues...
It was pending reviews for more than two weeks.
Ab
On date Thursday 2024-07-04 17:29:16 +0200, Michael Koch wrote:
> Tested and working fine. It would be nice if you could add the default
> values to the documentation.
Will do, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.
On date Tuesday 2024-07-02 20:38:00 +0200, Marvin Scholz wrote:
> An incorrect calculation in ff_perlin_init causes a write to the
> stack array at index 256, which is out of bounds.
>
> Fixes: CID1608711
> ---
> libavfilter/perlin.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
On date Tuesday 2024-07-02 10:08:37 +0100, Andrew Sayers wrote:
> Some notes about this version:
>
> As previously mentioned, I think this is better with all three patches,
> but can live without #2.
>
> I think I've followed the deprecation instructions, but editing APIchanges
> seems to imply
On date Tuesday 2024-07-02 11:58:09 +0800, Zhao Zhili wrote:
>
> > 在 2024年7月2日，上午6:33，Stefano Sabatini 写道：
> >
> > On date Sunday 2024-06-16 18:08:29 +0100, Andrew Sayers wrote:
> >> The old name could be misread as the opposite of "AV_OPT_FLAG_READONLY" -
> >> some things can be set at runtime
On date Tuesday 2024-07-02 10:08:38 +0100, Andrew Sayers wrote:
> The old name could be misread as the opposite of "AV_OPT_FLAG_READONLY" -
> some things can be set at runtime, others are read-only. Clarify that
> this refers to options that can be set after the struct is initialized.
> ---
> doc
On Sat, Jul 6, 2024 at 11:44 AM Stefano Sabatini wrote:
> On date Tuesday 2024-07-02 10:08:37 +0100, Andrew Sayers wrote:
> > Some notes about this version:
> >
> > As previously mentioned, I think this is better with all three patches,
> > but can live without #2.
> >
> > I think I've followed t
On Sat, Jul 06, 2024 at 11:37:19AM +0200, Stefano Sabatini wrote:
> On date Tuesday 2024-07-02 10:08:37 +0100, Andrew Sayers wrote:
[...]
> While I agree with Anton that we should avoid duplication, for the
> usual arguments that a reference should avoid duplication of content
> as much as possible
On Sat, Jul 6, 2024 at 11:19 AM Stefano Sabatini wrote:
> On date Tuesday 2024-07-02 10:17:26 +0200, Paul B Mahol wrote:
> > No need for query function.
> > This implementation is so blatantly slow and inefficient that is not
> useful.
> > Source filters should use .activate instead.
> > Many mor
There are two implementations here:
- a generic scalable one processing two columns 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 e
T-Head C908:
h264_biweight2_8_c:58.0
h264_biweight2_8_rvv_i32: 11.2
h264_biweight4_8_c: 106.0
h264_biweight4_8_rvv_i32: 22.7
h264_biweight8_8_c: 205.7
h264_biweight8_8_rvv_i32: 50.0
h264_biweight16_8_c: 403.5
h264_biweight16_8_rvv_i32: 83.2
SpacemiT X60:
h264_weight2_8_
Superseded.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
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 "unsubscrib
Will merge soonish except for feedback.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
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
On date Saturday 2024-07-06 12:40:55 +0200, Paul B Mahol wrote:
> On Sat, Jul 6, 2024 at 11:19 AM Stefano Sabatini wrote:
[...]
> Not interested in your marginal toys or project.
Good, so the next time avoid the rant and save even more time.
___
ffmpeg-
On date Tuesday 2024-07-02 00:41:39 -0500, Marth64 wrote:
> Some discs (usually same ones with padding cells), also have empty
> padding PTTs / chapters to accompany them. This results, for example,
> in an extra chapter marker that starts and ends at 0 (no duration).
>
> Don't add these empty cha
On date Tuesday 2024-07-02 01:03:29 -0500, Marth64 wrote:
> Remove initializing ret = 0, in areas where ret is
> only used to hold an error value, immediately returned,
> and the function would otherwise return a literal 0.
>
> Signed-off-by: Marth64
> ---
> libavformat/dvdvideodec.c | 12 ++
On date Tuesday 2024-07-02 01:41:31 -0500, Marth64 wrote:
> When -trim option is used (by default), padding cells
> at the beginning of the title are supposed to be ignored.
> The current implementation does the ignoring after we
> have locked on to the PGC navigation event stream,
> but does not s
On date Tuesday 2024-07-02 10:56:34 +0100, Andrew Sayers wrote:
> On Tue, Jul 02, 2024 at 12:16:21AM +0200, Stefano Sabatini wrote:
> > On date Sunday 2024-06-16 19:02:51 +0100, Andrew Sayers wrote:
> [...]
> >
> > Andrew, sorry again for the slow reply. Thinking about the whole
> > discussion, I
On Fri, Jul 05, 2024 at 11:34:06PM +0200, Michael Niedermayer wrote:
> On Fri, Jul 05, 2024 at 08:31:17PM +0200, Niklas Haas wrote:
[...]
>
> > Attached is my revised working draft of .
>
> I dont agree to the renaming of swscale, that is heading toward
Would you mind talking a bit more about th
On date Saturday 2024-06-22 00:37:01 -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> fftools/ffprobe.c | 3 ++-
> tests/ref/fate/matroska-spherical-mono | 1 -
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fftools/ffprobe.c b/fftools/ffpr
(Updating an old thread)
Le perjantaina 19. tammikuuta 2024, 19.14.02 EEST Rémi Denis-Courmont a écrit
:
> Hi,
>
> Le perjantaina 19. tammikuuta 2024, 17.30.00 EET Michael Platzer via ffmpeg-
> devel a écrit :
> > Commit 446b0090cbb66ee614dcf6ca79c78dc8eb7f0e37 by Remi Denis-Courmont has
> > rep
On Fri, 05 Jul 2024 23:34:06 +0200 Michael Niedermayer
wrote:
> 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 confu
On Sat, 06 Jul 2024 02:11:30 +0200 Hendrik Leppkes wrote:
> 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 follo
On date Tuesday 2024-07-02 10:17:26 +0200, Paul B Mahol wrote:
[...]
> Source filters should use .activate instead.
Can someone elaborate about why .activate is favoured in this case
(sorry I missed the activate discussion altogether and I cannot graps
it from the docs)?
Also, is the direct AVFil
On 7/4/2024 2:58 PM, James Almer wrote:
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 100
Rémi Denis-Courmont:
> Note that optimised implementations of these functions will be taken
> into actual use only if MpegEncContext.dct_unquantize_h263_{inter,intra}
> are *not* overloaded by existing optimisations.
> ---
> libavcodec/h263dsp.c | 25 +
> libavcodec/h263dsp
Rémi Denis-Courmont:
> ---
> configure | 4 ++--
> libavcodec/mpegvideo.c | 40 +---
> 2 files changed, 11 insertions(+), 33 deletions(-)
>
> diff --git a/configure b/configure
> index fed4c44cd1..42b9a72d5a 100755
> --- a/configure
> +++ b/config
Le lauantaina 6. heinäkuuta 2024, 18.17.37 EEST Andreas Rheinhardt a écrit :
> Rémi Denis-Courmont:
> > Note that optimised implementations of these functions will be taken
> > into actual use only if MpegEncContext.dct_unquantize_h263_{inter,intra}
> > are *not* overloaded by existing optimisation
Le lauantaina 6. heinäkuuta 2024, 18.23.00 EEST Andreas Rheinhardt a écrit :
> > static void dct_unquantize_h263_inter_c(MpegEncContext *s,
> >
> >int16_t *block, int n, int qscale)
> >
> > {
> >
> > -int i, level, qmul, qadd;
> > +int qmul = qscal
Rémi Denis-Courmont:
> Le lauantaina 6. heinäkuuta 2024, 18.23.00 EEST Andreas Rheinhardt a écrit :
>>> static void dct_unquantize_h263_inter_c(MpegEncContext *s,
>>>
>>>int16_t *block, int n, int qscale)
>>>
>>> {
>>>
>>> -int i, level, qmul, qadd;
>>>
Rémi Denis-Courmont:
> Le lauantaina 6. heinäkuuta 2024, 18.17.37 EEST Andreas Rheinhardt a écrit :
>> Rémi Denis-Courmont:
>>> Note that optimised implementations of these functions will be taken
>>> into actual use only if MpegEncContext.dct_unquantize_h263_{inter,intra}
>>> are *not* overloaded
On Wed, Jul 03, 2024 at 02:05:06PM -0700, Josh Allmann wrote:
> Encoders may emit a buffering period SEI without a corresponding
> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
>
> During Annex B conversion, this may result in the SPS/PPS being
> inserted *after* the buffering perio
On Sat, Jul 06, 2024 at 02:11:30AM +0200, Hendrik Leppkes wrote:
> 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
Le lauantaina 6. heinäkuuta 2024, 19.20.33 EEST Andreas Rheinhardt a écrit :
> Rémi Denis-Courmont:
> > Le lauantaina 6. heinäkuuta 2024, 18.23.00 EEST Andreas Rheinhardt a écrit
:
> >>> static void dct_unquantize_h263_inter_c(MpegEncContext *s,
> >>>
> >>>in
On Sat, Jul 06, 2024 at 12:40:07PM +0200, Paul B Mahol wrote:
[...]
> its much more text to type too.
shorter options:
AV_OPT_FLAG_ALTERABLE_PARAM
AV_OPT_FLAG_MUTABLE_PARAM
(just in case consensus ends on a rename, i am not sure a rename is a good idea
here)
thx
[...]
--
Michael GnuPG
Le lauantaina 6. heinäkuuta 2024, 19.19.35 EEST Andreas Rheinhardt a écrit :
> Rémi Denis-Courmont:
> > Le lauantaina 6. heinäkuuta 2024, 18.17.37 EEST Andreas Rheinhardt a écrit
:
> >> Rémi Denis-Courmont:
> >>> Note that optimised implementations of these functions will be taken
> >>> into actua
On Sat, Jul 6, 2024 at 6:42 PM Michael Niedermayer
wrote:
>
> On Sat, Jul 06, 2024 at 02:11:30AM +0200, Hendrik Leppkes wrote:
> > On Fri, Jul 5, 2024 at 11:34 PM Michael Niedermayer
> > wrote:
> > > > /**
> > > > * The exact interpretation of these quality presets depends on the
> > > > backen
>t++: possibly add some more information to aid debugging, such as
"Trimming enabled, skipping padding cell for non promising cell ..."
Thanks Stefano for the review. A further cleanup patch set is coming
shortly with a patch specifically on language in log messages, will include
this.
Cheers,
__
On Sat, Jul 06, 2024 at 06:49:51PM +0200, Michael Niedermayer wrote:
> On Sat, Jul 06, 2024 at 12:40:07PM +0200, Paul B Mahol wrote:
> [...]
>
> > its much more text to type too.
>
> shorter options:
>
> AV_OPT_FLAG_ALTERABLE_PARAM
>
> AV_OPT_FLAG_MUTABLE_PARAM
>
> (just in case consensus ends
Rémi Denis-Courmont:
> Le lauantaina 6. heinäkuuta 2024, 19.19.35 EEST Andreas Rheinhardt a écrit :
>> Rémi Denis-Courmont:
>>> Le lauantaina 6. heinäkuuta 2024, 18.17.37 EEST Andreas Rheinhardt a écrit
> :
Rémi Denis-Courmont:
> Note that optimised implementations of these functions will
Rémi Denis-Courmont:
> Le lauantaina 6. heinäkuuta 2024, 19.20.33 EEST Andreas Rheinhardt a écrit :
>> Rémi Denis-Courmont:
>>> Le lauantaina 6. heinäkuuta 2024, 18.23.00 EEST Andreas Rheinhardt a écrit
> :
> static void dct_unquantize_h263_inter_c(MpegEncContext *s,
>
>
Rémi Denis-Courmont:
> ---
> tests/checkasm/h263dsp.c | 57 +++-
> 1 file changed, 56 insertions(+), 1 deletion(-)
>
> diff --git a/tests/checkasm/h263dsp.c b/tests/checkasm/h263dsp.c
> index 2d0957a90b..26020211dc 100644
> --- a/tests/checkasm/h263dsp.c
> +++
Hi,
On Wed, Jul 3, 2024, 21:24 Sean McGovern wrote:
> ---
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index b28221f258..bbda7a02cb 100755
> --- a/configure
> +++ b/configure
> @@ -5493,7 +5493,7 @@ elif enabled ppc; then
>
Hi,
On Thu, Jul 4, 2024, 13:54 Rémi Denis-Courmont wrote:
> 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 s
Le lauantaina 6. heinäkuuta 2024, 23.00.47 EEST Sean McGovern a écrit :
> Does wasted32 (and I guess wasted33 by proxy) not have to worry about loops
> tails? I noticed the other vectorized versions don't do anything special in
> that regard.
Frankly, RISC-V vectors (like Arm SVE's) are scalable s
Hello,
this is revised patch, to sum up the changes:
The current VapourSynth implementation is rarely used, as it links the
VapourSynth library at build time, making the resulting build unable to
run when VapourSynth is not installed. Therefore barely anyone compiles
with VapourSynth activated.
On Tue, Jul 02, 2024 at 11:36:43AM +0200, Anton Khirnov wrote:
> ---
> tests/fate/mov.mak | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
> index b54fe19620..d12980815f 100644
> --- a/tests/fate/mov.mak
> +++ b/tests/fate/mov.mak
> @@ -218,6 +
On Sun, Jul 07, 2024 at 01:57:56AM +0200, Michael Niedermayer wrote:
> On Tue, Jul 02, 2024 at 11:36:43AM +0200, Anton Khirnov wrote:
> > ---
> > tests/fate/mov.mak | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
> > index b54fe19620..d1
The atexit() handler in the avisynth demuxer was added because
there was a conflict in AvxSynth that arose due to their use
of C++ global objects, particularly in relation to having
added a logging function relying on log4cpp.
This conflict was responsible for causing a segfault on exit.
It did no
49 matches
Mail list logo
