[FFmpeg-devel] FFmpeg release 6.1

[FFmpeg-devel] FFmpeg release 6.1

[Michael Niedermayer]

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

Hi all

There was the request to make a 6.1 before end of April
Is that still so ?

Assuming it is, its time to make that branch and release soon

Thx
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Nations do behave wisely once they have exhausted all other alternatives. 
-- Abba Eban

[-- 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] FFmpeg release 6.1

[James Almer]

On 4/10/2023 7:14 PM, Michael Niedermayer wrote:
> Hi all
> 
> There was the request to make a 6.1 before end of April
> Is that still so ?
> 
> Assuming it is, its time to make that branch and release soon
> 
> Thx

The Changelog looks awfully short...
_______________________________________________
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] FFmpeg release 6.1

[Neal Gompa]

On Mon, Apr 10, 2023 at 6:14 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> Hi all
>
> There was the request to make a 6.1 before end of April
> Is that still so ?
>
> Assuming it is, its time to make that branch and release soon
>

Well, I think the hope was that the Vulkan Video and AV1 VA-API
patches would have landed by now. Neither have done so yet...


-- 
真実はいつも一つ！/ 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] FFmpeg release 6.1

[Niklas Haas]

On Tue, 11 Apr 2023 00:14:28 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
> Hi all
> 
> There was the request to make a 6.1 before end of April
> Is that still so ?
> 
> Assuming it is, its time to make that branch and release soon

Hi,

It is now september. What happened to this release? FFmpeg 6.1 is
currently the only thing blocking the adoption of vulkan video.
_______________________________________________
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] FFmpeg release 6.1

[Michael Niedermayer]

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

On Tue, Sep 19, 2023 at 07:18:03PM +0200, Niklas Haas wrote:
> On Tue, 11 Apr 2023 00:14:28 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
> > Hi all
> > 
> > There was the request to make a 6.1 before end of April
> > Is that still so ?
> > 
> > Assuming it is, its time to make that branch and release soon
> 
> Hi,
> 
> It is now september. What happened to this release? FFmpeg 6.1 is
> currently the only thing blocking the adoption of vulkan video.

there are several security issues that need to be fixed
ossfuzz found more, it also put some random unlreated issues again
into the same ticket. (which are basically invissible sub-tickets)
the evc code also needs a security review, Maybe Dawid is working on this
iam not sure. And iam sure theres more
We also have a security issue in fate, i belive nicolas is looking into
that, that doesnt hold up the release but all these things compete for time
and some people you may have noticed tried to just randomly block patches
going back and forth on these and discussing with tech/community committtees
also took time.
And last but not least if people want me to design a standalone SDR library
while thats not holding up 6.1 it takes time from the pot from 6.1 work.
I did say this, i was attacked but yes time is unforgiving it doesnt care

Also I did fall behind with security fixes in the summer a bit, the weather was
nice, some members of the community where not nice. So i tried to spend some
time with the nice weather

If you want 6.1 to happen quick. be nice to me or help with anything that i
have to work on 6.1 or other so theres more time in the pot
what about merging libplacebo into FFmpeg for example ?
As far as iam concerned you can have absolute final power about anything
in that libplacebo inside FFmpeg.
Or help with the whole SDR thing. If i dont have to think about it and
can concentrate on the release and security then yes it will happen faster

I also have some paid work under NDA which i signed a contract for, i need
to work on that too. Yes code will be submitted to FFmpeg when/if its done
And theres life, i have other shit to do too. For example my taxes and i also
want to spend some time working on AI/neural nets. I guess that will not be
FFmpeg related as id like my work on AI not to be in a similar position to
where avradio is now.

So yeah, i think theres no problem with 6.1 its just not happening as quick
as I and others wanted

thx

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.

[-- 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] FFmpeg release 6.1

[Lynne]

Sep 19, 2023, 21:16 by michael@niedermayer.cc:

> On Tue, Sep 19, 2023 at 07:18:03PM +0200, Niklas Haas wrote:
>
>> On Tue, 11 Apr 2023 00:14:28 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
>> > Hi all
>> > 
>> > There was the request to make a 6.1 before end of April
>> > Is that still so ?
>> > 
>> > Assuming it is, its time to make that branch and release soon
>>
>> Hi,
>>
>> It is now september. What happened to this release? FFmpeg 6.1 is
>> currently the only thing blocking the adoption of vulkan video.
>>
>
> there are several security issues that need to be fixed
> ossfuzz found more, it also put some random unlreated issues again
> into the same ticket. (which are basically invissible sub-tickets)
> the evc code also needs a security review, Maybe Dawid is working on this
> iam not sure. And iam sure theres more
> We also have a security issue in fate, i belive nicolas is looking into
> that, that doesnt hold up the release but all these things compete for time
> and some people you may have noticed tried to just randomly block patches
> going back and forth on these and discussing with tech/community committtees
> also took time.
> And last but not least if people want me to design a standalone SDR library
> while thats not holding up 6.1 it takes time from the pot from 6.1 work.
> I did say this, i was attacked but yes time is unforgiving it doesnt care
>
> Also I did fall behind with security fixes in the summer a bit, the weather was
> nice, some members of the community where not nice. So i tried to spend some
> time with the nice weather
>
> If you want 6.1 to happen quick. be nice to me or help with anything that i
> have to work on 6.1 or other so theres more time in the pot
> what about merging libplacebo into FFmpeg for example ?
> As far as iam concerned you can have absolute final power about anything
> in that libplacebo inside FFmpeg.
> Or help with the whole SDR thing. If i dont have to think about it and
> can concentrate on the release and security then yes it will happen faster
>
> I also have some paid work under NDA which i signed a contract for, i need
> to work on that too. Yes code will be submitted to FFmpeg when/if its done
> And theres life, i have other shit to do too. For example my taxes and i also
> want to spend some time working on AI/neural nets. I guess that will not be
> FFmpeg related as id like my work on AI not to be in a similar position to
> where avradio is now.
>
> So yeah, i think theres no problem with 6.1 its just not happening as quick
> as I and others wanted
>
> thx
>
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you think the mosad wants you dead since a long time then you are either
> wrong or dead since a long time.
>

I'm not sure it's a good idea to wait to merge the EVC decoder.
Perhaps we should move that to the next release.

I'd like to get my AAC padding/duration fixes in, and drop lavc's
old FFT code entirely.
_______________________________________________
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] FFmpeg release 6.1

[Neal Gompa]

On Tue, Sep 19, 2023 at 5:58 PM Lynne <dev@lynne.ee> wrote:
>
> Sep 19, 2023, 21:16 by michael@niedermayer.cc:
>
> > On Tue, Sep 19, 2023 at 07:18:03PM +0200, Niklas Haas wrote:
> >
> >> On Tue, 11 Apr 2023 00:14:28 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
> >> > Hi all
> >> >
> >> > There was the request to make a 6.1 before end of April
> >> > Is that still so ?
> >> >
> >> > Assuming it is, its time to make that branch and release soon
> >>
> >> Hi,
> >>
> >> It is now september. What happened to this release? FFmpeg 6.1 is
> >> currently the only thing blocking the adoption of vulkan video.
> >>
> >
> > there are several security issues that need to be fixed
> > ossfuzz found more, it also put some random unlreated issues again
> > into the same ticket. (which are basically invissible sub-tickets)
> > the evc code also needs a security review, Maybe Dawid is working on this
> > iam not sure. And iam sure theres more
> > We also have a security issue in fate, i belive nicolas is looking into
> > that, that doesnt hold up the release but all these things compete for time
> > and some people you may have noticed tried to just randomly block patches
> > going back and forth on these and discussing with tech/community committtees
> > also took time.
> > And last but not least if people want me to design a standalone SDR library
> > while thats not holding up 6.1 it takes time from the pot from 6.1 work.
> > I did say this, i was attacked but yes time is unforgiving it doesnt care
> >
> > Also I did fall behind with security fixes in the summer a bit, the weather was
> > nice, some members of the community where not nice. So i tried to spend some
> > time with the nice weather
> >
> > If you want 6.1 to happen quick. be nice to me or help with anything that i
> > have to work on 6.1 or other so theres more time in the pot
> > what about merging libplacebo into FFmpeg for example ?
> > As far as iam concerned you can have absolute final power about anything
> > in that libplacebo inside FFmpeg.
> > Or help with the whole SDR thing. If i dont have to think about it and
> > can concentrate on the release and security then yes it will happen faster
> >
> > I also have some paid work under NDA which i signed a contract for, i need
> > to work on that too. Yes code will be submitted to FFmpeg when/if its done
> > And theres life, i have other shit to do too. For example my taxes and i also
> > want to spend some time working on AI/neural nets. I guess that will not be
> > FFmpeg related as id like my work on AI not to be in a similar position to
> > where avradio is now.
> >
> > So yeah, i think theres no problem with 6.1 its just not happening as quick
> > as I and others wanted
> >
> > thx
> >
> > [...]
> > --
> > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > If you think the mosad wants you dead since a long time then you are either
> > wrong or dead since a long time.
> >
>
> I'm not sure it's a good idea to wait to merge the EVC decoder.
> Perhaps we should move that to the next release.
>
> I'd like to get my AAC padding/duration fixes in, and drop lavc's
> old FFT code entirely.

From my wishlist, the only thing left unmerged is AV1 VA-API encode
support. The patchset is on v5 now and seems to be fine? I can't test
it due to lack of compatible hardware, so if someone here does have
something and can do it, it'd be great to see it get reviewed and
landed.



-- 
真実はいつも一つ！/ 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] FFmpeg release 6.1

[Xiang, Haihao]

On Di, 2023-09-19 at 20:38 -0400, Neal Gompa wrote:
> On Tue, Sep 19, 2023 at 5:58 PM Lynne <dev@lynne.ee> wrote:
> > 
> > Sep 19, 2023, 21:16 by michael@niedermayer.cc:
> > 
> > > On Tue, Sep 19, 2023 at 07:18:03PM +0200, Niklas Haas wrote:
> > > 
> > > > On Tue, 11 Apr 2023 00:14:28 +0200 Michael Niedermayer
> > > > <michael@niedermayer.cc> wrote:
> > > > > Hi all
> > > > > 
> > > > > There was the request to make a 6.1 before end of April
> > > > > Is that still so ?
> > > > > 
> > > > > Assuming it is, its time to make that branch and release soon
> > > > 
> > > > Hi,
> > > > 
> > > > It is now september. What happened to this release? FFmpeg 6.1 is
> > > > currently the only thing blocking the adoption of vulkan video.
> > > > 
> > > 
> > > there are several security issues that need to be fixed
> > > ossfuzz found more, it also put some random unlreated issues again
> > > into the same ticket. (which are basically invissible sub-tickets)
> > > the evc code also needs a security review, Maybe Dawid is working on this
> > > iam not sure. And iam sure theres more
> > > We also have a security issue in fate, i belive nicolas is looking into
> > > that, that doesnt hold up the release but all these things compete for
> > > time
> > > and some people you may have noticed tried to just randomly block patches
> > > going back and forth on these and discussing with tech/community
> > > committtees
> > > also took time.
> > > And last but not least if people want me to design a standalone SDR
> > > library
> > > while thats not holding up 6.1 it takes time from the pot from 6.1 work.
> > > I did say this, i was attacked but yes time is unforgiving it doesnt care
> > > 
> > > Also I did fall behind with security fixes in the summer a bit, the
> > > weather was
> > > nice, some members of the community where not nice. So i tried to spend
> > > some
> > > time with the nice weather
> > > 
> > > If you want 6.1 to happen quick. be nice to me or help with anything that
> > > i
> > > have to work on 6.1 or other so theres more time in the pot
> > > what about merging libplacebo into FFmpeg for example ?
> > > As far as iam concerned you can have absolute final power about anything
> > > in that libplacebo inside FFmpeg.
> > > Or help with the whole SDR thing. If i dont have to think about it and
> > > can concentrate on the release and security then yes it will happen faster
> > > 
> > > I also have some paid work under NDA which i signed a contract for, i need
> > > to work on that too. Yes code will be submitted to FFmpeg when/if its done
> > > And theres life, i have other shit to do too. For example my taxes and i
> > > also
> > > want to spend some time working on AI/neural nets. I guess that will not
> > > be
> > > FFmpeg related as id like my work on AI not to be in a similar position to
> > > where avradio is now.
> > > 
> > > So yeah, i think theres no problem with 6.1 its just not happening as
> > > quick
> > > as I and others wanted
> > > 
> > > thx
> > > 
> > > [...]
> > > --
> > > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> > > 
> > > If you think the mosad wants you dead since a long time then you are
> > > either
> > > wrong or dead since a long time.
> > > 
> > 
> > I'm not sure it's a good idea to wait to merge the EVC decoder.
> > Perhaps we should move that to the next release.
> > 
> > I'd like to get my AAC padding/duration fixes in, and drop lavc's
> > old FFT code entirely.
> 
> From my wishlist, the only thing left unmerged is AV1 VA-API encode
> support. The patchset is on v5 now and seems to be fine? I can't test
> it due to lack of compatible hardware, so if someone here does have
> something and can do it, it'd be great to see it get reviewed and
> landed.

AV1 VA-API encode works well for me, I'll push it if no more comments.

BRs
Haihao

> 
> 
> 

_______________________________________________
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] FFmpeg release 6.1

[Niklas Haas]

On Tue, 19 Sep 2023 21:16:08 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
> what about merging libplacebo into FFmpeg for example ?
> As far as iam concerned you can have absolute final power about anything
> in that libplacebo inside FFmpeg.

To respond quickly to this point,

I'm not sure what merging libplacebo would improve to the status quo. As
far as I can tell, it would only make my life harder, at least if you
expect me to start caring about patches sent to the mailing list (as
opposed to using PR/MRs as I do currently).

I'm not sure what the goal would be, either, except dragging more code
into FFmpeg. Code that can easily live outside it, because the degree of
interoperation between the two is minimal. All relevant distros already
package both libplacebo and FFmpeg, so the "ease of distribution" ship
has sailed.

It would also make libplacebo releases now tied to FFmpeg releases,
which is an obvious downgrade for my own reverse dependents and a
significant downgrade to my current release process. The FFmpeg ABI
policy also seems wholly incompatible with the libplacebo ABI policy.

_______________________________________________
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] FFmpeg release 6.1

[Michael Niedermayer]

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

On Tue, Sep 19, 2023 at 11:58:41PM +0200, Lynne wrote:
> Sep 19, 2023, 21:16 by michael@niedermayer.cc:
> 
> > On Tue, Sep 19, 2023 at 07:18:03PM +0200, Niklas Haas wrote:
> >
> >> On Tue, 11 Apr 2023 00:14:28 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
> >> > Hi all
> >> > 
> >> > There was the request to make a 6.1 before end of April
> >> > Is that still so ?
> >> > 
> >> > Assuming it is, its time to make that branch and release soon
> >>
> >> Hi,
> >>
> >> It is now september. What happened to this release? FFmpeg 6.1 is
> >> currently the only thing blocking the adoption of vulkan video.
> >>
> >
> > there are several security issues that need to be fixed
> > ossfuzz found more, it also put some random unlreated issues again
> > into the same ticket. (which are basically invissible sub-tickets)
> > the evc code also needs a security review, Maybe Dawid is working on this
> > iam not sure. And iam sure theres more
> > We also have a security issue in fate, i belive nicolas is looking into
> > that, that doesnt hold up the release but all these things compete for time
> > and some people you may have noticed tried to just randomly block patches
> > going back and forth on these and discussing with tech/community committtees
> > also took time.
> > And last but not least if people want me to design a standalone SDR library
> > while thats not holding up 6.1 it takes time from the pot from 6.1 work.
> > I did say this, i was attacked but yes time is unforgiving it doesnt care
> >
> > Also I did fall behind with security fixes in the summer a bit, the weather was
> > nice, some members of the community where not nice. So i tried to spend some
> > time with the nice weather
> >
> > If you want 6.1 to happen quick. be nice to me or help with anything that i
> > have to work on 6.1 or other so theres more time in the pot
> > what about merging libplacebo into FFmpeg for example ?
> > As far as iam concerned you can have absolute final power about anything
> > in that libplacebo inside FFmpeg.
> > Or help with the whole SDR thing. If i dont have to think about it and
> > can concentrate on the release and security then yes it will happen faster
> >
> > I also have some paid work under NDA which i signed a contract for, i need
> > to work on that too. Yes code will be submitted to FFmpeg when/if its done
> > And theres life, i have other shit to do too. For example my taxes and i also
> > want to spend some time working on AI/neural nets. I guess that will not be
> > FFmpeg related as id like my work on AI not to be in a similar position to
> > where avradio is now.
> >
> > So yeah, i think theres no problem with 6.1 its just not happening as quick
> > as I and others wanted
> >
> > thx
> >
> > [...]
> > -- 
> > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > If you think the mosad wants you dead since a long time then you are either
> > wrong or dead since a long time.
> >
> 
> I'm not sure it's a good idea to wait to merge the EVC decoder.
> Perhaps we should move that to the next release.

I dont suggest merging more EVC code before the release. I meant the
EVC code already in git, is reading alot of things with no checks.
It maybe doesnt matter in most cases, as its not used in most cases without
more EVC code but still
Also ATM other things are blocking so EVC still could make it in principle.
Just that the release should not be delayed because of addition of more EVC code
But someone needs to check the existing EVC code in git without checks is safe


> 
> I'd like to get my AAC padding/duration fixes in, and drop lavc's
> old FFT code entirely.

fine

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.

[-- 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] FFmpeg release 6.1

[Kieran Kunhya]

>
> I dont suggest merging more EVC code before the release. I meant the
> EVC code already in git, is reading alot of things with no checks.
> It maybe doesnt matter in most cases, as its not used in most cases without
> more EVC code but still
> Also ATM other things are blocking so EVC still could make it in principle.
> Just that the release should not be delayed because of addition of more
> EVC code
> But someone needs to check the existing EVC code in git without checks is
> safe
>

Or just mark EVC as experimental?

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] FFmpeg release 6.1

[Michael Niedermayer]

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

On Wed, Sep 20, 2023 at 02:47:19PM +0200, Niklas Haas wrote:
> On Tue, 19 Sep 2023 21:16:08 +0200 Michael Niedermayer <michael@niedermayer.cc> wrote:
> > what about merging libplacebo into FFmpeg for example ?
> > As far as iam concerned you can have absolute final power about anything
> > in that libplacebo inside FFmpeg.
> 
> To respond quickly to this point,
> 
> I'm not sure what merging libplacebo would improve to the status quo. As

Code in libavfilter could more deeply depend on / integrate with libplacebo


> far as I can tell, it would only make my life harder, at least if you
> expect me to start caring about patches sent to the mailing list (as
> opposed to using PR/MRs as I do currently).

Well, _I_ dont mind how you manage libplacebo.


> 
> I'm not sure what the goal would be, either, except dragging more code
> into FFmpeg. Code that can easily live outside it, because the degree of
> interoperation between the two is minimal. All relevant distros already
> package both libplacebo and FFmpeg, so the "ease of distribution" ship
> has sailed.

Well the goal is to have some sort of lib that unifies swscale, libplacebo
and similar into code that provides high performance, high quality, CPU and
GPU based convertion. And this really needs to be "close" to libavfilter if
libavfilter would use it.


> 
> It would also make libplacebo releases now tied to FFmpeg releases,
> which is an obvious downgrade for my own reverse dependents and a
> significant downgrade to my current release process.

We must avoid downgrades


> The FFmpeg ABI
> policy also seems wholly incompatible with the libplacebo ABI policy.

i am not sure what the libplacebo ABI policy is

thx

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

Observe your enemies, for they first find out your faults. -- Antisthenes

[-- 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] FFmpeg release 6.1

[Michael Niedermayer]

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

On Wed, Sep 20, 2023 at 06:43:18PM +0100, Kieran Kunhya wrote:
> >
> > I dont suggest merging more EVC code before the release. I meant the
> > EVC code already in git, is reading alot of things with no checks.
> > It maybe doesnt matter in most cases, as its not used in most cases without
> > more EVC code but still
> > Also ATM other things are blocking so EVC still could make it in principle.
> > Just that the release should not be delayed because of addition of more
> > EVC code
> > But someone needs to check the existing EVC code in git without checks is
> > safe
> >
> 
> Or just mark EVC as experimental?

thats an option but even now, before we even have a experimental decoder in
git we already had a out of array write issue caused by evc code
so we still need to be carefull as not everything is under these checks

also iam not sure "experimental" is the right flag for code that has
possible security issues. People might turn experimental on not realizing
the security aspect.

thx

[...]

-- 
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] FFmpeg release 6.1

[Kieran Kunhya]

>
> also iam not sure "experimental" is the right flag for code that has
> possible security issues. People might turn experimental on not realizing
> the security aspect.
>

We should make this clear in the docs then.

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] FFmpeg release 6.1

[Jean-Baptiste Kempf]

Hello,

On Thu, 21 Sep 2023, at 00:47, Kieran Kunhya wrote:
>>
>> also iam not sure "experimental" is the right flag for code that has
>> possible security issues. People might turn experimental on not realizing
>> the security aspect.
>>
>
> We should make this clear in the docs then.

+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] FFmpeg release 6.1

[Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: wtorek, 19 września 2023 21:16
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] FFmpeg release 6.1
> 
> On Tue, Sep 19, 2023 at 07:18:03PM +0200, Niklas Haas wrote:
> > On Tue, 11 Apr 2023 00:14:28 +0200 Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> > > Hi all
> > >
> > > There was the request to make a 6.1 before end of April Is that
> > > still so ?
> > >
> > > Assuming it is, its time to make that branch and release soon
> >
> > Hi,
> >
> > It is now september. What happened to this release? FFmpeg 6.1 is
> > currently the only thing blocking the adoption of vulkan video.
> 
> there are several security issues that need to be fixed ossfuzz found
more, it also
> put some random unlreated issues again into the same ticket. (which are
> basically invissible sub-tickets) the evc code also needs a security
review, Maybe
> Dawid is working on this iam not sure. 

At the moment we are focusing on improving encoder and decoder wrapper for
EVC.
We've got in our agenda thorough review of the entire EVC related code.
We'll check it for compliance with documentation and for security. I'll deal
with it as soon.

And iam sure theres more We also have a
> security issue in fate, i belive nicolas is looking into that, that doesnt
hold up the
> release but all these things compete for time and some people you may have
> noticed tried to just randomly block patches going back and forth on these
and
> discussing with tech/community committtees also took time.
> And last but not least if people want me to design a standalone SDR
library while
> thats not holding up 6.1 it takes time from the pot from 6.1 work.
> I did say this, i was attacked but yes time is unforgiving it doesnt care
> 
> Also I did fall behind with security fixes in the summer a bit, the
weather was
> nice, some members of the community where not nice. So i tried to spend
some
> time with the nice weather
> 
> If you want 6.1 to happen quick. be nice to me or help with anything that
i have
> to work on 6.1 or other so theres more time in the pot what about merging
> libplacebo into FFmpeg for example ?
> As far as iam concerned you can have absolute final power about anything
in
> that libplacebo inside FFmpeg.
> Or help with the whole SDR thing. If i dont have to think about it and can
> concentrate on the release and security then yes it will happen faster
> 
> I also have some paid work under NDA which i signed a contract for, i need
to
> work on that too. Yes code will be submitted to FFmpeg when/if its done
And
> theres life, i have other shit to do too. For example my taxes and i also
want to
> spend some time working on AI/neural nets. I guess that will not be FFmpeg
> related as id like my work on AI not to be in a similar position to where
avradio is
> now.
> 
> So yeah, i think theres no problem with 6.1 its just not happening as
quick as I
> and others wanted
> 
> thx
> 
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> If you think the mosad wants you dead since a long time then you are
either
> wrong or dead since a long time.


_______________________________________________
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] FFmpeg release 6.1

[Michael Niedermayer]

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

On Wed, Sep 20, 2023 at 11:47:36PM +0100, Kieran Kunhya wrote:
> >
> > also iam not sure "experimental" is the right flag for code that has
> > possible security issues. People might turn experimental on not realizing
> > the security aspect.
> >
> 
> We should make this clear in the docs then.

ATM AV_CODEC_CAP_EXPERIMENTAL seems to be used mainly for "not so good" encoders
using it for potentially insecure codecs seems a semantic change.

Docs say this ATM:
 * Codec is experimental and is thus avoided in favor of non experimental
 * encoders

I dont think we can just change this to "that might allow the multimedia file author
to login to your computer"

I dont know how other see this or if iam missing something
but this may need a seperate flag

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] FFmpeg release 6.1 (SDR Plans)

[Michael Niedermayer]

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

Hi all

As the 6.1 release is upcoming and as it was previously stated by me that sdr
will be part of 6.1. Heres some update of what i intend to do about that.

People previously agreed to including a SDR input device in libavdevice with
SDR in a seperate library.

If the community and the SDR code are happy with each other before the release
then SDR will simply be merged and be part of 6.1 like any other feature.

OTOH If a majority of people are against the SDR code at the time of
branching 6.1. Then i will make a separate release identical to 6.1 with
the SDR code and of course also provide security support

Of course iam happy to change my plans if someone has a better suggestion!

What i intend to do with SDR next is AVExecutor support to improve processing
capacity with multiple threads and also to look into factoring the code so
SDR is more seperated, where this will lead to i do not know

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates

[-- 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] FFmpeg release 6.1 (SDR Plans)

[Kieran Kunhya via ffmpeg-devel]

On Thu, Sep 21, 2023 at 5:21 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
> OTOH If a majority of people are against the SDR code at the time of
> branching 6.1. Then i will make a separate release identical to 6.1 with
> the SDR code and of course also provide security support

How on earth is it acceptable that you can publish your hobby project
under the FFmpeg project name?
You are of course welcome to publish SDR in a different project that
is not FFmpeg.

I have been working on BIOS code recently but I haven't decided to
create FFBIOS and put it in the main FFmpeg repo.

Regards,
Kieran Kunhya
_______________________________________________
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] FFmpeg release 6.1 (SDR Plans)

[Paul B Mahol]

On Thu, Sep 21, 2023 at 6:21 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> Hi all
>
> As the 6.1 release is upcoming and as it was previously stated by me that
> sdr
> will be part of 6.1. Heres some update of what i intend to do about that.
>

Very bold claim.


>
> People previously agreed to including a SDR input device in libavdevice
> with
> SDR in a seperate library.
>
> If the community and the SDR code are happy with each other before the
> release
> then SDR will simply be merged and be part of 6.1 like any other feature.
>
> OTOH If a majority of people are against the SDR code at the time of
> branching 6.1. Then i will make a separate release identical to 6.1 with
> the SDR code and of course also provide security support
>

Very bold claim, there should be real voting otherwise its just your word
against mine.


>
> Of course iam happy to change my plans if someone has a better suggestion!
>

I can't and do not want to force you to work on something else. Its your
motivation and decision.


>
> What i intend to do with SDR next is AVExecutor support to improve
> processing
> capacity with multiple threads and also to look into factoring the code so
> SDR is more seperated, where this will lead to i do not know
>

Working on SDR inside FFmpeg or part of FFmpeg is wasting resources on
technology that is basically already solved problem,


>
> thx
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
> _______________________________________________
> 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] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

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

Kieran Kunhya via ffmpeg-devel (12023-09-21):
> How on earth is it acceptable that you can publish your hobby project
> under the FFmpeg project name?

How on earth is it acceptable that you continue bikeshedding a feature
that some users have been enthusiastically waiting for?

> I have been working on BIOS code recently

If it brings useful features in a way that integrate gracefully in
FFmpeg, then great! Send the patches then. 

-- 
  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] FFmpeg release 6.1 (SDR Plans)

[Vittorio Giovara]

On Thu, Sep 21, 2023 at 1:16 PM Nicolas George <george@nsup.org> wrote:

> Kieran Kunhya via ffmpeg-devel (12023-09-21):
> > How on earth is it acceptable that you can publish your hobby project
> > under the FFmpeg project name?
>
> How on earth is it acceptable that you continue bikeshedding a feature
> that some users have been enthusiastically waiting for?
>

Because it adds maintenance burden and it's out of scope with the proejct


> > I have been working on BIOS code recently
>
> If it brings useful features in a way that integrate gracefully in
> FFmpeg, then great! Send the patches then.


No thanks, feature creep is a bad mojo.


At any rate for the topic at hand, in my opinion there shouldn't be two
separate releases, either there is one with SDR or there is one without,
not both.
I actually thought the majority of the developer community was against
including this feature and I thought it was already removed.
-- 
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] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

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

Vittorio Giovara (12023-09-21):
> Because it adds maintenance burden and it's out of scope with the proejct

The feature is isolated, so that is a lie.

> No thanks, feature creep is a bad mojo.

“Creep” is your opinion, the opinion of somebody who we never see on
users mailing lists by the way.

> At any rate for the topic at hand, in my opinion there shouldn't be two
> separate releases, either there is one with SDR or there is one without,
> not both.
> I actually thought the majority of the developer community was against
> including this feature and I thought it was already removed.

There is a clear majority of the developer community who do the work.

-- 
  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] FFmpeg release 6.1 (SDR Plans)

[Vittorio Giovara]

On Thu, Sep 21, 2023 at 2:19 PM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12023-09-21):
> > Because it adds maintenance burden and it's out of scope with the proejct
>
> The feature is isolated, so that is a lie.
>

Good, if it's so isolated it can be moved to a separate library and we're
arguing over nothing.


> > No thanks, feature creep is a bad mojo.
>
> “Creep” is your opinion, the opinion of somebody who we never see on
> users mailing lists by the way.
>

Will you stop with this accusatory tone in _every_ _single_ _email_ you
send?
Meeting a threshold of emails is not a good measure of the validity of any
claim.


> > At any rate for the topic at hand, in my opinion there shouldn't be two
> > separate releases, either there is one with SDR or there is one without,
> > not both.
> > I actually thought the majority of the developer community was against
> > including this feature and I thought it was already removed.
>
> There is a clear majority of the developer community who do the work.
>

Yes, and it agrees with its removal.
-- 
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] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

Vittorio Giovara (12023-09-21):
> Good, if it's so isolated it can be moved to a separate library and we're
> arguing over nothing.

Wasting Michael's time for the maintenance and users' time for
installing it in the process. That is a completely stupid idea.

> Will you stop with this accusatory tone in _every_ _single_ _email_ you
> send?
> Meeting a threshold of emails is not a good measure of the validity of any
> claim.

What?

> Yes, and it agrees with its removal.

Not if you count correctly.

-- 
  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] FFmpeg release 6.1 (SDR Plans)

[Vittorio Giovara]

On Thu, Sep 21, 2023 at 2:51 PM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12023-09-21):
> > Good, if it's so isolated it can be moved to a separate library and we're
> > arguing over nothing.
>
> Wasting Michael's time for the maintenance and users' time for
> installing it in the process. That is a completely stupid idea.
>

What about other developers' time for maintenance?
And for users installing a library nowadays is a one liner, not really a
big deal


> > Will you stop with this accusatory tone in _every_ _single_ _email_ you
> > send?
> > Meeting a threshold of emails is not a good measure of the validity of
> any
> > claim.
>
> What?
>

What?

> Yes, and it agrees with its removal.
>
> Not if you count correctly.
>

As someone wiser than me said, People can come up with statistics to prove
anything
<https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwj8mJ-FsLyBAxVShYkEHZr9B-sQwqsBegQICRAF&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D7tzfl1wTemM&usg=AOvVaw3R4pSNbU-TvVTTJngxzrgp&opi=89978449>
!
-- 
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] FFmpeg release 6.1 (SDR Plans)

[Michael Niedermayer]

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

Hi

On Thu, Sep 21, 2023 at 05:33:54PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> On Thu, Sep 21, 2023 at 5:21 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> > OTOH If a majority of people are against the SDR code at the time of
> > branching 6.1. Then i will make a separate release identical to 6.1 with
> > the SDR code and of course also provide security support
> 
> How on earth is it acceptable that you can publish your hobby project
> under the FFmpeg project name?

How on earth is this defamation acceptable?
In fact iam not even sure what you talk about.
FFmpeg is not a propriatery licensed project

It seems to me you are trying to rally your followers against me, with
these attacks, thats really lame IMHO
If you have real arguments, you can state them without these attacks


> You are of course welcome to publish SDR in a different project that
> is not FFmpeg.

> 
> I have been working on BIOS code recently but I haven't decided to
> create FFBIOS and put it in the main FFmpeg repo.

because doing so would make no sense, BIOS is unrelated to FFmpeg and
multimedia
But if you do, noone would attack you like you do, we would just
have a normal discussion about why you think this makes sense, and
i think you dont think that makes sense so we would agree that BIOS
doesnt belong in FFmpeg

If OTOH you would create something related, you could name it FFmpeg-<whatever>
nothing wrong here, other people do it to, github has 26300 hits for FFmpeg

If its something that has users, maintained, ... but is not accepted in
main FFmpeg. Sure we can list it on our download page too.

thx

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

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."

[-- 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] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

Vittorio Giovara (12023-09-21):
> What about other developers' time for maintenance?

Yes, what about it?

How much time did YOU spend maintaining libavfilter or libavdevice?
Zero.

How much time will you spend maintaining SDR? Zero.

What does it change for you and everybody who thinks like you? NOTHING.

Michael wants to invest his time in a features that integrates
beautifully in FFmpeg and that some users are glad to expect. That is a
good thing.

People who are not interested in it but have no practical arguments
against it have absolutely no right to oppose or put so much roadblock
it becomes discouraging just because they would like it better if
Michael spent his time on things that they find useful rather than
things that he finds fun.

> And for users installing a library nowadays is a one liner, not really a
> big deal

Only if it is packaged by a distribution. I am guessing you are not
volunteering to package it yourself, so you are again proposing to waste
somebody else's time.

-- 
  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] FFmpeg release 6.1 (SDR Plans)

[Paul B Mahol]

On Thu, Sep 21, 2023 at 9:05 PM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12023-09-21):
> > What about other developers' time for maintenance?
>
> Yes, what about it?
>
> How much time did YOU spend maintaining libavfilter or libavdevice?
> Zero.
>
> How much time will you spend maintaining SDR? Zero.
>
> What does it change for you and everybody who thinks like you? NOTHING.
>
> Michael wants to invest his time in a features that integrates
> beautifully in FFmpeg and that some users are glad to expect. That is a
> good thing.
>
> People who are not interested in it but have no practical arguments
> against it have absolutely no right to oppose or put so much roadblock
> it becomes discouraging just because they would like it better if
> Michael spent his time on things that they find useful rather than
> things that he finds fun.
>
> > And for users installing a library nowadays is a one liner, not really a
> > big deal
>
> Only if it is packaged by a distribution. I am guessing you are not
> volunteering to package it yourself, so you are again proposing to waste
> somebody else's time.
>

If this SDR troll code ever get committed in FFmpeg libraries I will
immediately leave project.


>
> --
>   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] FFmpeg release 6.1 (SDR Plans)

[Vittorio Giovara]

On Thu, Sep 21, 2023 at 3:05 PM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12023-09-21):
> > What about other developers' time for maintenance?
>
> Yes, what about it?
>
> How much time did YOU spend maintaining libavfilter or libavdevice?
> Zero.
>
> How much time will you spend maintaining SDR? Zero.
>
> What does it change for you and everybody who thinks like you? NOTHING.
>
> Michael wants to invest his time in a features that integrates
> beautifully in FFmpeg and that some users are glad to expect. That is a
> good thing.
>
> People who are not interested in it but have no practical arguments
> against it have absolutely no right to oppose or put so much roadblock
> it becomes discouraging just because they would like it better if
> Michael spent his time on things that they find useful rather than
> things that he finds fun.
>
> > And for users installing a library nowadays is a one liner, not really a
> > big deal
>
> Only if it is packaged by a distribution. I am guessing you are not
> volunteering to package it yourself, so you are again proposing to waste
> somebody else's time.
>

So this is an example of accusatory tone - discrediting the previous author
in order to make your arguments have more weight. It's a bad move and
easily spottable, you should argue with better elements at your disposal,
not by claiming that I don't package software or don't contribute to
libavfilter. Really, have you thought how many contributors have we lost
only because of the tone (and length) of your emails? You said you stopped
contributing patches because you don't like the development environment,
but maybe you should consider stopping sending emails too, just as a
friendly advice.

I will stop replying to any further baseless accusation, and going back on
topic, regardless who wrote what or how many users are requesting it, my
opinion on this release still stands: either a release with everything or a
release without the contentious piece of code, but not both. It's confusing
to the end users, and shows lack of direction of the project. End of
transmission.
-- 
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] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

Vittorio Giovara (12023-09-21):
> So this is an example of accusatory tone - discrediting the previous author
> in order to make your arguments have more weight. It's a bad move and
> easily spottable, you should argue with better elements at your disposal,
> not by claiming that I don't package software or don't contribute to
> libavfilter.

You are misunderstanding my point completely, I am not accusing you of
anything, I am merely using you as an example to show how your argument
is flawed.

I can take myself as an example instead, if you like it better:

How much did *I* contribute to hardware acceleration? Zero!

How much did *I* contribute to assembly optimization? Zero!

How much do *I* intend to contribute to hardware acceleration? Zero!

But now, however much I would like to, especially in libavfilter, I
refrain from objecting to new features of hardware acceleration.

Because I can make the difference between the things that benefit me and
the things that are useful to many users and therefore good for the
project.

FFmpeg is made a of a lot of parts that are often very independent. That
is on purpose: that way, if somebody is not interested in a part, they
can just ignore it and let others work on it.

And that is exactly what I am asking you to do:

Just ignore SDR and let Michael work on it.

SDR costs NOTHING except Michael's time, and Michael's time is his own
to spend. For the rest of us, the grounds for objecting are the same
NOTHING.

> opinion on this release still stands: either a release with everything or a
> release without the contentious piece of code, but not both. It's confusing
> to the end users, and shows lack of direction of the project.

On this we agree, making a second release without the feature just some
people object to it would be a waste of Michael's time.

-- 
  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] FFmpeg release 6.1 (SDR Plans)

[Paul B Mahol]

On Thu, Sep 21, 2023 at 9:37 PM Nicolas George <george@nsup.org> wrote:

> Vittorio Giovara (12023-09-21):
> > So this is an example of accusatory tone - discrediting the previous
> author
> > in order to make your arguments have more weight. It's a bad move and
> > easily spottable, you should argue with better elements at your disposal,
> > not by claiming that I don't package software or don't contribute to
> > libavfilter.
>
> You are misunderstanding my point completely, I am not accusing you of
> anything, I am merely using you as an example to show how your argument
> is flawed.
>
> I can take myself as an example instead, if you like it better:
>
> How much did *I* contribute to hardware acceleration? Zero!
>
> How much did *I* contribute to assembly optimization? Zero!
>
> How much do *I* intend to contribute to hardware acceleration? Zero!
>
> But now, however much I would like to, especially in libavfilter, I
> refrain from objecting to new features of hardware acceleration.
>
> Because I can make the difference between the things that benefit me and
> the things that are useful to many users and therefore good for the
> project.
>
> FFmpeg is made a of a lot of parts that are often very independent. That
> is on purpose: that way, if somebody is not interested in a part, they
> can just ignore it and let others work on it.
>
> And that is exactly what I am asking you to do:
>
> Just ignore SDR and let Michael work on it.
>
> SDR costs NOTHING except Michael's time, and Michael's time is his own
> to spend. For the rest of us, the grounds for objecting are the same
> NOTHING.
>

SDR API is not trivial and inclusion of it with all its features and
components is not trivial inside FFmpeg libraries.


>
> > opinion on this release still stands: either a release with everything
> or a
> > release without the contentious piece of code, but not both. It's
> confusing
> > to the end users, and shows lack of direction of the project.
>
> On this we agree, making a second release without the feature just some
> people object to it would be a waste of Michael's time.
>
> --
>   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] FFmpeg release 6.1 (SDR Plans)

[Gijs Peskens]

On 21-09-2023 18:21, Michael Niedermayer wrote:
> Hi all
>
> As the 6.1 release is upcoming and as it was previously stated by me that sdr
> will be part of 6.1. Heres some update of what i intend to do about that.
>
> People previously agreed to including a SDR input device in libavdevice with
> SDR in a seperate library.
>
> If the community and the SDR code are happy with each other before the release
> then SDR will simply be merged and be part of 6.1 like any other feature.
>
> OTOH If a majority of people are against the SDR code at the time of
> branching 6.1. Then i will make a separate release identical to 6.1 with
> the SDR code and of course also provide security support
What does this mean? Does this mean an FFmpeg release containing code 
that interfaces with your SDR library? Or does it mean the library fully 
integrated into FFmpeg?
>
> Of course iam happy to change my plans if someone has a better suggestion!
>
> What i intend to do with SDR next is AVExecutor support to improve processing
> capacity with multiple threads and also to look into factoring the code so
> SDR is more seperated, where this will lead to i do not know
>
> thx
>
> [...]
>
>
> _______________________________________________
> 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] FFmpeg release 6.1 (SDR Plans)

[Michael Niedermayer]

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

On Fri, Sep 22, 2023 at 03:55:57PM +0200, Gijs Peskens wrote:
> 
> On 21-09-2023 18:21, Michael Niedermayer wrote:
> > Hi all
> > 
> > As the 6.1 release is upcoming and as it was previously stated by me that sdr
> > will be part of 6.1. Heres some update of what i intend to do about that.
> > 
> > People previously agreed to including a SDR input device in libavdevice with
> > SDR in a seperate library.
> > 
> > If the community and the SDR code are happy with each other before the release
> > then SDR will simply be merged and be part of 6.1 like any other feature.
> > 
> > OTOH If a majority of people are against the SDR code at the time of
> > branching 6.1. Then i will make a separate release identical to 6.1 with
> > the SDR code and of course also provide security support
> What does this mean? Does this mean an FFmpeg release containing code that
> interfaces with your SDR library? Or does it mean the library fully
> integrated into FFmpeg?

It depends on the code at the time of release. ATM there is no seperate
library, just a SDR input device.
creating a separte library and the related API/ABI needs to be done with
thought and care not something to rush quickly.

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] FFmpeg release 6.1 (SDR Plans)

[Neal Gompa]

On Fri, Sep 22, 2023 at 12:33 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> On Fri, Sep 22, 2023 at 03:55:57PM +0200, Gijs Peskens wrote:
> >
> > On 21-09-2023 18:21, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > As the 6.1 release is upcoming and as it was previously stated by me that sdr
> > > will be part of 6.1. Heres some update of what i intend to do about that.
> > >
> > > People previously agreed to including a SDR input device in libavdevice with
> > > SDR in a seperate library.
> > >
> > > If the community and the SDR code are happy with each other before the release
> > > then SDR will simply be merged and be part of 6.1 like any other feature.
> > >
> > > OTOH If a majority of people are against the SDR code at the time of
> > > branching 6.1. Then i will make a separate release identical to 6.1 with
> > > the SDR code and of course also provide security support
> > What does this mean? Does this mean an FFmpeg release containing code that
> > interfaces with your SDR library? Or does it mean the library fully
> > integrated into FFmpeg?
>
> It depends on the code at the time of release. ATM there is no seperate
> library, just a SDR input device.
> creating a separte library and the related API/ABI needs to be done with
> thought and care not something to rush quickly.
>

What does this code *do*? All these arguments about the SDR code, and
I haven't seen it myself (because the email patch workflow really
makes it hard to track this stuff down, and I assume it was submitted
on list somewhere?)

If it's just taking SDR devices as inputs and allowing you to encode
audio and video streams, I'm not sure why you *wouldn't* have this as
something in libavdevice or extended from it as a separate library.




--
真実はいつも一つ！/ 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] FFmpeg release 6.1 (SDR Plans)

[Michael Niedermayer]

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

On Sat, Sep 23, 2023 at 02:49:47AM -0400, Neal Gompa wrote:
> On Fri, Sep 22, 2023 at 12:33 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> >
> > On Fri, Sep 22, 2023 at 03:55:57PM +0200, Gijs Peskens wrote:
> > >
> > > On 21-09-2023 18:21, Michael Niedermayer wrote:
> > > > Hi all
> > > >
> > > > As the 6.1 release is upcoming and as it was previously stated by me that sdr
> > > > will be part of 6.1. Heres some update of what i intend to do about that.
> > > >
> > > > People previously agreed to including a SDR input device in libavdevice with
> > > > SDR in a seperate library.
> > > >
> > > > If the community and the SDR code are happy with each other before the release
> > > > then SDR will simply be merged and be part of 6.1 like any other feature.
> > > >
> > > > OTOH If a majority of people are against the SDR code at the time of
> > > > branching 6.1. Then i will make a separate release identical to 6.1 with
> > > > the SDR code and of course also provide security support
> > > What does this mean? Does this mean an FFmpeg release containing code that
> > > interfaces with your SDR library? Or does it mean the library fully
> > > integrated into FFmpeg?
> >
> > It depends on the code at the time of release. ATM there is no seperate
> > library, just a SDR input device.
> > creating a separte library and the related API/ABI needs to be done with
> > thought and care not something to rush quickly.
> >
> 
> What does this code *do*? All these arguments about the SDR code, and
> I haven't seen it myself (because the email patch workflow really
> makes it hard to track this stuff down, and I assume it was submitted
> on list somewhere?)
> 
> If it's just taking SDR devices as inputs and allowing you to encode
> audio and video streams, I'm not sure why you *wouldn't* have this as
> something in libavdevice or extended from it as a separate library.

Yes thats correct

Let me try to describe what it does in more detail. Ill keep the HW
side very simplified here as it doesnt matter.

The HW side:
You start with an Antena (wire) connecting to a SDR dongle (which is
basically a analog->digital converter capable to take a piece of
radio spectrum and digitizing it) then generally a USB cable and
then with some intermediate drivers follow our SDR code
(The implementation of the HW is much more complex but that above
 is what it does from a high level view)

The libavdevice SDR code:
The digital radio spectrum piece is then analyzed. AM and FM stations
identified and demodulated into AVStreams. The user can ask for all or
one station to be demodulated. Digital metadata (RDS) is demodulated too
and put in AVStream.metadata
Optionally, the radio spectrum can also be returned in the form of a video
stream so one can see where radio stations are within the piece of the
spectrum (like a spectrum analyzer). And the seek keys can be used to
move between stations and to move the piece of the radio spectrum returned
by the hardware (giving also the functionality of an old radio with next/prev
station buttons)

thx

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 

[-- 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] FFmpeg release 6.1 (SDR Plans)

[Neal Gompa]

On Sat, Sep 23, 2023 at 6:55 AM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> On Sat, Sep 23, 2023 at 02:49:47AM -0400, Neal Gompa wrote:
> > On Fri, Sep 22, 2023 at 12:33 PM Michael Niedermayer
> > <michael@niedermayer.cc> wrote:
> > >
> > > On Fri, Sep 22, 2023 at 03:55:57PM +0200, Gijs Peskens wrote:
> > > >
> > > > On 21-09-2023 18:21, Michael Niedermayer wrote:
> > > > > Hi all
> > > > >
> > > > > As the 6.1 release is upcoming and as it was previously stated by me that sdr
> > > > > will be part of 6.1. Heres some update of what i intend to do about that.
> > > > >
> > > > > People previously agreed to including a SDR input device in libavdevice with
> > > > > SDR in a seperate library.
> > > > >
> > > > > If the community and the SDR code are happy with each other before the release
> > > > > then SDR will simply be merged and be part of 6.1 like any other feature.
> > > > >
> > > > > OTOH If a majority of people are against the SDR code at the time of
> > > > > branching 6.1. Then i will make a separate release identical to 6.1 with
> > > > > the SDR code and of course also provide security support
> > > > What does this mean? Does this mean an FFmpeg release containing code that
> > > > interfaces with your SDR library? Or does it mean the library fully
> > > > integrated into FFmpeg?
> > >
> > > It depends on the code at the time of release. ATM there is no seperate
> > > library, just a SDR input device.
> > > creating a separte library and the related API/ABI needs to be done with
> > > thought and care not something to rush quickly.
> > >
> >
> > What does this code *do*? All these arguments about the SDR code, and
> > I haven't seen it myself (because the email patch workflow really
> > makes it hard to track this stuff down, and I assume it was submitted
> > on list somewhere?)
> >
> > If it's just taking SDR devices as inputs and allowing you to encode
> > audio and video streams, I'm not sure why you *wouldn't* have this as
> > something in libavdevice or extended from it as a separate library.
>
> Yes thats correct
>
> Let me try to describe what it does in more detail. Ill keep the HW
> side very simplified here as it doesnt matter.
>
> The HW side:
> You start with an Antena (wire) connecting to a SDR dongle (which is
> basically a analog->digital converter capable to take a piece of
> radio spectrum and digitizing it) then generally a USB cable and
> then with some intermediate drivers follow our SDR code
> (The implementation of the HW is much more complex but that above
>  is what it does from a high level view)
>
> The libavdevice SDR code:
> The digital radio spectrum piece is then analyzed. AM and FM stations
> identified and demodulated into AVStreams. The user can ask for all or
> one station to be demodulated. Digital metadata (RDS) is demodulated too
> and put in AVStream.metadata
> Optionally, the radio spectrum can also be returned in the form of a video
> stream so one can see where radio stations are within the piece of the
> spectrum (like a spectrum analyzer). And the seek keys can be used to
> move between stations and to move the piece of the radio spectrum returned
> by the hardware (giving also the functionality of an old radio with next/prev
> station buttons)
>

So it's not *really* SDR in the sense that most people talk about it,
it's actually more about classical radio in software. That seems more
than reasonable to support in FFmpeg. If we were talking about some of
the crazy things people do with SDR, I would think that's
inappropriate. But being able to decode AM/FM/SiriusXM and listen to
it on a Linux machine is nice enough.

I suppose the logical extension would be to be able to integrate
support for handling analog and digital TV signals, eventually?

I can see the argument that it'd be better as a separate project, but
offhand I actually don't know of any that do this now...

I guess this would be called libavradio or something like that?





--
真実はいつも一つ！/ 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] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

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

Neal Gompa (12023-09-23):
> If it's just taking SDR devices as inputs and allowing you to encode
> audio and video streams, I'm not sure why you *wouldn't* have this as
> something in libavdevice or extended from it as a separate library.

The people who oppose Michael's SDR also have been trying to kill
libavdevice for years. At least some of them.

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] FFmpeg release 6.1 (SDR Plans)

[Paul B Mahol]

On Sun, Sep 24, 2023 at 11:12 AM Nicolas George <george@nsup.org> wrote:

> Neal Gompa (12023-09-23):
> > If it's just taking SDR devices as inputs and allowing you to encode
> > audio and video streams, I'm not sure why you *wouldn't* have this as
> > something in libavdevice or extended from it as a separate library.
>
> The people who oppose Michael's SDR also have been trying to kill
> libavdevice for years. At least some of them.
>

libavdevice is abusing libavformat.

It should have own API or be removed.


>
> 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] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

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

Paul B Mahol (12023-09-24):
> libavdevice is abusing libavformat.
> 
> It should have own API or be removed.

libavdevice works.

-- 
  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] FFmpeg release 6.1 (SDR Plans)

[Paul B Mahol]

On 9/24/23, Nicolas George <george@nsup.org> wrote:
> Paul B Mahol (12023-09-24):
>> libavdevice is abusing libavformat.
>>
>> It should have own API or be removed.
>
> libavdevice works.

Define 'works'.

It is clearly sub-optimal.
_______________________________________________
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] libavdevice (was: FFmpeg release 6.1 (SDR Plans))

[Nicolas George]

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

Paul B Mahol (12023-09-24):
> Define 'works'.
> 
> It is clearly sub-optimal.

Many users use it for many different tasks and it serves them
efficiently.

There are probably ways to enhance the API of libavdevice. If you have
suggestions, then please share them. But when you say that libavdevices
is “abusing libavformat”, it seems to indicate you completely missed the
fact that being able to use devices in places that were not designed is
an essential part of the service libavdevice gives to users, and if your
suggestions involve breaking it you can keep them to yourself, they are
useless.

As for people who criticize libavdevice without even a hint of a
reflection on how to make make it better, they are just hypocrites who
disguise their hate into technical opinion.

-- 
  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] libavdevice (was: FFmpeg release 6.1 (SDR Plans))

[Paul B Mahol]

On 9/24/23, Nicolas George <george@nsup.org> wrote:
> Paul B Mahol (12023-09-24):
>> Define 'works'.
>>
>> It is clearly sub-optimal.
>
> Many users use it for many different tasks and it serves them
> efficiently.
>
> There are probably ways to enhance the API of libavdevice. If you have
> suggestions, then please share them. But when you say that libavdevices
> is “abusing libavformat”, it seems to indicate you completely missed the
> fact that being able to use devices in places that were not designed is
> an essential part of the service libavdevice gives to users, and if your
> suggestions involve breaking it you can keep them to yourself, they are
> useless.

Citations needed.

>
> As for people who criticize libavdevice without even a hint of a
> reflection on how to make make it better, they are just hypocrites who
> disguise their hate into technical opinion.

libavdevice have no API.
_______________________________________________
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] libavdevice (was: FFmpeg release 6.1 (SDR Plans))

[Nicolas George]

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

Paul B Mahol (12023-09-24):
> Citations needed.

<facepalm emoji>

> libavdevice have no API.

Yes, that was my point. If you do not understand why it is an essential
part of libavdevice, I suggest you take the time to learn what
libavdevice is all about and refrain from commenting on it before you
have gotten a clue.

-- 
  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] libavdevice (was: FFmpeg release 6.1 (SDR Plans))

[Paul B Mahol]

On 9/24/23, Nicolas George <george@nsup.org> wrote:
> Paul B Mahol (12023-09-24):
>> Citations needed.
>
> <facepalm emoji>
>
>> libavdevice have no API.
>
> Yes, that was my point. If you do not understand why it is an essential
> part of libavdevice, I suggest you take the time to learn what
> libavdevice is all about and refrain from commenting on it before you
> have gotten a clue.

You are typical wannabe next-door tyrant.

libavdevice is using libavformat API that is unacceptable maintenance burden.
_______________________________________________
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] libavdevice (was: FFmpeg release 6.1 (SDR Plans))

[Nicolas George]

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

Paul B Mahol (12023-09-24):
> libavdevice is using libavformat API that is unacceptable maintenance burden.

This is a lie. You would not even know if libavdevice is a maintenance
burden, you never touch it.

-- 
  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] FFmpeg release 6.1 (SDR Plans)

[Kieran Kunhya]

On Sun, 24 Sept 2023, 18:34 Paul B Mahol, <onemda@gmail.com> wrote:

> On 9/24/23, Nicolas George <george@nsup.org> wrote:
> > Paul B Mahol (12023-09-24):
> >> libavdevice is abusing libavformat.
> >>
> >> It should have own API or be removed.
> >
> > libavdevice works.
>
> Define 'works'.
>
> It is clearly sub-optimal.
>

Why should a big feature like SDR be put into a point release?

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] libavdevice (was: FFmpeg release 6.1 (SDR Plans))

[Paul B Mahol]

On Sun, Sep 24, 2023 at 8:09 PM Nicolas George <george@nsup.org> wrote:

> Paul B Mahol (12023-09-24):
> > libavdevice is using libavformat API that is unacceptable maintenance
> burden.
>
> This is a lie. You would not even know if libavdevice is a maintenance
> burden, you never touch it.
>

[computer@archlinux ffmpeg]$ git sn libavdevice/|grep Paul\ B\ Mahol
    12  Paul B Mahol
[computer@archlinux ffmpeg]$ git sn libavformat/|grep Paul\ B\ Mahol
   684  Paul B Mahol
[computer@archlinux ffmpeg]$ git sn libavformat/|grep Nicolas\ George
   154  Nicolas George
[computer@archlinux ffmpeg]$ git sn libavdevice/|grep Nicolas\ George
    51  Nicolas George

I had great plans for libavdevice, but as my proposal to change API was
rejected I'm no longer contributing to libavdevice.


>
> --
>   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] libavdevice (was: FFmpeg release 6.1 (SDR Plans))

[Nicolas George]

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

Paul B Mahol (12023-09-25):
> [computer@archlinux ffmpeg]$ git sn libavdevice/|grep Paul\ B\ Mahol

~/prog/ffmpeg $ git sn libavformat/|grep Paul\ B\ Mahol
git: 'sn' is not a git command. See 'git --help'.


> I had great plans for libavdevice, but as my proposal to change API was
> rejected I'm no longer contributing to libavdevice.

I do not remember your proposal and it rejection, nor do I manage to
find it in my archives, but I will assume you remember correctly having
sent it.

If your great plans involved breaking the ability to use most device
transparently in place of a muxer or demuxer, then of course they were
rejected.

-- 
  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] FFmpeg release 6.1 (SDR Plans)

[Nicolas George]

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

Paul B Mahol (12023-09-21):
> If this SDR troll code ever get committed in FFmpeg libraries I will
> immediately leave project.

That would be sad for the project. But I am sorry, I sincerely believe
that if you were to follow through with it, it would be a price worth
paying to have Michael working on code that gives him fun again.

Anyway, I suppose you have no difficulty seeing how this kind of
blackmail cannot be taken into consideration for the decision of the
future of the project.

-- 
  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] FFmpeg release 6.1 (SDR Plans)

[Rémi Denis-Courmont]

Le torstaina 21. syyskuuta 2023, 21.56.52 EEST Michael Niedermayer a écrit :
> Hi
> 
> On Thu, Sep 21, 2023 at 05:33:54PM +0100, Kieran Kunhya via ffmpeg-devel 
wrote:
> > On Thu, Sep 21, 2023 at 5:21 PM Michael Niedermayer
> > 
> > <michael@niedermayer.cc> wrote:
> > > OTOH If a majority of people are against the SDR code at the time of
> > > branching 6.1. Then i will make a separate release identical to 6.1 with
> > > the SDR code and of course also provide security support
> > 
> > How on earth is it acceptable that you can publish your hobby project
> > under the FFmpeg project name?
> 
> How on earth is this defamation acceptable?

Michael, that is totally out of line. You pointed out that SDR was a new hobby 
project of yours. You do not get to complain that people throw your own words 
back at you (even if, hypothetically, you regret them).

> In fact iam not even sure what you talk about.
> FFmpeg is not a propriatery licensed project

Nobody said anything about FFmpeg or your SDR code being proprietary.

> It seems to me you are trying to rally your followers against me,

This is very demeaning to those people who are perfectly capable of thinking 
for ourselves and objected to the SDR code on similar technical grounds as 
Kieran's. And it is very highly hypocritical of you to accuse Kieran of 
politicking right after your allegations of defamation, since your words could 
very well be interpreted as defamation against him.

> If you have real arguments, you can state them without these attacks

Kieran, and others, have provided technical arguments a number of times in the 
past.

> > I have been working on BIOS code recently but I haven't decided to
> > create FFBIOS and put it in the main FFmpeg repo.
> 
> because doing so would make no sense, BIOS is unrelated to FFmpeg and
> multimedia

FFmpeg as a UEFI app or bare metal "BIOS" would be more related to multimedia 
than SDR is, relatively speaking, IMO.

(FWIW, UEFI has graphical output, HID, file systems and TCP/IP. You could very 
well run the FFmpeg on it.)

> But if you do, noone would attack you like you do, we would just
> have a normal discussion about why you think this makes sense, and
> i think you dont think that makes sense so we would agree that BIOS
> doesnt belong in FFmpeg
> 
> If OTOH you would create something related, you could name it
> FFmpeg-<whatever> nothing wrong here, other people do it to, github has
> 26300 hits for FFmpeg

Like no? Other people do it is a very sorry excuse. If it doesn't relate to 
FFmpeg, it shouldn't be called FFmpeg.

It's not even just a question of morality and principles: Trademarks need to 
be defended afterall.

-- 
レミ・デニ-クールモン
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] FFmpeg release 6.1 (SDR Plans)

[Rémi Denis-Courmont]

Le lauantaina 23. syyskuuta 2023, 9.49.47 EEST Neal Gompa a écrit :
> On Fri, Sep 22, 2023 at 12:33 PM Michael Niedermayer
> 
> <michael@niedermayer.cc> wrote:
> > > What does this mean? Does this mean an FFmpeg release containing code
> > > that
> > > interfaces with your SDR library? Or does it mean the library fully
> > > integrated into FFmpeg?
> > 
> > It depends on the code at the time of release. ATM there is no seperate
> > library, just a SDR input device.
> > creating a separte library and the related API/ABI needs to be done with
> > thought and care not something to rush quickly.
> 
> What does this code *do*? All these arguments about the SDR code, and
> I haven't seen it myself (because the email patch workflow really
> makes it hard to track this stuff down, and I assume it was submitted
> on list somewhere?)
> 
> If it's just taking SDR devices as inputs and allowing you to encode
> audio and video streams, I'm not sure why you *wouldn't* have this as
> something in libavdevice or extended from it as a separate library.

I'm pretty damn sure why: that's not how you normally deal with analog (or 
PCM) audio inputs and outputs. There *are* already a standard interfaces for 
the purpose: ALSA is the most common (others include JACK and Pipewire). It is 
already supported by FFmpeg - and hundreds of other open-source applications 
that would benefit from it too. (And yes, you *can* implement ALSA devices in 
userspace.)

There are simply no particular reasons why this should be tied to FFmpeg, and 
there are conversely no reasons to bloat the FFmpeg code with SDR code that 
will only be usable to one in a million with suitable radio equipment.

But really the main concern was the slippery slope argument: SDR code for FM 
may be small, but SDR code, say, DVB wouldn't be, and the line has to be drawn 
somewhere.

-- 
レミ・デニ-クールモン
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".