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
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
---
> 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
> 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:
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
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
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
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 -
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
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
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 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
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
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
>
> 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
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,
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
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
> 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
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
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
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
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
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
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
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
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
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 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
---
`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 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
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
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
>> 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
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
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
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
---
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
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
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
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++) {
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,
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
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 <
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
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
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
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
> ---
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
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
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
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 +++---
>
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
+++
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
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
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
+++
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
---
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
> > +++
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
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
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
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
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
64 matches
Mail list logo
