From: Wenbin Chen
PyTorch is an open source machine learning framework that accelerates
the path from research prototyping to production deployment. Official
websit: https://pytorch.org/. We call the C++ library of PyTorch as
LibTorch, the same below.
To build FFmpeg with LibTorch, please take f
From 71df566c93a0b7538405cd9bb2da6da155084283 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Fri, 2 Feb 2024 12:50:50 +0800
Subject: [PATCH 3/3] lavc/vp8dsp: R-V V vp8_idct_dc_add4uv
c908:
vp8_idct_dc_add4uv_c: 387.7
vp8_idct_dc_add4uv_rvv_i32: 134.5
---
libavcodec/riscv/vp8dsp_init.c | 2 ++
From 1388287e7fb00cae1709bc3b82bc373fff4cd0a8 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Fri, 2 Feb 2024 12:50:07 +0800
Subject: [PATCH 2/3] lavc/vp8dsp: R-V V vp8_idct_dc_add4y
c908:
vp8_idct_dc_add4y_c: 368.5
vp8_idct_dc_add4y_rvv_i32: 134.5
---
libavcodec/riscv/vp8dsp_init.c | 2 ++
lib
From 32fdf006a81da78bde29b5cc0c26446d0bb3390d Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Fri, 2 Feb 2024 12:49:07 +0800
Subject: [PATCH 1/3] lavc/vp8dsp: R-V V vp8_idct_dc_add
c908:
vp8_idct_dc_add_c: 102.2
vp8_idct_dc_add_rvv_i32: 42.0
---
libavcodec/riscv/Makefile | 2 ++
libavcodec
Quoting Marton Balint (2024-02-01 21:01:37)
>
>
> On Thu, 1 Feb 2024, Anton Khirnov wrote:
>
> > Quoting Marton Balint (2024-01-30 00:27:53)
> >> Signed-off-by: Marton Balint
> >> ---
> >> doc/APIchanges | 3 +++
> >> libavutil/channel_layout.c | 20
> >> liba
Most of this patch was written by Dave Airlie ,
with some additions by me.
Patch attached.
>From 8d4c2936343d0340f1489c49585083f7bc52e14f Mon Sep 17 00:00:00 2001
From: Lynne
Date: Fri, 19 Jan 2024 10:49:02 +1000
Subject: [PATCH 2/2] lavc/vulkan_av1: port to the new stable API
Most of this patc
Needed for AV1.
Patch attached
>From 81be215060a718fdc3d043847e8155ba56fcb431 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Fri, 2 Feb 2024 03:54:06 +0100
Subject: [PATCH 1/2] lavc/cbs_av1: fill in ref_frame_sign_bias
Needed for AV1.
---
libavcodec/cbs_av1.h | 1 +
libavcodec/cbs
Ok, updated it in the reply
Rémi Denis-Courmont 于2024年2月2日周五 04:13写道：
> You should probably use an assembler macro to repeat the code.
>
>
> --
> レミ・デニ-クールモン
> http://www.remlab.net/
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https:/
DXV files seem to misnomer DXT5 and really encode DXT4 with premultiplied alpha.
At least, this is what Resolume alley does. To check, encode some input with
alpha
as "Normal Quality, With Alpha" in Alley, then decode the output with this
change
-- results are true to the original input compared
This function should convert premultiplied alpha to straight, but does the
opposite.
Signed-off-by: Connor Worley
---
libavcodec/texturedsp.c | 9 ++---
tests/ref/fate/dds-dxt2 | 2 +-
tests/ref/fate/dds-dxt4 | 2 +-
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavcodec/
It seems to be caused by movd m0, r1d in libavcodec/x86/rv34dsp.asm? I'm
not quite sure.
Michael Niedermayer 于2024年2月2日周五 07:42写道：
> On Wed, Jan 31, 2024 at 08:00:18PM +0800, flow gg wrote:
> >
>
> > checkasm/Makefile |1
> > checkasm/checkasm.c |3 ++
> > checkasm/checkasm.h |1
>
For future use in lavc/dxvenc.
Signed-off-by: Connor Worley
---
libavcodec/texturedsp.h| 1 +
libavcodec/texturedspenc.c | 41 ++
2 files changed, 42 insertions(+)
diff --git a/libavcodec/texturedsp.h b/libavcodec/texturedsp.h
index 86c8eea02d..888143618
DXV files seem to misnomer DXT5 and really encode DXT4 with premultiplied alpha.
At least, this is what Resolume alley does. To check, encode some input with
alpha
as "Normal Quality, With Alpha" in Alley, then decode the output with this
change
-- results are true to the original input compared
This function should convert premultiplied alpha to straight, but does the
opposite.
Signed-off-by: Connor Worley
---
libavcodec/texturedsp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/texturedsp.c b/libavcodec/texturedsp.c
index 5fb79937da..1b8237e9f7
On Wed, Jan 31, 2024 at 08:00:18PM +0800, flow gg wrote:
>
> checkasm/Makefile |1
> checkasm/checkasm.c |3 ++
> checkasm/checkasm.h |1
> checkasm/rv34dsp.c | 65
>
> fate/checkasm.mak |1
> 5 files changed, 71 ins
On Thu, Feb 01, 2024 at 06:59:14PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-02-01 00:07:02)
> >
> > about antons comment
> > "Objections: (Anton) Coverity (and other static analysis tools) are
> > notoriously prone to false positives. I am concerned that this might lead
>
On Thu, 1 Feb 2024, Michael Niedermayer wrote:
On Wed, Jan 31, 2024 at 03:42:46AM +0100, Marton Balint wrote:
On Wed, 31 Jan 2024, Michael Niedermayer wrote:
On Sun, Jan 28, 2024 at 04:01:36AM +0100, Marton Balint wrote:
Yadif filter assumed that the output timebase is always half of the
On Thu, Feb 1, 2024 at 9:41 PM Connor Worley
wrote:
> Got some confirmation that this patch fixes
> https://trac.ffmpeg.org/ticket/10264
>
>
Thanks for the fix. I had encountered similar artifacts but failed to fix
it, and then removed files long ago, but i got them from the web so will
recheck i
Hi Jonatas
On Thu, Feb 01, 2024 at 04:42:34PM -0300, Jonatas L. Nogueira via ffmpeg-devel
wrote:
[...]
> Of course, if they voluntarily renounce the right to participate that's an
> entirely different story. Anyone can do that, but that's entirely up to
> them and trying to coerce them into doin
Got some confirmation that this patch fixes
https://trac.ffmpeg.org/ticket/10264
--
Connor Worley
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-d
On Thu, 1 Feb 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-02-01 00:01:36)
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 37629ab5d2..7e27a00d39 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -817,6 +817,17 @@ int av_channel_
You should probably use an assembler macro to repeat the code.
--
レミ・デニ-クールモン
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
ffmp
Le torstaina 1. helmikuuta 2024, 19.45.52 EET Vittorio Giovara a écrit :
> The same of course should apply to any other future funding, it must be
> either the community (via GA) or a third party setting up the sponsorship.
Neither the community or the GA can forbid people from seeking funding for
On Thu, 1 Feb 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-01-30 00:27:53)
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 +++
libavutil/channel_layout.c | 20
libavutil/channel_layout.h | 13 +
libavutil/version.h| 4 ++
> The same of course should apply to any other future funding, it must be
either the community (via GA) or a third party setting up the sponsorship.
I honestly didn't understood this part. Maybe because I'm not involved with
FFmpeg internal workings and policies, but could you clarify the exact
di
On 1/31/2024 9:44 PM, Derek Buitenhuis wrote:
> On 1/30/2024 1:48 AM, Michael Niedermayer wrote:
>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
>
> Not to derail this fine thread, but what forks does the Merge Forks
> project refer to?
I do not believe this has been answered.
- Dere
Signed-off-by: Connor Worley
---
tests/fate/video.mak | 6 ++
tests/ref/fate/dxv3-ycg6 | 6 ++
tests/ref/fate/dxv3-yg10 | 6 ++
3 files changed, 18 insertions(+)
create mode 100644 tests/ref/fate/dxv3-ycg6
create mode 100644 tests/ref/fate/dxv3-yg10
diff --git a/tests/fate/vide
Signed-off-by: Connor Worley
---
tests/fate/video.mak| 7 +++
tests/ref/fate/dxv3enc-dxt1 | 6 ++
2 files changed, 13 insertions(+)
create mode 100644 tests/ref/fate/dxv3enc-dxt1
diff --git a/tests/fate/video.mak b/tests/fate/video.mak
index 4e7a77537f..fbc8a1a682 100644
--- a/t
On Thu, Feb 01, 2024 at 06:45:52PM +0100, Vittorio Giovara wrote:
> On Thu, Feb 1, 2024 at 5:29 AM Michael Niedermayer
> wrote:
>
> > Hi all
> >
> > To do the STF/SPI thing properly, and make sure we do what the Community
> > wants.
> > We should do this vote: (unless lots of people reply and say
Le torstaina 1. helmikuuta 2024, 19.59.14 EET Anton Khirnov a écrit :
> > Why should i suddenly do something different ?
> > I did it for 100% free back then
> > and here it wouldnt even make sense, closing false positives also
> > counts as resolved. Its less work even to get 70USD ;)
>
> What's
Alternative patch which eliminates the I/O error, but slightly modifies
the behavior by introducing a two-stage shutdown (the only difference is
the end of the rtmp_close function) which keeps the server open until
the client closes its end.
On 01/02/2024 17:40, Momtchil Momtchev wrote:
h
Quoting Michael Niedermayer (2024-02-01 00:07:02)
>
> about antons comment
> "Objections: (Anton) Coverity (and other static analysis tools) are
> notoriously prone to false positives. I am concerned that this might lead to
> a large number of patches that "fix" such false positives, but make th
> On Feb 1, 2024, at 9:45 AM, Vittorio Giovara
> wrote:
>
> Since all objections and requests for more time have been ignored, and this
> is happening anyway, can we add a small amendment for the sake of
> transparency and for avoiding any conflict of interest? Whoever was
> involved with the
On Thu, Feb 1, 2024 at 5:29 AM Michael Niedermayer
wrote:
> Hi all
>
> To do the STF/SPI thing properly, and make sure we do what the Community
> wants.
> We should do this vote: (unless lots of people reply and say we should
> skip the vote)
> (i am also CCing jonatan to make sure the option in
https://trac.ffmpeg.org/ticket/10838
Hello,
This small PR implements:
* RTMP flow control on the server side - now the server will stop
sending data if it has filled the window and the client hasn't ACKed
* Improves the tear-down by not returning an error when the server
closes t
From: Frank Plowman
pps_single_slice_per_subpic_flag is not yet supported. Support is WIP,
but in the meantime throw an error when trying to decode a bitstream
with it set, avoiding an out-of-bounds array access.
Fixes: out-of-bounds array access for conformance bitstreams
SUBPIC_C_ERICSSON_1,
On 2/1/2024 9:15 AM, Nuo Mi wrote:
On Wed, Jan 24, 2024 at 2:17 AM wrote:
From: Wu Jianhua
Signed-off-by: Wu Jianhua
---
libavcodec/h26x/h2656_inter_template.c | 577 +
libavcodec/vvc/vvc_inter_template.c| 559 +---
2 files changed, 578 in
On Fri, 26 Jan 2024 18:17:30 +0800 Zhao Zhili wrote:
>
>
> > On Jan 26, 2024, at 17:36, Anton Khirnov wrote:
> >
> > Quoting Niklas Haas (2024-01-10 10:05:46)
> >> From: Niklas Haas
> >>
> >> Fixes error spam from the `ffplay` tool since commit 2d555dc82d, caused
> >> by an oversight on my p
---
tests/fate/filter-audio.mak| 22 ++
tests/ref/fate/filter-aoverlay-crossfade-d | 224 ++
tests/ref/fate/filter-aoverlay-crossfade-t | 202
tests/ref/fate/filter-aoverlay-default | 259 +
tests/ref/fate/filter-aoverlay-ti
Co-authored-by: Paul B Mahol
Signed-off-by: Harshit Karwal
---
doc/filters.texi | 40 +++
libavfilter/Makefile | 1 +
libavfilter/af_aoverlay.c | 548 ++
libavfilter/allfilters.c | 1 +
4 files changed, 590 insertions(+)
create mode 100644
Added enum for crossfade modes, av_logs for stream transitions and minor change
to the docs
Harshit Karwal (2):
avfilter: add audio overlay filter
fate: Add tests for aoverlay filter
doc/filters.texi | 40 ++
libavfilter/Makefile | 1 +
lib
On Wed, 10 Jan 2024 10:05:46 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> Fixes error spam from the `ffplay` tool since commit 2d555dc82d, caused
> by an oversight on my part - I didn't notice during development that
> `ffplay` goes through its own filtering code path separate from
> fftools
On Wed, Jan 24, 2024 at 2:17 AM wrote:
> From: Wu Jianhua
>
> Signed-off-by: Wu Jianhua
> ---
> libavcodec/h26x/h2656_inter_template.c | 577 +
> libavcodec/vvc/vvc_inter_template.c| 559 +---
> 2 files changed, 578 insertions(+), 558 deletions(-
On 2024-01-31 09:49 am, Gyan Doshi wrote:
On 2024-01-26 07:39 pm, Gyan Doshi wrote:
The video param change check will print loglines below debug level
for each frame which is different from the inlink parameters. This
can spam the console. It is now printed at warning level once for
each pa
Am 30.01.24 um 22:57 schrieb Connor Worley:
OK, attached are some significantly smaller HQ samples that produce the
same coverage.
5b11c393dda223b5dd198ad2f2576fe2 fate-suite/dxv/dxv3-hqna.mov
3af30eaba2b6ec68a0f5b2c136f4dab6 fate-suite/dxv/dxv3-hqwa.mov
5b11c393dda223b5dd198ad2f2576fe2 dow
Quoting Marton Balint (2024-02-01 00:01:36)
> diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
> index 37629ab5d2..7e27a00d39 100644
> --- a/libavutil/channel_layout.h
> +++ b/libavutil/channel_layout.h
> @@ -817,6 +817,17 @@ int av_channel_layout_check(const AVChannelLayout
>
Quoting Marton Balint (2024-01-30 00:27:53)
> Signed-off-by: Marton Balint
> ---
> doc/APIchanges | 3 +++
> libavutil/channel_layout.c | 20
> libavutil/channel_layout.h | 13 +
> libavutil/version.h| 4 ++--
> 4 files changed, 38 insertions
From 91236c12365de8a39250ceee07a6234a1735ae77 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Thu, 1 Feb 2024 15:41:09 +0800
Subject: [PATCH 2/2] lavc/blockdsp: R-V V clear_blocks
C908:
blockdsp.clear_blocks_c: 128.2
blockdsp.clear_blocks_rvv_i64: 102.5
---
libavcodec/riscv/blockdsp_init.c | 2
From d545f5ccc1c5923cb38c25b18ca750ef0ee529f4 Mon Sep 17 00:00:00 2001
From: sunyuechi
Date: Thu, 1 Feb 2024 15:12:49 +0800
Subject: [PATCH 1/2] lavc/blockdsp: R-V V clear_block
C908:
blockdsp.clear_block_c: 47.2
blockdsp.clear_block_rvv_i64: 28.5
---
libavcodec/blockdsp.c| 2 ++
l
Its use has been discouraged since 2016, but now is no longer used in
avformat, so there is no reason to keep it public.
---
libavcodec/avcodec.c | 12 +---
libavcodec/avcodec.h | 5 -
libavcodec/avcodec_internal.h | 2 ++
libavcodec/frame_thread_encoder
Replace it with recreating the codec context.
This is the last remaining blocker for deprecating avcodec_close().
---
libavformat/demux.c | 53 -
1 file changed, 48 insertions(+), 5 deletions(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
in
The demuxer opens an internal parser instance in read_timestamp(), which
requires a codec context. There is no need for it to access the FFStream
one which is used for other purposes, it can allocate its own internal
one.
---
libavformat/flacdec.c | 25 -
1 file changed, 24
This check has survived the transition to AVCodecParameters, but is no
longer relevant after it, since the codec context is no longer updated
or accessed at all from the demuxer.
---
libavformat/mpegts.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpe
53 matches
Mail list logo
