Hello,
My messages are being blocked on the mailing list. How is this fair that
one person can unilaterally decide this?
Here is my message:
Hi Michael,
If the CC has voted to ban someone, why has it not happened?
You can't complain it the CC fails to act when it has voted for something
to hap
based on Hendrik Leppkes's fork
0001-matroskadec-support-S_TEXT-WEBVTT.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmp
---
libavcodec/ffv1.h| 2 +
libavcodec/ffv1dec.c | 451 +--
2 files changed, 268 insertions(+), 185 deletions(-)
diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
index ca03fd2b10..93174bd45e 100644
--- a/libavcodec/ffv1.h
+++ b/libavcodec/ffv1.h
@@
On Thu, 19 Dec 2024 05:07:16 +0100 Michael Niedermayer
wrote:
> Hi
>
>
> On Mon, Dec 16, 2024 at 12:17:23PM +0100, Niklas Haas wrote:
> [...]
> > diff --git a/libswscale/utils.h b/libswscale/utils.h
> > index 4d204ef6cc..52b1e67644 100644
> > --- a/libswscale/utils.h
> > +++ b/libswscale/utils.h
Hi J-B:
> The 2 situations are not the same at all:
> One claims to be from this community and uses the FFmpeg name,
> the other one does not make any claims.
> Please don't confuse the 2 situations.
Thanks for clarifying, I was going off of my interpretation
based on how I read through it last n
On Thu, 19 Dec 2024 14:58:34 +0100, Anton Khirnov wrote:
> Quoting James Almer (2024-12-19 14:04:53)
> > On 12/19/2024 6:34 AM, Anton Khirnov wrote:
> > > Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14)
> > >> Hello,
> > >>
> > >> My messages are being blocked on the mailing list.
Hello,
On Thu, 19 Dec 2024, at 04:40, Marth64 wrote:
> Statement #1 (NAB 2023)
>
> * Trademarked FFmpeg branding was used by a different organization
> without clear authorization.
Incorrect: FFmpeg is not trademarked in the USA.
Actually, in 2023, FFmpeg was not trademarked anywhere in the
On 12/19/2024 6:34 AM, Anton Khirnov wrote:
Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14)
Hello,
My messages are being blocked on the mailing list. How is this fair that
one person can unilaterally decide this?
This also happened to one mail I sent a few weeks ago. I thought it
On Thu, 19 Dec 2024, 02:22 Michael Niedermayer,
wrote:
>
> Kieran reports this to the CC
> and jb and ronald vote for a third ban of Nicolas,
> ronald states that he would not have voted for a ban if Nicolas apologized.
>
Hi Michael,
If the CC has voted to ban someone, why has it not happened?
On Thu, 19 Dec 2024 13:16:23 -0300, James Almer wrote:
> On 12/19/2024 1:12 PM, compn wrote:
> > On Thu, 19 Dec 2024 10:04:53 -0300, James Almer wrote:
> >> I have no idea who added the rule for "upcoming vote", but i just
> >> removed it.
> >>
> >
> > i added upcoming vote to mod as devs were
On 12/19/2024 11:46 AM, Timo Rothenpieler wrote:
On 19/12/2024 09:58, Kieran Kunhya via ffmpeg-devel wrote:
Hello,
My messages are being blocked on the mailing list. How is this fair that
one person can unilaterally decide this?
It's not even possible for a moderator do hold individual mails
On Thu, 19 Dec 2024 10:04:53 -0300, James Almer wrote:
> On 12/19/2024 6:34 AM, Anton Khirnov wrote:
> > Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14)
> >> Hello,
> >>
> >> My messages are being blocked on the mailing list. How is this fair that
> >> one person can unilaterally de
On Thu, 19 Dec 2024 08:58:14 +, Kieran Kunhya via ffmpeg-devel
wrote:
> Hello,
>
> My messages are being blocked on the mailing list.
your message, and the message of others in that specific thread was
not blocked. it was held for moderator approval as you quoted below.
> The reason it is b
On 12/19/2024 1:12 PM, compn wrote:
On Thu, 19 Dec 2024 10:04:53 -0300, James Almer wrote:
On 12/19/2024 6:34 AM, Anton Khirnov wrote:
Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14)
Hello,
My messages are being blocked on the mailing list. How is this fair that
one person can u
On 12/16/24 6:17 AM, Niklas Haas wrote:
From: Niklas Haas
---
libswscale/utils.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 2d8fc10beb..3d3fcadacc 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -46
From: Niklas Haas
This one was documented, but never actually supported.
Fixes: ticket #9192
Signed-off-by: Niklas Haas
Sponsored-by: Sovereign Tech Fund
---
libswscale/options.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libswscale/options.c b/libswscale/options.c
index 5eef26de06..8
Quoting James Almer (2024-12-19 14:04:53)
> On 12/19/2024 6:34 AM, Anton Khirnov wrote:
> > Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14)
> >> Hello,
> >>
> >> My messages are being blocked on the mailing list. How is this fair that
> >> one person can unilaterally decide this?
> >
From: Niklas Haas
This fixes multiple bugs with semiplanar formats like NV12. Not only do these
false positive the grayscale format checks (because dst[2] in NULL), but they
also copied an incorrect number of pixels.
Fixes conversions such as nv12 -> nv12, gray8 -> nv12, nv20le -> nv20be, etc.
From: Niklas Haas
As fixed in the previous commit, this enables semipacked range and
bit depth conversions. Previously these would go through the general
purpose path.
Signed-off-by: Niklas Haas
Sponsored-by: Sovereign Tech Fund
---
libswscale/swscale_unscaled.c | 2 +-
1 file changed, 1 inser
Quoting Niklas Haas (2024-12-19 15:07:59)
> From: Niklas Haas
>
> This fixes multiple bugs with semiplanar formats like NV12. Not only do these
> false positive the grayscale format checks (because dst[2] in NULL), but they
> also copied an incorrect number of pixels.
>
> Fixes conversions such
On Mon, Dec 16, 2024 at 12:17:26PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> Logic ported from libplacebo's AVFrame helpers. The basic idea is to use the
> provided MaxRGB/MaxSCL values to infer what the actual luminance would have
> been, which HDR10+ metadata does not provide directly.
On Wed, 04 Dec 2024 15:51:02 +0100 Niklas Haas wrote:
> From: Niklas Haas
>
> This entry was seemingly missing.
> ---
> libavutil/frame.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 5fb47dbaa6..3020845ef8 100644
> --- a/libavutil/frame.c
On 19 Dec 2024, at 10:34, Anton Khirnov wrote:
> Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14)
>> Hello,
>>
>> My messages are being blocked on the mailing list. How is this fair that
>> one person can unilaterally decide this?
>
> This also happened to one mail I sent a few week
Hi there,
On 12/13/24 15:09, Tristan Matthews via ffmpeg-devel wrote:
I don't seem to be able to replay the Chimera video directly with my
local build of ffplay, get's all choppy and skips big deals of the
video. Might be an outdated libdav1d?
I still have problems with the media server and t
Hi,
On Thu, Dec 19, 2024 at 8:05 AM Kieran Kunhya via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> On Thu, 19 Dec 2024, 02:22 Michael Niedermayer,
> wrote:
>
> > Kieran reports this to the CC
> > and jb and ronald vote for a third ban of Nicolas,
> > ronald states that he would not have vote
Hi,
On Thu, Dec 19, 2024 at 8:23 AM Chris Hodges wrote:
> Hi there,
>
> On 12/13/24 15:09, Tristan Matthews via ffmpeg-devel wrote:
>
> >> I don't seem to be able to replay the Chimera video directly with my
> >> local build of ffplay, get's all choppy and skips big deals of the
> >> video. Migh
On 19/12/2024 09:58, Kieran Kunhya via ffmpeg-devel wrote:
Hello,
My messages are being blocked on the mailing list. How is this fair that
one person can unilaterally decide this?
It's not even possible for a moderator do hold individual mails after
the fact, unless I'm missing something here
Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14)
> Hello,
>
> My messages are being blocked on the mailing list. How is this fair that
> one person can unilaterally decide this?
This also happened to one mail I sent a few weeks ago. I thought it was
a thread block put in place by CC,
> On Dec 19, 2024, at 08:28, James Almer wrote:
>
> On 12/18/2024 6:59 PM, Scott Theisen wrote:
>> Originally from:
>> https://github.com/MythTV/mythtv/commit/669955c6cb29196b4b5120451b5b998d67a65749
>> ---
>> v3:
>> remove unnecessary clearing of already 0 valued flags
>> use switch-case; I don
On 12/4/2024 11:51 AM, Niklas Haas wrote:
From: Niklas Haas
As discussed in the previous commit, we often need a convenient way of
stripping all side data related to a certain aspect of the frame. This helper
accomplishes just that.
I considered also adding a way to match only side data matchi
Quoting compn (2024-12-19 17:32:26)
> On Thu, 19 Dec 2024 14:58:34 +0100, Anton Khirnov wrote:
>
> > Quoting James Almer (2024-12-19 14:04:53)
> > > On 12/19/2024 6:34 AM, Anton Khirnov wrote:
> > > > Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14)
> > > >> Hello,
> > > >>
> > > >
On Thu, 19 Dec 2024 17:51:24 +0100, Anton Khirnov wrote:
> Quoting compn (2024-12-19 17:32:26)
> > On Thu, 19 Dec 2024 14:58:34 +0100, Anton Khirnov wrote:
> > > I saw no announcement of any CC action related to that thread.
> >
> > i didnt moderate that standard*set thread. CC did , as specifi
Hi
On Mon, Dec 16, 2024 at 12:17:33PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> Logic is, for the most part, a straight port of similar logic in
> liplacebo's colorspace.c, with some general edits and refactors.
> ---
> libswscale/Makefile | 1 +
> libswscale/csputils.c | 418 ++
Hi
On Mon, Dec 16, 2024 at 12:17:35PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> This is a lightweight wrapper around the underlying color management system,
> whose job it is merely to manage the 3DLUT state and apply them to the frame
> data. This is where we might add platform-specific
Hi,
On Thu, Dec 19, 2024 at 11:51 AM Anton Khirnov wrote:
> Quoting compn (2024-12-19 17:32:26)
> > i didnt moderate that standard*set thread. CC did , as specified here:
> >
> >
> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-December/337678.html
>
> Then I apologize for the speculation.
On Mon, Dec 16, 2024 at 12:17:36PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> This leverages the previously introduced color management subsystem in order
> to adapt between transfer functions and color spaces, as well as for HDR tone
> mapping.
>
> Take special care to handle grayscale f
Hi
On Mon, Dec 16, 2024 at 12:17:30PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> In the long run, it would be ideal if we could add these to the avfilter
> negotiation as well, but for now, this is a good start.
> ---
> doc/filters.texi | 56
> liba
On Mon, Dec 16, 2024 at 12:17:32PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> This is no longer relevant after a change in color space.
> ---
> libavfilter/vf_scale.c | 12
> 1 file changed, 12 insertions(+)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF67
On Thu, 19 Dec 2024 20:40:55 +, Kieran Kunhya via ffmpeg-devel
wrote:
> Please can you confirm you will be resigning your moderator status in light
> of the election censorship you have undertaken while at the same time being
> a candidate for CC?
i have no intention to resign from being ml a
This reduces the amount the horizontal filters read beyond the filter
width to a consistent 1 pixel. The data is not used so this is usually
not noticeable. It becomes a problem when the application allocates
frame buffers only for the aligned picture size and the end of it is at
a page boundary. T
The arm/aarch64 horizontal filter reads one additional pixel beyond what
the filter uses. This can become an issue if the application does not
allocate larger buffers than what's required for the pixel data. If the
motion vector points to the bottom right edge of the picture this
becomes a read buf
This reduces the amount the horizontal filters read beyond the filter
width to a consistent 1 pixel. The data is not used so this is usually
not noticeable. It becomes a problem when the application allocates
frame buffers only for the aligned picture size and the end of it is at
a page boundary. T
On Thu, 19 Dec 2024, 20:30 compn, wrote:
> On Thu, 19 Dec 2024 20:15:10 +, Kieran Kunhya via ffmpeg-devel
> wrote:
>
> > Some Animals are More Equal Than Others.
> >
> > Kieran
>
> and now a CC candidate calling devs animals ?
>
This is one of the most famous literary quotes:
https://www.dic
On Thu, 19 Dec 2024 20:15:10 +, Kieran Kunhya via ffmpeg-devel
wrote:
> Some Animals are More Equal Than Others.
>
> Kieran
and now a CC candidate calling devs animals ?
-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.o
On Thu, 19 Dec 2024 20:35:43 +, Kieran Kunhya via ffmpeg-devel
wrote:
> On Thu, 19 Dec 2024, 20:30 compn, wrote:
>
> > On Thu, 19 Dec 2024 20:15:10 +, Kieran Kunhya via ffmpeg-devel
> > wrote:
> >
> > > Some Animals are More Equal Than Others.
> > >
> > > Kieran
> >
> > and now a CC
On Thu, 19 Dec 2024, 20:38 compn, wrote:
> On Thu, 19 Dec 2024 20:35:43 +, Kieran Kunhya via ffmpeg-devel
> wrote:
>
> > On Thu, 19 Dec 2024, 20:30 compn, wrote:
> >
> > > On Thu, 19 Dec 2024 20:15:10 +, Kieran Kunhya via ffmpeg-devel
> > > wrote:
> > >
> > > > Some Animals are More Equa
Hi
On Wed, Dec 18, 2024 at 07:40:43PM -1000, compn wrote:
> On Thu, 19 Dec 2024 03:22:46 +0100, Michael Niedermayer wrote:
>
> i think we need to have a separate mailing list to talk about non
> development stuff.
>
> i think there are a lot of people who wish to contribute to ffmpeg and
> deve
Hi Kieran
First before replying, id like to say, that i hope we can resolve this and
in the future work together in a mutually more friendly way.
On Wed, Dec 18, 2024 at 10:18:20PM -0500, Kieran Kunhya via ffmpeg-devel wrote:
> > 1a. Prior context:
> > For a long time FFmpeg booths where organize
On Thu, Dec 19, 2024 at 7:25 PM Michael Niedermayer
wrote:
>
> Hi Kieran
>
> First before replying, id like to say, that i hope we can resolve this and
> in the future work together in a mutually more friendly way.
>
> On Wed, Dec 18, 2024 at 10:18:20PM -0500, Kieran Kunhya via ffmpeg-devel
> wro
On 2024-12-19 06:46 -1000, compn wrote:
> On Thu, 19 Dec 2024 13:16:23 -0300, James Almer wrote:
>
> > On 12/19/2024 1:12 PM, compn wrote:
> > > On Thu, 19 Dec 2024 10:04:53 -0300, James Almer wrote:
> > >> I have no idea who added the rule for "upcoming vote", but i just
> > >> removed it.
> > >>
Hi
On Thu, Dec 19, 2024 at 08:27:50AM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Dec 19, 2024 at 8:05 AM Kieran Kunhya via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
> > On Thu, 19 Dec 2024, 02:22 Michael Niedermayer,
> > wrote:
> >
> > > Kieran reports this to the CC
> > > and jb
Hi
On Thu, Dec 19, 2024 at 11:12:21AM +0100, Marvin Scholz wrote:
>
>
> On 19 Dec 2024, at 10:34, Anton Khirnov wrote:
>
> > Quoting Kieran Kunhya via ffmpeg-devel (2024-12-19 09:58:14)
> >> Hello,
> >>
> >> My messages are being blocked on the mailing list. How is this fair that
> >> one perso
Hi Kieran
(also thx to compn for reminding me about this mail)
On Fri, Dec 13, 2024 at 01:30:43AM +, Kieran Kunhya via ffmpeg-devel wrote:
> Hello,
>
> This person asked for coverity access:
> https://x.com/acentauri92/status/1867186643704099105
>
> I don't know if they should have access.
Hi
On Tue, Dec 17, 2024 at 11:23:39PM +0100, Timo Rothenpieler wrote:
> On 15.12.2024 23:41, Michael Niedermayer wrote:
> > Hi Timo
> >
> > On Thu, Dec 12, 2024 at 08:55:31PM +0100, Timo Rothenpieler wrote:
> > > ---
> > > libavformat/flvenc.c | 96 ++--
>
On Wed, Dec 11, 2024 at 09:27:51AM +1100, Peter Ross wrote:
> Fixes ticket #5553.
> ---
> Additional hardening thanks to target_dem_fuzzer.c
>
> libavformat/iff.c | 311 +++---
> 1 file changed, 210 insertions(+), 101 deletions(-)
>
will apply
-- Peter
(
Hi,
On Thu, Dec 19, 2024 at 2:02 PM Michael Niedermayer
wrote:
> Hi
>
> On Thu, Dec 19, 2024 at 08:27:50AM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Thu, Dec 19, 2024 at 8:05 AM Kieran Kunhya via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> >
> > > On Thu, 19 Dec 2024, 02:22 Mich
Hi Marth64
On Wed, Dec 18, 2024 at 10:27:40PM -0600, Marth64 wrote:
> Hi Michael,
>
> > 2. and the most recent case
> Continuing where I left off.
>
> Let us analyze the s337m situation.
> * Contributor shares significant work, as an RFC, in good faith
> * A back and forth exchange happens with
Hi compn
On Thu, Dec 19, 2024 at 06:16:03AM -1000, compn wrote:
> On Thu, 19 Dec 2024 08:58:14 +, Kieran Kunhya via ffmpeg-devel
> wrote:
>
> > Hello,
> >
> > My messages are being blocked on the mailing list.
>
> your message, and the message of others in that specific thread was
> not blo
Hi
On Wed, Dec 18, 2024 at 12:48:03PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Dec 18, 2024 at 5:29 AM Niklas Haas wrote:
>
> > On Wed, 18 Dec 2024 02:32:07 +0100 Michael Niedermayer <
> > mich...@niedermayer.cc> wrote:
> > > Hi
> > >
> > > On Tue, Dec 17, 2024 at 10:31:42AM +0100, Nikl
From: Dennis Sädtler
Based on enhanced-rtmp v2 spec published by Veovera:
https://veovera.github.io/enhanced-rtmp/docs/enhanced/enhanced-rtmp-v2
This implementation maintains some backwards compatibility by only
writing the track information for track indices > 0. This means that
older FFmpeg ve
This should address most of the comments received on the previous
iteration.
Added a test, and found one more issue that allowed muxing invalid
files, which is fixed by patch 16/16.
Dennis Sädtler (2):
avformat/flvenc: implement support for multi-track video
avformat/flvdec: add support for de
---
libavformat/flvdec.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 15312cfa02..c66c37efa2 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1396,8 +1396,8 @@ re
---
libavformat/rtmpproto.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index b3b1eedacb..bb974390d3 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -356,8 +356,15 @@ static int gen_connect(URLC
---
libavformat/flv.h| 6 ++
libavformat/flvenc.c | 149 +++
2 files changed, 114 insertions(+), 41 deletions(-)
diff --git a/libavformat/flv.h b/libavformat/flv.h
index 653c2bc82c..d030d576f3 100644
--- a/libavformat/flv.h
+++ b/libavformat/flv.h
@@
From: Dennis Sädtler
Based on enhanced-rtmp v2 spec published by Veovera:
https://veovera.github.io/enhanced-rtmp/docs/enhanced/enhanced-rtmp-v2
Signed-off-by: Dennis Sädtler
---
libavformat/flvdec.c | 119 +++
1 file changed, 97 insertions(+), 22 deleti
---
libavformat/flvenc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 1818b5482a..78235af233 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -1070,11 +1070,6 @@ static int flv_write_packet(AVFormatContext *s, AVPacket
---
libavformat/flv.h| 8 +++
libavformat/flvdec.c | 119 +++
2 files changed, 116 insertions(+), 11 deletions(-)
diff --git a/libavformat/flv.h b/libavformat/flv.h
index d030d576f3..8926db6388 100644
--- a/libavformat/flv.h
+++ b/libavformat/flv.h
@@
---
tests/fate/flvenc.mak | 4 +
tests/ref/fate/enhanced-flv-multitrack | 526 +
2 files changed, 530 insertions(+)
create mode 100644 tests/ref/fate/enhanced-flv-multitrack
diff --git a/tests/fate/flvenc.mak b/tests/fate/flvenc.mak
index e3703a8cc5..7b
---
libavformat/flvdec.c | 571 +++
1 file changed, 310 insertions(+), 261 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index c66c37efa2..39e872f473 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1275,6 +1275,7 @@
---
libavformat/flvenc.c | 96 ++--
1 file changed, 47 insertions(+), 49 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 78235af233..5973e6be8d 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -493,6 +493,45 @@ sta
---
libavformat/rtmpproto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index bb974390d3..a34020b092 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -2004,7 +2004,7 @@ static int send_invoke_response(UR
---
libavformat/flvenc.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 09a930fb1a..f3f32dc433 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -970,6 +970,15 @@ static int flv_init(struct AVForma
---
libavformat/flvenc.c | 92
1 file changed, 68 insertions(+), 24 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 5623b119fd..09a930fb1a 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -132,7 +132,7 @@ type
---
libavformat/flvdec.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index fbc8bc9d32..15312cfa02 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1338,12 +1338,26 @@ retry:
pkt_
---
libavformat/flvenc.c | 93
1 file changed, 85 insertions(+), 8 deletions(-)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 5973e6be8d..5623b119fd 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -712,10 +712,82 @@ sta
---
libavformat/flvdec.c | 41 +
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index f9859c0980..fbc8bc9d32 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1337,8 +1337,6 @@ retry
fix for https://trac.ffmpeg.org/ticket/11360
Signed-off-by: Lingyi Kong
---
libavcodec/h264_mb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
index 4e94136313..6083f7ad84 100644
--- a/libavcodec/h264_mb.c
+++ b/libavcodec/h264_m
When decoding a bitstream with weighted-bipred enabled,
the results on ARM and x86 platforms may differ.
The reason for the inconsistency is that the value of
STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN
is set to the buffer stride of temporary buffers for U
and V components in mc_part
On 12/19/2024 5:04 PM, Michael Niedermayer wrote:
Hi Kieran
(also thx to compn for reminding me about this mail)
On Fri, Dec 13, 2024 at 01:30:43AM +, Kieran Kunhya via ffmpeg-devel wrote:
Hello,
This person asked for coverity access:
https://x.com/acentauri92/status/1867186643704099105
On Thu, Dec 19, 2024 at 7:52 PM Michael Niedermayer
wrote:
>
> Hi compn
>
> On Thu, Dec 19, 2024 at 06:16:03AM -1000, compn wrote:
> > On Thu, 19 Dec 2024 08:58:14 +, Kieran Kunhya via ffmpeg-devel
> > wrote:
> >
> > > Hello,
> > >
> > > My messages are being blocked on the mailing list.
> >
>
On Thu, 19 Dec 2024 21:04:50 +0100, Michael Niedermayer wrote:
> Hi Kieran
>
> (also thx to compn for reminding me about this mail)
>
> On Fri, Dec 13, 2024 at 01:30:43AM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> > Hello,
> >
> > This person asked for coverity access:
> > https://x.com/
Hi
On Wed, Dec 18, 2024 at 03:24:59PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> Fixes: ticket #9520
> Signed-off-by: Niklas Haas
> Sponsored-by: Sovereign Tech Fund
> ---
> libswscale/swscale.c | 2 +
> libswscale/swscale_unscaled.c | 81 ++-
>
On Fri, 20 Dec 2024 06:24:46 +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-12-19 20:52:39)
> > This was a brave decission and IMO it was the correct decission.
> > You saw people fighting, and you stepped between them to stop it.
>
> So what we have here is a server admin appr
fix for https://trac.ffmpeg.org/ticket/11360
Signed-off-by: Lingyi Kong
---
libavcodec/h264_mb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
index 4e94136313..6083f7ad84 100644
--- a/libavcodec/h264_mb.c
+++ b/libavcodec/h264_
On Fri, 20 Dec 2024 01:35:01 +, Kieran Kunhya via ffmpeg-devel
wrote:
> On Thu, Dec 19, 2024 at 9:11 PM compn wrote:
> >
> > On Thu, 19 Dec 2024 20:40:55 +, Kieran Kunhya via ffmpeg-devel
> > wrote:
> >
> > > Please can you confirm you will be resigning your moderator status in
> > > l
Hi
On Fri, Dec 20, 2024 at 02:44:43AM +0900, Lynne via ffmpeg-devel wrote:
> ---
> libavcodec/ffv1.h| 2 +
> libavcodec/ffv1dec.c | 451 +--
> 2 files changed, 268 insertions(+), 185 deletions(-)
breaks fate on ubuntu x86-64
TESTffmpeg-loopback-
On 12/18/2024 11:24 AM, Niklas Haas wrote:
From: Niklas Haas
Fixes: ticket #9520
Signed-off-by: Niklas Haas
Sponsored-by: Sovereign Tech Fund
---
libswscale/swscale.c | 2 +
libswscale/swscale_unscaled.c | 81 ++-
2 files changed, 81 insertions(+),
On Thu, Dec 19, 2024 at 9:11 PM compn wrote:
>
> On Thu, 19 Dec 2024 20:40:55 +, Kieran Kunhya via ffmpeg-devel
> wrote:
>
> > Please can you confirm you will be resigning your moderator status in light
> > of the election censorship you have undertaken while at the same time being
> > a candi
When decoding a bitstream with weighted-bipred enabled,
the results on ARM and x86 platforms may differ.
The reason for the inconsistency is that the value of
STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN
is set to the buffer stride of temporary buffers for U
and V components in mc_par
Quoting Michael Niedermayer (2024-12-19 20:52:39)
> This was a brave decission and IMO it was the correct decission.
> You saw people fighting, and you stepped between them to stop it.
So what we have here is a server admin approving and encouraging his
buddy to perform arbitrary censorship with n
fix for https://trac.ffmpeg.org/ticket/11360
Signed-off-by: Lingyi Kong
---
libavcodec/h264_mb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
index 4e94136313..6083f7ad84 100644
--- a/libavcodec/h264_mb.c
+++ b/libavcodec/h264_mb
When decoding a bitstream with weighted-bipred enabled,
the results on ARM and x86 platforms may differ.
The reason for the inconsistency is that the value of
STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN
is set to the buffer stride of temporary buffers for U
and V components in mc_part
92 matches
Mail list logo
