[FFmpeg-devel] [RFC] Release 6.1

[FFmpeg-devel] [RFC] Release 6.1

[Lynne]

It's been a while since we've had a release, and we've had
a lot of new features in.
We did say we would make releases more often, and I think
it's about time we have a new release.

Anything anyone wants to have merged or should we branch
off 6.1 in a few days?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Jean-Baptiste Kempf]

Heya,

On Thu, 6 Jul 2023, at 18:04, Lynne wrote:
> It's been a while since we've had a release, and we've had
> a lot of new features in.
> We did say we would make releases more often, and I think
> it's about time we have a new release.

It's a good idea.

> Anything anyone wants to have merged or should we branch
> off 6.1 in a few days?

By experience, it requires a bit more than a few days... :D

jb
-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Lynne]

Jul 6, 2023, 18:19 by jb@videolan.org:

> Heya,
>
> On Thu, 6 Jul 2023, at 18:04, Lynne wrote:
>
>> It's been a while since we've had a release, and we've had
>> a lot of new features in.
>> We did say we would make releases more often, and I think
>> it's about time we have a new release.
>>
>
> It's a good idea.
>
>> Anything anyone wants to have merged or should we branch
>> off 6.1 in a few days?
>>
>
> By experience, it requires a bit more than a few days... :D
>

May as well decide on a name in the meanwhile.
Anyone got any suggestions?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Ingo Oppermann]

Leavitt

https://en.wikipedia.org/wiki/Henrietta_Swan_Leavitt

> On 7 Jul 2023, at 08:40, Lynne <dev@lynne.ee> wrote:
> 
> Jul 6, 2023, 18:19 by jb@videolan.org:
> 
>> Heya,
>> 
>> On Thu, 6 Jul 2023, at 18:04, Lynne wrote:
>> 
>>> It's been a while since we've had a release, and we've had
>>> a lot of new features in.
>>> We did say we would make releases more often, and I think
>>> it's about time we have a new release.
>>> 
>> 
>> It's a good idea.
>> 
>>> Anything anyone wants to have merged or should we branch
>>> off 6.1 in a few days?
>>> 
>> 
>> By experience, it requires a bit more than a few days... :D
>> 
> 
> May as well decide on a name in the meanwhile.
> Anyone got any suggestions?
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Steven Liu]

Lynne <dev@lynne.ee> 于2023年7月7日周五 14:40写道：
>
> Jul 6, 2023, 18:19 by jb@videolan.org:
>
> > Heya,
> >
> > On Thu, 6 Jul 2023, at 18:04, Lynne wrote:
> >
> >> It's been a while since we've had a release, and we've had
> >> a lot of new features in.
> >> We did say we would make releases more often, and I think
> >> it's about time we have a new release.
> >>
> >
> > It's a good idea.
> >
> >> Anything anyone wants to have merged or should we branch
> >> off 6.1 in a few days?
> >>
> >
> > By experience, it requires a bit more than a few days... :D
> >
>
> May as well decide on a name in the meanwhile.
> Anyone got any suggestions?

Ting
https://en.wikipedia.org/wiki/Samuel_C._C._Ting

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Leo Izen]

On 7/7/23 02:40, Lynne wrote:
> 
> May as well decide on a name in the meanwhile.
> Anyone got any suggestions?
> _______________________________________________

Has Thomson been used?

https://en.wikipedia.org/wiki/J._J._Thomson

- Leo Izen


_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 971 bytes --]

Hi

On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> It's been a while since we've had a release, and we've had
> a lot of new features in.
> We did say we would make releases more often, and I think
> it's about time we have a new release.

yes


> 
> Anything anyone wants to have merged or should we branch
> off 6.1 in a few days?

libavradio needs testing, at least build testing.
all parts of git master are tested automatically by our user base
but anything in seperate repositories might receive less testing
so we should encourage people to test these seperate repositories
for the release

also note iam quite busy ATM, its not the best time for me to
do 6.1, so "in a few days" is a bit too optimistic i think

thx


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Lynne]

Jul 7, 2023, 17:07 by michael@niedermayer.cc:

> Hi
>
> On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
>
>> It's been a while since we've had a release, and we've had
>> a lot of new features in.
>> We did say we would make releases more often, and I think
>> it's about time we have a new release.
>>
>
> yes
>
>
>>
>> Anything anyone wants to have merged or should we branch
>> off 6.1 in a few days?
>>
>
> libavradio needs testing, at least build testing.
> all parts of git master are tested automatically by our user base
> but anything in seperate repositories might receive less testing
> so we should encourage people to test these seperate repositories
> for the release
>

It's still quite a new library, its API might change, I think we
should release 6.1 first, then release libavradio, so the next
FFmpeg release has a stable target API-wise to use.

It's fine if you don't have time in the next few days, I have to remove
the old FFT code, which means finishing my DCT/DST lavu/tx patch.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1431 bytes --]

On Fri, Jul 07, 2023 at 05:33:32PM +0200, Lynne wrote:
> Jul 7, 2023, 17:07 by michael@niedermayer.cc:
> 
> > Hi
> >
> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> >
> >> It's been a while since we've had a release, and we've had
> >> a lot of new features in.
> >> We did say we would make releases more often, and I think
> >> it's about time we have a new release.
> >>
> >
> > yes
> >
> >
> >>
> >> Anything anyone wants to have merged or should we branch
> >> off 6.1 in a few days?
> >>
> >
> > libavradio needs testing, at least build testing.
> > all parts of git master are tested automatically by our user base
> > but anything in seperate repositories might receive less testing
> > so we should encourage people to test these seperate repositories
> > for the release
> >
> 
> It's still quite a new library, its API might change, I think we
> should release 6.1 first, then release libavradio, so the next
> FFmpeg release has a stable target API-wise to use.

I think we should release early and often. also 7.0 would be a
major version bump, so the 6.1 API/ABI doesnt matter.
And i have not seen anyone working on changing the API ...

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Anton Khirnov]

Quoting Michael Niedermayer (2023-07-07 17:06:54)
> Hi
> 
> On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> > It's been a while since we've had a release, and we've had
> > a lot of new features in.
> > We did say we would make releases more often, and I think
> > it's about time we have a new release.
> 
> yes
> 
> 
> > 
> > Anything anyone wants to have merged or should we branch
> > off 6.1 in a few days?
> 
> libavradio needs testing, at least build testing.
> all parts of git master are tested automatically by our user base
> but anything in seperate repositories might receive less testing
> so we should encourage people to test these seperate repositories
> for the release
> 
> also note iam quite busy ATM, its not the best time for me to
> do 6.1, so "in a few days" is a bit too optimistic i think

How is libavradio related to the release?

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2659 bytes --]

On Sun, Jul 09, 2023 at 12:14:09PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-07-07 17:06:54)
> > Hi
> > 
> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> > > It's been a while since we've had a release, and we've had
> > > a lot of new features in.
> > > We did say we would make releases more often, and I think
> > > it's about time we have a new release.
> > 
> > yes
> > 
> > 
> > > 
> > > Anything anyone wants to have merged or should we branch
> > > off 6.1 in a few days?
> > 
> > libavradio needs testing, at least build testing.
> > all parts of git master are tested automatically by our user base
> > but anything in seperate repositories might receive less testing
> > so we should encourage people to test these seperate repositories
> > for the release
> > 
> > also note iam quite busy ATM, its not the best time for me to
> > do 6.1, so "in a few days" is a bit too optimistic i think
> 
> How is libavradio related to the release?

Right, thats a valid question
when i wrote the SDR code it seemed to me that including it in 6.1 was
very simple. But as then some people tried to block SDR by any means
(blocking patches randomly, asking for moving it into a seperate libraray
 while not replying to any questions about that libraray and so on)
that made libavradio now have much more strings attached
then the original simple self contained input device
secondary, i lost the will to really work on FFmpeg around the time
of these attacks, so even without SDR i had limited motivation
and then more things that should be in 6.1 accumulated and summer and
good waether ...
And noone else took up the accumulating work either ...

Now the SDR + blockings is solved by not including any SDR that the
community doesnt like in 6.1 but instead me simply making a seperate
release with SDR, or so i thought. It seems given the replies I seem
to have touched some nerve here too

The idea was really just, that i said ill include SDR and i want to
keep this word so i want our users to have that 6.1 with SDR that i
promised and also have everyone happy about 6.1 and the long term
design of the SDR code.
I have some more comments about the seperate libraray and SDR but
thats better in a seperate mail in the future.

Thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Paul B Mahol]

On Fri, Sep 22, 2023 at 11:28 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Sun, Jul 09, 2023 at 12:14:09PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-07-07 17:06:54)
> > > Hi
> > >
> > > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> > > > It's been a while since we've had a release, and we've had
> > > > a lot of new features in.
> > > > We did say we would make releases more often, and I think
> > > > it's about time we have a new release.
> > >
> > > yes
> > >
> > >
> > > >
> > > > Anything anyone wants to have merged or should we branch
> > > > off 6.1 in a few days?
> > >
> > > libavradio needs testing, at least build testing.
> > > all parts of git master are tested automatically by our user base
> > > but anything in seperate repositories might receive less testing
> > > so we should encourage people to test these seperate repositories
> > > for the release
> > >
> > > also note iam quite busy ATM, its not the best time for me to
> > > do 6.1, so "in a few days" is a bit too optimistic i think
> >
> > How is libavradio related to the release?
>
> Right, thats a valid question
> when i wrote the SDR code it seemed to me that including it in 6.1 was
> very simple. But as then some people tried to block SDR by any means
> (blocking patches randomly, asking for moving it into a seperate libraray
>  while not replying to any questions about that libraray and so on)
> that made libavradio now have much more strings attached
> then the original simple self contained input device
> secondary, i lost the will to really work on FFmpeg around the time
> of these attacks, so even without SDR i had limited motivation
> and then more things that should be in 6.1 accumulated and summer and
> good waether ...
> And noone else took up the accumulating work either ...
>

What accumulating work? The SDR work for certainly nobody else wants to
pick, except maybe Peter.
If you mean real FFmpeg work, than by all means give access to services
only you have to other
interesting parties, like security related reports and others.


>
> Now the SDR + blockings is solved by not including any SDR that the
> community doesnt like in 6.1 but instead me simply making a seperate
> release with SDR, or so i thought. It seems given the replies I seem
> to have touched some nerve here too
>
> The idea was really just, that i said ill include SDR and i want to
> keep this word so i want our users to have that 6.1 with SDR that i
> promised and also have everyone happy about 6.1 and the long term
> design of the SDR code.
> I have some more comments about the seperate libraray and SDR but
> thats better in a seperate mail in the future.
>


Thank you for all hard FFmpeg related work, hope your continuing work on
your SDR hobby related projects.


>
> Thanks
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> "You are 36 times more likely to die in a bathtub than at the hands of a
> terrorist. Also, you are 2.5 times more likely to become a president and
> 2 times more likely to become an astronaut, than to die in a terrorist
> attack." -- Thoughty2
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2095 bytes --]

On Fri, Sep 22, 2023 at 11:32:27AM +0200, Paul B Mahol wrote:
> On Fri, Sep 22, 2023 at 11:28 AM Michael Niedermayer <michael@niedermayer.cc>
[...]

> If you mean real FFmpeg work, than by all means give access to services
> only you have to other
> interesting parties, like security related reports and others.

what ?

There are 633 open issues in coverity, every FFmpeg developer can work on.
i remember bringing this number down years ago to something rather small but now
the statistics dwarf that with the upward trend ...

if you mean oss-fuzz, there are 18 tickets public about FFmpeg, anyone can work on these
https://bugs.chromium.org/p/oss-fuzz/issues/list?q=ffmpeg

and the ffmpeg ossfuzz tickets, go to
ffmpeg-security, 3 people from google, 1 from mozilla, jb
and ffmpeg-security is me, reimar, ce, andreas cadhalpun, ubitux, rodger combs

so thats not just me
and a quick count, i think i have 32 open ossfuzz issues in my inbox,
with the 18 subtracted more are public with noone caring about.
if we assume i fix 5 a day, what is that, 4 days of work, to fix the ones that are
not public. (that doesnt count ossfuzz hiding 12 issues in 62164 but yeah these ive
already posted fixes for i think)

Also theres our bug tracker and just the normal compiler warnings
if you want to work on this sort of thing

where are the developers who want to work on something above but do not have
access ?

the only other issue i remember on ffmpeg-security thats not spam and not ossfuzz
is a XSS issue in the fate server which i believe nicolas is working on.
If someone is interrested in working on the fate server code, please come forth
the code is in need for a maintainer outside this issue. I just had asked nicolas
about it because i did not know anyone else who knows perl and be willing
to help look into a not entirely trivial (for me) issue in fate server

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Paul B Mahol]

On 9/22/23, Michael Niedermayer <michael@niedermayer.cc> wrote:
> On Fri, Sep 22, 2023 at 11:32:27AM +0200, Paul B Mahol wrote:
>> On Fri, Sep 22, 2023 at 11:28 AM Michael Niedermayer
>> <michael@niedermayer.cc>
> [...]
>
>> If you mean real FFmpeg work, than by all means give access to services
>> only you have to other
>> interesting parties, like security related reports and others.
>
> what ?
>
> There are 633 open issues in coverity, every FFmpeg developer can work on.
> i remember bringing this number down years ago to something rather small but
> now
> the statistics dwarf that with the upward trend ...
>
> if you mean oss-fuzz, there are 18 tickets public about FFmpeg, anyone can
> work on these
> https://bugs.chromium.org/p/oss-fuzz/issues/list?q=ffmpeg
>
> and the ffmpeg ossfuzz tickets, go to
> ffmpeg-security, 3 people from google, 1 from mozilla, jb
> and ffmpeg-security is me, reimar, ce, andreas cadhalpun, ubitux, rodger
> combs
>
> so thats not just me
> and a quick count, i think i have 32 open ossfuzz issues in my inbox,
> with the 18 subtracted more are public with noone caring about.
> if we assume i fix 5 a day, what is that, 4 days of work, to fix the ones
> that are
> not public. (that doesnt count ossfuzz hiding 12 issues in 62164 but yeah
> these ive
> already posted fixes for i think)
>
> Also theres our bug tracker and just the normal compiler warnings
> if you want to work on this sort of thing
>
> where are the developers who want to work on something above but do not
> have
> access ?
>
> the only other issue i remember on ffmpeg-security thats not spam and not
> ossfuzz
> is a XSS issue in the fate server which i believe nicolas is working on.
> If someone is interrested in working on the fate server code, please come
> forth
> the code is in need for a maintainer outside this issue. I just had asked
> nicolas
> about it because i did not know anyone else who knows perl and be willing
> to help look into a not entirely trivial (for me) issue in fate server
>

Do not lie, you are working for FFlabs now.

> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Everything should be made as simple as possible, but not simpler.
> -- Albert Einstein
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Jean-Baptiste Kempf]

Yo,

On Fri, 22 Sep 2023, at 17:27, Paul B Mahol wrote:
>> about it because i did not know anyone else who knows perl and be willing
>> to help look into a not entirely trivial (for me) issue in fate server
>
> Do not lie, [...]

Calling people liars is not really fitting our Code of Conduct.
It's not the first time I remind this fact.

jb

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

Michael Niedermayer (12023-09-22):
> Now the SDR + blockings is solved by not including any SDR that the
> community doesnt like in 6.1 but instead me simply making a seperate
> release with SDR, or so i thought.

I strongly suggest you just refuse to make any release that do not
include SDR. If somebody wants it, let them do the work.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Paul B Mahol]

On Fri, Sep 22, 2023 at 12:04 PM Nicolas George <george@nsup.org> wrote:

> Michael Niedermayer (12023-09-22):
> > Now the SDR + blockings is solved by not including any SDR that the
> > community doesnt like in 6.1 but instead me simply making a seperate
> > release with SDR, or so i thought.
>
> I strongly suggest you just refuse to make any release that do not
> include SDR. If somebody wants it, let them do the work.
>

Agreed, I want to be release maintainer.


>
> Regards,
>
> --
>   Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Anton Khirnov]

Quoting Michael Niedermayer (2023-09-22 11:27:54)
> The idea was really just, that i said ill include SDR and i want to
> keep this word

Well, you should not have spoken for the entire project without
consulting the rest of the community first. Nobody here is entitled to
decide unilaterally what will or won't go in.

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 976 bytes --]

On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-09-22 11:27:54)
> > The idea was really just, that i said ill include SDR and i want to
> > keep this word
> 
> Well, you should not have spoken for the entire project without
> consulting the rest of the community first. Nobody here is entitled to

This statement is a little misleading, i think

Iam part of the community, i would think and for 99% of the tweets made
on the official twitter account i have never been asked or even had a
chance to comment before they where made. So what you suggest here is
"the correct way", has never been applied.

Thilo raised this very same issue already also. The tweets should all be
reviewed. And i do not disagree.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is a danger to trust the dream we wish for rather than
the science we have, -- Dr. Kenneth Brown

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Kieran Kunhya via ffmpeg-devel]

> Iam part of the community, i would think and for 99% of the tweets made
> on the official twitter account i have never been asked or even had a
> chance to comment before they where made. So what you suggest here is
> "the correct way", has never been applied.

Announcing feature are going to be present in a release in a tweet
that the community has no consensus on is not the same as making
general tweets about VDD, FFmpeg etc.

Kieran
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Anton Khirnov]

Quoting Michael Niedermayer (2023-09-26 17:09:47)
> On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-09-22 11:27:54)
> > > The idea was really just, that i said ill include SDR and i want to
> > > keep this word
> > 
> > Well, you should not have spoken for the entire project without
> > consulting the rest of the community first. Nobody here is entitled to
> 
> This statement is a little misleading, i think
> 
> Iam part of the community, i would think and for 99% of the tweets made
> on the official twitter account i have never been asked or even had a
> chance to comment before they where made. So what you suggest here is
> "the correct way", has never been applied.

This is disingenuous sophistry, and honestly I find it insulting that
you expect people to swallow it.

You made the tweet in question long after it was clear that the feature
is controversial. Then you tried to use it as an argument in favor of
pushing SDR to master. In other words, you used the fact that you have
Twitter posting rights to promote your opinion over that of other
developers. If that is not abuse of power then I don't know what is.

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Derek Buitenhuis]

On 9/26/2023 4:30 PM, Anton Khirnov wrote:
> This is disingenuous sophistry, and honestly I find it insulting that
> you expect people to swallow it.

I have been pretty silent on list, but as one of the people who has
access to the Twitter account as a delegate (but who was locked out
at the time of the tweet), it offensive to me on a personal level to
insnuate that it is at all comparable to any tweet (few though they
are) I have made, or that the situation is comparable.

It reads to me like purposely playing dumb. We aren't.

- Derek
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1339 bytes --]

On Tue, Sep 26, 2023 at 05:27:23PM +0100, Derek Buitenhuis wrote:
> On 9/26/2023 4:30 PM, Anton Khirnov wrote:
> > This is disingenuous sophistry, and honestly I find it insulting that
> > you expect people to swallow it.
> 
> I have been pretty silent on list, but as one of the people who has
> access to the Twitter account as a delegate (but who was locked out
> at the time of the tweet), it offensive to me on a personal level to
> insnuate that it is at all comparable to any tweet (few though they
> are) I have made, or that the situation is comparable.
> 
> It reads to me like purposely playing dumb. We aren't.

Iam not claimining anything is comparable.

Iam just asking that everyone is posting tweets for review. Same as thilo
long ago suggested

It is reasonable that the whole community can review public statements
that are made in the name of the project

This example here shows how easily this can go wrong (even if maybe you
never made a comparable tweet)

Thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3096 bytes --]

On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-09-26 17:09:47)
> > On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2023-09-22 11:27:54)
> > > > The idea was really just, that i said ill include SDR and i want to
> > > > keep this word
> > > 
> > > Well, you should not have spoken for the entire project without
> > > consulting the rest of the community first. Nobody here is entitled to
> > 
> > This statement is a little misleading, i think
> > 
> > Iam part of the community, i would think and for 99% of the tweets made
> > on the official twitter account i have never been asked or even had a
> > chance to comment before they where made. So what you suggest here is
> > "the correct way", has never been applied.
> 
> This is disingenuous sophistry, and honestly I find it insulting that
> you expect people to swallow it.
> 
> You made the tweet in question long after it was clear that the feature
> is controversial. Then you tried to use it as an argument in favor of
> pushing SDR to master. In other words, you used the fact that you have
> Twitter posting rights to promote your opinion over that of other
> developers. If that is not abuse of power then I don't know what is.

ok
I wrote a SDR input device for free, wanted to give it to the users
as i believed it was a cool and usefull feature

i tried to argue for it, i tried to promote it.
And as the person doing all releases of FFmpeg since a very long time
i thought yeah we will be able to resolve the disagreements and get it
in 6.1 with everyone geing happy.
I was wrong, i announced this before i actually got people to agree yes
I still belive if people where not so "excited" on this whole and if it
was just a technical question we could get SDR in 6.1 with everyone
agreeing.
But now heres a man to be burned at the stake, and thats more important.

abuse of power ?
If its abuse of power to risk my position in FFmpeg to try to get users a feature
i belive in they would like and find cool then yes i abused my power.

Should i ask the counter-question ?
are the developers who have less than 10 commits since 2017 abusing something
by organizing and rallying the people against SDR, against the domain owner
and against me ?

Without that, i do belive we could have gotten SDR with everyone being happy
in 6.1

Anyway, i appologize for announcing SDR in 6.1. I was too much in love with
SDR and how cool it would be ...

I guess there will be votes to remove me from everything.
But dont fear, i will not abuse anything, i will resign from everything that
a correct vote asks me to resign from.

Thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[James Almer]

On 9/26/2023 2:16 PM, Michael Niedermayer wrote:
> On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote:
>> Quoting Michael Niedermayer (2023-09-26 17:09:47)
>>> On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote:
>>>> Quoting Michael Niedermayer (2023-09-22 11:27:54)
>>>>> The idea was really just, that i said ill include SDR and i want to
>>>>> keep this word
>>>>
>>>> Well, you should not have spoken for the entire project without
>>>> consulting the rest of the community first. Nobody here is entitled to
>>>
>>> This statement is a little misleading, i think
>>>
>>> Iam part of the community, i would think and for 99% of the tweets made
>>> on the official twitter account i have never been asked or even had a
>>> chance to comment before they where made. So what you suggest here is
>>> "the correct way", has never been applied.
>>
>> This is disingenuous sophistry, and honestly I find it insulting that
>> you expect people to swallow it.
>>
>> You made the tweet in question long after it was clear that the feature
>> is controversial. Then you tried to use it as an argument in favor of
>> pushing SDR to master. In other words, you used the fact that you have
>> Twitter posting rights to promote your opinion over that of other
>> developers. If that is not abuse of power then I don't know what is.
> 
> ok
> I wrote a SDR input device for free, wanted to give it to the users
> as i believed it was a cool and usefull feature
> 
> i tried to argue for it, i tried to promote it.
> And as the person doing all releases of FFmpeg since a very long time
> i thought yeah we will be able to resolve the disagreements and get it
> in 6.1 with everyone geing happy.
> I was wrong, i announced this before i actually got people to agree yes
> I still belive if people where not so "excited" on this whole and if it
> was just a technical question we could get SDR in 6.1 with everyone
> agreeing.
> But now heres a man to be burned at the stake, and thats more important.
> 
> abuse of power ?
> If its abuse of power to risk my position in FFmpeg to try to get users a feature
> i belive in they would like and find cool then yes i abused my power.

No, it was not abuse of power per se. That was a bit strong from Anton's 
part. But tweeting it was jumping the gun about something that was 
controversial and still in the discussion phase of things, and then 
using it as argument to upstream the code bothered some people.

> 
> Should i ask the counter-question ?
> are the developers who have less than 10 commits since 2017 abusing something
> by organizing and rallying the people against SDR, against the domain owner
> and against me ?
> 
> Without that, i do belive we could have gotten SDR with everyone being happy
> in 6.1
> 
> Anyway, i appologize for announcing SDR in 6.1. I was too much in love with
> SDR and how cool it would be ...
> 
> I guess there will be votes to remove me from everything.
> But dont fear, i will not abuse anything, i will resign from everything that
> a correct vote asks me to resign from.

We don't want you to resign anything. We want a proper discussion in how 
to handle SDR, if at all. Pushing it in a form that everyone agrees is 
not ready for upstream is not a good idea. Best case scenario we end up 
with a period of having to change things around as they were made public 
in a release and thus part of the API, which is harder to maintain and 
migrate from, and worst case scenario we end up with something that 
doesn't get more development because it was limited from the get go.

SDR is big, so its API needs to be designed carefully and in an 
extensible way.
libavradio must absolutely not be libavdevice redux, and it must have 
its own, versatile and extensible API that a lavd device can then work 
with, even if not using its full potential, because libavradio can have 
other users that will not be constrained to what lavf/lavd can do.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 1429 bytes --]

James Almer (12023-09-26):
> We don't want you to resign anything. We want a proper discussion in how to
> handle SDR, if at all. Pushing it in a form that everyone agrees is not
> ready for upstream is not a good idea.

We can agree on this, if we consider that the opinion on whether it is
ready of people who have made it clear they will never consider it
“ready” is to be disregarded, just as much as somebody who says “nak” to
a patch without reasons.

> SDR is big, so its API needs to be designed carefully and in an extensible
> way.
> libavradio must absolutely not be libavdevice redux, and it must have its
> own, versatile and extensible API that a lavd device can then work with,
> even if not using its full potential, because libavradio can have other
> users that will not be constrained to what lavf/lavd can do.

SDR **will be** big. SDR **will need** to have its own versatile and
extensible API.

But the way to get there is to start small. First make it a module, with
a very simple API to the rest. Then, as it grows, it acquires utility
functions: an internal API that we can change as we discover what it
needs. And progressively the API stabilizes and becomes good.

Nothing successful starts as a library. Suggesting that a project starts
as a library is either an expression of incompetence or a dishonest
attempt at killing it.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Anton Khirnov]

Quoting Michael Niedermayer (2023-09-26 19:16:30)
> On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2023-09-26 17:09:47)
> > > On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote:
> > > > Quoting Michael Niedermayer (2023-09-22 11:27:54)
> > > > > The idea was really just, that i said ill include SDR and i want to
> > > > > keep this word
> > > > 
> > > > Well, you should not have spoken for the entire project without
> > > > consulting the rest of the community first. Nobody here is entitled to
> > > 
> > > This statement is a little misleading, i think
> > > 
> > > Iam part of the community, i would think and for 99% of the tweets made
> > > on the official twitter account i have never been asked or even had a
> > > chance to comment before they where made. So what you suggest here is
> > > "the correct way", has never been applied.
> > 
> > This is disingenuous sophistry, and honestly I find it insulting that
> > you expect people to swallow it.
> > 
> > You made the tweet in question long after it was clear that the feature
> > is controversial. Then you tried to use it as an argument in favor of
> > pushing SDR to master. In other words, you used the fact that you have
> > Twitter posting rights to promote your opinion over that of other
> > developers. If that is not abuse of power then I don't know what is.
> 
> ok
> I wrote a SDR input device for free, wanted to give it to the users
> as i believed it was a cool and usefull feature
> 
> i tried to argue for it, i tried to promote it.
> And as the person doing all releases of FFmpeg since a very long time
> i thought yeah we will be able to resolve the disagreements and get it
> in 6.1 with everyone geing happy.
> I was wrong, i announced this before i actually got people to agree yes
> I still belive if people where not so "excited" on this whole and if it
> was just a technical question we could get SDR in 6.1 with everyone
> agreeing.
> But now heres a man to be burned at the stake, and thats more important.

You keep framing this as some kind of a personal campaign against you.
It is not. From my perspective, the objections to SDR have been largely
technical, and most of the "heat" comes from your refusal to accept that
many active developers are against it.

> abuse of power ?
> If its abuse of power to risk my position in FFmpeg to try to get users a feature
> i belive in they would like and find cool then yes i abused my power.
> 
> Should i ask the counter-question ?
> are the developers who have less than 10 commits since 2017 abusing something
> by organizing and rallying the people against SDR, against the domain owner
> and against me ?

I see zero indication of any of the above.

1) Nobody is rallying anyone against SDR. My objections to it are
   entirely my own. Paul is also against it, and nobody is able to
   make him do anything, as far as I can tell.
   What evidence do you see that anyone's opinion on this question has
   been "organized" or otherwise manipulated?

2) Nobody is attacking Fabrice in any way. Ronald raised the (in my view
   entirely reasonable) observation that someone who has had almost no
   involvement with the project since 2003 should not have the ultimate
   veto power over it. That is not in any way a personal attack, and is
   also entirely unrelated to this.

3) Nobody is attacking you. Disagreeing about technical questions is NOT
   a personal attack.

> Without that, i do belive we could have gotten SDR with everyone being happy
> in 6.1
> 
> Anyway, i appologize for announcing SDR in 6.1. I was too much in love with
> SDR and how cool it would be ...
> 
> I guess there will be votes to remove me from everything.
> But dont fear, i will not abuse anything, i will resign from everything that
> a correct vote asks me to resign from.

I really wish you would drop the drama, it is entirely unnecessary.
Nobody wants you to resign from anything, people (including me) merely
want you to stop trying to force your opinions on the rest of the
project.

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 947 bytes --]

Anton Khirnov (12023-09-26):
> It is not. From my perspective, the objections to SDR have been largely
> technical

We have not read the same discussion. The objections to SDR start and
end at “it does not belong in FFmpeg”, which is not a technical
objection but an aesthetic one.

Furthermore, the way these objections were stated made it quite obvious
the motivation behind them was that they wanted Michael to spend his
time on more useful tasks. More useful for them, implicitly. Again, that
is not technical, that is egoistical.

Last, there have been some suggestions or demands, technical indeed,
that looked like openings for compromise. But the same people who made
them made it clear in other parts of the discussion they had no
intention of meeting anybody on any kind of middle ground. Given the
disingenuousness of these demands, I think Michael is entitled to feel a
little paranoid.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Vittorio Giovara]

On Tue, Sep 26, 2023 at 2:24 PM Nicolas George <george@nsup.org> wrote:

> Anton Khirnov (12023-09-26):
> > It is not. From my perspective, the objections to SDR have been largely
> > technical
>
> We have not read the same discussion. The objections to SDR start and
> end at “it does not belong in FFmpeg”, which is not a technical
> objection but an aesthetic one.
>

This is not true.
-- 
Vittorio
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 97 bytes --]

Vittorio Giovara (12023-09-26):
> This is not true.

If you say so.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] SDR choices

[Cosmin Stejerean via ffmpeg-devel]

> On Sep 26, 2023, at 11:14 AM, Anton Khirnov <anton@khirnov.net> wrote:
> 
> From my perspective, the objections to SDR have been largely
> technical,

From my perspective the objections against the current SDR implementation could be grouped into roughly 3 categories:

A) support for taking input from an SDR device doesn't belong in ffmpeg at all in any form, it's way too big and there are other projects out there for SDR there that one ought to use instead, and trying to do it in ffmpeg in any form would bloat the codebase and make a mess no matter which option is chosen

B) support for SDR is fine to have in ffmpeg, but it should be done via an external library that does not live in the ffmpeg source tree, and ffmpeg could be optionally compiled with a --enable-libsdr or some such

C) support for SDR is fine to have as long as it's in a separate module like a libavradio with a clean API rather than trying to beat it into libavdevice, the current implementation is too invasive

All 3 are united in objecting to the current implementation, which I'd summarize as SDR using libavdevice (let's call it option D). This makes it seem like there's a united front against SDR, but I think there's significant disagreement even among the people objecting to the current implementation as to which one of these 3 ought to be the right outcome for SDR. The discussion tends to go in circles. Discussions about C-vs-D tend to run into objections from B, trying to discuss the relative merits of B-vs-C runs into objections from A and so on.

This might be a good use of the TC (after a new GA and new TC is formed to avoid arguments about the validity of the decision). The TC could then settle on the direction for SDR in the project:

A. no SDR in ffmpeg at all
B. SDR via external library
C. SDR via a new libavradio library
D. SDR via libavdevice

For what it's worth as a user of ffmpeg I hope the outcome is not A, I believe having support for RTL-SDR in ffmpeg would be neat and I'd love to use it (at home, at work I'd compile ffmpeg with SDR disabled). I'm not qualified to comment on whether B,C or D are better ways to achieve it.

- Cosmin












_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 5328 bytes --]

On Tue, Sep 26, 2023 at 08:14:37PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-09-26 19:16:30)
> > On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2023-09-26 17:09:47)
> > > > On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote:
> > > > > Quoting Michael Niedermayer (2023-09-22 11:27:54)
> > > > > > The idea was really just, that i said ill include SDR and i want to
> > > > > > keep this word
> > > > > 
> > > > > Well, you should not have spoken for the entire project without
> > > > > consulting the rest of the community first. Nobody here is entitled to
> > > > 
> > > > This statement is a little misleading, i think
> > > > 
> > > > Iam part of the community, i would think and for 99% of the tweets made
> > > > on the official twitter account i have never been asked or even had a
> > > > chance to comment before they where made. So what you suggest here is
> > > > "the correct way", has never been applied.
> > > 
> > > This is disingenuous sophistry, and honestly I find it insulting that
> > > you expect people to swallow it.
> > > 
> > > You made the tweet in question long after it was clear that the feature
> > > is controversial. Then you tried to use it as an argument in favor of
> > > pushing SDR to master. In other words, you used the fact that you have
> > > Twitter posting rights to promote your opinion over that of other
> > > developers. If that is not abuse of power then I don't know what is.
> > 
> > ok
> > I wrote a SDR input device for free, wanted to give it to the users
> > as i believed it was a cool and usefull feature
> > 
> > i tried to argue for it, i tried to promote it.
> > And as the person doing all releases of FFmpeg since a very long time
> > i thought yeah we will be able to resolve the disagreements and get it
> > in 6.1 with everyone geing happy.
> > I was wrong, i announced this before i actually got people to agree yes
> > I still belive if people where not so "excited" on this whole and if it
> > was just a technical question we could get SDR in 6.1 with everyone
> > agreeing.
> > But now heres a man to be burned at the stake, and thats more important.
> 
> You keep framing this as some kind of a personal campaign against you.
> It is not. From my perspective, the objections to SDR have been largely
> technical, and most of the "heat" comes from your refusal to accept that
> many active developers are against it.

Technical arguments ?
Yes, several people had technical arguments, I remember Tomas and Remi and some
others. But at least subjectively i felt that the bulk of people where alot more
emotional than technical

But let me list a few observations, from memory
First objection was because processing is done in an external library.
Then it was found out that was wrong and actually processing is done in the new code
so the objection flipped and people demanded it to be moved into an external library.

If you object to pink and want blue and when you find out its actually blue you have
to be happy and become a supporter but what happened was the opposit, the objection
was simply adjusted to object to whatever was the case and demand whatever was not.

Ok so thats at least one developers "Technical objection" down here, maybe more
i dont know if anyone else expressed that same initial objection. but lets move on

In all cases we prefer not to have external dependancies, this is the Technical position of FFmpeg
no, there is no technical argument in this.
Also personal preferrances of people is not a technical argument. Noone explained why a
avdevice module with more external depandancies would be ok but a avdevice module with
fewer external depandancies was not. <-- This last sentance is a technical argument
I could go as far as call this a proof by contradiction.

If people are happy with a avdevice module and FFmpeg prefers fewer external dependancies
then my suggestion of first starting with a plain simple self contained avdevice/avformat
module, would have to be fine too.
We can always move this to an external library once there is a technical reason for that
like for example some other software wants to use it

About the attack/rallying/compaign stuff. Ill keep it very brief as its not useful i think.
Also this is my own personal and subjective view. In fact the whole mail is
There was alot of (negative) emotion from 1-2 people about SDR. This emotion was what spread
slash rallied other developers. That came before any technical arguments.
Now people have picked their flag and march to war.

Everyone will deny it, same as every patriot will fight to the death for the colors of
the flag of the country and religion they where born into.

My claim, sorry to be stubborn, is that had this started a slight bit different there
would be little opposition to SDR. Iam not denying that now there are several people
against it.

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
than the original author, trying to rewrite it will not make it better.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Anton Khirnov]

Quoting Michael Niedermayer (2023-10-03 21:22:58)
> On Tue, Sep 26, 2023 at 08:14:37PM +0200, Anton Khirnov wrote:
> > You keep framing this as some kind of a personal campaign against you.
> > It is not. From my perspective, the objections to SDR have been largely
> > technical, and most of the "heat" comes from your refusal to accept that
> > many active developers are against it.
> 
> Technical arguments ?
> Yes, several people had technical arguments, I remember Tomas and Remi and some
> others. But at least subjectively i felt that the bulk of people where alot more
> emotional than technical
> 
> But let me list a few observations, from memory
> First objection was because processing is done in an external library.
> Then it was found out that was wrong and actually processing is done in the new code
> so the objection flipped and people demanded it to be moved into an external library.
> 
> If you object to pink and want blue and when you find out its actually blue you have
> to be happy and become a supporter but what happened was the opposit, the objection
> was simply adjusted to object to whatever was the case and demand whatever was not.
> 
> Ok so thats at least one developers "Technical objection" down here, maybe more
> i dont know if anyone else expressed that same initial objection. but lets move on
> 
> In all cases we prefer not to have external dependancies, this is the Technical position of FFmpeg
> no, there is no technical argument in this.
> Also personal preferrances of people is not a technical argument. Noone explained why a
> avdevice module with more external depandancies would be ok but a avdevice module with
> fewer external depandancies was not. <-- This last sentance is a technical argument
> I could go as far as call this a proof by contradiction.
> 
> If people are happy with a avdevice module and FFmpeg prefers fewer external dependancies
> then my suggestion of first starting with a plain simple self contained avdevice/avformat
> module, would have to be fine too.
> We can always move this to an external library once there is a technical reason for that
> like for example some other software wants to use it
> 
> About the attack/rallying/compaign stuff. Ill keep it very brief as its not useful i think.
> Also this is my own personal and subjective view. In fact the whole mail is
> There was alot of (negative) emotion from 1-2 people about SDR. This emotion was what spread
> slash rallied other developers. That came before any technical arguments.
> Now people have picked their flag and march to war.
> 
> Everyone will deny it, same as every patriot will fight to the death for the colors of
> the flag of the country and religion they where born into.
> 
> My claim, sorry to be stubborn, is that had this started a slight bit different there
> would be little opposition to SDR. Iam not denying that now there are several people
> against it.

These are largely unfalsifiable claims, so I don't see how they can
productively contribute to this discussion.

But dismissing people's concerns as "patriotic" or "religious" isn't
helping your case IMO.

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Lynne]

This discussion has drifted far away from any topic set upfront.

It's gotten to the point where there's no way for anyone outside
to join and give their own opinion, as it's not possible to know the
entire discussion that's happened up to this point.

Hence, spin this off in multiple threads. Maybe the one summarizing
a discussion will find it's pointless and we could focus on a smaller
set of things to worry about for 6.1's release.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 4291 bytes --]

On Wed, Oct 04, 2023 at 05:19:17PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-10-03 21:22:58)
> > On Tue, Sep 26, 2023 at 08:14:37PM +0200, Anton Khirnov wrote:
> > > You keep framing this as some kind of a personal campaign against you.
> > > It is not. From my perspective, the objections to SDR have been largely
> > > technical, and most of the "heat" comes from your refusal to accept that
> > > many active developers are against it.
> > 
> > Technical arguments ?
> > Yes, several people had technical arguments, I remember Tomas and Remi and some
> > others. But at least subjectively i felt that the bulk of people where alot more
> > emotional than technical
> > 
> > But let me list a few observations, from memory
> > First objection was because processing is done in an external library.
> > Then it was found out that was wrong and actually processing is done in the new code
> > so the objection flipped and people demanded it to be moved into an external library.
> > 
> > If you object to pink and want blue and when you find out its actually blue you have
> > to be happy and become a supporter but what happened was the opposit, the objection
> > was simply adjusted to object to whatever was the case and demand whatever was not.
> > 
> > Ok so thats at least one developers "Technical objection" down here, maybe more
> > i dont know if anyone else expressed that same initial objection. but lets move on
> > 
> > In all cases we prefer not to have external dependancies, this is the Technical position of FFmpeg
> > no, there is no technical argument in this.
> > Also personal preferrances of people is not a technical argument. Noone explained why a
> > avdevice module with more external depandancies would be ok but a avdevice module with
> > fewer external depandancies was not. <-- This last sentance is a technical argument
> > I could go as far as call this a proof by contradiction.
> > 
> > If people are happy with a avdevice module and FFmpeg prefers fewer external dependancies
> > then my suggestion of first starting with a plain simple self contained avdevice/avformat
> > module, would have to be fine too.
> > We can always move this to an external library once there is a technical reason for that
> > like for example some other software wants to use it
> > 
> > About the attack/rallying/compaign stuff. Ill keep it very brief as its not useful i think.
> > Also this is my own personal and subjective view. In fact the whole mail is
> > There was alot of (negative) emotion from 1-2 people about SDR. This emotion was what spread
> > slash rallied other developers. That came before any technical arguments.
> > Now people have picked their flag and march to war.
> > 
> > Everyone will deny it, same as every patriot will fight to the death for the colors of
> > the flag of the country and religion they where born into.
> > 
> > My claim, sorry to be stubborn, is that had this started a slight bit different there
> > would be little opposition to SDR. Iam not denying that now there are several people
> > against it.
> 
> These are largely unfalsifiable claims, so I don't see how they can
> productively contribute to this discussion.
> 

> But dismissing people's concerns as "patriotic" or "religious" isn't
> helping your case IMO.

That was not my intend
i had not intended to dismiss anyones concern
What i was trying to do with this 2nd part of the mail was to document
a subjective observation. The reason was simply _IF_ this observation
is somewhat correct, then awareness of this could help people next time.
As i stated i expect noone to change their position here. But maybe
next time we have a similar growing disagreement being aware of the
possible effects of emotional statements from fellow developers could
be helpfull.

thx, and ill try to end this debate in this thread, this minor comment
just felt it fits better here

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Ronald S. Bultje]

Hi Michael,

On Tue, Sep 26, 2023 at 7:16 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> Should i ask the counter-question ?
> are the developers who have less than 10 commits since 2017 abusing
> something
> by organizing and rallying the people against SDR, against the domain owner
> and against me ?
>

Hm... That's not very nice of you. I hope this is not targeted at me.
That's honestly under the belt, if it is.

Ronald
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Tomas Härdin]

tis 2023-09-26 klockan 19:16 +0200 skrev Michael Niedermayer:

> Anyway, i appologize for announcing SDR in 6.1. I was too much in
> love with
> SDR and how cool it would be ...

This is why I have suggested many times that you should get involved in
actual SDR projects. For example the FreeDV people have a spinoff
project called FreeDATA (https://freedata.app/  which is all about
sending data (including IP packets) over difficult channels. There is
plenty of DSP work to be done in these projects. If you also get an
amateur radio license then a whole world of experimentation opens up.

/Tomas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2841 bytes --]

On Wed, Sep 27, 2023 at 03:53:56PM +0200, Tomas Härdin wrote:
> tis 2023-09-26 klockan 19:16 +0200 skrev Michael Niedermayer:
> 
> > Anyway, i appologize for announcing SDR in 6.1. I was too much in
> > love with
> > SDR and how cool it would be ...
> 
> This is why I have suggested many times that you should get involved in
> actual SDR projects. For example the FreeDV people have a spinoff
> project called FreeDATA (https://freedata.app/  which is all about
> sending data (including IP packets) over difficult channels. There is
> plenty of DSP work to be done in these projects. If you also get an
> amateur radio license then a whole world of experimentation opens up.

And you can repeat it as often as you want, iam not interrested.
Why do you not understand this ?
my interrest is/was specific to FFmpeg gaining SDR support
its that and ONLY that

Ive earlier this year written some code to monitor liquidations in AAVE
why? for fun, it was a excercise for solidity & python. It was not
usefull for anything really, only the miners can do liquidations profitably
I guess i should use my blog more to write about what iam doing ...
I didnt touch blockchain related coding after that IIRC

Then i looked into security issues in a random number generator of a hw
password manager.

Then i looked at SDR and wrote the AM/FM demodulation. It added a feature
that was and is IMO usefull to FFmpeg and libavdevice users.
(we know the rest ...)
Iam happy to maintain this code, Iam happy to improve and extend it
if it has users (which requires this to be in a release used by people
at some point)

I have no interrest and no time to do other things in SDR outside the
FFmpeg codebase. And if FFmpeg doesnt want it, ill put it in a personal
fork or whatever we call it.

after this ive spend some time implementing a basic transformer based NN
(this was bascially just an excercise so nothing to show).

There are many things i find interresting. (also non programming things like
chemistry, biology and so on but i totally lack the time for these)
In the past it was possible to align my random interrest with FFmpeg.
Like for example a mandelbrot fractal zoom filter.
People did not ask that to be put in a seperate general purpose fractal
library.
With SDR they do ask for a seperate library. maybe we can organize the
existing code to make everyone happy. Maybe this will be a personal fork,
maybe it will grow and we will have a FFmpeg with many of my and other
peoples random projects. I dont know
But i dont feel drawn to any SDR projects, i hope above mail explains
better my point. I have too many interrests :)

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 1128 bytes --]

Michael Niedermayer (12023-09-27):
> With SDR they do ask for a seperate library.

And they are being dishonest in that. Nothing successful starts as a
library, they start small and grow, and get turned into libraries once
multiple projects can use them.

Demanding you make a separate library and a separate project is a
hypocritical ploy to have you spend your time on boring things like
build system and packaging, so that you lose interest in SDR and go back
to doing useful things for them, like fixing fuzzing bugs and
backporting the fixes.

>						maybe we can organize the
> existing code to make everyone happy.

You will NOT make everyone happy. Some people here have made absolutely
clear they will never be happy with your SDR code and will not rest
until they have killed it.

Acknowledge it: if you cannot make them happy, do not waste effort
trying, just accept you will be making them unhappy as unavoidable, and
make the rest of us — developers who would like to have fun with FFmpeg
again and users who would like to use the code — very happy.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Ronald S. Bultje]

Hi,

On Wed, Sep 27, 2023 at 10:27 PM Nicolas George <george@nsup.org> wrote:

> Michael Niedermayer (12023-09-27):
> > With SDR they do ask for a seperate library.
>
> And they are being dishonest in that. Nothing successful starts as a
> library
>

Didn't dav1d start as a library? (Or maybe it's not very successful by your
standards.) x264/5 are external libs, also.

I don't think we have to be absolutist about these things. Nothing's quite
so black/white.

Ronald
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Rémi Denis-Courmont]

Le keskiviikkona 27. syyskuuta 2023, 23.27.40 EEST Nicolas George a écrit :
> Michael Niedermayer (12023-09-27):
> > With SDR they do ask for a seperate library.
> 
> And they are being dishonest in that. Nothing successful starts as a
> library,

Strange, I thought FFmpeg really became popular as a back-end library for 
mplayer, before it was picked up by all other OSS multimedia at the time 
(gstreamer, VLC, Xine, etc.).

Force-feeding the SDR code to all FFmpeg packagers is not going to make it 
popular. Most of them will just disable it, especially if it brings new 
dependencies and/or doesn't work on the popular proprietary platforms.

FWIW, Fabrice Bellard didn't bundle all his initially hobby projects together. 
Several of them became popular.

> Demanding you make a separate library and a separate project is a
> hypocritical ploy to have you spend your time on boring things like
> build system and packaging, so that you lose interest in SDR and go back
> to doing useful things for them, like fixing fuzzing bugs and
> backporting the fixes.

To the contrary, I would much rather Michael uses his free time on his 
hobbies, including SDR-outside-FFmpeg. He can stick to spending his "time on 
boring things" if/when he gets paid.

That will add incentives for big tech corps to actually fund FFmpeg. This 
community, and presumably Michael in particular, are way too good at doing 
those "boring things" for free.

-- 
Rémi Denis-Courmont
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
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 1182 bytes --]

Rémi Denis-Courmont (12023-09-28):
> Strange, I thought FFmpeg really became popular as a back-end library for 
> mplayer, before it was picked up by all other OSS multimedia at the time 
> (gstreamer, VLC, Xine, etc.).

Fortunately, I know the history of our projects better than you:

First, FFmpeg was already a feature-rich self-contained program when
MPlayer started using it.

Second, MPlayer did not start using it FFmpeg as a library, it started —
and still does in part — using it as embedded code.

Too bad your attempt at disproving my point just proves it.

> Force-feeding the SDR code to all FFmpeg packagers is not going to make it 
> popular. Most of them will just disable it, especially if it brings new 
> dependencies and/or doesn't work on the popular proprietary platforms.

So, they can “just disable it” and ignore it. They have no ground to
oppose, and neither do you.

> FWIW, Fabrice Bellard didn't bundle all his initially hobby projects together. 
> Several of them became popular.

He bundled together the things that fit nicely together. Once again an
argument in favor of SDR integration.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Rémi Denis-Courmont]

Le torstaina 28. syyskuuta 2023, 18.33.33 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > Strange, I thought FFmpeg really became popular as a back-end library for
> > mplayer, before it was picked up by all other OSS multimedia at the time
> > (gstreamer, VLC, Xine, etc.).
> 
> Fortunately, I know the history of our projects better than you:
> 
> First, FFmpeg was already a feature-rich self-contained program when
> MPlayer started using it.

Just being feature-rich does not make it popular. I never said anything about 
being or not being feature-rich at that point in time. But congratulations on 
disproving a point that nobody made anyway.

> Second, MPlayer did not start using it FFmpeg as a library, it started —
> and still does in part — using it as embedded code.

Sure and that is in fact one way to use a software library. There is even a 
name for that practice nowadays: vendoring. Thanks for making my point.

> Too bad your attempt at disproving my point just proves it.

Just providing some historical facts (that I don't challenge) does not 
disprove my point. You pretty much confirmed my point actually.

And besides, one example (FFmpeg) does not prove a general rule, such as you 
up-thread postulate that started-as-library software is never popular.

Indeed, anybody who knows open-source in general knows that there are plenty 
of libraries that are popular. In fact, there are far more popular libraries 
than popular applications in terms of user base, and often in terms of 
development activity and community strength. (And I don't count libraries with 
reference command line tools as applications, otherwise everything is an 
application and your implied dichotomy would not make sense to begin with.)

> > Force-feeding the SDR code to all FFmpeg packagers is not going to make it
> > popular. Most of them will just disable it, especially if it brings new
> > dependencies and/or doesn't work on the popular proprietary platforms.
> 
> So, they can “just disable it” and ignore it.

That does not change the fact that it won't make it any popular, and thus your 
postulate is wrong.

> They have no ground to oppose, and neither do you.

I neither needed nor sought new ground here. I just disprove your postulate, 
not that I expect you to be able to grasp the possibility of such occurrence, 
in light of your past and present show of self-assurance (to put it politely).

> > FWIW, Fabrice Bellard didn't bundle all his initially hobby projects
> > together. Several of them became popular.
> 
> He bundled together the things that fit nicely together.
> Once again an argument in favor of SDR integration.

It should be blatantly obvious to anybody with a modicum of modesty that "fit 
nicely together" is intrinsically a very subjective value judgement, not a 
technical argument in favor or disfavor of anything.

-- 
レミ・デニ-クールモン
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
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 898 bytes --]

Rémi Denis-Courmont (12023-09-28):
> Thanks for making my point.

Stealing the other person rhetoric device does not make you right.

> That does not change the fact that it won't make it any popular, and thus your 
> postulate is wrong.

It reach more popular included in FFmpeg than if users have to download
it separately. Nobody honest would seriously try to argue the opposite.

> It should be blatantly obvious to anybody with a modicum of modesty that "fit 
> nicely together" is intrinsically a very subjective value judgement, not a 
> technical argument in favor or disfavor of anything.

What you are describing here is your “does not belong”.

“Fit nicely together” means it allows to do things that were not
possible previously or required more work and were more fragile
(pipelines and shell scripts). It is a technical argument.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Rémi Denis-Courmont]

Le torstaina 28. syyskuuta 2023, 19.13.37 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > Thanks for making my point.
> 
> Stealing the other person rhetoric device does not make you right.
> 
> > That does not change the fact that it won't make it any popular, and thus
> > your postulate is wrong.
> 
> It reach more popular included in FFmpeg than if users have to download
> it separately.

If this were a feature that would be somehow automatically enabled or highly 
visible, that would make sense. But not only is it no such thing, it requires 
special hardware.

With that noted, for any reasonable understanding of "popularity", it would be 
less popular. That is the point. People who want to do SDR will be burdened 
with the other 99% of FFmpeg that they don't need for SDR. And that's if they 
find out that FFmpeg can actually do SDR - but in all likelihood, they 
wouldn't, because of the brand recognition of FFmpeg. Instead, they'd end up 
with some SDR-specific projects.

That's why, if Michael does not want to join an existing SDR project, he is 
much better off making a new one, than bundling in FFmpeg.

> Nobody honest would seriously try to argue the opposite.

I believe that you have high IQ, and good English skill, enough that you 
should be able to more or less figure out what was noted above and up-thread.

And this puts me in a bit of a conundrum. See, if you did figure that much out, 
then you would be willfully committing defamation against me, by calling me 
dishonest. I suppose that I am going to have to assume that you are somehow 
temporarily incapacitated.
 
-- 
Rémi Denis-Courmont
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
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 521 bytes --]

Rémi Denis-Courmont (12023-09-28):
> And this puts me in a bit of a conundrum. See, if you did figure that much out, 
> then you would be willfully committing defamation against me, by calling me 
> dishonest.

I am calling your argument dishonest. I stand by it.

>	     I suppose that I am going to have to assume that you are somehow 
                                                              ^^^^^^^
> temporarily incapacitated.

Now, *this* is an ad-hominem argument indeed.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Rémi Denis-Courmont]

Le keskiviikkona 27. syyskuuta 2023, 23.18.29 EEST Michael Niedermayer a écrit 
:
> And you can repeat it as often as you want, iam not interrested.
> Why do you not understand this ?

You can repeat the contrary as much as you want, we do not believe that your 
SDR code fits in FFmpeg. Why do you not understand this?

(...)
> Then i looked at SDR and wrote the AM/FM demodulation. It added a feature
> that was and is IMO usefull to FFmpeg and libavdevice users.

Like no, seriously. If you really want to generic support for AM and FM RX in 
FFmpeg, then you should use implement frontends for the already *existing* HAL 
(that would be V4L radio and ALSA on Linux), or perhaps, write a new user-
space HAL library that would accomodate both hardware radio RX devices and 
SDR.

In fact, the SDR code has quite a number of impediments that all but guarantee 
that it will not "catch on" in FFmpeg:
- it requires niche hardware,
- it only works on some limited set of OSes (if not only Linux),
- it will be subject to all the FFmpeg processes and drama,
- it will be obscured by FFmpeg's existing own fame, remaining an obscure 
feature set that hardly anybody outside FFmpeg-devel knows about.

You are doing your own work a disservice by pushing it in FFmpeg, IMO.

-- 
雷米‧德尼-库尔蒙
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
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 1598 bytes --]

Rémi Denis-Courmont (12023-09-28):
> You can repeat the contrary as much as you want, we do not believe that your 
> SDR code fits in FFmpeg. Why do you not understand this?

We understand that very well. Once again, it is you who do not
understand something: your BELIEF that SDR does not belong in ffmpeg is
nothing more than that, a belief, an opinion, and it weighs nothing in
front of the argument that some users want it.

> Like no, seriously. If you really want to generic support for AM and FM RX in 
> FFmpeg, then you should use implement frontends for the already *existing* HAL 
> (that would be V4L radio and ALSA on Linux), or perhaps, write a new user-
> space HAL library that would accomodate both hardware radio RX devices and 
> SDR.

Did you miss the part where he explained he was not interesting in doing
it like that?

> In fact, the SDR code has quite a number of impediments that all but guarantee 
> that it will not "catch on" in FFmpeg:
> - it requires niche hardware,

Like a few components of libavdevice, that is not an issue.

> - it only works on some limited set of OSes (if not only Linux),

Like a few components of libavdevice, that is not an issue.

> - it will be subject to all the FFmpeg processes and drama,

This problem does not come from SDR, it comes from you.

> - it will be obscured by FFmpeg's existing own fame, remaining an obscure 
> feature set that hardly anybody outside FFmpeg-devel knows about.

Like a lot of features.

Scrapping the bottom of drawers for arguments are you?

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Rémi Denis-Courmont]

Le torstaina 28. syyskuuta 2023, 18.28.50 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > You can repeat the contrary as much as you want, we do not believe that
> > your SDR code fits in FFmpeg. Why do you not understand this?
> 
> We understand that very well. Once again, it is you who do not
> understand something: your BELIEF that SDR does not belong in ffmpeg is
> nothing more than that, a belief, an opinion, and it weighs nothing in
> front of the argument that some users want it.

"We understand that very well. Once again, it is you who do not understand 
something: your BELIEF tha SDR does beling in FFmpeg is nothing more than 
that, a belief, an opinion, and it weighs" very little in the face of repeated 
technical arguments by several members of the development community as well as 
common sense.

> it weighs nothing in front of the argument that some users want it.

Literally ABSOLUTELY ZERO *users* said that they wanted it, except for Michael 
himself. Other people (including you) did say that they wanted it, yes, but 
none of them were users or even potential users of SDR. Some even explicitly 
said that (although it sounded cool) they would not use it.

So you fail at logical argumentation again.

> > Like no, seriously. If you really want to generic support for AM and FM RX
> > in FFmpeg, then you should use implement frontends for the already
> > *existing* HAL (that would be V4L radio and ALSA on Linux), or perhaps,
> > write a new user- space HAL library that would accomodate both hardware
> > radio RX devices and SDR.
> 
> Did you miss the part where he explained he was not interesting in doing
> it like that?

He said that he did not want to join an existing SDR project. That's 
completely orthogonal.

And in any case, this is one of several technical argument. You cannot 
"disprove" it with the subjective opinions and authority fallacies.

> > In fact, the SDR code has quite a number of impediments that all but
> > guarantee that it will not "catch on" in FFmpeg:
> > - it requires niche hardware,
> 
> Like a few components of libavdevice, that is not an issue.

Err, it is very much an issue w.r.t. "catching on".

You even left the original quote up there. This makes your highly 
intellectually dishonest attempt at distorting my statements all the more 
blatant.

> > - it only works on some limited set of OSes (if not only Linux),
> 
> Like a few components of libavdevice, that is not an issue.

Same thing.

> > - it will be subject to all the FFmpeg processes and drama,
> 
> This problem does not come from SDR, it comes from you.

I was not the one to start this drama (on either side of the argument), and 
there have been plenty more people on my side than yours.  I am indeed part of 
the problem in a sense. Though if I follow that logic, you are a 
proportionally bigger part of the problem, FWIW.

Now you could argue that my argument si a self-realising prophecy. But 
regardless of who is to blame, my argument holds: the drame will continue 
(with or without me, by the way) unless Michael compromises and takes SDR out 
of FFmpeg.git and FFmpeg-devel.

> > - it will be obscured by FFmpeg's existing own fame, remaining an obscure
> > feature set that hardly anybody outside FFmpeg-devel knows about.
> 
> Like a lot of features.

Probably indeed like a lot of features, who failed to catch on and will 
continue to fail to catch on. My point exactly!
 
> Scrapping the bottom of drawers for arguments are you?

I think that I made it clear that this was about how/why SDR will not be 
*popular* inside FFmpeg.

Maybe those are bottom of the drawer arguments against SDR in FFmpeg. That 
does not exactly matter in this context, since that is not what they were 
about.

Also that's an ad hominem attack, which violates the CC.

-- 
Rémi Denis-Courmont
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
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 655 bytes --]

Rémi Denis-Courmont (12023-09-28):
> Err, it is very much an issue w.r.t. "catching on".

Moving the goalpost much.

> Also that's an ad hominem attack, which violates the CC.

No it is not.

This mail is no longer part of a honest discussion, and therefore I will
save myself the time of answering it in details.

Stop moving the goalposts, stop wasting everybody's time by turning
arguments on their head and emptying them of their value at the same
time.

You can sate what you want about SDR and why you want it, that might
make the discussion progress. Or you can continue wasting your time with
bullshit arguments.

-- 
  Nico

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Paul B Mahol]

On 9/28/23, Nicolas George <george@nsup.org> wrote:
> Rémi Denis-Courmont (12023-09-28):
>> Err, it is very much an issue w.r.t. "catching on".
>
> Moving the goalpost much.
>
>> Also that's an ad hominem attack, which violates the CC.
>
> No it is not.
>
> This mail is no longer part of a honest discussion, and therefore I will
> save myself the time of answering it in details.
>
> Stop moving the goalposts, stop wasting everybody's time by turning
> arguments on their head and emptying them of their value at the same
> time.
>
> You can sate what you want about SDR and why you want it, that might
> make the discussion progress. Or you can continue wasting your time with
> bullshit arguments.

This is again against the CC.

>
> --
>   Nico
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Rémi Denis-Courmont]

Le torstaina 28. syyskuuta 2023, 19.32.44 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > Err, it is very much an issue w.r.t. "catching on".
> 
> Moving the goalpost much.

I think obviously not, considering the original quote (EMPHASIS ADDED):

> In fact, the SDR code has quite a number of impediments that all but
> guarantee that IT WILL NOT CATCH ON in FFmpeg:
> - it requires niche hardware,
> - it only works on some limited set of OSes (if not only Linux),

Literally the exact same verb even.


P.S.: Your repeated CoC violations will be reported shortly.

-- 
レミ・デニ-クールモン
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
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 486 bytes --]

Rémi Denis-Courmont (12023-09-28):
> Literally the exact same verb even.

So what are you saying, that I noticed you moved the goalposts one
message too late?

> P.S.: Your repeated CoC violations will be reported shortly.

So, for your information:

(1) There was no violations in my message. Calling your arguments
bullshit is not a personal attack, by definition.

(2) Even if there were any violation, there is nobody to report it to
anyway.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Rémi Denis-Courmont]

Le torstaina 28. syyskuuta 2023, 19.41.06 EEST Nicolas George a écrit :
> (1) There was no violations in my message. Calling your arguments
> bullshit is not a personal attack, by definition.

Calling BBB, Kieran and myself dishonest is.

> (2) Even if there were any violation, there is nobody to report it to
> anyway.

I take that as an admission of guilt.

-- 
レミ・デニ-クールモン
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
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 212 bytes --]

Rémi Denis-Courmont (12023-09-28):
> Calling BBB, Kieran and myself dishonest is.

I call your arguments dishonest.

> I take that as an admission of guilt.

Take it as you want.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Rémi Denis-Courmont]

Le torstaina 28. syyskuuta 2023, 19.43.57 EEST Nicolas George a écrit :
> Rémi Denis-Courmont (12023-09-28):
> > Calling BBB, Kieran and myself dishonest is.
> 
> I call your arguments dishonest.

You almost had me doubting my recollection for a minute. But:

Michael wrote:
> > People did not ask that to be put in a seperate general purpose fractal
> > library.
> > With SDR they do ask for a seperate library.
And you then wrote:
> And they are being dishonest in that

Arguments cannot "ask for separate library". "They" were explicitly "people", 
specifically people asking for a separate library.

Later on:
> Nobody honest would seriously try to argue the opposite.
[after I had indeed argued the opposite]

Feel free to call me captain obvious: "nobody" is a negative pronoun for 
people, not for abstract concepts such as arguments, for which the pronoun 
would be "nothing".

But hey, I shall not reproduce Paul's mistake that got him admonished by JB.

-- 
雷米‧德尼-库尔蒙
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
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Neal Gompa]

On Thu, Jul 6, 2023 at 12:04 PM Lynne <dev@lynne.ee> wrote:
>
> It's been a while since we've had a release, and we've had
> a lot of new features in.
> We did say we would make releases more often, and I think
> it's about time we have a new release.
>
> Anything anyone wants to have merged or should we branch
> off 6.1 in a few days?

I was hoping to see the enhanced RTMP/FLV stuff merged by now... And
maybe the Intel person finally posting their AV1 VA-API patches...



-- 
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Anton Khirnov]

Quoting Lynne (2023-07-06 18:04:41)
> It's been a while since we've had a release, and we've had
> a lot of new features in.
> We did say we would make releases more often, and I think
> it's about time we have a new release.
> 
> Anything anyone wants to have merged or should we branch
> off 6.1 in a few days?

I'd like to have
'[PATCH 21/22] fftools/ffmpeg: rework -enc_time_base handling'
(<20230707094847.25324-21-anton@khirnov.net>), which fixes #10393,
in the release.

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Lynne]

Jul 6, 2023, 18:04 by dev@lynne.ee:

> It's been a while since we've had a release, and we've had
> a lot of new features in.
> We did say we would make releases more often, and I think
> it's about time we have a new release.
>
> Anything anyone wants to have merged or should we branch
> off 6.1 in a few days?
>

Could we consider at least branching off 6.1?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1491 bytes --]

On Mon, Oct 09, 2023 at 05:37:42AM +0200, Lynne wrote:
> Jul 6, 2023, 18:04 by dev@lynne.ee:
> 
> > It's been a while since we've had a release, and we've had
> > a lot of new features in.
> > We did say we would make releases more often, and I think
> > it's about time we have a new release.
> >
> > Anything anyone wants to have merged or should we branch
> > off 6.1 in a few days?
> >
> 
> Could we consider at least branching off 6.1?

we can consider branching whenever theres a consensus to do so
People are always quick in saying what they want in / done before
releases/branching. But its rare that people later reply and say that an issue
was resolved.
This makes monitoring for what blockers remain painfull
i think for the next release we should automate this
because trac has a "Blocking" field and that could be set to 6.1
for example and then one can just query trac for all open tickets
that are blocking "6.1"
Which would make it MUCH easier to know what is blocking it and would
make it easier to know when all blockers are gone
ATM one has to go over multiple threads and then figure out what people
asked for to be done first and then find out if the things are still
not done.


thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Neal Gompa]

On Mon, Oct 9, 2023 at 1:42 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> On Mon, Oct 09, 2023 at 05:37:42AM +0200, Lynne wrote:
> > Jul 6, 2023, 18:04 by dev@lynne.ee:
> >
> > > It's been a while since we've had a release, and we've had
> > > a lot of new features in.
> > > We did say we would make releases more often, and I think
> > > it's about time we have a new release.
> > >
> > > Anything anyone wants to have merged or should we branch
> > > off 6.1 in a few days?
> > >
> >
> > Could we consider at least branching off 6.1?
>
> we can consider branching whenever theres a consensus to do so
> People are always quick in saying what they want in / done before
> releases/branching. But its rare that people later reply and say that an issue
> was resolved.
> This makes monitoring for what blockers remain painfull
> i think for the next release we should automate this
> because trac has a "Blocking" field and that could be set to 6.1
> for example and then one can just query trac for all open tickets
> that are blocking "6.1"
> Which would make it MUCH easier to know what is blocking it and would
> make it easier to know when all blockers are gone
> ATM one has to go over multiple threads and then figure out what people
> asked for to be done first and then find out if the things are still
> not done.
>

Sorry if I haven't chimed in about this. From my point of view, the
things I need in 6.1 have landed. So I'm fine with 6.1 being released
now.



-- 
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1439 bytes --]

On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> It's been a while since we've had a release, and we've had
> a lot of new features in.
> We did say we would make releases more often, and I think
> it's about time we have a new release.
> 
> Anything anyone wants to have merged or should we branch
> off 6.1 in a few days?

Whats the status of this ?
I can branch 6.1 anytime

It was just that jb told me
"6.1 opportunity is gone.
 We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"

but now i see on IRC
<Lynne> make a damn release already
<durandal_1707> j-b: drop MiNi from release maintership and nominate Lynne
<Lynne> I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release!
<j-b> durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release.

noone mentioned 5.1.x and 6.0.x to me before

anyway, ill try to make releases from all maintained branches,

and will branch 6.1 as soon as Lynne or others say everything is ready.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[James Almer]

On 10/28/2023 1:49 PM, Michael Niedermayer wrote:
> On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
>> It's been a while since we've had a release, and we've had
>> a lot of new features in.
>> We did say we would make releases more often, and I think
>> it's about time we have a new release.
>>
>> Anything anyone wants to have merged or should we branch
>> off 6.1 in a few days?
> 
> Whats the status of this ?
> I can branch 6.1 anytime
> 
> It was just that jb told me
> "6.1 opportunity is gone.
>   We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"
> 
> but now i see on IRC
> <Lynne> make a damn release already
> <durandal_1707> j-b: drop MiNi from release maintership and nominate Lynne
> <Lynne> I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release!
> <j-b> durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release.
> 
> noone mentioned 5.1.x and 6.0.x to me before

Point releases are in general up to you. 6.0 could have gotten one 
during the past few months, to be honest, but unless there were critical 
bugs there was probably no hurry.

> 
> anyway, ill try to make releases from all maintained branches,
> 
> and will branch 6.1 as soon as Lynne or others say everything is ready.

I'd branch a 6.1 with the tree in its current state (doesn't need to be 
right now, i mean API wise). 7.0 will feature a major bump and 
deprecated API removal, so it'd be nice to have one more release with 
the current sonames.
And IMO it's fine if we release 7.0 in January despite not having much 
development done post 6.1. But i want other people's opinions.

I forgot, which release was supposed to be LTS? 6.0 or 6.1?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Lynne]

Oct 28, 2023, 18:49 by michael@niedermayer.cc:

> On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
>
>> It's been a while since we've had a release, and we've had
>> a lot of new features in.
>> We did say we would make releases more often, and I think
>> it's about time we have a new release.
>>
>> Anything anyone wants to have merged or should we branch
>> off 6.1 in a few days?
>>
>
> Whats the status of this ?
> I can branch 6.1 anytime
>
> It was just that jb told me
> "6.1 opportunity is gone.
>  We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"
>
> but now i see on IRC
> <Lynne> make a damn release already
> <durandal_1707> j-b: drop MiNi from release maintership and nominate Lynne
> <Lynne> I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release!
> <j-b> durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release.
>
> noone mentioned 5.1.x and 6.0.x to me before
>
> anyway, ill try to make releases from all maintained branches,
>
> and will branch 6.1 as soon as Lynne or others say everything is ready.
>
> thx
>

It's never too late to make a release. If we do a release now, nothing's stopping
us from doing a 7.0 and getting back on track with releases every two months or so,
like the plan was.

7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec,
Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to
have a release before all this lands.

I think the tree is in a pretty good state ATM, you should go ahead and branch if you're
comfortable with it as well.
Let's aim for a release by Sunday next week. That should give everyone enough time to
backport fixes they want in.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2653 bytes --]

On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote:
> Oct 28, 2023, 18:49 by michael@niedermayer.cc:
> 
> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> >
> >> It's been a while since we've had a release, and we've had
> >> a lot of new features in.
> >> We did say we would make releases more often, and I think
> >> it's about time we have a new release.
> >>
> >> Anything anyone wants to have merged or should we branch
> >> off 6.1 in a few days?
> >>
> >
> > Whats the status of this ?
> > I can branch 6.1 anytime
> >
> > It was just that jb told me
> > "6.1 opportunity is gone.
> >  We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"
> >
> > but now i see on IRC
> > <Lynne> make a damn release already
> > <durandal_1707> j-b: drop MiNi from release maintership and nominate Lynne
> > <Lynne> I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release!
> > <j-b> durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release.
> >
> > noone mentioned 5.1.x and 6.0.x to me before
> >
> > anyway, ill try to make releases from all maintained branches,
> >
> > and will branch 6.1 as soon as Lynne or others say everything is ready.
> >
> > thx
> >
> 
> It's never too late to make a release. If we do a release now, nothing's stopping
> us from doing a 7.0 and getting back on track with releases every two months or so,
> like the plan was.
> 
> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec,
> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to
> have a release before all this lands.
> 

> I think the tree is in a pretty good state ATM, you should go ahead and branch if you're
> comfortable with it as well.

branch made


> Let's aim for a release by Sunday next week. That should give everyone enough time to
> backport fixes they want in.

I would aim for 1-3 weeks (when code and developers are ready)
dont want to aim for a specific day, better pick a day when everything is fine
not too many distractions, ...

Or is there something that favors us to be before a specific date ?

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Lynne]

Oct 29, 2023, 05:51 by michael@niedermayer.cc:

> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote:
>
>> Oct 28, 2023, 18:49 by michael@niedermayer.cc:
>>
>> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
>> >
>> >> It's been a while since we've had a release, and we've had
>> >> a lot of new features in.
>> >> We did say we would make releases more often, and I think
>> >> it's about time we have a new release.
>> >>
>> >> Anything anyone wants to have merged or should we branch
>> >> off 6.1 in a few days?
>> >>
>> >
>> > Whats the status of this ?
>> > I can branch 6.1 anytime
>> >
>> > It was just that jb told me
>> > "6.1 opportunity is gone.
>> >  We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"
>> >
>> > but now i see on IRC
>> > <Lynne> make a damn release already
>> > <durandal_1707> j-b: drop MiNi from release maintership and nominate Lynne
>> > <Lynne> I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release!
>> > <j-b> durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release.
>> >
>> > noone mentioned 5.1.x and 6.0.x to me before
>> >
>> > anyway, ill try to make releases from all maintained branches,
>> >
>> > and will branch 6.1 as soon as Lynne or others say everything is ready.
>> >
>> > thx
>> >
>>
>> It's never too late to make a release. If we do a release now, nothing's stopping
>> us from doing a 7.0 and getting back on track with releases every two months or so,
>> like the plan was.
>>
>> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec,
>> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to
>> have a release before all this lands.
>>
>> I think the tree is in a pretty good state ATM, you should go ahead and branch if you're
>> comfortable with it as well.
>>
>
> branch made
>

Thanks. I'll get a blog post ready for the transform work, as kierank wanted to post something,
and if users can know to who to point fingers to in case it degrades performance on RPI1 devices.


>> Let's aim for a release by Sunday next week. That should give everyone enough time to
>> backport fixes they want in.
>>
>
> I would aim for 1-3 weeks (when code and developers are ready)
> dont want to aim for a specific day, better pick a day when everything is fine
> not too many distractions, ...
>
> Or is there something that favors us to be before a specific date ?
>

Not really a reason, Sunday is just an optimistic date to aim for.
If there are no big fixes to backport to the branch, I think we can target it.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Lynne]

Oct 29, 2023, 06:57 by dev@lynne.ee:

> Oct 29, 2023, 05:51 by michael@niedermayer.cc:
>
>> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote:
>>
>>> Oct 28, 2023, 18:49 by michael@niedermayer.cc:
>>>
>>> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
>>> >
>>> >> It's been a while since we've had a release, and we've had
>>> >> a lot of new features in.
>>> >> We did say we would make releases more often, and I think
>>> >> it's about time we have a new release.
>>> >>
>>> >> Anything anyone wants to have merged or should we branch
>>> >> off 6.1 in a few days?
>>> >>
>>> >
>>> > Whats the status of this ?
>>> > I can branch 6.1 anytime
>>> >
>>> > It was just that jb told me
>>> > "6.1 opportunity is gone.
>>> >  We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"
>>> >
>>> > but now i see on IRC
>>> > <Lynne> make a damn release already
>>> > <durandal_1707> j-b: drop MiNi from release maintership and nominate Lynne
>>> > <Lynne> I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release!
>>> > <j-b> durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release.
>>> >
>>> > noone mentioned 5.1.x and 6.0.x to me before
>>> >
>>> > anyway, ill try to make releases from all maintained branches,
>>> >
>>> > and will branch 6.1 as soon as Lynne or others say everything is ready.
>>> >
>>> > thx
>>> >
>>>
>>> It's never too late to make a release. If we do a release now, nothing's stopping
>>> us from doing a 7.0 and getting back on track with releases every two months or so,
>>> like the plan was.
>>>
>>> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec,
>>> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to
>>> have a release before all this lands.
>>>
>>> I think the tree is in a pretty good state ATM, you should go ahead and branch if you're
>>> comfortable with it as well.
>>>
>>
>> branch made
>>
>
> Thanks. I'll get a blog post ready for the transform work, as kierank wanted to post something,
> and if users can know to who to point fingers to in case it degrades performance on RPI1 devices.
>
>
>>> Let's aim for a release by Sunday next week. That should give everyone enough time to
>>> backport fixes they want in.
>>>
>>
>> I would aim for 1-3 weeks (when code and developers are ready)
>> dont want to aim for a specific day, better pick a day when everything is fine
>> not too many distractions, ...
>>
>> Or is there something that favors us to be before a specific date ?
>>
>
> Not really a reason, Sunday is just an optimistic date to aim for.
> If there are no big fixes to backport to the branch, I think we can target it.
>

The nlmeans_vulkan patch I just sent is the last patch I'd like to have in 6.1.
Does anyone else have any patches they would like in 6.1?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Tristan Matthews]

On Tue, Nov 7, 2023 at 2:36 AM Lynne <dev@lynne.ee> wrote:
>
> Oct 29, 2023, 06:57 by dev@lynne.ee:
>
> > Oct 29, 2023, 05:51 by michael@niedermayer.cc:
> >
> >> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote:
> >>
> >>> Oct 28, 2023, 18:49 by michael@niedermayer.cc:
> >>>
> >>> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> >>> >
> >>> >> It's been a while since we've had a release, and we've had
> >>> >> a lot of new features in.
> >>> >> We did say we would make releases more often, and I think
> >>> >> it's about time we have a new release.
> >>> >>
> >>> >> Anything anyone wants to have merged or should we branch
> >>> >> off 6.1 in a few days?
> >>> >>
> >>> >
> >>> > Whats the status of this ?
> >>> > I can branch 6.1 anytime
> >>> >
> >>> > It was just that jb told me
> >>> > "6.1 opportunity is gone.
> >>> >  We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"
> >>> >
> >>> > but now i see on IRC
> >>> > <Lynne> make a damn release already
> >>> > <durandal_1707> j-b: drop MiNi from release maintership and nominate Lynne
> >>> > <Lynne> I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release!
> >>> > <j-b> durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release.
> >>> >
> >>> > noone mentioned 5.1.x and 6.0.x to me before
> >>> >
> >>> > anyway, ill try to make releases from all maintained branches,
> >>> >
> >>> > and will branch 6.1 as soon as Lynne or others say everything is ready.
> >>> >
> >>> > thx
> >>> >
> >>>
> >>> It's never too late to make a release. If we do a release now, nothing's stopping
> >>> us from doing a 7.0 and getting back on track with releases every two months or so,
> >>> like the plan was.
> >>>
> >>> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec,
> >>> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to
> >>> have a release before all this lands.
> >>>
> >>> I think the tree is in a pretty good state ATM, you should go ahead and branch if you're
> >>> comfortable with it as well.
> >>>
> >>
> >> branch made
> >>
> >
> > Thanks. I'll get a blog post ready for the transform work, as kierank wanted to post something,
> > and if users can know to who to point fingers to in case it degrades performance on RPI1 devices.
> >
> >
> >>> Let's aim for a release by Sunday next week. That should give everyone enough time to
> >>> backport fixes they want in.
> >>>
> >>
> >> I would aim for 1-3 weeks (when code and developers are ready)
> >> dont want to aim for a specific day, better pick a day when everything is fine
> >> not too many distractions, ...
> >>
> >> Or is there something that favors us to be before a specific date ?
> >>
> >
> > Not really a reason, Sunday is just an optimistic date to aim for.
> > If there are no big fixes to backport to the branch, I think we can target it.
> >
>
> The nlmeans_vulkan patch I just sent is the last patch I'd like to have in 6.1.
> Does anyone else have any patches they would like in 6.1?

I was going to request Steven Liu's enhanced RTMP set but it looks
like those are already in the release/6.1 branch, so cheers.

-t
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Steven Liu]

Tristan Matthews <tmatth@videolan.org> 于2023年11月8日周三 00:47写道：
>
> On Tue, Nov 7, 2023 at 2:36 AM Lynne <dev@lynne.ee> wrote:
> >
> > Oct 29, 2023, 06:57 by dev@lynne.ee:
> >
> > > Oct 29, 2023, 05:51 by michael@niedermayer.cc:
> > >
> > >> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote:
> > >>
> > >>> Oct 28, 2023, 18:49 by michael@niedermayer.cc:
> > >>>
> > >>> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> > >>> >
> > >>> >> It's been a while since we've had a release, and we've had
> > >>> >> a lot of new features in.
> > >>> >> We did say we would make releases more often, and I think
> > >>> >> it's about time we have a new release.
> > >>> >>
> > >>> >> Anything anyone wants to have merged or should we branch
> > >>> >> off 6.1 in a few days?
> > >>> >>
> > >>> >
> > >>> > Whats the status of this ?
> > >>> > I can branch 6.1 anytime
> > >>> >
> > >>> > It was just that jb told me
> > >>> > "6.1 opportunity is gone.
> > >>> >  We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"
> > >>> >
> > >>> > but now i see on IRC
> > >>> > <Lynne> make a damn release already
> > >>> > <durandal_1707> j-b: drop MiNi from release maintership and nominate Lynne
> > >>> > <Lynne> I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release!
> > >>> > <j-b> durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release.
> > >>> >
> > >>> > noone mentioned 5.1.x and 6.0.x to me before
> > >>> >
> > >>> > anyway, ill try to make releases from all maintained branches,
> > >>> >
> > >>> > and will branch 6.1 as soon as Lynne or others say everything is ready.
> > >>> >
> > >>> > thx
> > >>> >
> > >>>
> > >>> It's never too late to make a release. If we do a release now, nothing's stopping
> > >>> us from doing a 7.0 and getting back on track with releases every two months or so,
> > >>> like the plan was.
> > >>>
> > >>> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec,
> > >>> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to
> > >>> have a release before all this lands.
> > >>>
> > >>> I think the tree is in a pretty good state ATM, you should go ahead and branch if you're
> > >>> comfortable with it as well.
> > >>>
> > >>
> > >> branch made
> > >>
> > >
> > > Thanks. I'll get a blog post ready for the transform work, as kierank wanted to post something,
> > > and if users can know to who to point fingers to in case it degrades performance on RPI1 devices.
> > >
> > >
> > >>> Let's aim for a release by Sunday next week. That should give everyone enough time to
> > >>> backport fixes they want in.
> > >>>
> > >>
> > >> I would aim for 1-3 weeks (when code and developers are ready)
> > >> dont want to aim for a specific day, better pick a day when everything is fine
> > >> not too many distractions, ...
> > >>
> > >> Or is there something that favors us to be before a specific date ?
> > >>
> > >
> > > Not really a reason, Sunday is just an optimistic date to aim for.
> > > If there are no big fixes to backport to the branch, I think we can target it.
> > >
> >
> > The nlmeans_vulkan patch I just sent is the last patch I'd like to have in 6.1.
> > Does anyone else have any patches they would like in 6.1?
>
> I was going to request Steven Liu's enhanced RTMP set but it looks
> like those are already in the release/6.1 branch, so cheers.
:-) Thanks ttmath
>
> -t

Thanks
Steven
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Steven Liu]

Steven Liu <lingjiujianke@gmail.com> 于2023年11月8日周三 09:26写道：
>
> Tristan Matthews <tmatth@videolan.org> 于2023年11月8日周三 00:47写道：
> >
> > On Tue, Nov 7, 2023 at 2:36 AM Lynne <dev@lynne.ee> wrote:
> > >
> > > Oct 29, 2023, 06:57 by dev@lynne.ee:
> > >
> > > > Oct 29, 2023, 05:51 by michael@niedermayer.cc:
> > > >
> > > >> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote:
> > > >>
> > > >>> Oct 28, 2023, 18:49 by michael@niedermayer.cc:
> > > >>>
> > > >>> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> > > >>> >
> > > >>> >> It's been a while since we've had a release, and we've had
> > > >>> >> a lot of new features in.
> > > >>> >> We did say we would make releases more often, and I think
> > > >>> >> it's about time we have a new release.
> > > >>> >>
> > > >>> >> Anything anyone wants to have merged or should we branch
> > > >>> >> off 6.1 in a few days?
> > > >>> >>
> > > >>> >
> > > >>> > Whats the status of this ?
> > > >>> > I can branch 6.1 anytime
> > > >>> >
> > > >>> > It was just that jb told me
> > > >>> > "6.1 opportunity is gone.
> > > >>> >  We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"
> > > >>> >
> > > >>> > but now i see on IRC
> > > >>> > <Lynne> make a damn release already
> > > >>> > <durandal_1707> j-b: drop MiNi from release maintership and nominate Lynne
> > > >>> > <Lynne> I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release!
> > > >>> > <j-b> durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release.
> > > >>> >
> > > >>> > noone mentioned 5.1.x and 6.0.x to me before
> > > >>> >
> > > >>> > anyway, ill try to make releases from all maintained branches,
> > > >>> >
> > > >>> > and will branch 6.1 as soon as Lynne or others say everything is ready.
> > > >>> >
> > > >>> > thx
> > > >>> >
> > > >>>
> > > >>> It's never too late to make a release. If we do a release now, nothing's stopping
> > > >>> us from doing a 7.0 and getting back on track with releases every two months or so,
> > > >>> like the plan was.
> > > >>>
> > > >>> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec,
> > > >>> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to
> > > >>> have a release before all this lands.
> > > >>>
> > > >>> I think the tree is in a pretty good state ATM, you should go ahead and branch if you're
> > > >>> comfortable with it as well.
> > > >>>
> > > >>
> > > >> branch made
> > > >>
> > > >
> > > > Thanks. I'll get a blog post ready for the transform work, as kierank wanted to post something,
> > > > and if users can know to who to point fingers to in case it degrades performance on RPI1 devices.
> > > >
> > > >
> > > >>> Let's aim for a release by Sunday next week. That should give everyone enough time to
> > > >>> backport fixes they want in.
> > > >>>
> > > >>
> > > >> I would aim for 1-3 weeks (when code and developers are ready)
> > > >> dont want to aim for a specific day, better pick a day when everything is fine
> > > >> not too many distractions, ...
> > > >>
> > > >> Or is there something that favors us to be before a specific date ?
> > > >>
> > > >
> > > > Not really a reason, Sunday is just an optimistic date to aim for.
> > > > If there are no big fixes to backport to the branch, I think we can target it.
> > > >
> > >
> > > The nlmeans_vulkan patch I just sent is the last patch I'd like to have in 6.1.
> > > Does anyone else have any patches they would like in 6.1?
> >
> > I was going to request Steven Liu's enhanced RTMP set but it looks
> > like those are already in the release/6.1 branch, so cheers.
> :-) Thanks ttmath
s/ttmath/tmatth/g
> >
> > -t
>
> Thanks
> Steven
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Lynne]

Nov 7, 2023, 08:36 by dev@lynne.ee:

> Oct 29, 2023, 06:57 by dev@lynne.ee:
>
>> Oct 29, 2023, 05:51 by michael@niedermayer.cc:
>>
>>> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote:
>>>
>>>> Oct 28, 2023, 18:49 by michael@niedermayer.cc:
>>>>
>>>> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
>>>> >
>>>> >> It's been a while since we've had a release, and we've had
>>>> >> a lot of new features in.
>>>> >> We did say we would make releases more often, and I think
>>>> >> it's about time we have a new release.
>>>> >>
>>>> >> Anything anyone wants to have merged or should we branch
>>>> >> off 6.1 in a few days?
>>>> >>
>>>> >
>>>> > Whats the status of this ?
>>>> > I can branch 6.1 anytime
>>>> >
>>>> > It was just that jb told me
>>>> > "6.1 opportunity is gone.
>>>> >  We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"
>>>> >
>>>> > but now i see on IRC
>>>> > <Lynne> make a damn release already
>>>> > <durandal_1707> j-b: drop MiNi from release maintership and nominate Lynne
>>>> > <Lynne> I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release!
>>>> > <j-b> durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release.
>>>> >
>>>> > noone mentioned 5.1.x and 6.0.x to me before
>>>> >
>>>> > anyway, ill try to make releases from all maintained branches,
>>>> >
>>>> > and will branch 6.1 as soon as Lynne or others say everything is ready.
>>>> >
>>>> > thx
>>>> >
>>>>
>>>> It's never too late to make a release. If we do a release now, nothing's stopping
>>>> us from doing a 7.0 and getting back on track with releases every two months or so,
>>>> like the plan was.
>>>>
>>>> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec,
>>>> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to
>>>> have a release before all this lands.
>>>>
>>>> I think the tree is in a pretty good state ATM, you should go ahead and branch if you're
>>>> comfortable with it as well.
>>>>
>>>
>>> branch made
>>>
>>
>> Thanks. I'll get a blog post ready for the transform work, as kierank wanted to post something,
>> and if users can know to who to point fingers to in case it degrades performance on RPI1 devices.
>>
>>
>>>> Let's aim for a release by Sunday next week. That should give everyone enough time to
>>>> backport fixes they want in.
>>>>
>>>
>>> I would aim for 1-3 weeks (when code and developers are ready)
>>> dont want to aim for a specific day, better pick a day when everything is fine
>>> not too many distractions, ...
>>>
>>> Or is there something that favors us to be before a specific date ?
>>>
>>
>> Not really a reason, Sunday is just an optimistic date to aim for.
>> If there are no big fixes to backport to the branch, I think we can target it.
>>
>
> The nlmeans_vulkan patch I just sent is the last patch I'd like to have in 6.1.
> Does anyone else have any patches they would like in 6.1?
>

Pushed the 2 patches.

Michael, do you think you can tag the release late tonight?
No one has said anything yet.
I'll write release notes for the website by then as well.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[epirat07]

On 9 Nov 2023, at 9:20, Lynne wrote:

> Nov 7, 2023, 08:36 by dev@lynne.ee:
>
>> Oct 29, 2023, 06:57 by dev@lynne.ee:
>>
>>> Oct 29, 2023, 05:51 by michael@niedermayer.cc:
>>>
>>>> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote:
>>>>
>>>>> Oct 28, 2023, 18:49 by michael@niedermayer.cc:
>>>>>
>>>>>> On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
>>>>>>
>>>>>>> It's been a while since we've had a release, and we've had
>>>>>>> a lot of new features in.
>>>>>>> We did say we would make releases more often, and I think
>>>>>>> it's about time we have a new release.
>>>>>>>
>>>>>>> Anything anyone wants to have merged or should we branch
>>>>>>> off 6.1 in a few days?
>>>>>>>
>>>>>>
>>>>>> Whats the status of this ?
>>>>>> I can branch 6.1 anytime
>>>>>>
>>>>>> It was just that jb told me
>>>>>> "6.1 opportunity is gone.
>>>>>>  We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"
>>>>>>
>>>>>> but now i see on IRC
>>>>>> <Lynne> make a damn release already
>>>>>> <durandal_1707> j-b: drop MiNi from release maintership and nominate Lynne
>>>>>> <Lynne> I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release!
>>>>>> <j-b> durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release.
>>>>>>
>>>>>> noone mentioned 5.1.x and 6.0.x to me before
>>>>>>
>>>>>> anyway, ill try to make releases from all maintained branches,
>>>>>>
>>>>>> and will branch 6.1 as soon as Lynne or others say everything is ready.
>>>>>>
>>>>>> thx
>>>>>>
>>>>>
>>>>> It's never too late to make a release. If we do a release now, nothing's stopping
>>>>> us from doing a 7.0 and getting back on track with releases every two months or so,
>>>>> like the plan was.
>>>>>
>>>>> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec,
>>>>> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to
>>>>> have a release before all this lands.
>>>>>
>>>>> I think the tree is in a pretty good state ATM, you should go ahead and branch if you're
>>>>> comfortable with it as well.
>>>>>
>>>>
>>>> branch made
>>>>
>>>
>>> Thanks. I'll get a blog post ready for the transform work, as kierank wanted to post something,
>>> and if users can know to who to point fingers to in case it degrades performance on RPI1 devices.
>>>
>>>
>>>>> Let's aim for a release by Sunday next week. That should give everyone enough time to
>>>>> backport fixes they want in.
>>>>>
>>>>
>>>> I would aim for 1-3 weeks (when code and developers are ready)
>>>> dont want to aim for a specific day, better pick a day when everything is fine
>>>> not too many distractions, ...
>>>>
>>>> Or is there something that favors us to be before a specific date ?
>>>>
>>>
>>> Not really a reason, Sunday is just an optimistic date to aim for.
>>> If there are no big fixes to backport to the branch, I think we can target it.
>>>
>>
>> The nlmeans_vulkan patch I just sent is the last patch I'd like to have in 6.1.
>> Does anyone else have any patches they would like in 6.1?

If 6.1 will be cut from master, my tpad fix I sent yesterday should probably be applied first
to prevent having a release with broken tpad.

>>
>
> Pushed the 2 patches.
>
> Michael, do you think you can tag the release late tonight?
> No one has said anything yet.
> I'll write release notes for the website by then as well.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Gyan Doshi]

On 2023-11-09 03:16 pm, epirat07@gmail.com wrote:
> If 6.1 will be cut from master, my tpad fix I sent yesterday should probably be applied first
> to prevent having a release with broken tpad.

The branch is already cut. Will need to be cherry-picked.

Regards,
Gyan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3809 bytes --]

On Thu, Nov 09, 2023 at 09:20:33AM +0100, Lynne wrote:
> Nov 7, 2023, 08:36 by dev@lynne.ee:
> 
> > Oct 29, 2023, 06:57 by dev@lynne.ee:
> >
> >> Oct 29, 2023, 05:51 by michael@niedermayer.cc:
> >>
> >>> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote:
> >>>
> >>>> Oct 28, 2023, 18:49 by michael@niedermayer.cc:
> >>>>
> >>>> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote:
> >>>> >
> >>>> >> It's been a while since we've had a release, and we've had
> >>>> >> a lot of new features in.
> >>>> >> We did say we would make releases more often, and I think
> >>>> >> it's about time we have a new release.
> >>>> >>
> >>>> >> Anything anyone wants to have merged or should we branch
> >>>> >> off 6.1 in a few days?
> >>>> >>
> >>>> >
> >>>> > Whats the status of this ?
> >>>> > I can branch 6.1 anytime
> >>>> >
> >>>> > It was just that jb told me
> >>>> > "6.1 opportunity is gone.
> >>>> >  We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"
> >>>> >
> >>>> > but now i see on IRC
> >>>> > <Lynne> make a damn release already
> >>>> > <durandal_1707> j-b: drop MiNi from release maintership and nominate Lynne
> >>>> > <Lynne> I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release!
> >>>> > <j-b> durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release.
> >>>> >
> >>>> > noone mentioned 5.1.x and 6.0.x to me before
> >>>> >
> >>>> > anyway, ill try to make releases from all maintained branches,
> >>>> >
> >>>> > and will branch 6.1 as soon as Lynne or others say everything is ready.
> >>>> >
> >>>> > thx
> >>>> >
> >>>>
> >>>> It's never too late to make a release. If we do a release now, nothing's stopping
> >>>> us from doing a 7.0 and getting back on track with releases every two months or so,
> >>>> like the plan was.
> >>>>
> >>>> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec,
> >>>> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to
> >>>> have a release before all this lands.
> >>>>
> >>>> I think the tree is in a pretty good state ATM, you should go ahead and branch if you're
> >>>> comfortable with it as well.
> >>>>
> >>>
> >>> branch made
> >>>
> >>
> >> Thanks. I'll get a blog post ready for the transform work, as kierank wanted to post something,
> >> and if users can know to who to point fingers to in case it degrades performance on RPI1 devices.
> >>
> >>
> >>>> Let's aim for a release by Sunday next week. That should give everyone enough time to
> >>>> backport fixes they want in.
> >>>>
> >>>
> >>> I would aim for 1-3 weeks (when code and developers are ready)
> >>> dont want to aim for a specific day, better pick a day when everything is fine
> >>> not too many distractions, ...
> >>>
> >>> Or is there something that favors us to be before a specific date ?
> >>>
> >>
> >> Not really a reason, Sunday is just an optimistic date to aim for.
> >> If there are no big fixes to backport to the branch, I think we can target it.
> >>
> >
> > The nlmeans_vulkan patch I just sent is the last patch I'd like to have in 6.1.
> > Does anyone else have any patches they would like in 6.1?
> >
> 
> Pushed the 2 patches.
> 
> Michael, do you think you can tag the release late tonight?
> No one has said anything yet.
> I'll write release notes for the website by then as well.

ill try to make the release tomorrow
if i do it now before going to bed likely something will go wrong

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 179 bytes --]

Michael Niedermayer (12023-10-28):
> It was just that jb told me
> "6.1 opportunity is gone.

Unsubstantiated opinion, let us ignore it.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Jean-Baptiste Kempf]

On Sun, 29 Oct 2023, at 10:30, Nicolas George wrote:
> Michael Niedermayer (12023-10-28):
>> It was just that jb told me
>> "6.1 opportunity is gone.
>
> Unsubstantiated opinion, let us ignore it.

Not like your opinions that are always substantiated...

Except I explain many times why the opportunity has passed for 6.1, but you, once again, don't listen, or refuse to be on the means where we discuss.

Again, a personal attack, from you.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 230 bytes --]

Jean-Baptiste Kempf (12023-10-29):
> > Unsubstantiated opinion, let us ignore it.
> Again, a personal attack, from you.

YOU are not an OPINION, so, no, this is not a personal attack, this is a
lie.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Jean-Baptiste Kempf]

On Sun, 29 Oct 2023, at 15:17, Nicolas George wrote:
> Jean-Baptiste Kempf (12023-10-29):
>> > Unsubstantiated opinion, let us ignore it.
>> Again, a personal attack, from you.
>
> YOU are not an OPINION, so, no, this is not a personal attack,

Because instead of doing the polite and normal thing which would be:
"jb, I did not hear your opinion, can you restate it?"
you said
"jb, I did not hear his opinion, he  should be ignored".



-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 214 bytes --]

Jean-Baptiste Kempf (12023-10-29):
> Because instead of doing the polite and normal thing which would be:

Politeness or not does not make it a personal attack. Moving goalposts
much?

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Jean-Baptiste Kempf]

On Sun, 29 Oct 2023, at 17:40, Nicolas George wrote:
> Jean-Baptiste Kempf (12023-10-29):
>> Because instead of doing the polite and normal thing which would be:
>
> Politeness or not does not make it a personal attack. Moving goalposts
> much?

Being not polite to someone is a personal attack.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

Jean-Baptiste Kempf (12023-10-29):
> Being not polite to someone is a personal attack.

No.

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Thilo Borgmann via ffmpeg-devel]

Am 29.10.23 um 14:51 schrieb Jean-Baptiste Kempf:
> On Sun, 29 Oct 2023, at 10:30, Nicolas George wrote:
>> Michael Niedermayer (12023-10-28):
>>> It was just that jb told me
>>> "6.1 opportunity is gone.
>>
>> Unsubstantiated opinion, let us ignore it.
> 
> Not like your opinions that are always substantiated...
> 
> Except I explain many times why the opportunity has passed for 6.1, but you, once again, don't listen, or refuse to be on the means where we discuss.

Where? I don't see you saying that in this thread.
If you said so at VDD, that's not many times.
Not being at where you say s.th. does not imply anything and is not an argument.


> Again, a personal attack, from you.

If you find calling your opinion unsubstantiated a personal attack, then why do 
you reply with the same personal attack?

-Thilo

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Jean-Baptiste Kempf]

On Sun, 29 Oct 2023, at 16:10, Thilo Borgmann via ffmpeg-devel wrote:
> Where? I don't see you saying that in this thread.
> If you said so at VDD, that's not many times.

Explained three times at VDD and several time on IRC.

> Not being at where you say s.th. does not imply anything and is not an argument.

Refusing to attend the developer meetups and also refusing to be on one of the major discussion media and then complaining about not receiving information is a problem in an open source community.

jb
-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Thilo Borgmann via ffmpeg-devel]

Am 29.10.23 um 17:25 schrieb Jean-Baptiste Kempf:
> On Sun, 29 Oct 2023, at 16:10, Thilo Borgmann via ffmpeg-devel wrote:
>> Where? I don't see you saying that in this thread.
>> If you said so at VDD, that's not many times.
> 
> Explained three times at VDD and several time on IRC.

Very well. Assuming with "explained" you mean that you gave your reasoning as 
well, instead of just that statement which was quoted. Because the lack of that 
is what Nicolas led to refuse your opinion.


>> Not being at where you say s.th. does not imply anything and is not an argument.
> 
> Refusing to attend the developer meetups and also refusing to be on one of the major discussion media and then complaining about not receiving information is a problem in an open source community.

Communication is the biggest problem indeed. In this case as well, I think you 
should have transported your reasoning back to this thread on the ML - you 
cannot blame anyone for not following live discussion like VDD or IRC. If you 
would have done so, your opinion could not have been waived away like Nicolas did.

-Thilo

p.s. sure, IRC is not really live, yet we expect to follow up on history only on 
the ML. Which is one reason why we say things like "as agreed on by X on IRC" in 
patch threads, for example.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Jean-Baptiste Kempf]

On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote:
> In this case as well, I think you 
> should have transported your reasoning back to this thread on the ML - 

It's actually in this very thread on the ML about the timing and prefering 7.0 over 6.1.

I even send a longer email to explain.

> cannot blame anyone for not following live discussion like VDD or IRC. 

Sorry, I can. Being on IRC is necessary, IMHO.

--  
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 508 bytes --]

Jean-Baptiste Kempf (12023-10-29):
> Sorry, I can. Being on IRC is necessary, IMHO.

Completely unacceptable and fortunately not true at all.

The mailing-list has always been the main channel of development,
anything synchronous, that requires people to be on line at the same
time, is unsuited for a project on multiple timezones where everybody is
equal but nobody has an obligation. And I think it is very bad that some
body with apparent authority suggests otherwise.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Jean-Baptiste Kempf]

On Sun, 29 Oct 2023, at 19:12, Nicolas George wrote:
> Jean-Baptiste Kempf (12023-10-29):
>> Sorry, I can. Being on IRC is necessary, IMHO.
>
> Completely unacceptable and fortunately not true at all.

We'll have to agree to disagree.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 226 bytes --]

Jean-Baptiste Kempf (12023-10-29):
> We'll have to agree to disagree.

So you disagree that ffmpeg is not a corporate project where developers
can be forced to have fixed work hours. Interesting.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Jean-Baptiste Kempf]

On Sun, 29 Oct 2023, at 19:31, Nicolas George wrote:
> Jean-Baptiste Kempf (12023-10-29):
>> We'll have to agree to disagree.
>
> So you disagree that ffmpeg is not a corporate project where developers
> can be forced to have fixed work hours. Interesting.

IRC has logs and many people having fixed work hours are on IRC.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 322 bytes --]

Jean-Baptiste Kempf (12023-10-29):
> IRC has logs

That are good to know what has been said, not for participating in the
decision making. Therefore IRC is unacceptable for making decisions.

> and many people having fixed work hours are on IRC.

The problem is the people who cannot be.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Thilo Borgmann via ffmpeg-devel]

Am 29.10.23 um 19:12 schrieb Nicolas George:
> Jean-Baptiste Kempf (12023-10-29):
>> Sorry, I can. Being on IRC is necessary, IMHO.
> 
> Completely unacceptable and fortunately not true at all.
> 
> The mailing-list has always been the main channel of development,
> anything synchronous, that requires people to be on line at the same
> time, is unsuited for a project on multiple timezones where everybody is
> equal but nobody has an obligation. And I think it is very bad that some
> body with apparent authority suggests otherwise.

+1

-Thilo

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Thilo Borgmann via ffmpeg-devel]

Am 29.10.23 um 18:56 schrieb Jean-Baptiste Kempf:
> On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote:
>> In this case as well, I think you
>> should have transported your reasoning back to this thread on the ML -
> 
> It's actually in this very thread on the ML about the timing and prefering 7.0 over 6.1.
> 
> I even send a longer email to explain.

I wonder why you didn't say that one iteration back when I asked you where to 
find it. (Your answer was "at VDD & on IRC", just not to delete too much history 
here.)

Anyway, in this very thread (and in the Release 6.1 thread started from Michael 
before this thread of Lynne) I can see exactly 3 prior mails from you.

06.07.23, "good idea lets do 6.1"
26.09.23, "calling people liars is bad"
21.09.23, "+1"

As well as the many mails from today, of course.

So is this problem on my mail client end?
Can you provide links into the archives regarding the mails you are referring to?

-Thilo

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Jean-Baptiste Kempf]

On Sun, 29 Oct 2023, at 19:46, Thilo Borgmann via ffmpeg-devel wrote:
> Am 29.10.23 um 18:56 schrieb Jean-Baptiste Kempf:
>> On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote:
>>> In this case as well, I think you
>>> should have transported your reasoning back to this thread on the ML -
>> 
>> It's actually in this very thread on the ML about the timing and prefering 7.0 over 6.1.
>> 
>> I even send a longer email to explain.
>
> I wonder why you didn't say that one iteration back when I asked you 
> where to 
> find it. (Your answer was "at VDD & on IRC", just not to delete too 
> much history 
> here.)
>
> Anyway, in this very thread (and in the Release 6.1 thread started from Michael 
> before this thread of Lynne) I can see exactly 3 prior mails from you.

Mail are not just from me, but about me.

Quoting the mail that supposedly quotes me:
"6.1 opportunity is gone.
 We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"

I think it's very clear about "opportunity" and "late on the schedule" and what they mean.

You decided then it was not clear and "unsubstantiated", and therefore that my opinion had no value, so I had to expand on it.

So, I spoke about it at VDD, several time, on IRC and it refers to me on this very mailing list.

And instead of asking me to clarify, you started to say that my opinion had no value, and then attacking me.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Thilo Borgmann via ffmpeg-devel]

Am 29.10.23 um 20:27 schrieb Jean-Baptiste Kempf:
> On Sun, 29 Oct 2023, at 19:46, Thilo Borgmann via ffmpeg-devel wrote:
>> Am 29.10.23 um 18:56 schrieb Jean-Baptiste Kempf:
>>> On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote:
>>>> In this case as well, I think you
>>>> should have transported your reasoning back to this thread on the ML -
>>>
>>> It's actually in this very thread on the ML about the timing and prefering 7.0 over 6.1.
>>>
>>> I even send a longer email to explain.
>>
>> I wonder why you didn't say that one iteration back when I asked you
>> where to
>> find it. (Your answer was "at VDD & on IRC", just not to delete too
>> much history
>> here.)
>>
>> Anyway, in this very thread (and in the Release 6.1 thread started from Michael
>> before this thread of Lynne) I can see exactly 3 prior mails from you.
> 
> Mail are not just from me, but about me.
> 
> Quoting the mail that supposedly quotes me:
> "6.1 opportunity is gone.
>   We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January"
> 
> I think it's very clear about "opportunity" and "late on the schedule" and what they mean.
> 

> You decided then it was not clear and "unsubstantiated", and therefore that my opinion had no value, so I had to expand on it.

I did not.


> So, I spoke about it at VDD, several time, on IRC and it refers to me on this very mailing list.
> 
> And instead of asking me to clarify, you started to say that my opinion had no value, and then attacking me.

Asking for clarification is exactly what I did by asking you where to find your 
elaborations. You are attacking me here.

-Thilo
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Jean-Baptiste Kempf]

Hello,

On Sat, 28 Oct 2023, at 18:49, Michael Niedermayer wrote:
> noone mentioned 5.1.x and 6.0.x to me before

Our last releases from our two major bracnhes, are a 5.1.3 (which is a LTS branch) and a 6.0.0.

Both of those have not had backports and releases of all the security issues, nor on the major regressions found (if any).

Also, if they had some commits for security reasons, we should have a release at least every 90 days (3 months), because this is the standard for the security issues reporting (after that time, the security community makes them public).
And seeing the number of fuzzing fixes, this is likely important.

So, yes, I think having a 5.1.4 and 6.0.1 with the security fixes is of the utmost importance.

> It was just that jb told me
> "6.1 opportunity is gone.
>  We're too late on the schedule, and noone had time to work on it, so 
> it is wiser to target 7.0 in January"

Yes, we said we would make a new major version for January (which will slip in February, as usual :D).
So, doing a 6.1.0 now, while 7.0 is not far away, might be a lot of work and it might not worth it.
Notably since at the time of 7.0, there might be not enough new things to cut a release.

So I'm not against a release for 6.1 at all, but I believe focusing on minor releases for security and on 7.0 with the next major deprecations is more important.
If we can do all of those, and keep more or less the timing for 7.0, please be my guest  for 6.1.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[James Almer]

On 10/29/2023 1:42 PM, Jean-Baptiste Kempf wrote:
> Hello,
> 
> On Sat, 28 Oct 2023, at 18:49, Michael Niedermayer wrote:
>> noone mentioned 5.1.x and 6.0.x to me before
> 
> Our last releases from our two major bracnhes, are a 5.1.3 (which is a LTS branch) and a 6.0.0.
> 
> Both of those have not had backports and releases of all the security issues, nor on the major regressions found (if any).
> 
> Also, if they had some commits for security reasons, we should have a release at least every 90 days (3 months), because this is the standard for the security issues reporting (after that time, the security community makes them public).
> And seeing the number of fuzzing fixes, this is likely important.
> 
> So, yes, I think having a 5.1.4 and 6.0.1 with the security fixes is of the utmost importance.
> 
>> It was just that jb told me
>> "6.1 opportunity is gone.
>>   We're too late on the schedule, and noone had time to work on it, so
>> it is wiser to target 7.0 in January"
> 
> Yes, we said we would make a new major version for January (which will slip in February, as usual :D).
> So, doing a 6.1.0 now, while 7.0 is not far away, might be a lot of work and it might not worth it.
> Notably since at the time of 7.0, there might be not enough new things to cut a release.
> 
> So I'm not against a release for 6.1 at all, but I believe focusing on minor releases for security and on 7.0 with the next major deprecations is more important.
> If we can do all of those, and keep more or less the timing for 7.0, please be my guest  for 6.1.

Lynne made a list of the things that should (hopefully) make it to 7.0 
for early 2024 (E.g. YUVJ removal, D3D12 hwdec, Vulkan encode, VVC, 
IAMF) plus Anton's CLI scheduler work, not to mention it will feature a 
major version bump and all the deprecated API removal that brings. So 
even with not a lot of things, the few it will get in these few months 
will be pretty big and appealing.

6.1 doesn't need to be supported for too long, but it's a good release 
to have as it will feature a year worth of development while being 6.0 
ABI compatible, for those distros that care.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] Release 6.1

[Jean-Baptiste Kempf]

On Sun, 29 Oct 2023, at 17:49, James Almer wrote:
> On 10/29/2023 1:42 PM, Jean-Baptiste Kempf wrote:
>> Hello,
>> 
>> On Sat, 28 Oct 2023, at 18:49, Michael Niedermayer wrote:
>>> noone mentioned 5.1.x and 6.0.x to me before
>> 
>> Our last releases from our two major bracnhes, are a 5.1.3 (which is a LTS branch) and a 6.0.0.
>> 
>> Both of those have not had backports and releases of all the security issues, nor on the major regressions found (if any).
>> 
>> Also, if they had some commits for security reasons, we should have a release at least every 90 days (3 months), because this is the standard for the security issues reporting (after that time, the security community makes them public).
>> And seeing the number of fuzzing fixes, this is likely important.
>> 
>> So, yes, I think having a 5.1.4 and 6.0.1 with the security fixes is of the utmost importance.
>> 
>>> It was just that jb told me
>>> "6.1 opportunity is gone.
>>>   We're too late on the schedule, and noone had time to work on it, so
>>> it is wiser to target 7.0 in January"
>> 
>> Yes, we said we would make a new major version for January (which will slip in February, as usual :D).
>> So, doing a 6.1.0 now, while 7.0 is not far away, might be a lot of work and it might not worth it.
>> Notably since at the time of 7.0, there might be not enough new things to cut a release.
>> 
>> So I'm not against a release for 6.1 at all, but I believe focusing on minor releases for security and on 7.0 with the next major deprecations is more important.
>> If we can do all of those, and keep more or less the timing for 7.0, please be my guest  for 6.1.
>
> Lynne made a list of the things that should (hopefully) make it to 7.0 
> for early 2024 (E.g. YUVJ removal, D3D12 hwdec, Vulkan encode, VVC, 
> IAMF) plus Anton's CLI scheduler work, not to mention it will feature a 
> major version bump and all the deprecated API removal that brings. So 
> even with not a lot of things, the few it will get in these few months 
> will be pretty big and appealing.
>
> 6.1 doesn't need to be supported for too long, but it's a good release 
> to have as it will feature a year worth of development while being 6.0 
> ABI compatible, for those distros that care.

Excellent then.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".