>
> > - The doors will be closed for all future
>
> As i predicted elsewhere privately, I do not belive Paul will return
> unless his fork fails.
> The more successfull his fork is, the less likely it is that he will
> return
>
> Also its like 18 months since paul forked and the way he speaks reall
On Sun, 1 Jun 2025, 20:23 Michael Niedermayer,
wrote:
> Hi James
>
> On Sun, Jun 01, 2025 at 02:27:37PM -0300, James Almer wrote:
> > On 6/1/2025 12:22 PM, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > almpeg is now merged upto 1 months ago. (and since last merge it
> contains
> > > bits of
On Sun, 1 Jun 2025, 16:22 Michael Niedermayer,
wrote:
> Hi all
>
> almpeg is now merged upto 1 months ago. (and since last merge it contains
> bits of AGPL code)
>
> The question now is, how does the community want to proceed from here?
>
> I think there are mainly 2 options
>
> 1. People review
>
> Let's get to the cast of the final chapter:
>
> - Lynne
> - Nicolas George
> - Kieran Kunyar
>
> The fact all of us (who normally disagree on various technical topics)
agree about the deficiencies of your patch speaks volumes.
Kieran
>
___
ffmpeg-de
On Sat, 31 May 2025, 10:17 Dmitriy Kovalenko,
wrote:
> This patch integrates so called double bufferring when we are loading
>
Nit: I am not sure this is what most people refer to as "double buffering"
Kieran
>
___
ffmpeg-devel mailing list
ffmpeg-de
>
> }
> +
> +if (strm.avail_out == 0) {
> +chunk *= 8;
>
*8 seems high
+uint8_t *tmp_buf = av_realloc(buf, chunk + 1);
> +if (!tmp_buf) {
> +inflateEnd(&strm);
> +av_free(buf);
> +return AVERROR(E
>
> - adding vzeroupper: ~12%
>
This seems quite suspicious.
Can you explain what you are doing here?
Kieran
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or
On Mon, May 26, 2025 at 8:13 PM Zhao Zhili
wrote:
>
>
>
> > On May 22, 2025, at 13:06, Zhao Zhili
> > wrote:
> >
> > From: Zhao Zhili
> >
> > Fix error reported by swscaler:
> > Unsupported input (Operation not supported): fmt:yuv420p csp:unknown
> > prim:reserved trc:bt709 -> fmt:yuv420p csp:
Hi Michael,
Here is how this should be handled.
"Hi Paul,
I'm sorry for aggressively trying to force SDR into the FFmpeg project
over a period of several weeks in spite of objections from you and the
community causing you to leave.
FFmpeg is now a better community* and we would love it if you co
Hi Michael,
On Wed, 14 May 2025, 23:35 Michael Niedermayer,
wrote:
> On Sun, May 11, 2025 at 10:13:36PM +0200, Michael Niedermayer wrote:
> > This is based on discussion with the GA and its simply the people
> > who have done or tried to do some uploads recently.
> >
> > Everyone who has a shel
On Sat, 24 May 2025, 17:39 Michael Niedermayer,
wrote:
> Hi
>
> On Fri, May 23, 2025 at 01:13:05PM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
> > > As an example i could have instead replied with a tone matching yours:
> > > (below is a (true) exa
On Tue, 4 Mar 2025, 19:01 Kieran Kunhya, wrote:
>
>
> On Tue, 4 Mar 2025, 11:17 Michael Niedermayer,
> wrote:
>
>> Hi Kieran
>>
>> On Tue, Mar 04, 2025 at 08:13:11AM -0600, Kieran Kunhya via ffmpeg-devel
>> wrote:
>> [...]
>> > Hi Michael,
On Thu, 22 May 2025, 07:32 Jiawei, wrote:
> 在 2025/5/22 2:21, Frank Plowman 写道:
> > On 21/05/2025 11:17, Jiawei wrote:
> >> 在 2025/5/21 14:52, Nicolas George 写道:
> >>> Jiawei (HE12025-05-21):
> particularly improving
> performance on x86_64 (AVX), AR
On Fri, 23 May 2025, 21:35 Michael Niedermayer,
wrote:
> Hi Kieran
>
> On Fri, May 23, 2025 at 04:45:53PM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> > On Fri, May 23, 2025 at 4:00 PM Kieran Kunhya
> wrote:
> > >
> > > On Fri, May 23, 2025 at
:40PM -0400, Devin Heitmueller wrote:
> > > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> > > > wrote:
> > > > > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > > > > maintenance of FFmpeg.
> &
On Fri, May 23, 2025 at 3:50 PM Devin Heitmueller
wrote:
>
> Hello Michael,
>
> On Fri, May 23, 2025 at 5:45 AM Michael Niedermayer
> wrote:
> > On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya
On Fri, May 23, 2025 at 12:33 PM Michael Niedermayer
wrote:
>
> Hi Kieran
>
> On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
> > I appreciate the way the 2024 organisers ran STF was not exactly stellar
>
> It seems every
On Fri, 23 May 2025, 12:33 Michael Niedermayer,
wrote:
> Hi Kieran
>
> On Fri, May 23, 2025 at 08:51:43AM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
> > I appreciate the way the 2024 organisers ran STF was not exactly stellar
>
> It seems every mail you pos
On Fri, 23 May 2025, 10:45 Michael Niedermayer,
wrote:
> Hi
>
> On Thu, May 22, 2025 at 07:55:40PM -0400, Devin Heitmueller wrote:
> > On Thu, May 22, 2025 at 7:42 PM Kieran Kunhya via ffmpeg-devel
> > wrote:
> > > I wanted to put on the record that
On Fri, 23 May 2025, 10:58 Michael Niedermayer,
wrote:
> On Fri, May 23, 2025 at 11:45:14AM +0200, Michael Niedermayer wrote:
> > Hi
> [...]
> > > I agree with Kieran that this seems to largely be outside the STF
> > > objectives (i.e. sustainability for open source projects).
> >
> > A new imple
On Fri, 23 May 2025, 04:44 Lynne, wrote:
> On 23/05/2025 08:42, Kieran Kunhya via ffmpeg-devel wrote:
> > Hello,
> >
> > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > maintenance of FFmpeg.
>
> It isn't -- it's research.
&g
On Fri, 23 May 2025, 04:44 Lynne, wrote:
> On 23/05/2025 08:42, Kieran Kunhya via ffmpeg-devel wrote:
> > Hello,
> >
> > I wanted to put on the record that adding RaptorQ to FFmpeg isn't
> > maintenance of FFmpeg.
>
> It isn't -- it's research.
&
Hello,
I wanted to put on the record that adding RaptorQ to FFmpeg isn't
maintenance of FFmpeg.
It's adding an obscure FEC protocol to FFmpeg, which is not going to be
implemented well without an event loop anyway.
I do not think it's a suitable STF project.
Regards,
Kieran Kunhya
_
On Thu, 22 May 2025, 15:03 softworkz ., wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Kieran
> > Kunhya via ffmpeg-devel
> > Sent: Donnerstag, 22. Mai 2025 14:46
> > To: FFmpeg development discussions and patches
> > C
> I really wonder how Kieran can't be embarrassed trying such maneuvers which
> are so obvious to everybody.
I really wonder how you can't be embarrassed sending what imo is the
worst patchset in the history of the project.
Instead of acknowledging that, it's deflecting and playing the victim
you
On Thu, May 22, 2025 at 12:24 PM Michael Niedermayer
wrote:
> 4. "seeing the scale of memory leaks." try to compare this to
>IAMF "git log --grep IAMF --oneline", IAMF is after a year still receiving
>frequent security fixes. This is just as a comparission
This is completely different, on
: ffmpeg-devel On Behalf Of Kyle
> > Swanson
> > > Sent: Mittwoch, 21. Mai 2025 22:11
> > > To: FFmpeg development discussions and patches <
> ffmpeg-devel@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] Graphprint Patches Overview
> > >
> > >
On Wed, May 21, 2025 at 2:00 PM Niklas Haas wrote:
>
> From: Niklas Haas
>
> This covers most 8-bit and 16-bit ops, and some 32-bit ops. It also covers all
> floating point operations. While this is not yet 100% coverage, it's good
> enough for the vast majority of formats out there.
>
> Of speci
On Wed, 21 May 2025, 01:45 softworkz .,
wrote:
> Hello,
>
> thanks again to all for the patches. I figured it might be a bit difficult
> to
> keep track of what has already been submitted and fixed and is still
> pending, and I'm sorry that there has been some duplicate effort to fix the
> same t
On Tue, 31 Dec 2024, 06:44 Michael Niedermayer,
wrote:
> Hi Ronald, Vittorio
>
> On Mon, Dec 30, 2024 at 11:05:59PM -0500, Ronald S. Bultje wrote:
> > Hi Michael,
> >
> > On Mon, Dec 30, 2024 at 2:13 PM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > Hi CC-2024
> > >
> > > On
On Wed, May 14, 2025 at 8:26 AM Michael Niedermayer
wrote:
>
> Hi
>
> On Wed, May 14, 2025 at 11:41:35AM +0100, Kieran Kunhya via ffmpeg-devel
> wrote:
> > On Wed, May 14, 2025 at 11:21 AM Michael Niedermayer
> > wrote:
> > >
> > > Hi Andrew
> &g
On Wed, May 14, 2025 at 11:21 AM Michael Niedermayer
wrote:
>
> Hi Andrew
>
> On Wed, May 14, 2025 at 05:54:54AM +0300, Andrew Randrianasulu wrote:
> > ср, 14 мая 2025 г., 03:55 Andrew Randrianasulu :
> >
> > >
> > >
> > > вт, 6 мая 2025 г., 02:27 Michael Niedermayer :
> > >
> > >> This will be av
On Wed, May 7, 2025 at 4:24 AM ffmpegagent wrote:
>
> This is for testing Patchwork CI builds, not for merging.
>
> softworkz (4):
> ci_test: Fail configure
> ci_test: Fail build
> ci_test: Fail fate
> ci_test: All good
>
>
>
> base-commit: 2b6303762fc0850b3bd841ebd234c336271f657c
> Publis
On Fri, 15 Nov 2024, 18:12 Thilo Borgmann via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:
> Hi,
>
> Am 17.05.24 um 15:49 schrieb Michael Niedermayer:
> > Hi all
> >
> > Before this is forgotten again, better start some dicsussion too early
> than too late
> >
> > I propose that if we have the
On Tue, 22 Apr 2025, 09:44 , wrote:
> Hi,
>
>
>
> I'm Dariusz from Samsung Electronics, you can know me from last VDD in
> Korea, I was presenting APV.
>
>
>
> I'm glad that Mark created native APV decoder. As you might know we're also
> working on APV implementation for FFmpeg.
>
> Our approach
On Tue, 22 Apr 2025, 00:44 Michael Niedermayer,
wrote:
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
>
I thought we decided postproc work in STF wasn't going to happen?
Note that the STF wiki doesn't mention anything about bugfixes to
libpostproc.
Kieran
>
On Mon, 3 Mar 2025, 16:38 Shreesh Adiga, <16567adigashre...@gmail.com>
wrote:
> On Thu, Feb 20, 2025 at 6:51 PM Shreesh Adiga
> <16567adigashre...@gmail.com> wrote:
> >
> > Currently the AVX2 version of uyvytoyuv422 in the SIMD loop does the
> following:
> > 4 vinsertq to have interleaving of the
On Sun, Mar 30, 2025 at 12:04 AM Cameron Gutman wrote:
>
> Previously, AV1 used filler data with CBR by default while H.264
> and HEVC did not. Make this consistent by using filler data in
> CBR mode across all codecs.
>
> Since there are valid reasons to use CBR with or without filler,
> also add
would like to report it.
Kieran
On Tue, Mar 25, 2025 at 8:55 AM Nicolas George wrote:
>
> Kieran Kunhya via ffmpeg-devel (HE12025-03-25):
> > The server belongs to @Jean-Baptiste Kempf
>
> Are you saying that the tweet that says “giving ***us*** a 160-core ARM
> server” (em
On Tue, 25 Mar 2025, 08:47 Zhao Zhili,
wrote:
> Hi,
>
> From Twitter
> > Unlike the majority of hardware/cloud companies, Ampere have supported
> the FFmpeg project by giving us a 160-core ARM server for development.
>
> Is the Ampere ARM server still available? Is it only for FATE or other
> par
>
> Kierans reply later refered back to this:
> > OMG a GSoC contributor is complaining about how hard the contribution
>
That's a selective quotation of an incomplete sentence.
Kieran
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffm
On Tue, 4 Mar 2025, 11:17 Michael Niedermayer,
wrote:
> Hi Kieran
>
> On Tue, Mar 04, 2025 at 08:13:11AM -0600, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
> > Hi Michael,
> >
> > Was all the STF discussion around the first application done in public?
>
&
>
> Nevertheless, the CC does issue a warning regarding unnecessarily
> offensive recent comments by Kieran on other topics, as well as for
> initially failing to provide background and context regarding Paul’s
> action on IRC.
>
Hi CC,
What comments are these? This is very vague as to what I've
On Mon, 3 Mar 2025, 20:35 Michael Niedermayer,
wrote:
> Hi jb
>
> On Thu, Feb 27, 2025 at 12:11:39AM +0100, Jean-Baptiste Kempf wrote:
> > On Wed, 26 Feb 2025, at 02:51, Michael Niedermayer wrote:
> > > 1. I agree we need discussions, transparency and maybe IRC or some
> other
> > >audio/vide
> While people who spent a significant time of their life working on FFmpeg
> may be great developers, their skillset might not be matching the one
> needed to handle a community.
>
> Cmon we've been over these points, let's not rehash the same drama over and
> over, and let the volunteers of the C
On Mon, 24 Feb 2025, 06:43 Cesar Matheus,
wrote:
> Hi, I'm a CS student working on an optimisation of the ebur128 filter.
> First I'm looking for the nicest way to get information on code performance.
> I saw that the configuration flag "--enable-linux-perf" enables
> Linux Performance Mo
On Sun, 23 Feb 2025, 04:11 Frank Plowman, wrote:
> On 09/02/2025 10:58, Frank Plowman wrote:
> > Signed-off-by: Frank Plowman
> > ---
> > tools/.gitignore | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/tools/.gitignore b/tools/.gitignore
> > index 7c45896923..f017fa2
On Fri, 21 Feb 2025, 15:02 Soft Works, wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Kieran Kunhya via ffmpeg-devel
> > Sent: Freitag, 21. Februar 2025 15:53
> > To: FFmpeg development discussions and patches >
On Fri, 21 Feb 2025, 14:30 Soft Works,
wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: Freitag, 21. Februar 2025 14:22
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] I've writ
On Fri, 21 Feb 2025, 13:18 Lynne, wrote:
> On 20/02/2025 14:06, Leandro Santiago wrote:
> Regardless of the language, I disagree with using crates in the context
> of FFmpeg, and any use of cargo.
>
I have no opinion on rust in FFmpeg but I broadly agree crates and cargo
are not suited for FFmpe
On Fri, 14 Feb 2025, 21:29 Steven Liu, wrote:
>
>
> Kieran Kunhya via ffmpeg-devel 于2025年2月15日
> 周六04:21写道：
>
>> On Fri, Feb 14, 2025 at 7:28 PM Michael Niedermayer
>> wrote:
>> >
>> > Hi everyone
>> >
>> > Please help improve the
On Fri, Feb 14, 2025 at 7:28 PM Michael Niedermayer
wrote:
>
> Hi everyone
>
> Please help improve the gsoc 2025 page
>
> 2 ideas are missing backup mentors, if you are able please
> add yourself to them as backup mentor
>
> Also please add more ideas!
> And help review the page and ideas to ensur
On Wed, 12 Feb 2025, 23:29 Timo Rothenpieler, wrote:
> On 12.02.2025 23:16, Soft Works wrote:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel On Behalf Of Timo
> >> Rothenpieler
> >> Sent: Mittwoch, 12. Februar 2025 23:05
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg
On Wed, 12 Feb 2025, 02:11 Michael Niedermayer,
wrote:
> On Wed, Feb 12, 2025 at 01:23:09AM +0000, Kieran Kunhya via ffmpeg-devel
> wrote:
> > Is this a joke?
>
> no
>
> It follows up on Jean Baptistes request here:
> https://lists.ffmpeg.org/pipermail/ffmpeg-de
Adding @Cc
This is a blatant attempt to push an unrelated pet project into FFmpeg
under the Gsoc banner with no notice. It's also unfair to students applying
as there was serious community pushback against this last time.
Kieran
On Wed, 12 Feb 2025, 01:16 Kieran Kunhya, wrote:
>
>
> On Wed, 1
On Wed, 12 Feb 2025, 01:21 Michael Niedermayer,
wrote:
> Hi all
>
> Ive added SDR to our GSoC 2025 page as there was just a single project
> on that page and the page needs to be more complete yesterday
>
> If people are against this say this NOW do not wait until we have accepted
> a student and
On Wed, 12 Feb 2025, 00:20 Michael Niedermayer,
wrote:
> Hi everyone
>
> On Wed, Feb 12, 2025 at 06:30:11AM +0800, Steven Liu wrote:
> > Michael Niedermayer 于2025年1月28日 周二10:21写道：
> >
> > > Hi
> > >
> > > Everyone interested in mentoring a project in 2025, please add your
> > > idea(s) to [1].
>
On Mon, Feb 10, 2025 at 12:40 PM Martin Storsjö wrote:
>
> On Sat, 8 Feb 2025, Kieran Kunhya via ffmpeg-devel wrote:
>
> > $subj
>
> > -if (memcmp(y0, y1, BUF_SIZE * sizeof(type))
> > \
> > -|| memcmp
$subj
0001-checkasm-v210enc.c-Use-checkasm_check_type.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
ffmpeg-devel-requ...@
Hi Michael,
On Sat, 1 Feb 2025, 22:27 Michael Niedermayer,
wrote:
>
> Lets be carefull here with the words. But the awnser is "yes"
> Many developers have been paid to write commits. employees, contractors,
> students
>
As an FFlabs employee (which I believe is the biggest GA cohort) and
shareh
On Sat, 1 Feb 2025, 15:03 Michael Niedermayer,
wrote:
> Hi
>
> On Sat, Feb 01, 2025 at 02:48:51PM +0000, Kieran Kunhya via ffmpeg-devel
> wrote:
> > On Sat, 1 Feb 2025, 14:46 Michael Niedermayer,
> > wrote:
> >
> > > Hi
> > >
> > > On
On Sat, 1 Feb 2025, 14:46 Michael Niedermayer,
wrote:
> Hi
>
> On Wed, Jan 29, 2025 at 10:21:37PM +0100, Niklas Haas wrote:
> > On Wed, 29 Jan 2025 21:51:27 +0100 Nicolas George
> wrote:
> > > Niklas Haas (12025-01-29):
> [...]
>
> > > *Some members* of
> > > what you call community have express
On Wed, Jan 29, 2025 at 6:27 PM Marth64 wrote:
>
> Here is an idea,
> Can we try to lay out the friction points in a table or bullet format
> where we can separate the issue from emotion and direct name calling?
>
> For example,
> " * Community has issue ABC but we can't move forward because senio
On Wed, Jan 29, 2025 at 7:01 PM Michael Niedermayer
wrote:
>
> Hi Yigithan
>
> Its good that you bring these issues up.
> Discussing about them is a step towards solving them
>
> see my coments inline below
>
> On Wed, Jan 29, 2025 at 06:51:40PM +0300, Yigithan Yigit wrote:
> > Hi Michael,
> >
> >
On Mon, Jan 27, 2025 at 7:03 PM Soft Works wrote:
>
> > From: ffmpeg-devel On Behalf Of
> > Kieran Kunhya via ffmpeg-devel
> > Sent: Monday, January 27, 2025 10:40 AM
> > > While this is a very valid concern for some kinds of frame side
> > data, it
> >
>
> While this is a very valid concern for some kinds of frame side data, it
> does not apply to CC data. It's either in every frame or none. If a
> provider generally broadcasts CC, then it's always present in every frame,
> even during programs for which no CC is available - it's always there. Li
>
> Or is there any reason to not call it what it is (Dish)? There are Sega or
> Nintendo audio decoders and other examples and a cryptic description like
> "DVB 0502" renders it useless for almost everybody.
>
Agreed.
Kieran
>
___
ffmpeg-devel mailing
On Sun, Jan 26, 2025 at 9:24 PM Michael Niedermayer
wrote:
>
> Hi Kieran
>
> On Sun, Jan 26, 2025 at 07:39:38PM +0000, Kieran Kunhya via ffmpeg-devel
> wrote:
> > > I remember such a IRC session before the libav fork.
> > > It is very similar to this here
> &g
On Sun, Jan 26, 2025 at 8:51 PM Kieran Kunhya wrote:
>
> On Sun, Jan 26, 2025 at 8:40 PM Rémi Denis-Courmont wrote:
> >
> > With my CC hat on,
> >
> > Le sunnuntaina 26. tammikuuta 2025, 21.39.38 UTC+2 Kieran Kunhya via ffmpeg-
> > devel a écrit :
> > &
On Sun, Jan 26, 2025 at 8:40 PM Rémi Denis-Courmont wrote:
>
> With my CC hat on,
>
> Le sunnuntaina 26. tammikuuta 2025, 21.39.38 UTC+2 Kieran Kunhya via ffmpeg-
> devel a écrit :
> > With Anton leaving the project because of you, Paul forking and James
> > lea
> I remember such a IRC session before the libav fork.
> It is very similar to this here
> 4+ people, who simply accuse me of everything (on IRC though)
> this serves no purpose. There is no common ground here
Hi Michael,
With Anton leaving the project because of you, Paul forking and James
leavi
> If the CC takes a clear action, this whole drama simply stops. Otherwise
> i suspect it will lead to a fork eventually. In the fork case they will leave
> with
> several others. I think thats a much bigger loss
I agree, Anton is gone because of your inflammatory behaviour
(banning, censorship e
On Sun, 26 Jan 2025, 00:31 Soft Works,
wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Marth64
> > Sent: Sunday, January 26, 2025 1:14 AM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg1
On Sat, 25 Jan 2025, 22:53 Marth64, wrote:
> Hello,
>
> I am to blame here for suggesting DVB_0502 as the name.
> I realize it was not the best choice and apologize for wasting your
> cycles on this.
>
> Looping in Keiran as we had discussed this over IRC briefly a few weeks
> back.
> As I don't
On Sat, 25 Jan 2025, 21:49 Rémi Denis-Courmont, wrote:
> Le lauantaina 25. tammikuuta 2025, 22.26.44 UTC+2 Michael Niedermayer a
> écrit
> :
> > I had posted one joke on my personal twitter that i deleted a few hours
> > later as people seem to have misunderstood it.
>
> It is completely irreleva
On Fri, Jan 24, 2025 at 3:59 AM Zhao Zhili
wrote:
>
>
>
> > On Jan 24, 2025, at 02:02, Timo Rothenpieler wrote:
> >
> > On 23.01.2025 15:17, Zhao Zhili wrote:
> >> From: Zhao Zhili
> >> Otherwise all frames can be dropped after seek without the
> >> output_corrupt/showall flags.
> >> ---
> >> l
On Thu, 23 Jan 2025, 00:11 Michael Niedermayer,
wrote:
> Hi Kieran
>
> On Wed, Jan 22, 2025 at 10:47:52PM +0000, Kieran Kunhya via ffmpeg-devel
> wrote:
> > On Wed, 22 Jan 2025, 20:36 Michael Niedermayer,
> > wrote:
> >
> > > This blocks disallowed extensi
> The FEC decoder works on the demuxer/transport layer and is
> independent from the content layer.
>
> The FEC decoder parameters can be set by the user according to their
> content settings to determine the delay incurred by buffering and
> packet loss for a CBR content.
A buffer of N packets do
On Wed, 22 Jan 2025, 20:36 Michael Niedermayer,
wrote:
> This blocks disallowed extensions from probing
> It also requires all available segments to have matching extensions to the
> format
> mpegts is treated independent of the extension
>
Potentially this is a stupid question but what stops an
> Can you please stop this "my way or no way"
The irony is not lost on me of this sentence (from the person banning
people, censoring people, creating paranoid theories about the GA).
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://
On Thu, Jan 16, 2025 at 8:15 PM Romain Beauxis wrote:
>
> This patch implements the decoding logic for the FEC error-
> correction method described in the Pro-MPEG CoP #3-R2 FEC[1]
>
> We are still in the process of testing this patch with our encoders but
> I wanted to send it now in case it coul
On Wed, Jan 22, 2025 at 4:37 PM Michael Niedermayer
wrote:
>
> Hi
>
> On Mon, Jan 20, 2025 at 03:00:17PM +0000, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
>
> > Error recovery protocols are complicated -
>
> everything is complicated
>
>
> > this
On Wed, Jan 22, 2025 at 4:53 PM Romain Beauxis wrote:
>
> Le mer. 22 janv. 2025 à 10:29, Kieran Kunhya via ffmpeg-devel
> a écrit :
> >
> > On Wed, Jan 22, 2025 at 3:33 PM Michael Niedermayer
> > wrote:
> > >
> > > On Mon, Jan 20, 2025 at 06:
On Wed, Jan 22, 2025 at 4:37 PM Michael Niedermayer
wrote:
>
> Hi
>
> On Mon, Jan 20, 2025 at 03:00:17PM +0000, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
>
> > Error recovery protocols are complicated -
>
> everything is complicated
>
>
> > this
On Wed, Jan 22, 2025 at 3:33 PM Michael Niedermayer
wrote:
>
> On Mon, Jan 20, 2025 at 06:46:46AM +, Kieran Kunhya via ffmpeg-devel
> wrote:
> > >
> > > > The data arrives on multiple sockets, leading to all sorts
> > > > of opportunities
On Tue, Jan 21, 2025 at 6:59 PM Vittorio Giovara
wrote:
>
> Greetings FFmpeg community
>
> There will be a community meeting during the conference, dates and times
> TBA!
>
> I believe there will be means to connect remotely, and everybody is invited
> to join, especially those that believe that o
On Tue, 21 Jan 2025, 18:57 James Almer, wrote:
> On 1/21/2025 3:13 PM, Kieran Kunhya via ffmpeg-devel wrote:
> > On Tue, Jan 21, 2025 at 5:42 PM Michael Niedermayer
> > wrote:
> >>
> >> Hi
> >>
> >> As people likely know i belive it
On Tue, Jan 21, 2025 at 5:42 PM Michael Niedermayer
wrote:
>
> Hi
>
> As people likely know i belive it is not but i got a 2nd opinion:
Hi Michael,
Can you ask ChatGPT the following:
Is it ok for one person to be in control of a major open source
project when they promised to step down?
Can you
>
> Ah, I got you now. This would mean that one part of patches will never go
> through the ML and another part will never be seen on "WEB". I hadn't even
> considered that as a possible/acceptable way, but I wouldn't mind.
>
How is this not confusing as hell for new contributors?
Running two sys
On Mon, Jan 20, 2025 at 2:51 PM Nicolas George wrote:
>
> Kieran Kunhya via ffmpeg-devel (12025-01-17):
> > I am the author of the only known functional OSS implementation of FEC.
>
> Seen from here, your rejection of this proposal looks a teeny tiny
> little bit like trying
On Tue, Dec 24, 2024 at 9:34 AM Lingyi Kong wrote:
>
> add fate test case
>
> Signed-off-by: Lingyi Kong
For whatever reason PATCHv4 is in neither of my email boxes, one of
which is subscribed to ffmpeg-devel, the other of which is not
subscribed but I still receive the emails. It's a great syst
>
> > 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 Fri, 17 Jan 2025, 21:32 Romain Beauxis, wrote:
> Le ven. 17 janv. 2025 à 08:32, Kieran Kunhya
> a écrit :
> >
> > On Fri, Jan 17, 2025 at 2:24 PM Kieran Kunhya
> wrote:
> > >
> > > On Fri, Jan 17, 2025 at 2:00 PM Romain Beauxis <
> romain.beau...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > FEC requires tons of heuristics to work in the real world.
>
> Besides your word, is there some evidence ?
>
> (and the question is not that YOUR implementation needs
> "tons of heuristics to work in the real world." or the reference
> does but that EVERY implementation does)
>
> You seem to
> A simple and clean mpeg FEC implementation will do no harm to FFmpeg,
> instead it will improve FFmpegs capabilities.
For the reasons I have described this is not possible. It's similar to
the way the kernel hides all the idiosyncrasies of real world TCP.
Kieran
On Fri, Jan 17, 2025 at 2:48 PM James Almer wrote:
>
> On 1/17/2025 11:42 AM, Nicolas George wrote:
> > James Almer (12025-01-17):
> >> Don't assume he will not extend the implementation. Ask him instead what he
> >> plans to do in the long term.
> >> And this could also be marked as experimental,
> Don't assume he will not extend the implementation. Ask him instead what
> he plans to do in the long term.
> And this could also be marked as experimental, in which case if
> abandoned or proven unstable for several real world cases, it can be
> removed or disabled.
"the most simple and elegant
On Fri, Jan 17, 2025 at 2:24 PM Kieran Kunhya wrote:
>
> On Fri, Jan 17, 2025 at 2:00 PM Romain Beauxis
> wrote:
> >
> > Hi,
> >
> > Le jeu. 16 janv. 2025 à 16:40, Kieran Kunhya
> > a écrit :
> > >
> > > On Thu, Jan 16, 2025 at 9:35 PM Romain Beauxis
> > > wrote:
> > > >
> > > > Le jeu. 16 ja
1 - 100 of 175 matches
Mail list logo
