Re: [FFmpeg-devel] 5.0 release

Re: [FFmpeg-devel] 5.0 release

[Michael Niedermayer]

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

On Tue, Dec 14, 2021 at 05:42:01PM +0100, Diederick C. Niehorster wrote:
> Hi Michael,
> 
> On Tue, Dec 14, 2021 at 5:19 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> >
> > On Mon, Dec 13, 2021 at 10:27:33PM +0100, Diederick C. Niehorster wrote:
> > > Hi Michael,
> > >
> > > On Mon, Dec 13, 2021 at 4:26 PM Michael Niedermayer
> > > <michael@niedermayer.cc> wrote:
> > > >
> > > > If you know of any major issues which need to be done before the release do them
> > > > now. If you know of any issues which are release-blocking list them in a reply
> > > > here please.
> > >
> > > Not major, but https://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/289462.html
> > > fixes a crashing bug. I'd of course love for the whole series to be
> > > pushed in time for release (its been reviewed multiple times and
> > > LGTMed offlist by the dshow maintainer), but we'll see :).
> >
> > The patches do not say in their commit messages that they have been reviewed
> > maybe you want to repost them with that changed.
> 
> Thanks for having a look!
> I have mentioned this here:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/289461.html
> 
> Or do you mean that for each specific patch, if there were previous
> review comments, i should mention that it was updated in response to
> the review? For some that may be hard (e.g. i was asked to change the
> order of some commits).

Patches which where approved already and not changed since then could
contain that information in the commit message. We tend to use some
Reviewed-by: ...
for that
that may speed up future review and commit

I dont know dshow and dont have a proper setup to test it so i wont be
applying or reviewing these patches

thx

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin

[-- 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] 5.0 release

[Diederick C. Niehorster]

Hi Michael,

On Wed, Dec 15, 2021 at 3:52 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> On Tue, Dec 14, 2021 at 05:42:01PM +0100, Diederick C. Niehorster wrote:
> > Hi Michael,
> >
> > On Tue, Dec 14, 2021 at 5:19 PM Michael Niedermayer
> > <michael@niedermayer.cc> wrote:
> > >
> > >
> > > The patches do not say in their commit messages that they have been reviewed
> > > maybe you want to repost them with that changed.
> >
> > Thanks for having a look!
> > I have mentioned this here:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/289461.html
> >
> > Or do you mean that for each specific patch, if there were previous
> > review comments, i should mention that it was updated in response to
> > the review? For some that may be hard (e.g. i was asked to change the
> > order of some commits).
>
> Patches which where approved already and not changed since then could
> contain that information in the commit message. We tend to use some
> Reviewed-by: ...
> for that
> that may speed up future review and commit
>
> I dont know dshow and dont have a proper setup to test it so i wont be
> applying or reviewing these patches

Ah, i see. I have made changes here in response to other review
comment since i got that LGTM for the series. I'll contact the dshow
maintainer again for that (I assume he would be the only one who
should be committing my patchset?).

Thanks,
Dee
_______________________________________________
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] 5.0 release

[Michael Niedermayer]

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

On Wed, Dec 15, 2021 at 04:08:43PM +0100, Diederick C. Niehorster wrote:
> Hi Michael,
> 
> On Wed, Dec 15, 2021 at 3:52 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> >
> > On Tue, Dec 14, 2021 at 05:42:01PM +0100, Diederick C. Niehorster wrote:
> > > Hi Michael,
> > >
> > > On Tue, Dec 14, 2021 at 5:19 PM Michael Niedermayer
> > > <michael@niedermayer.cc> wrote:
> > > >
> > > >
> > > > The patches do not say in their commit messages that they have been reviewed
> > > > maybe you want to repost them with that changed.
> > >
> > > Thanks for having a look!
> > > I have mentioned this here:
> > > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/289461.html
> > >
> > > Or do you mean that for each specific patch, if there were previous
> > > review comments, i should mention that it was updated in response to
> > > the review? For some that may be hard (e.g. i was asked to change the
> > > order of some commits).
> >
> > Patches which where approved already and not changed since then could
> > contain that information in the commit message. We tend to use some
> > Reviewed-by: ...
> > for that
> > that may speed up future review and commit
> >
> > I dont know dshow and dont have a proper setup to test it so i wont be
> > applying or reviewing these patches
> 
> Ah, i see. I have made changes here in response to other review
> comment since i got that LGTM for the series. I'll contact the dshow
> maintainer again for that (I assume he would be the only one who
> should be committing my patchset?).

anyone with commit rights could apply after a review by someone who knows
the code. Of course could != will

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.

[-- 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] 5.0 release

[Michael Niedermayer]

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

On Mon, Dec 13, 2021 at 07:05:07PM +0100, Jean-Baptiste Kempf wrote:
> On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
> > If you know of any major issues which need to be done before the release do them
> > now. If you know of any issues which are release-blocking list them in a reply
> > here please.
> 
> Maybe the audio channel layout would be nice to settle before?

iam not sure we will achieve a december 2021 release if we want to
include that

anyone has an opinion if we should wait with the release until this
is in ?

thx


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

Republics decline into democracies and democracies degenerate into
despotisms. -- 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] 5.0 release

[James Almer]

On 12/22/2021 11:03 AM, Michael Niedermayer wrote:
> On Mon, Dec 13, 2021 at 07:05:07PM +0100, Jean-Baptiste Kempf wrote:
>> On Mon, 13 Dec 2021, at 16:25, Michael Niedermayer wrote:
>>> If you know of any major issues which need to be done before the release do them
>>> now. If you know of any issues which are release-blocking list them in a reply
>>> here please.
>>
>> Maybe the audio channel layout would be nice to settle before?
> 
> iam not sure we will achieve a december 2021 release if we want to
> include that
> 
> anyone has an opinion if we should wait with the release until this
> is in ?
> 
> thx

Is the December target to get into the feature freeze schedule from 
distros? If so, then IMO better make the release now. The channel layout 
API is unlikely to be committed before the end of the year.
_______________________________________________
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] 5.0 release

[Jean-Baptiste Kempf]

On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
> Is the December target to get into the feature freeze schedule from 
> distros?

No, it was set by me, in order to get the distro freezes from January.

We can miss the target a bit this year, and then make it better for 2022.

BEst,.

-- 
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] 5.0 release

[Michael Niedermayer]

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

On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
> On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
> > Is the December target to get into the feature freeze schedule from 
> > distros?
> 
> No, it was set by me, in order to get the distro freezes from January.
> 

> We can miss the target a bit this year, and then make it better for 2022.

as you seem to know the distro freeze shedules
can you clarify "a bit" ?

iam asking just in case the channel patch doesnt make it before
so i know when its time to stop waiting for it

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The smallest minority on earth is the individual. Those who deny 
individual rights cannot claim to be defenders of minorities. - Ayn Rand

[-- 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] 5.0 release

[Michael Niedermayer]

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

On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:
> On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
> > On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
> > > Is the December target to get into the feature freeze schedule from 
> > > distros?
> > 
> > No, it was set by me, in order to get the distro freezes from January.
> > 
> 
> > We can miss the target a bit this year, and then make it better for 2022.
> 
> as you seem to know the distro freeze shedules
> can you clarify "a bit" ?
> 
> iam asking just in case the channel patch doesnt make it before
> so i know when its time to stop waiting for it

ok
when do people want me to make the branch ?
any preferrances ?
should i do it now or continue waiting?

I saw on IRC some sugestions to make it at a past commit to keep some
code out

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus

[-- 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] 5.0 release

[Gyan Doshi]

On 2021-12-31 10:22 pm, Michael Niedermayer wrote:
> On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:
>> On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
>>> On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
>>>> Is the December target to get into the feature freeze schedule from
>>>> distros?
>>> No, it was set by me, in order to get the distro freezes from January.
>>>
>>> We can miss the target a bit this year, and then make it better for 2022.
>> as you seem to know the distro freeze shedules
>> can you clarify "a bit" ?
>>
>> iam asking just in case the channel patch doesnt make it before
>> so i know when its time to stop waiting for it
> ok
> when do people want me to make the branch ?
> any preferrances ?
> should i do it now or continue waiting?
>
> I saw on IRC some sugestions to make it at a past commit to keep some
> code out

It would be nice to have a public date set a few days into the future.

Regards,
Gyan

P.S. Are the libera chats not archived like freenode?
_______________________________________________
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] 5.0 release

[Michael Niedermayer]

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

On Fri, Dec 31, 2021 at 10:45:46PM +0530, Gyan Doshi wrote:
> 
> 
> On 2021-12-31 10:22 pm, Michael Niedermayer wrote:
> > On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:
> > > On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
> > > > On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
> > > > > Is the December target to get into the feature freeze schedule from
> > > > > distros?
> > > > No, it was set by me, in order to get the distro freezes from January.
> > > > 
> > > > We can miss the target a bit this year, and then make it better for 2022.
> > > as you seem to know the distro freeze shedules
> > > can you clarify "a bit" ?
> > > 
> > > iam asking just in case the channel patch doesnt make it before
> > > so i know when its time to stop waiting for it
> > ok
> > when do people want me to make the branch ?
> > any preferrances ?
> > should i do it now or continue waiting?
> > 
> > I saw on IRC some sugestions to make it at a past commit to keep some
> > code out
> 
> It would be nice to have a public date set a few days into the future.

yes, i intended to do that, unless people wanted a ASAP/NOW branch

i guess 3rd january seems like a good choice
1st and 2nd as being close to newyear probably would not be ideal so
3rd seems the soonest good date
but we can push this out more if people want? or also do it earlier
of course that assumes nothing unexpected happens
(and something unexpected always happens...)

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] 5.0 release

[Anton Khirnov]

Quoting Michael Niedermayer (2021-12-31 20:40:24)
> On Fri, Dec 31, 2021 at 10:45:46PM +0530, Gyan Doshi wrote:
> > 
> > 
> > On 2021-12-31 10:22 pm, Michael Niedermayer wrote:
> > > On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:
> > > > On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
> > > > > On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
> > > > > > Is the December target to get into the feature freeze schedule from
> > > > > > distros?
> > > > > No, it was set by me, in order to get the distro freezes from January.
> > > > > 
> > > > > We can miss the target a bit this year, and then make it better for 2022.
> > > > as you seem to know the distro freeze shedules
> > > > can you clarify "a bit" ?
> > > > 
> > > > iam asking just in case the channel patch doesnt make it before
> > > > so i know when its time to stop waiting for it
> > > ok
> > > when do people want me to make the branch ?
> > > any preferrances ?
> > > should i do it now or continue waiting?
> > > 
> > > I saw on IRC some sugestions to make it at a past commit to keep some
> > > code out
> > 
> > It would be nice to have a public date set a few days into the future.
> 
> yes, i intended to do that, unless people wanted a ASAP/NOW branch
> 
> i guess 3rd january seems like a good choice
> 1st and 2nd as being close to newyear probably would not be ideal so
> 3rd seems the soonest good date
> but we can push this out more if people want? or also do it earlier
> of course that assumes nothing unexpected happens
> (and something unexpected always happens...)

There were some disagreements on IRC a few days ago about what should
and should not go into the release because of insufficient fuzzing and
the danger of introducing security issues.

To avoid conflicts around this in the future, I'd suggest (for future
releases) to create the release branch a significant time (e.g. a month)
before doing the actual release.

Opinions?

-- 
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] 5.0 release

[James Almer]

On 1/2/2022 11:12 AM, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-12-31 20:40:24)
>> On Fri, Dec 31, 2021 at 10:45:46PM +0530, Gyan Doshi wrote:
>>>
>>>
>>> On 2021-12-31 10:22 pm, Michael Niedermayer wrote:
>>>> On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:
>>>>> On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
>>>>>> On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
>>>>>>> Is the December target to get into the feature freeze schedule from
>>>>>>> distros?
>>>>>> No, it was set by me, in order to get the distro freezes from January.
>>>>>>
>>>>>> We can miss the target a bit this year, and then make it better for 2022.
>>>>> as you seem to know the distro freeze shedules
>>>>> can you clarify "a bit" ?
>>>>>
>>>>> iam asking just in case the channel patch doesnt make it before
>>>>> so i know when its time to stop waiting for it
>>>> ok
>>>> when do people want me to make the branch ?
>>>> any preferrances ?
>>>> should i do it now or continue waiting?
>>>>
>>>> I saw on IRC some sugestions to make it at a past commit to keep some
>>>> code out
>>>
>>> It would be nice to have a public date set a few days into the future.
>>
>> yes, i intended to do that, unless people wanted a ASAP/NOW branch
>>
>> i guess 3rd january seems like a good choice
>> 1st and 2nd as being close to newyear probably would not be ideal so
>> 3rd seems the soonest good date
>> but we can push this out more if people want? or also do it earlier
>> of course that assumes nothing unexpected happens
>> (and something unexpected always happens...)
> 
> There were some disagreements on IRC a few days ago about what should
> and should not go into the release because of insufficient fuzzing and
> the danger of introducing security issues.
> 
> To avoid conflicts around this in the future, I'd suggest (for future
> releases) to create the release branch a significant time (e.g. a month)
> before doing the actual release.
> 
> Opinions?

It's a good idea, but we need to be strict about it. As in, we need to 
state that the moment the branch is made it's a definite feature freeze, 
and only fixes, documentation changes and similar may be cherry-picked 
into it (meaning nothing that usually comes with a version bump, even if 
micro), much like we do for a point release, even if the initial release 
was not tagged yet.

Reverting something in the release branch is already going to be dirty 
no matter what, because we do a minor bump to ensure the release has its 
own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking 
a demuxer available in lavf 59.12
_______________________________________________
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] 5.0 release

[Zane van Iperen]

On Monday, 3 January 2022 12:29:02 AM AEST James Almer wrote:

> > There were some disagreements on IRC a few days ago about what should
> > and should not go into the release because of insufficient fuzzing and
> > the danger of introducing security issues.
> > 
> > To avoid conflicts around this in the future, I'd suggest (for future
> > releases) to create the release branch a significant time (e.g. a month)
> > before doing the actual release.
> > 
> > Opinions?
> 
> It's a good idea, but we need to be strict about it. As in, we need to 
> state that the moment the branch is made it's a definite feature freeze, 
> and only fixes, documentation changes and similar may be cherry-picked 
> into it (meaning nothing that usually comes with a version bump, even if 
> micro), much like we do for a point release, even if the initial release 
> was not tagged yet.
> 

I completely agree, this is a *very* good idea. If people treat it like
an existing release branch, i.e. only bugfixes, etc., then it would
save this from happening again.

Also means there wouldn't need to be a "don't add big things" announcement
_somewhere_ on the ML.

> Reverting something in the release branch is already going to be dirty 
> no matter what, because we do a minor bump to ensure the release has its 
> own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking 
> a demuxer available in lavf 59.12

Depends on what you mean by "lacking a demuxer"... One (hacky) option would
be to replace it with a stub implementation that always fails.

Or we could just branch off at 7cee3b3718 and cherry-pick anything we need back.
There's only like four commits that need it (so far): 2f6360ff21, 9cfc7a2440,
c417616762, and d6b2357edd.




_______________________________________________
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] 5.0 release

[James Almer]

On 1/2/2022 11:50 AM, Zane van Iperen wrote:
> On Monday, 3 January 2022 12:29:02 AM AEST James Almer wrote:
> 
>>> There were some disagreements on IRC a few days ago about what should
>>> and should not go into the release because of insufficient fuzzing and
>>> the danger of introducing security issues.
>>>
>>> To avoid conflicts around this in the future, I'd suggest (for future
>>> releases) to create the release branch a significant time (e.g. a month)
>>> before doing the actual release.
>>>
>>> Opinions?
>>
>> It's a good idea, but we need to be strict about it. As in, we need to
>> state that the moment the branch is made it's a definite feature freeze,
>> and only fixes, documentation changes and similar may be cherry-picked
>> into it (meaning nothing that usually comes with a version bump, even if
>> micro), much like we do for a point release, even if the initial release
>> was not tagged yet.
>>
> 
> I completely agree, this is a *very* good idea. If people treat it like
> an existing release branch, i.e. only bugfixes, etc., then it would
> save this from happening again.
> 
> Also means there wouldn't need to be a "don't add big things" announcement
> _somewhere_ on the ML.
> 
>> Reverting something in the release branch is already going to be dirty
>> no matter what, because we do a minor bump to ensure the release has its
>> own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
>> a demuxer available in lavf 59.12
> 
> Depends on what you mean by "lacking a demuxer"... One (hacky) option would
> be to replace it with a stub implementation that always fails.

Or tag it as experimental.

> 
> Or we could just branch off at 7cee3b3718 and cherry-pick anything we need back.
> There's only like four commits that need it (so far): 2f6360ff21, 9cfc7a2440,
> c417616762, and d6b2357edd.

Branching at 7cee3b3718 will give you a snapshot with lavf 59.10. What 
do you do with the release branch exclusive bump? Can't be 59.11 as 
that's in master post branch creation. Same with 59.12. So you have to 
do 59.13, but then the 59.13 feature set is that of 59.10, thus lacking 
the stuff added in 59.{11,12}, And that's a real pain in the ass for 
anyone looking at our versioning to know what they can expect from the 
libraries.

The less-messy options at this point, besides your suggestion above or 
mine about tagging it as experimental, would be to revert the imf 
demuxer in master and then branch, or branch at the newest commit in the 
tree without a revert then delay tagging the release until a month has 
passed and the imf demuxer was tested somewhat (Which is what Anton 
suggested, but starting with this release instead).

Also, unless ossfuzz compiles with libxml2 enabled, we're not going to 
see any kind of fuzzing for imf from 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".

_______________________________________________
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] 5.0 release

[Zane van Iperen]

On 3/1/22 01:09, James Almer wrote:
>>
>>> Reverting something in the release branch is already going to be dirty
>>> no matter what, because we do a minor bump to ensure the release has its
>>> own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
>>> a demuxer available in lavf 59.12
>>
>> Depends on what you mean by "lacking a demuxer"... One (hacky) option would
>> be to replace it with a stub implementation that always fails.
> 
> Or tag it as experimental.
> 

That's much better. If we're not willing to wait, then I suggest we do this.

> 
> Also, unless ossfuzz compiles with libxml2 enabled, we're not going to see any kind of fuzzing for imf from it.
> 

I just checked - it doesn't. I'm adding it and will send a PR.
_______________________________________________
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] 5.0 release

[Lynne]

2 Jan 2022, 16:52 by zane@zanevaniperen.com:

>
>
> On 3/1/22 01:09, James Almer wrote:
>
>>>> Reverting something in the release branch is already going to be dirty
>>>> no matter what, because we do a minor bump to ensure the release has its
>>>> own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
>>>> a demuxer available in lavf 59.12
>>>>
>>>
>>> Depends on what you mean by "lacking a demuxer"... One (hacky) option would
>>> be to replace it with a stub implementation that always fails.
>>>
>>
>> Or tag it as experimental.
>>
>
> That's much better. If we're not willing to wait, then I suggest we do this.
>

I'd rather have it reverted in master, branch 5.0, and add it back and bump minor
again. I'm not willing to wait for a month to get fuzzing, the release is way
overdue as-is. We generally don't put experimental on decoders or demuxers.


>> Also, unless ossfuzz compiles with libxml2 enabled, we're not going to see any kind of fuzzing for imf from it.
>>
>
> I just checked - it doesn't. I'm adding it and will send a PR.
>


_______________________________________________
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] 5.0 release

[Michael Niedermayer]

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

On Sun, Jan 02, 2022 at 05:28:24PM +0100, Lynne wrote:
> 2 Jan 2022, 16:52 by zane@zanevaniperen.com:
> 
> >
> >
> > On 3/1/22 01:09, James Almer wrote:
> >
> >>>> Reverting something in the release branch is already going to be dirty
> >>>> no matter what, because we do a minor bump to ensure the release has its
> >>>> own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
> >>>> a demuxer available in lavf 59.12
> >>>>
> >>>
> >>> Depends on what you mean by "lacking a demuxer"... One (hacky) option would
> >>> be to replace it with a stub implementation that always fails.
> >>>
> >>
> >> Or tag it as experimental.
> >>
> >
> > That's much better. If we're not willing to wait, then I suggest we do this.
> >
> 
> I'd rather have it reverted in master, branch 5.0, and add it back and bump minor
> again. I'm not willing to wait for a month to get fuzzing, the release is way
> overdue as-is. We generally don't put experimental on decoders or demuxers.

I think if we dont want it in the release either as you suggest
revert in master or mark as experimental in master before the branch

having special cases in the release branch feels a bit iffy

thx

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

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr

[-- 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] 5.0 release

[Lynne]

2 Jan 2022, 18:11 by michael@niedermayer.cc:

> On Sun, Jan 02, 2022 at 05:28:24PM +0100, Lynne wrote:
>
>> 2 Jan 2022, 16:52 by zane@zanevaniperen.com:
>>
>> >
>> >
>> > On 3/1/22 01:09, James Almer wrote:
>> >
>> >>>> Reverting something in the release branch is already going to be dirty
>> >>>> no matter what, because we do a minor bump to ensure the release has its
>> >>>> own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
>> >>>> a demuxer available in lavf 59.12
>> >>>>
>> >>>
>> >>> Depends on what you mean by "lacking a demuxer"... One (hacky) option would
>> >>> be to replace it with a stub implementation that always fails.
>> >>>
>> >>
>> >> Or tag it as experimental.
>> >>
>> >
>> > That's much better. If we're not willing to wait, then I suggest we do this.
>> >
>>
>> I'd rather have it reverted in master, branch 5.0, and add it back and bump minor
>> again. I'm not willing to wait for a month to get fuzzing, the release is way
>> overdue as-is. We generally don't put experimental on decoders or demuxers.
>>
>
> I think if we dont want it in the release either as you suggest
> revert in master or mark as experimental in master before the branch
>
> having special cases in the release branch feels a bit iffy
>

Okay, I can live with an experimental flag on it for the time being.
_______________________________________________
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] 5.0 release

[Michael Niedermayer]

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

On Sun, Jan 02, 2022 at 07:12:54PM +0100, Lynne wrote:
> 2 Jan 2022, 18:11 by michael@niedermayer.cc:
> 
> > On Sun, Jan 02, 2022 at 05:28:24PM +0100, Lynne wrote:
> >
> >> 2 Jan 2022, 16:52 by zane@zanevaniperen.com:
> >>
> >> >
> >> >
> >> > On 3/1/22 01:09, James Almer wrote:
> >> >
> >> >>>> Reverting something in the release branch is already going to be dirty
> >> >>>> no matter what, because we do a minor bump to ensure the release has its
> >> >>>> own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
> >> >>>> a demuxer available in lavf 59.12
> >> >>>>
> >> >>>
> >> >>> Depends on what you mean by "lacking a demuxer"... One (hacky) option would
> >> >>> be to replace it with a stub implementation that always fails.
> >> >>>
> >> >>
> >> >> Or tag it as experimental.
> >> >>
> >> >
> >> > That's much better. If we're not willing to wait, then I suggest we do this.
> >> >
> >>
> >> I'd rather have it reverted in master, branch 5.0, and add it back and bump minor
> >> again. I'm not willing to wait for a month to get fuzzing, the release is way
> >> overdue as-is. We generally don't put experimental on decoders or demuxers.
> >>
> >
> > I think if we dont want it in the release either as you suggest
> > revert in master or mark as experimental in master before the branch
> >
> > having special cases in the release branch feels a bit iffy
> >
> 
> Okay, I can live with an experimental flag on it for the time being.

Ok, please add that experimental flag then

thx

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes

[-- 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] 5.0 release

[Michael Niedermayer]

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

On Sun, Jan 02, 2022 at 11:29:18PM +0100, Michael Niedermayer wrote:
> On Sun, Jan 02, 2022 at 07:12:54PM +0100, Lynne wrote:
> > 2 Jan 2022, 18:11 by michael@niedermayer.cc:
> > 
> > > On Sun, Jan 02, 2022 at 05:28:24PM +0100, Lynne wrote:
> > >
> > >> 2 Jan 2022, 16:52 by zane@zanevaniperen.com:
> > >>
> > >> >
> > >> >
> > >> > On 3/1/22 01:09, James Almer wrote:
> > >> >
> > >> >>>> Reverting something in the release branch is already going to be dirty
> > >> >>>> no matter what, because we do a minor bump to ensure the release has its
> > >> >>>> own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
> > >> >>>> a demuxer available in lavf 59.12
> > >> >>>>
> > >> >>>
> > >> >>> Depends on what you mean by "lacking a demuxer"... One (hacky) option would
> > >> >>> be to replace it with a stub implementation that always fails.
> > >> >>>
> > >> >>
> > >> >> Or tag it as experimental.
> > >> >>
> > >> >
> > >> > That's much better. If we're not willing to wait, then I suggest we do this.
> > >> >
> > >>
> > >> I'd rather have it reverted in master, branch 5.0, and add it back and bump minor
> > >> again. I'm not willing to wait for a month to get fuzzing, the release is way
> > >> overdue as-is. We generally don't put experimental on decoders or demuxers.
> > >>
> > >
> > > I think if we dont want it in the release either as you suggest
> > > revert in master or mark as experimental in master before the branch
> > >
> > > having special cases in the release branch feels a bit iffy
> > >
> > 
> > Okay, I can live with an experimental flag on it for the time being.
> 
> Ok, please add that experimental flag then

disregard that, just saw antons patch

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- 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] 5.0 release

[Jean-Baptiste Kempf]

On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote:
>> It would be nice to have a public date set a few days into the future.
>
> yes, i intended to do that, unless people wanted a ASAP/NOW branch

So what are the open topics, besides the Audio Channel Layout API?

Best,

-- 
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] 5.0 release

[Michael Niedermayer]

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

On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote:
> >> It would be nice to have a public date set a few days into the future.
> >
> > yes, i intended to do that, unless people wanted a ASAP/NOW branch
> 
> So what are the open topics, besides the Audio Channel Layout API?

the mov issue was fixed, channels dont seem to happen
theres a regression with 946493eb3e072b499909f606625480c928834a44
that ive reported 1 day after the patch was posted and pinged 11 days later

221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in single substream
221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>

thats not branch blocking, a bugfix is just a normal backport
I dont have the file that 946493eb3e072b499909f606625480c928834a44 fixes
so trying to fix it is like working blindfolded, thats why ive so far
waited for the author to respond and take a look

There may be other features someone wants in but i think delaying the release
for features is in general a bad idea. (there may be individual exceptions
where it makes sense)

And regressions & security issues, i hope there are no major ones.
If there are they should not block making the branch though

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.

[-- 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] 5.0 release

[Hendrik Leppkes]

On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> > On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote:
> > >> It would be nice to have a public date set a few days into the future.
> > >
> > > yes, i intended to do that, unless people wanted a ASAP/NOW branch
> >
> > So what are the open topics, besides the Audio Channel Layout API?
>
> the mov issue was fixed, channels dont seem to happen
> theres a regression with 946493eb3e072b499909f606625480c928834a44
> that ive reported 1 day after the patch was posted and pinged 11 days later
>
> 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in single substream
> 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
>
> thats not branch blocking, a bugfix is just a normal backport
> I dont have the file that 946493eb3e072b499909f606625480c928834a44 fixes
> so trying to fix it is like working blindfolded, thats why ive so far
> waited for the author to respond and take a look
>

As far as I can tell, the recent mlpdec changes seem to be intended to
fix playback of streams made by our own experimental encoder, and not
independent samples.
So perhaps those should be reverted for a stable release (or
generally), seeing as there is no response 2 months later, and no
indication what they actually fix.

The  available whitepapers and bitstream syntax document on TrueHD/MLP
also do not seem to support more then 2 channel in the first
substream, limiting it to a stereo presentation in the first, up to 6
channel in the second, and up to 8 channel in the third substream (and
16 in the extended substream)

Unfortunately the patch was also never on the ML for discussion or review.

- Hendrik
_______________________________________________
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] 5.0 release

[Hendrik Leppkes]

On Mon, Jan 3, 2022 at 6:17 PM Hendrik Leppkes <h.leppkes@gmail.com> wrote:
>
> Unfortunately the patch was also never on the ML for discussion or review.
>

 Sorry, I was blind, it was in fact on the ML. I must've been thinking
of something else..

- Hendrik
_______________________________________________
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] 5.0 release

[Paul B Mahol]

On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes <h.leppkes@gmail.com> wrote:

> On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> >
> > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> > > On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote:
> > > >> It would be nice to have a public date set a few days into the
> future.
> > > >
> > > > yes, i intended to do that, unless people wanted a ASAP/NOW branch
> > >
> > > So what are the open topics, besides the Audio Channel Layout API?
> >
> > the mov issue was fixed, channels dont seem to happen
> > theres a regression with 946493eb3e072b499909f606625480c928834a44
> > that ive reported 1 day after the patch was posted and pinged 11 days
> later
> >
> > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel]
> [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in single
> substream
> > 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> >
> > thats not branch blocking, a bugfix is just a normal backport
> > I dont have the file that 946493eb3e072b499909f606625480c928834a44 fixes
> > so trying to fix it is like working blindfolded, thats why ive so far
> > waited for the author to respond and take a look
> >
>
> As far as I can tell, the recent mlpdec changes seem to be intended to
> fix playback of streams made by our own experimental encoder, and not
> independent samples.
> So perhaps those should be reverted for a stable release (or
> generally), seeing as there is no response 2 months later, and no
> indication what they actually fix.
>
> The  available whitepapers and bitstream syntax document on TrueHD/MLP
> also do not seem to support more then 2 channel in the first
> substream, limiting it to a stereo presentation in the first, up to 6
> channel in the second, and up to 8 channel in the third substream (and
> 16 in the extended substream)
>

This statement is not in sync with reality.

I have sample that 946... fixes, single stream with > 2 channels.


>
> Unfortunately the patch was also never on the ML for discussion or review.
>
> - Hendrik
> _______________________________________________
> 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] 5.0 release

[Michael Niedermayer]

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

On Mon, Jan 03, 2022 at 07:04:48PM +0100, Paul B Mahol wrote:
> On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes <h.leppkes@gmail.com> wrote:
> 
> > On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
> > <michael@niedermayer.cc> wrote:
> > >
> > > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> > > > On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote:
> > > > >> It would be nice to have a public date set a few days into the
> > future.
> > > > >
> > > > > yes, i intended to do that, unless people wanted a ASAP/NOW branch
> > > >
> > > > So what are the open topics, besides the Audio Channel Layout API?
> > >
> > > the mov issue was fixed, channels dont seem to happen
> > > theres a regression with 946493eb3e072b499909f606625480c928834a44
> > > that ive reported 1 day after the patch was posted and pinged 11 days
> > later
> > >
> > > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel]
> > [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in single
> > substream
> > > 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> > >
> > > thats not branch blocking, a bugfix is just a normal backport
> > > I dont have the file that 946493eb3e072b499909f606625480c928834a44 fixes
> > > so trying to fix it is like working blindfolded, thats why ive so far
> > > waited for the author to respond and take a look
> > >
> >
> > As far as I can tell, the recent mlpdec changes seem to be intended to
> > fix playback of streams made by our own experimental encoder, and not
> > independent samples.

How can that be reproduced ?
I tried with a 5.1 stream and the decoded output is not changing with this
patch


> > So perhaps those should be reverted for a stable release (or
> > generally), seeing as there is no response 2 months later, and no
> > indication what they actually fix.
> >
> > The  available whitepapers and bitstream syntax document on TrueHD/MLP
> > also do not seem to support more then 2 channel in the first
> > substream, limiting it to a stereo presentation in the first, up to 6
> > channel in the second, and up to 8 channel in the third substream (and
> > 16 in the extended substream)
> >
> 
> This statement is not in sync with reality.
> 
> I have sample that 946... fixes, single stream with > 2 channels.

Iam not sure i understand what you mean exactly but

the sample which it breaks is here:
https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1726/Mono.thd

can you look into this issue, you as author of the change maybe
remember why you did it and so are better qualified to adjust it.

thx

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

Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.

[-- 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] 5.0 release

[Paul B Mahol]

On Mon, Jan 3, 2022 at 7:58 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Mon, Jan 03, 2022 at 07:04:48PM +0100, Paul B Mahol wrote:
> > On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes <h.leppkes@gmail.com>
> wrote:
> >
> > > On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
> > > <michael@niedermayer.cc> wrote:
> > > >
> > > > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> > > > > On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote:
> > > > > >> It would be nice to have a public date set a few days into the
> > > future.
> > > > > >
> > > > > > yes, i intended to do that, unless people wanted a ASAP/NOW
> branch
> > > > >
> > > > > So what are the open topics, besides the Audio Channel Layout API?
> > > >
> > > > the mov issue was fixed, channels dont seem to happen
> > > > theres a regression with 946493eb3e072b499909f606625480c928834a44
> > > > that ive reported 1 day after the patch was posted and pinged 11 days
> > > later
> > > >
> > > > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel]
> > > [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in
> single
> > > substream
> > > > 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> > > >
> > > > thats not branch blocking, a bugfix is just a normal backport
> > > > I dont have the file that 946493eb3e072b499909f606625480c928834a44
> fixes
> > > > so trying to fix it is like working blindfolded, thats why ive so far
> > > > waited for the author to respond and take a look
> > > >
> > >
> > > As far as I can tell, the recent mlpdec changes seem to be intended to
> > > fix playback of streams made by our own experimental encoder, and not
> > > independent samples.
>
> How can that be reproduced ?
> I tried with a 5.1 stream and the decoded output is not changing with this
> patch
>
>
> > > So perhaps those should be reverted for a stable release (or
> > > generally), seeing as there is no response 2 months later, and no
> > > indication what they actually fix.
> > >
> > > The  available whitepapers and bitstream syntax document on TrueHD/MLP
> > > also do not seem to support more then 2 channel in the first
> > > substream, limiting it to a stereo presentation in the first, up to 6
> > > channel in the second, and up to 8 channel in the third substream (and
> > > 16 in the extended substream)
> > >
> >
> > This statement is not in sync with reality.
> >
> > I have sample that 946... fixes, single stream with > 2 channels.
>
> Iam not sure i understand what you mean exactly but
>
> the sample which it breaks is here:
> https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1726/Mono.thd
>
> can you look into this issue, you as author of the change maybe
> remember why you did it and so are better qualified to adjust it.
>

Sorry but that sample was never decoded properly. As it is not mono and it
is not stereo.


>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Homeopathy is like voting while filling the ballot out with transparent
> ink.
> Sometimes the outcome one wanted occurs. Rarely its worse than filling out
> a ballot properly.
> _______________________________________________
> 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] 5.0 release

[Michael Niedermayer]

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

On Mon, Jan 03, 2022 at 08:25:44PM +0100, Paul B Mahol wrote:
> On Mon, Jan 3, 2022 at 7:58 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > On Mon, Jan 03, 2022 at 07:04:48PM +0100, Paul B Mahol wrote:
> > > On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes <h.leppkes@gmail.com>
> > wrote:
> > >
> > > > On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
> > > > <michael@niedermayer.cc> wrote:
> > > > >
> > > > > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> > > > > > On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote:
> > > > > > >> It would be nice to have a public date set a few days into the
> > > > future.
> > > > > > >
> > > > > > > yes, i intended to do that, unless people wanted a ASAP/NOW
> > branch
> > > > > >
> > > > > > So what are the open topics, besides the Audio Channel Layout API?
> > > > >
> > > > > the mov issue was fixed, channels dont seem to happen
> > > > > theres a regression with 946493eb3e072b499909f606625480c928834a44
> > > > > that ive reported 1 day after the patch was posted and pinged 11 days
> > > > later
> > > > >
> > > > > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel]
> > > > [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in
> > single
> > > > substream
> > > > > 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> > > > >
> > > > > thats not branch blocking, a bugfix is just a normal backport
> > > > > I dont have the file that 946493eb3e072b499909f606625480c928834a44
> > fixes
> > > > > so trying to fix it is like working blindfolded, thats why ive so far
> > > > > waited for the author to respond and take a look
> > > > >
> > > >
> > > > As far as I can tell, the recent mlpdec changes seem to be intended to
> > > > fix playback of streams made by our own experimental encoder, and not
> > > > independent samples.
> >
> > How can that be reproduced ?
> > I tried with a 5.1 stream and the decoded output is not changing with this
> > patch
> >
> >
> > > > So perhaps those should be reverted for a stable release (or
> > > > generally), seeing as there is no response 2 months later, and no
> > > > indication what they actually fix.
> > > >
> > > > The  available whitepapers and bitstream syntax document on TrueHD/MLP
> > > > also do not seem to support more then 2 channel in the first
> > > > substream, limiting it to a stereo presentation in the first, up to 6
> > > > channel in the second, and up to 8 channel in the third substream (and
> > > > 16 in the extended substream)
> > > >
> > >
> > > This statement is not in sync with reality.
> > >
> > > I have sample that 946... fixes, single stream with > 2 channels.
> >
> > Iam not sure i understand what you mean exactly but
> >
> > the sample which it breaks is here:
> > https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1726/Mono.thd
> >
> > can you look into this issue, you as author of the change maybe
> > remember why you did it and so are better qualified to adjust it.
> >
> 
> Sorry but that sample was never decoded properly. As it is not mono and it
> is not stereo.

around the time of 3.2 it was decoded as mono and it sounds reasonable
after that until 946... it was decoded as stereo with only the left channel
after 946... it now doesnt decode at all

it would be nice if we could support this kind of file

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] 5.0 release

[Paul B Mahol]

On Mon, Jan 3, 2022 at 9:14 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Mon, Jan 03, 2022 at 08:25:44PM +0100, Paul B Mahol wrote:
> > On Mon, Jan 3, 2022 at 7:58 PM Michael Niedermayer <
> michael@niedermayer.cc>
> > wrote:
> >
> > > On Mon, Jan 03, 2022 at 07:04:48PM +0100, Paul B Mahol wrote:
> > > > On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes <h.leppkes@gmail.com>
> > > wrote:
> > > >
> > > > > On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
> > > > > <michael@niedermayer.cc> wrote:
> > > > > >
> > > > > > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf
> wrote:
> > > > > > > On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote:
> > > > > > > >> It would be nice to have a public date set a few days into
> the
> > > > > future.
> > > > > > > >
> > > > > > > > yes, i intended to do that, unless people wanted a ASAP/NOW
> > > branch
> > > > > > >
> > > > > > > So what are the open topics, besides the Audio Channel Layout
> API?
> > > > > >
> > > > > > the mov issue was fixed, channels dont seem to happen
> > > > > > theres a regression with 946493eb3e072b499909f606625480c928834a44
> > > > > > that ive reported 1 day after the patch was posted and pinged 11
> days
> > > > > later
> > > > > >
> > > > > > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel]
> > > > > [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in
> > > single
> > > > > substream
> > > > > > 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> > > > > >
> > > > > > thats not branch blocking, a bugfix is just a normal backport
> > > > > > I dont have the file that
> 946493eb3e072b499909f606625480c928834a44
> > > fixes
> > > > > > so trying to fix it is like working blindfolded, thats why ive
> so far
> > > > > > waited for the author to respond and take a look
> > > > > >
> > > > >
> > > > > As far as I can tell, the recent mlpdec changes seem to be
> intended to
> > > > > fix playback of streams made by our own experimental encoder, and
> not
> > > > > independent samples.
> > >
> > > How can that be reproduced ?
> > > I tried with a 5.1 stream and the decoded output is not changing with
> this
> > > patch
> > >
> > >
> > > > > So perhaps those should be reverted for a stable release (or
> > > > > generally), seeing as there is no response 2 months later, and no
> > > > > indication what they actually fix.
> > > > >
> > > > > The  available whitepapers and bitstream syntax document on
> TrueHD/MLP
> > > > > also do not seem to support more then 2 channel in the first
> > > > > substream, limiting it to a stereo presentation in the first, up
> to 6
> > > > > channel in the second, and up to 8 channel in the third substream
> (and
> > > > > 16 in the extended substream)
> > > > >
> > > >
> > > > This statement is not in sync with reality.
> > > >
> > > > I have sample that 946... fixes, single stream with > 2 channels.
> > >
> > > Iam not sure i understand what you mean exactly but
> > >
> > > the sample which it breaks is here:
> > > https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1726/Mono.thd
> > >
> > > can you look into this issue, you as author of the change maybe
> > > remember why you did it and so are better qualified to adjust it.
> > >
> >
> > Sorry but that sample was never decoded properly. As it is not mono and
> it
> > is not stereo.
>
> around the time of 3.2 it was decoded as mono and it sounds reasonable
> after that until 946... it was decoded as stereo with only the left channel
> after 946... it now doesnt decode at all
>
> it would be nice if we could support this kind of file
>

To really support it, it needs both streams to be presented.


>
> 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
> _______________________________________________
> 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] 5.0 release

[Michael Niedermayer]

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

On Mon, Jan 03, 2022 at 09:29:40PM +0100, Paul B Mahol wrote:
> On Mon, Jan 3, 2022 at 9:14 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > On Mon, Jan 03, 2022 at 08:25:44PM +0100, Paul B Mahol wrote:
> > > On Mon, Jan 3, 2022 at 7:58 PM Michael Niedermayer <
> > michael@niedermayer.cc>
> > > wrote:
> > >
> > > > On Mon, Jan 03, 2022 at 07:04:48PM +0100, Paul B Mahol wrote:
> > > > > On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes <h.leppkes@gmail.com>
> > > > wrote:
> > > > >
> > > > > > On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
> > > > > > <michael@niedermayer.cc> wrote:
> > > > > > >
> > > > > > > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf
> > wrote:
> > > > > > > > On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote:
> > > > > > > > >> It would be nice to have a public date set a few days into
> > the
> > > > > > future.
> > > > > > > > >
> > > > > > > > > yes, i intended to do that, unless people wanted a ASAP/NOW
> > > > branch
> > > > > > > >
> > > > > > > > So what are the open topics, besides the Audio Channel Layout
> > API?
> > > > > > >
> > > > > > > the mov issue was fixed, channels dont seem to happen
> > > > > > > theres a regression with 946493eb3e072b499909f606625480c928834a44
> > > > > > > that ive reported 1 day after the patch was posted and pinged 11
> > days
> > > > > > later
> > > > > > >
> > > > > > > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel]
> > > > > > [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in
> > > > single
> > > > > > substream
> > > > > > > 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> > > > > > >
> > > > > > > thats not branch blocking, a bugfix is just a normal backport
> > > > > > > I dont have the file that
> > 946493eb3e072b499909f606625480c928834a44
> > > > fixes
> > > > > > > so trying to fix it is like working blindfolded, thats why ive
> > so far
> > > > > > > waited for the author to respond and take a look
> > > > > > >
> > > > > >
> > > > > > As far as I can tell, the recent mlpdec changes seem to be
> > intended to
> > > > > > fix playback of streams made by our own experimental encoder, and
> > not
> > > > > > independent samples.
> > > >
> > > > How can that be reproduced ?
> > > > I tried with a 5.1 stream and the decoded output is not changing with
> > this
> > > > patch
> > > >
> > > >
> > > > > > So perhaps those should be reverted for a stable release (or
> > > > > > generally), seeing as there is no response 2 months later, and no
> > > > > > indication what they actually fix.
> > > > > >
> > > > > > The  available whitepapers and bitstream syntax document on
> > TrueHD/MLP
> > > > > > also do not seem to support more then 2 channel in the first
> > > > > > substream, limiting it to a stereo presentation in the first, up
> > to 6
> > > > > > channel in the second, and up to 8 channel in the third substream
> > (and
> > > > > > 16 in the extended substream)
> > > > > >
> > > > >
> > > > > This statement is not in sync with reality.
> > > > >
> > > > > I have sample that 946... fixes, single stream with > 2 channels.
> > > >
> > > > Iam not sure i understand what you mean exactly but
> > > >
> > > > the sample which it breaks is here:
> > > > https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1726/Mono.thd
> > > >
> > > > can you look into this issue, you as author of the change maybe
> > > > remember why you did it and so are better qualified to adjust it.
> > > >
> > >
> > > Sorry but that sample was never decoded properly. As it is not mono and
> > it
> > > is not stereo.
> >
> > around the time of 3.2 it was decoded as mono and it sounds reasonable
> > after that until 946... it was decoded as stereo with only the left channel
> > after 946... it now doesnt decode at all
> >
> > it would be nice if we could support this kind of file
> >
> 
> To really support it, it needs both streams to be presented.

yes

thx

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

No great genius has ever existed without some touch of madness. -- 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] 5.0 release

[Michael Niedermayer]

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

On Mon, Jan 03, 2022 at 05:14:13PM +0100, Michael Niedermayer wrote:
> On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> > On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote:
> > >> It would be nice to have a public date set a few days into the future.
> > >
> > > yes, i intended to do that, unless people wanted a ASAP/NOW branch
> > 
> > So what are the open topics, besides the Audio Channel Layout API?
> 
> the mov issue was fixed, channels dont seem to happen
> theres a regression with 946493eb3e072b499909f606625480c928834a44
> that ive reported 1 day after the patch was posted and pinged 11 days later
> 
> 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in single substream
> 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> 
> thats not branch blocking, a bugfix is just a normal backport
> I dont have the file that 946493eb3e072b499909f606625480c928834a44 fixes
> so trying to fix it is like working blindfolded, thats why ive so far
> waited for the author to respond and take a look
> 
> There may be other features someone wants in but i think delaying the release
> for features is in general a bad idea. (there may be individual exceptions
> where it makes sense)
> 
> And regressions & security issues, i hope there are no major ones.
> If there are they should not block making the branch though

Also 

imfdec / experimental flag
we have a patchset from anton, there where some comments, i think nothing
blocking it but it needs to be applied

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire

[-- 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] 5.0 release

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Jean-
> Baptiste Kempf
> Sent: Monday, January 3, 2022 6:32 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] 5.0 release
> 
> On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote:
> >> It would be nice to have a public date set a few days into the future.
> >
> > yes, i intended to do that, unless people wanted a ASAP/NOW branch
> 
> So what are the open topics, besides the Audio Channel Layout API?

If you don't want to ship a regression:

[PATCH v2] avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)

Regards,
softworkz
_______________________________________________
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] 5.0 release

[Lynne]

31 Dec 2021, 17:52 by michael@niedermayer.cc:

> On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:
>
>> On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
>> > On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
>> > > Is the December target to get into the feature freeze schedule from 
>> > > distros?
>> > 
>> > No, it was set by me, in order to get the distro freezes from January.
>> > 
>>
>> > We can miss the target a bit this year, and then make it better for 2022.
>>
>> as you seem to know the distro freeze shedules
>> can you clarify "a bit" ?
>>
>> iam asking just in case the channel patch doesnt make it before
>> so i know when its time to stop waiting for it
>>
>
> ok
> when do people want me to make the branch ?
> any preferrances ?
> should i do it now or continue waiting?
>

Not yet, mkver is still offline, we're waiting on him to give his
opinion on the dovi patchset. I think dovi is pretty important for
5.0, since it's gotten popular as streaming providers now use it.
He was online earlier this morning, but I forgot to ping him :P


> I saw on IRC some sugestions to make it at a past commit to keep some
> code out
>

Once its time, make it from git master, just revert 73f6cce936130ab
and 6b7e4de0dbc from the release branch.
_______________________________________________
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".