Hi,
in the 'avcodec/s302m: enable non-PCM decoding' thread it became
apparent that there is wide disagreement about the interpretation of
this line in the TC rules:
> If the disagreement involves a member of the TC, that member should
> recuse themselves from the decision.
The word 'involves' in
My personal opinion is that broad interpretations of the rule in
question are highly undesirable, as they punish TC members for active
participation in the project. And since TC members tend to be among the
most active contributors, this can substantially reduce our already low
review rate, and lea
On Tue, 20 Feb 2024, Anton Khirnov wrote:
My personal opinion is that broad interpretations of the rule in
question are highly undesirable, as they punish TC members for active
participation in the project. And since TC members tend to be among the
most active contributors, this can substanti
Quoting Marton Balint (2024-02-20 10:12:34)
> We have no means to prove financial interest, because it is not public.
We also have no means to prove that committee members are acting in the
project's interest.
E.g. if I had no qualms about being dishonest, I could always ask a
friend to object t
On 2024-02-20 02:20 pm, Anton Khirnov wrote:
So IMO the only case that needs to be excluded is 6) - an actual
conflict of interest. I therefore propose the following wording changes:
--- a/doc/community.texi
+++ b/doc/community.texi
-If the disagreement involves a member of the TC, that membe
Quoting Gyan Doshi (2024-02-20 11:01:15)
>
>
> On 2024-02-20 02:20 pm, Anton Khirnov wrote:
> > So IMO the only case that needs to be excluded is 6) - an actual
> > conflict of interest. I therefore propose the following wording changes:
> >
> > --- a/doc/community.texi
> > +++ b/doc/community.te
device_uninit will be called by hwdevice_ctx_free. vulkan_device_uninit
is non-reentrant.
---
libavutil/hwcontext.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index e23bad230f..e8c6256a73 100644
--- a/libavutil/hwco
From: Zhao Zhili
Fix heap use after free when vulkan_frames_init failed.
---
libavutil/hwcontext.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index e8c6256a73..dec8b84783 100644
--- a/libavutil/hwcontext.c
+++ b/libav
From: Zhao Zhili
---
libavutil/vulkan.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/vulkan.h b/libavutil/vulkan.h
index b666841836..a5e78760d7 100644
--- a/libavutil/vulkan.h
+++ b/libavutil/vulkan.h
@@ -271,7 +271,7 @@ typedef struct FFVulkanContext {
static i
From: Zhao Zhili
Also simplify error handing.
---
This patch is untested since I don't have a proper device.
libavutil/hwcontext_vulkan.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index c64094f31c
From: Zhao Zhili
---
libavutil/hwcontext_vulkan.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index a84713e621..c64094f31c 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavuti
I found serious memory leaks (dozens of frames depends on video filter) when
test vulkan, which may or may not directly related to vulkan. See trac 10873.
> 在 2024年2月20日，下午8:08，Zhao Zhili 写道：
>
> From: Zhao Zhili
>
> ---
> libavutil/hwcontext_vulkan.c | 30 +++---
> 1
On 2/17/2024 7:02 PM, James Almer wrote:
Signed-off-by: James Almer
---
tests/fate/mov.mak | 35
tests/ref/fate/mov-mp4-iamf-5_1_4 | 98
tests/ref/fate/mov-mp4-iamf-7_1_4 | 114
tests/ref/fate/mov-mp4-
James Almer:
> Signed-off-by: James Almer
> ---
> libavformat/movenc.c | 349 +++
> libavformat/movenc.h | 6 +
> 2 files changed, 293 insertions(+), 62 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index c71a9983ed..cd63b35
Postponed in 9f4708c22def8a0f13c3b2bc39baca928bb58aaa
because the sample had not been uploaded at that time.
Signed-off-by: Andreas Rheinhardt
---
tests/fate/image.mak | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tests/fate/image.mak b/tests/fate/image.mak
index 40019
Andreas Rheinhardt:
> Fixes a leak in the mov-mp4-pcm-float FATE test.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/af_pan.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavfilter/af_pan.c b/libavfilter/af_pan.c
> index cfed9f146a..d8431a51d9 100644
> --- a/libavfilte
On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
[...]
> their preferred wording, and then we can have the GA vote on it.
Before this GA vote, we need another extra member discussion/vote.
Because the last GA reset droped several developers from the GA
thx
[...]
--
Michael Gnu
On 2/20/2024 10:37 AM, Andreas Rheinhardt wrote:
@@ -7862,7 +8087,7 @@ static int avif_write_trailer(AVFormatContext *s)
// write extent offsets.
pos_backup = avio_tell(pb);
-for (i = 0; i < s->nb_streams; i++) {
+for (i = 0; i < mov->nb_streams; i++) {
Can you use loop-s
Le 20 février 2024 16:01:11 GMT+02:00, Michael Niedermayer
a écrit :
>On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
>[...]
>> their preferred wording, and then we can have the GA vote on it.
>
>Before this GA vote, we need another extra member discussion/vote.
>Because the last
James Almer:
> On 2/20/2024 10:37 AM, Andreas Rheinhardt wrote:
>>> @@ -7862,7 +8087,7 @@ static int avif_write_trailer(AVFormatContext *s)
>>> // write extent offsets.
>>> pos_backup = avio_tell(pb);
>>> - for (i = 0; i < s->nb_streams; i++) {
>>> + for (i = 0; i < mov->nb_stre
From: Zhao Zhili
Without ff_vk_exec_discard_deps which is called by ff_vk_exec_wait,
the reference count of hwframe context cannot reach zero due to
circular reference created by ff_vk_exec_add_dep_frame.
Fix #10873
---
libavutil/hwcontext_vulkan.c | 4 +---
1 file changed, 1 insertion(+), 3 de
Hi all
I did hear (at fosdem?)
about the idea to switch from rsync to git for managing the fate samples
i thought the idea sounds interresting but isnt rsync more efficient ?
If someone wants to try (it would be interresting to see how it
compares to rsync in terms of bandwidth, speed, latency, l
On 2/20/2024 11:21 AM, Andreas Rheinhardt wrote:
James Almer:
On 2/20/2024 10:37 AM, Andreas Rheinhardt wrote:
@@ -7862,7 +8087,7 @@ static int avif_write_trailer(AVFormatContext *s)
// write extent offsets.
pos_backup = avio_tell(pb);
- for (i = 0; i < s->nb_streams; i++) {
Attached is an updated version of the patch proposal.
About the idea to keep separate fields in the output AVFrame, I note
from the discussion that it is commonly accepted that up to now it is
expected that the AVPacket contains what is in the MXF element and that
the AVFrame contains a frame
Anton Khirnov (12024-02-20):
> Hi,
> in the 'avcodec/s302m: enable non-PCM decoding' thread it became
> apparent that there is wide disagreement about the interpretation of
> this line in the TC rules:
>
> > If the disagreement involves a member of the TC, that member should
> > recuse themselves
Quoting Michael Niedermayer (2024-02-20 15:01:11)
> On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
> [...]
> > their preferred wording, and then we can have the GA vote on it.
>
> Before this GA vote, we need another extra member discussion/vote.
> Because the last GA reset droped
Fix fetch_timestamp when the frame start is in a previous packet.
Signed-off-by: Nicolas Gaullier
---
libavcodec/parser.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index efc28b8918..853b5323b0 100644
--- a/libavcodec/parse
This is the scenario:
- unaligned PES and NAL encoding
- the first NAL of the access unit begins at the very end of a ts packet,
sometimes only the 0x00 of the trailing byte (unfortunately, this is still
conformant to the standards!)
- the video frame is so small (ex: typically still picture) it
Signed-off-by: Nicolas Gaullier
---
libavformat/demux.c | 23 ++-
tests/ref/fate/concat-demuxer-simple2-lavf-ts | 164 +-
tests/ref/fate/ts-demux | 8 +-
3 files changed, 104 insertions(+), 91 deletions(-)
diff --git a/libavforma
>> Personally, I have not found a better solution as an mpegts fix, but if
>> anyone has a better code, of course my version can be dropped.
>> (I have not looked for a possible fix in the upper ffmpeg demux/parser
>> layers, but it would be certainly even more ugly, if possible at all).
>
>I don
Feb 20, 2024, 13:10 by quinkbl...@foxmail.com:
> From: Zhao Zhili
>
> ---
> libavutil/hwcontext_vulkan.c | 30 +++---
> 1 file changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
> index a84713e621..c6409
Also fixes a Clang warning:
"overlapping comparisons always evaluate to false
[-Wtautological-overlap-compare]"
Signed-off-by: Andreas Rheinhardt
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index afcee68
On 2024/2/21 01:10, Lynne wrote:
Feb 20, 2024, 13:10 by quinkbl...@foxmail.com:
From: Zhao Zhili
---
libavutil/hwcontext_vulkan.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
`colorspace` in avcodec terms means `matrix coefficients`.
---
libavcodec/av1dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 7ffa7821e9..7debc4deda 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -743,7 +743,7
On 2/20/2024 3:28 PM, Jan Ekström wrote:
`colorspace` in avcodec terms means `matrix coefficients`.
---
libavcodec/av1dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 7ffa7821e9..7debc4deda 100644
--- a/libavcodec/av1dec.
On 2/20/24 23:58, Jan Ekström wrote:
`colorspace` in avcodec terms means `matrix coefficients`.
---
libavcodec/av1dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 7ffa7821e9..7debc4deda 100644
--- a/libavcodec/av1dec.c
++
On Tue, Feb 20, 2024 at 4:31 PM Michael Niedermayer
wrote:
>
> Hi all
>
> I did hear (at fosdem?)
> about the idea to switch from rsync to git for managing the fate samples
> i thought the idea sounds interresting but isnt rsync more efficient ?
>
Do note that the idea was that this would only be
On Tue, Feb 20, 2024 at 8:30 PM James Almer wrote:
>
> On 2/20/2024 3:28 PM, Jan Ekström wrote:
> > `colorspace` in avcodec terms means `matrix coefficients`.
> > ---
> > libavcodec/av1dec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/av1dec.c b/lib
On 2/11/24 20:45, Lynne wrote:
Most of this patch was written by Dave Airlie ,
with some additions by me.
Tested and verified that this works with
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27424
___
ffmpeg-devel mailing list
ffmpeg-d
On Tue, 20 Feb 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-02-20 10:12:34)
We have no means to prove financial interest, because it is not public.
We also have no means to prove that committee members are acting in the
project's interest.
E.g. if I had no qualms about being dis
Le tiistaina 20. helmikuuta 2024, 10.22.57 EET Anton Khirnov a écrit :
> Hi,
> in the 'avcodec/s302m: enable non-PCM decoding' thread it became
> apparent that there is wide disagreement about the interpretation of
>
> this line in the TC rules:
> > If the disagreement involves a member of the TC,
On Tue, Feb 20, 2024 at 05:10:11PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-02-20 15:01:11)
> > On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
> > [...]
> > > their preferred wording, and then we can have the GA vote on it.
> >
> > Before this GA vote, we nee
On Tue, 20 Feb 2024 09:50:33 +0100 Anton Khirnov wrote:
> + Each TC member must vote on such decision according to what is, in their
> + view, best for the project. If a TC member is affected by a conflict of
> + interest with regards to the case, they must announce it and recuse
> + themselves fr
On Tue, Feb 20, 2024 at 8:58 PM Jan Ekström wrote:
>
> On Tue, Feb 20, 2024 at 8:30 PM James Almer wrote:
> >
> > On 2/20/2024 3:28 PM, Jan Ekström wrote:
> > > `colorspace` in avcodec terms means `matrix coefficients`.
> > > ---
> > > libavcodec/av1dec.c | 2 +-
> > > 1 file changed, 1 insert
> On Feb 20, 2024, at 12:41 PM, Michael Niedermayer
> wrote:
>
> On Tue, Feb 20, 2024 at 05:10:11PM +0100, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2024-02-20 15:01:11)
>>> On Tue, Feb 20, 2024 at 09:22:57AM +0100, Anton Khirnov wrote:
>>> [...]
their preferred wording, and th
On Mon, Feb 19, 2024 at 10:37:15PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-02-18 23:34:39)
[...]
> > > > But I think it is reasonable that parties of a disagreement cannot be
> > > > the judge of the disagreement.
> > >
> > > Why not? This is one of those truthy-sounding st
This is the proper poll mode for waiting for an incoming connection according
to the SRT API docs.
Fixes ticket #9142.
Signed-off-by: Marton Balint
---
libavformat/libsrt.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/libavformat/libsrt.c b/libavformat/
On Tue, Feb 20, 2024 at 09:12:11PM +, Cosmin Stejerean via ffmpeg-devel
wrote:
>
>
> > On Feb 20, 2024, at 12:41 PM, Michael Niedermayer
> > wrote:
> >
> > On Tue, Feb 20, 2024 at 05:10:11PM +0100, Anton Khirnov wrote:
> >> Quoting Michael Niedermayer (2024-02-20 15:01:11)
> >>> On Tue, F
>
> i disagree
>
> A TC member who wants to block a patch and wants to decide if a patch
> should be
> blocked is in the same situation as
>
> a Judge who wants to sue someone and wants to judge that someone.
>
Whilst I am not getting into a whole philosophical legal discussion about
this (to foll
Kieran Kunhya (12024-02-20):
> This isn't the same thing. The TC is more like a jury where a juror can
> have an opinion and their opinion can be swayed by arguments during private
In a jury trial, the defense can recuse any juror they want.
--
Nicolas George
__
Fixes errors when opening streams with no extradata (like those from raw OBU
sources). It also calls get_format() on new Sequence Headers when required.
Signed-off-by: James Almer
---
libavcodec/av1dec.c | 58 +
libavcodec/av1dec.h | 2 ++
2 files cha
On Tue, Feb 20, 2024 at 12:41:57AM -0300, James Almer wrote:
> On 2/19/2024 11:49 PM, Michael Niedermayer wrote:
> > +int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
> > +int srcW= 48, srcH = 48;
> > +int dstW= 48, dstH = 48;
> > +int srcHShift, srcVShift;
> > +int ds
Overlay filter for VideoToolbox hwframes. Unlike most hardware
overlay filters, this filter does not require the two inputs to
have the same pixel format; instead, it will perform format
conversion automatically with hardware accelerated methods.
Signed-off-by: Gnattu OC
---
Changelog
Yo,
On Tue, 20 Feb 2024, at 15:31, Michael Niedermayer wrote:
> I did hear (at fosdem?)
> about the idea to switch from rsync to git for managing the fate samples
> i thought the idea sounds interresting but isnt rsync more efficient ?
Yes, that's my idea.
The git part is not for others clients
Hello,
On Tue, 20 Feb 2024, at 05:48, wenbin.chen-at-intel@ffmpeg.org wrote:
> From: Wenbin Chen
>
> PyTorch is an open source machine learning framework that accelerates
OK for me
> the path from research prototyping to production deployment. Official
> websit: https://pytorch.org/. We cal
Signed-off-by: Gnattu OC
---
Changelog | 1 +
configure | 1 +
doc/filters.texi | 52 +++
libavfilter/Makefile | 3 +++
libavfilter/allfilters.c | 1 +
libavfilter/metal/utils.h | 1 -
libavfilter/metal/utils.
Overlay filter for VideoToolbox hwframes. Unlike most hardware
overlay filters, this filter does not require the two inputs to
have the same pixel format; instead, it will perform format
conversion automatically with hardware accelerated methods.
Signed-off-by: Gnattu OC
---
Changelog
Overlay filter for VideoToolbox hwframes. Unlike most hardware
overlay filters, this filter does not require the two inputs to
have the same pixel format; instead, it will perform format
conversion automatically with hardware accelerated methods.
Signed-off-by: Gnattu OC
---
Changelog
On 2/20/2024 10:17 PM, Michael Niedermayer wrote:
On Tue, Feb 20, 2024 at 12:41:57AM -0300, James Almer wrote:
On 2/19/2024 11:49 PM, Michael Niedermayer wrote:
+int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
+int srcW= 48, srcH = 48;
+int dstW= 48, dstH = 48;
+int s
From: Wenbin Chen
PyTorch is an open source machine learning framework that accelerates
the path from research prototyping to production deployment. Official
website: https://pytorch.org/. We call the C++ library of PyTorch as
LibTorch, the same below.
To build FFmpeg with LibTorch, please take
> Hello,
>
> On Tue, 20 Feb 2024, at 05:48, wenbin.chen-at-intel@ffmpeg.org wrote:
> > From: Wenbin Chen
> >
> > PyTorch is an open source machine learning framework that accelerates
>
> OK for me
>
> > the path from research prototyping to production deployment. Official
> > websit: https:
> On Feb 21, 2024, at 09:39, Jean-Baptiste Kempf wrote:
>
> Yo,
>
> On Tue, 20 Feb 2024, at 15:31, Michael Niedermayer wrote:
>> I did hear (at fosdem?)
>> about the idea to switch from rsync to git for managing the fate samples
>> i thought the idea sounds interresting but isnt rsync more eff
On Tue, Feb 20, 2024 at 05:33:01PM +0100, Nicolas Gaullier wrote:
> Fix fetch_timestamp when the frame start is in a previous packet.
>
> Signed-off-by: Nicolas Gaullier
> ---
> libavcodec/parser.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
This change looses pts
--- /tmp/ol
When the silencedetect audio filter is run against long files, the
output timestamps gradually lose precision as the scan proceeds further
into the file. This is because the output format specifier ("%.6g" in
libavutil/timestamp.h) limits the total field width to six significant
digits. As the offs
64 matches
Mail list logo
