>
> > The data arrives on multiple sockets, leading to all sorts
> > of opportunities for timing behavior and reordering issues.
>
> how does this matter?
>
There are routers that put traffic on a different port down a different ISP
so you have to compensate for latency delays between the two link
The mere possibility that the CC could "intervene" about anything has a very
> chilling effect. Few people will touch finances in such an environment.
> Bascially this will make use of money in the future more difficult.
> In the past we just all tried to do the right thing for the project
> but if
On Sun, 19 Jan 2025, 22:22 Michael Niedermayer,
wrote:
> The part i do not agree with and iam not convinced about is that this
> cannot be done in a clean and fully working and heuristics free
> way in the real world.
>
Protocols are not the same as codecs. Just because you have a hammer,
everyt
On Sun, Jan 19, 2025 at 07:36:20PM +0900, Lynne wrote:
> Adding support for hwaccels means that avctx->pix_fmt will indicate
> hardware formats.
> ---
> libavcodec/ffv1.h| 1 +
> libavcodec/ffv1dec.c | 145 +++
> 2 files changed, 79 insertions(+), 67 d
On Fri, Jan 17, 2025 at 07:35:09AM +0100, Manuel Lauss wrote:
> Servus Michael,
>
> On Fri, Jan 17, 2025 at 2:32 AM Michael Niedermayer
> wrote:
> >
> > Hi
> >
> > On Wed, Jan 15, 2025 at 06:24:44PM +0100, Manuel Lauss wrote:
> > > Ping?
> > >
> >
> > > Incidentally this also closes trac ticket #
Hi James
On Fri, Jan 17, 2025 at 03:48:15PM -0300, James Almer wrote:
> On 1/17/2025 2:39 PM, Michael Niedermayer wrote:
> > Hi
> >
> > On Tue, Jan 14, 2025 at 03:40:42PM -0300, James Almer wrote:
> > > On 1/14/2025 2:06 PM, Michael Niedermayer wrote:
[...]
>
> > and from that a community committ
Hi James
On Fri, Jan 17, 2025 at 07:37:16PM -0300, James Almer wrote:
> On 1/16/2025 12:39 AM, Michael Niedermayer wrote:
> > This blocks disallowed extensions from probing
> > It also requires segments to have matching extensions to the format
> >
> > It is recommended to set the whitelists corr
Hi Devin
On Fri, Jan 17, 2025 at 12:54:10PM -0500, Devin Heitmueller wrote:
> Hello all,
>
> I've got some experience in this particular area, so figured it might
> be helpful to offer another voice.
>
> Kieran makes a number of excellent points, and I largely agree with
> his discussion of the
On Sun, 19 Jan 2025, Krzysztof Pyrkosz via ffmpeg-devel wrote:
Modified the main loop to handle 8 floats in one go. A special case of
length not being multiple of 8 is handled at the beginning. The speed
increased from 3.90 to 4.50.
The same request about benchmark numbers and reference to whe
On Sun, 19 Jan 2025, Krzysztof Pyrkosz via ffmpeg-devel wrote:
Removed a branch, unrolled loop. Speed increase bumped from 3.95 to 5.60.
On what core is that? Please quote the actual output including the
absolute numbers.
I'm getting much more inconclusive numbers for this one:
Before:
Storing them separately performs slightly worse (compression wise)
in every variant i tried.
It also would likely be slower
if someone has ideas, they are welcome
This is the result of several hours tuning first the
sign bit storage (theres little to gain here as its 1% of the bitstream)
then th
On Sun, 19 Jan 2025, Krzysztof Pyrkosz via ffmpeg-devel wrote:
---
libavutil/aarch64/float_dsp_neon.S | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavutil/aarch64/float_dsp_neon.S
b/libavutil/aarch64/float_dsp_neon.S
index 35e2715b87..b21f34c084 100644
---
On Fri, 17 Jan 2025, Ramiro Polla wrote:
Hi Marton,
On Tue, Jan 7, 2025 at 12:09 AM Marton Balint wrote:
The comments supposed to track the possible value of the qmat and qmat16
matrices, but they were not updated properly in the long history of the
mpegvideo encoder. Also they wrongly ass
Modified the main loop to handle 8 floats in one go. A special case of
length not being multiple of 8 is handled at the beginning. The speed
increased from 3.90 to 4.50.
Krzysztof
---
libavutil/aarch64/float_dsp_neon.S | 30 ++
1 file changed, 22 insertions(+), 8 dele
Removed a branch, unrolled loop. Speed increase bumped from 3.95 to 5.60.
Krzysztof
---
libavutil/aarch64/float_dsp_neon.S | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/libavutil/aarch64/float_dsp_neon.S
b/libavutil/aarch64/float_dsp_neon.S
i
On 20/01/2025 00:04, Krzysztof Pyrkosz via ffmpeg-devel wrote:
---
libavutil/aarch64/float_dsp_neon.S | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavutil/aarch64/float_dsp_neon.S
b/libavutil/aarch64/float_dsp_neon.S
index 35e2715b87..b21f34c084 100644
-
> -Original Message-
> From: Alexander Strasser
> Sent: Sunday, January 19, 2025 11:09 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Guo, Yejun
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: minor spell fix
>
> On 2025-01-13 19:42 +0100, Leandro Santiag
On 2025-01-13 19:42 +0100, Leandro Santiago wrote:
> Signed-off-by: Leandro Santiago
> ---
> libavfilter/dnn/dnn_backend_openvino.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_openvino.c
> b/libavfilter/dnn/dnn_backend_openvino.c
> ind
On 2025-01-12 22:19 +0100, Andreas Rheinhardt wrote:
> Patch attached
> From 1abad60fe2eba199845db35c92e27dbc4d35b93f Mon Sep 17 00:00:00 2001
> From: Andreas Rheinhardt
> Date: Sun, 12 Jan 2025 20:40:31 +0100
> Subject: [PATCH] fftools/ffmpeg_opt: Remove audio_drift_threshold
>
> Forgotten in 5a
---
libavutil/aarch64/float_dsp_neon.S | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavutil/aarch64/float_dsp_neon.S
b/libavutil/aarch64/float_dsp_neon.S
index 35e2715b87..b21f34c084 100644
--- a/libavutil/aarch64/float_dsp_neon.S
+++ b/libavutil/aarch64/flo
Removed two redundant pointer arithmetic operations and split load
section into two smaller ones.
Speedup compared to C increased from 4.50 to 5.80.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
---
libavcodec/ffv1dec.c | 64 +++-
1 file changed, 40 insertions(+), 24 deletions(-)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index aa988571bc..68a233932d 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -548,11 +548,10 @@ st
This commit adds a Vulkan-based accelerated decoding of FFv1.
Currently, only monochrome, arithmetic coding, version 3 and 4 are
supported.
Posting this more as an RFC.
---
configure | 2 +
libavcodec/Makefile | 1 +
libavcodec/ffv1dec.c
---
libavcodec/vulkan_decode.c | 192 +++--
libavcodec/vulkan_decode.h | 10 ++
2 files changed, 152 insertions(+), 50 deletions(-)
diff --git a/libavcodec/vulkan_decode.c b/libavcodec/vulkan_decode.c
index c57998108c..87132651e2 100644
--- a/libavcodec/vulkan_dec
The shaders were written to support sharing, but needed slight
tweaking.
---
libavcodec/ffv1enc_vulkan.c | 75 +++
libavcodec/vulkan/ffv1_common.comp| 24 +++--
libavcodec/vulkan/ffv1_enc_setup.comp | 18 +--
libavcodec/vulkan/ffv1_reset.comp | 3
This adds support for default range coder tables, rather than
only custom ones. Its two lines, as the same code can be used
for both thanks to ffv1enc.c setting f->state_transition properly.
---
libavcodec/ffv1enc_vulkan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/liba
This commit adds support for hardware accelerated decoding to
the decoder.
The previous commits already refactored the decoder, this commit
simply adds calls to hooks to decode.
---
libavcodec/ffv1.h| 1 +
libavcodec/ffv1dec.c | 62 +---
2 files changed
The table is only set when f->ac is set to CUSTOM. Setting it
for default range coder tables simplifies hardware accelerator code.
---
libavcodec/ffv1dec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 83c5975550..fdd3d1c15d 10064
This also cleans up and gives the code some much needed comments.
---
libavcodec/ffv1dec.c | 66 +++-
1 file changed, 47 insertions(+), 19 deletions(-)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index b7f235c47f..aa988571bc 100644
--- a/libavc
---
libavcodec/Makefile | 2 +-
libavcodec/ffv1_vulkan.c| 123 ++
libavcodec/ffv1_vulkan.h| 39 ++
libavcodec/ffv1enc_vulkan.c | 145 +---
4 files changed, 199 insertions(+), 110 deletions(-)
create mode 100644
This simply movies all slice decoding code from decode_frame
to decode_slices; nothing more.
---
libavcodec/ffv1dec.c | 106 ---
1 file changed, 60 insertions(+), 46 deletions(-)
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 68a233932d..83c
Adding support for hwaccels means that avctx->pix_fmt will indicate
hardware formats.
---
libavcodec/ffv1.h| 1 +
libavcodec/ffv1dec.c | 145 +++
2 files changed, 79 insertions(+), 67 deletions(-)
diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
ind
---
libavutil/vulkan.c | 51 ++
libavutil/vulkan.h | 7 +++
2 files changed, 58 insertions(+)
diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
index 7315af928f..c86b77c3ee 100644
--- a/libavutil/vulkan.c
+++ b/libavutil/vulkan.c
@@ -1586,6 +158
Fixes ticket #10658.
---
Tested with some different vertical resolution alignments.
When the vertical resolution is not aligned to macroblock height, the
reference encoder & decoder performs buggy placement of the initial
field. Its an internal bug, but because the encoder and decoder are
aligned
> This change has caused regressions for many users and consumers.
See:
- https://www.reddit.com/r/mpv/comments/181yu2z/problem_streaming_radio/
- https://github.com/mpv-player/mpv/issues/13428
In my case:
Restreaming HLS to HLS. The source provides segments of 15s length, while
output is 3/6s
From: softworkz
This change has caused regressions for many users and consumers.
Playlist reloads only happen when a playlist doesn't indicate that it
has ended (via #EXT-X-ENDLIST), which means that the addition of future
segments is still expected.
It is well possible that an HLS server is temp
36 matches
Mail list logo
