Le 28 septembre 2024 12:42:37 GMT+03:00, flow gg a écrit
:
>> Is 4x unroll really faster than 2x here? We don't typically unroll 4x
>> manually.
>
>I first did 2x and then changed it to 4x. The test results are similar, and
>I'm not sure how to choose between them...
At similar speed, shorter
Thanks for the fix. Merged.
___
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".
Pushed the set up to this patch, will wait a few more days for the rest
in case someone wants to comment on the API changes.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsu
> At similar speed, shorter code is better.
Okay, updated it.
> Sure but so what? vsetvli/vsetivli is pretty fast (unlike vsetvl), and in
this case the code would be shorter. Or are you trying to factor the code
for different VTYPEs?
I mistakenly thought these vsets would slow things down.. afte
From: sunyuechi
k230 banana_f3
dmvr_8_12x20_c: 619.3 ( 1.00x)624.1 ( 1.00x)
dmvr_8_12x20_rvv_i32: 128.6 ( 4.82x)103.4 ( 6.04x)
dmvr_8_20x12_c: 610.0 ( 1.00x)665.6 ( 1.00x)
dm
On Fri, 27 Sept 2024 at 00:51, Michael Niedermayer
wrote:
> On Thu, Sep 26, 2024 at 12:27:58PM +0100, Filip Mašić wrote:
> > On Tue, 24 Sept 2024 at 23:48, Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > if someone can help with reviewing and applying, thats certainly
> welco
Ensure that when the `-hls_flags omit_endlist` option is set,
the `#EXT-X-ENDLIST` tag is also omitted from the `stream_vtt.m3u8`
subtitle playlist. This maintains consistency with the behavior
in other playlists when `omit_endlist` is specified.
---
libavformat/hlsenc.c | 2 +-
1 file changed, 1
Ensure that when the `-hls_flags append_list` option is set,
that *.vtt files in stream_vtt.m3u8 are correctly updated.
This fixes https://trac.ffmpeg.org/ticket/11208
Is a bit of an ugly fix, let me know what you think.
---
libavformat/hlsenc.c | 37 +
1 file
Hi Brad,
On Fri, Sep 27, 2024, 22:16 Brad Smith
wrote:
> ping.
>
> On 2024-09-21 5:05 a.m., Brad Smith wrote:
> > ppc: Recognize the PPC VSX and Power8 CPU flags
> >
> > Signed-off-by: Brad Smith
> > ---
> > libavutil/cpu.c | 2 ++
> > libavutil/tests/cpu.c | 2 ++
> > 2 files change
On Sat, Sep 28, 2024 at 9:04 AM Dmitrii Ovchinnikov
wrote:
>
> Thanks for the fix. Merged.
Thanks Dmitrii, can you cherry-pick this bugfix and the fix for
supported HEVC color ranges to release/7.1 (if you agree they are
suitable for backporting)?
___
f
On Thu, Sep 26, 2024 at 10:44:32PM -0300, James Almer wrote:
[...]
> index 78d3a2e0fa..ab6182bf4c 100644
> --- a/tests/ref/fate/source
> +++ b/tests/ref/fate/source
> @@ -25,6 +25,7 @@ compat/djgpp/math.h
> compat/float/float.h
> compat/float/limits.h
> compat/stdbit/stdbit.h
> +compat/stdckdint
If 'sname:*' is set in the var_stream_map variable, use it as
the NAME attribute for subtitles. This improves the naming of
subtitle streams in HTML players, providing clearer and more
descriptive labels for users.
---
doc/muxers.texi | 5 +++--
libavformat/hlsenc.c | 7 ++-
lib
On Fri, Sep 27, 2024 at 02:52:37PM +0200, Ramiro Polla wrote:
> There is an issue with the constants used in YUV to YUV range conversion,
> where the upper bound is not respected when converting to mpeg range.
>
> With this commit, the constants are calculated at runtime, depending on
> the bit de
Hello,
Le lun. 23 sept. 2024 à 16:19, Ramiro Polla a écrit :
> For bit depths <= 14, amax is 16-bit and offset is 32-bit.
> For bit depths > 14, amax is 32-bit and offset is 64-bit.
[...]
> -static void chrRangeToJpeg_c(int16_t *dstU, int16_t *dstV, int width)
> +static void chrRangeToJpeg_c(in
The options-setting functions share several operations at their
beginnings - locating the option and the object to operate on, handling
the read-only and deprecated flags, and constructing the pointer to the
target value. Some of the functions also do not perform some of the
checks, although they s
Add a mechanism to AVClass to allow objects to signal their state to
generic code. When an object flags itself with the 'initialized' state,
print an error (and fail, after the next major bump) if the caller
attempts to set non-runtime options.
---
doc/APIchanges | 3 +++
libavutil/log.h
---
libavutil/log.h | 43 +++
1 file changed, 27 insertions(+), 16 deletions(-)
diff --git a/libavutil/log.h b/libavutil/log.h
index ab7ceabe22..c6b47cc054 100644
--- a/libavutil/log.h
+++ b/libavutil/log.h
@@ -77,7 +77,9 @@ typedef struct AVClass {
co
Makes it easier to handle options generically and will be useful in
future commits.
---
libavutil/opt.c | 84 +++--
1 file changed, 33 insertions(+), 51 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 45db4f484f..2b66318f92 100644
---
This will allow the AVOption code to detect setting non-runtime options
after the filter has been initialized.
---
libavfilter/avfilter.c | 8 +---
libavfilter/avfilter_internal.h | 5 ++---
libavfilter/graphparser.c | 3 ++-
3 files changed, 9 insertions(+), 7 deletions(-)
dif
LGTM!
___
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".
Hi Christophe,
On Sat, Sep 28, 2024 at 3:21 PM Christophe Gisquet
wrote:
> Le lun. 23 sept. 2024 à 16:19, Ramiro Polla a écrit :
> > For bit depths <= 14, amax is 16-bit and offset is 32-bit.
> > For bit depths > 14, amax is 32-bit and offset is 64-bit.
>
> [...]
>
> > -static void chrRangeToJpe
On Mon, Sep 23, 2024 at 11:16:42AM +0200, Martin Schitter wrote:
> Patchset for DNxUncomprressed decoder.
>
> v9 includes changes to fix issues mentioned in Marton Balints review.
>
> ---
> libavcodec/codec_desc.c | 7 +++
> libavcodec/codec_id.h | 1 +
> libavcodec/version.c| 2 +-
>
On Sat, Sep 28, 2024 at 06:00:11AM +0200, Lynne via ffmpeg-devel wrote:
> On 22/09/2024 23:56, Michael Niedermayer wrote:
> > CC: Lynne
> > Signed-off-by: Michael Niedermayer
> > ---
> > MAINTAINERS | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> >
On Sat, Sep 28, 2024 at 12:35:13PM +0200, martin schitter wrote:
> I know, you are all busy with 7.1 release cleanup, but could you please take
> another look at my DNxUncompressed patches and merge them.
>
> I always fixed the change requests reported by reviewers within 24 hours,
> and most of t
On Mon, Sep 23, 2024 at 11:14:19PM +0800, Zhao Zhili wrote:
> From: Zhao Zhili
>
> It's similar to av_get_frame_filename2 but with int64_t number
> support. Make av_get_frame_filename* a wrapper over
> ff_get_frame_filename.
>
> Co-authored-by: Filip Mašić
> ---
> libavformat/internal.h | 16 +
On Tue, Sep 24, 2024 at 12:16:13AM +0800, Zhao Zhili wrote:
> From: Zhao Zhili
>
> ---
> libavformat/img2enc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
probably ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"Nothing to hide" o
On Tue, Sep 24, 2024 at 06:15:57PM +0100, Filip Mašić wrote:
> On Mon, 23 Sept 2024 at 16:14, Zhao Zhili wrote:
>
> > From: Zhao Zhili
> >
> > It's similar to av_get_frame_filename2 but with int64_t number
> > support. Make av_get_frame_filename* a wrapper over
> > ff_get_frame_filename.
> >
> >
On Tue, Sep 24, 2024 at 05:47:54PM +0200, Michael Niedermayer wrote:
> On Wed, Aug 14, 2024 at 02:41:55PM +0200, Michael Niedermayer wrote:
> > Hi all
> >
> > Are there any upcoming LTS releases that want to/could include FFmpeg 7.1 ?
> > If so please reply here and list the date before which we w
The encoding AVCodecContext is a part of the encoder, and so should live
there.
---
fftools/ffmpeg.c | 6 ++--
fftools/ffmpeg.h | 3 +-
fftools/ffmpeg_enc.c | 33 ++--
fftools/ffmpeg_mux.c | 8 ++---
fftools/ffmpeg_mux_init.c | 66 ++--
It is write-only after d119ae2fd82a494d9430ff4d4fc262961a68c598.
---
fftools/ffmpeg.h | 8
fftools/ffmpeg_demux.c | 7 ---
2 files changed, 15 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index b5c95439e5..13e0fd14cd 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/
It is now a trivial wrapper over ist_use(), so export that directly.
---
fftools/ffmpeg.h | 3 ++-
fftools/ffmpeg_demux.c| 17 ++---
fftools/ffmpeg_mux_init.c | 17 +
3 files changed, 13 insertions(+), 24 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftoo
---
fftools/ffmpeg.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index c796de19f5..0f5809b752 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -541,11 +541,6 @@ typedef struct EncStats {
extern const char *const forced_keyframes_const_names
It is only used in this file.
---
fftools/ffmpeg.h | 2 --
fftools/ffmpeg_mux_init.c | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 0f5809b752..9439be0f41 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -539,8 +539,6
Similar to what was previously done for other components, e.g. decoders
(see 3b84140a1bb5a5b3044915888a40a7b619921633).
Start by moving {samples,frames}_encoded into the public struct.
---
fftools/ffmpeg.h | 11 +++---
fftools/ffmpeg_enc.c | 86 +---
ff
To streamcopy_init().
This will allow to simplify the control flow in ost_add() by moving the
ost_get_filters() call (which previously had to handle both encoding and
streamcopy streams) to ost_bind_filter() (which is only called for
audio/video encoding).
Also, return EINVAL rather than ENOSYS,
---
fftools/ffmpeg_mux_init.c | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 50ce45ef1b..944176ca5d 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -89
That is a more appropriate place for it.
---
fftools/ffmpeg_mux_init.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 1ddd1d7492..50ce45ef1b 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmp
From: sunyuechi
k230 banana_f3
dmvr_8_12x20_c: 626.5 ( 1.00x)621.7 ( 1.00x)
dmvr_8_12x20_rvv_i32: 126.3 ( 4.96x)79.9 ( 7.78x)
dmvr_8_20x12_c: 608.0 ( 1.00x)652.9 ( 1.00x)
dmv
> Is 4x unroll really faster than 2x here? We don't typically unroll 4x
> manually.
I first did 2x and then changed it to 4x. The test results are similar, and
I'm not sure how to choose between them...
> t5 seems to be 8-bit, so vwmulu.vx should work better here? Since you
> leveraged it in the
I know, you are all busy with 7.1 release cleanup, but could you please
take another look at my DNxUncompressed patches and merge them.
I always fixed the change requests reported by reviewers within 24
hours, and most of them were in fact really trivial and of cosmetic
nature anyway, but in t
40 matches
Mail list logo
