[FFmpeg-devel] FFmpeg 7.0 blocking issues

[FFmpeg-devel] FFmpeg 7.0 blocking issues

[Michael Niedermayer]

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

Hi all

As it was a little difficult for me to not loose track of what is
blocking a release. I suggest that for all release blocking issues
open a ticket and set Blocking to 7.0
that way this:
https://trac.ffmpeg.org/query?blocking=~7.0

or for the ones not closed:
https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0

will list all blocking issues

Ive added one, for testing that, i intend to add more if i see something

What is blocking? (IMHO)
* regressions (unless its non possible to fix before release)
* crashes
* security issues
* data loss
* privacy issues
* anything the commuity agrees should be in the release

thx


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus

[-- 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 7.0 blocking issues

[Lynne]

Jan 23, 2024, 20:22 by michael@niedermayer.cc:

> Hi all
>
> As it was a little difficult for me to not loose track of what is
> blocking a release. I suggest that for all release blocking issues
> open a ticket and set Blocking to 7.0
> that way this:
> https://trac.ffmpeg.org/query?blocking=~7.0
>
> or for the ones not closed:
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>
> will list all blocking issues
>
> Ive added one, for testing that, i intend to add more if i see something
>
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
> * data loss
> * privacy issues
> * anything the commuity agrees should be in the release
>

On my side, what I want:
Vulkan AV1. It's ready to be posted once the spec goes public very very soon.
This shouldn't even become a blocker unless you want a release tagged immediately.

And those that I don't consider as blockers, just something nice to have:

Vulkan encode (H264). Needs about a week of work.
HE-AAC 960-point.
Preliminary xHE-AAC support. Not sure.
AAC prepad fixes - perhaps partial (off by one sample for SBR).

Should be able to finish a couple by mid-February for a release by
late February like last 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 7.0 blocking issues

[Anton Khirnov]

Quoting Lynne (2024-01-23 21:18:29)
> Jan 23, 2024, 20:22 by michael@niedermayer.cc:
> 
> > Hi all
> >
> > As it was a little difficult for me to not loose track of what is
> > blocking a release. I suggest that for all release blocking issues
> > open a ticket and set Blocking to 7.0
> > that way this:
> > https://trac.ffmpeg.org/query?blocking=~7.0
> >
> > or for the ones not closed:
> > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> >
> > will list all blocking issues
> >
> > Ive added one, for testing that, i intend to add more if i see something
> >
> > What is blocking? (IMHO)
> > * regressions (unless its non possible to fix before release)
> > * crashes
> > * security issues
> > * data loss
> > * privacy issues
> > * anything the commuity agrees should be in the release
> >
> 
> On my side, what I want:
> Vulkan AV1. It's ready to be posted once the spec goes public very very soon.
> This shouldn't even become a blocker unless you want a release tagged immediately.
> 
> And those that I don't consider as blockers, just something nice to have:
> 
> Vulkan encode (H264). Needs about a week of work.
> HE-AAC 960-point.
> Preliminary xHE-AAC support. Not sure.
> AAC prepad fixes - perhaps partial (off by one sample for SBR).

Sigh. We already had this drama last time, must we do it again?
If you haven't even started working on it yet, then it shouldn't be a
blocker for the release, it can wait half a year for 7.1.

-- 
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] FFmpeg 7.0 blocking issues

[Lynne]

Jan 24, 2024, 08:40 by anton@khirnov.net:

> Quoting Lynne (2024-01-23 21:18:29)
>
>> Jan 23, 2024, 20:22 by michael@niedermayer.cc:
>>
>> > Hi all
>> >
>> > As it was a little difficult for me to not loose track of what is
>> > blocking a release. I suggest that for all release blocking issues
>> > open a ticket and set Blocking to 7.0
>> > that way this:
>> > https://trac.ffmpeg.org/query?blocking=~7.0
>> >
>> > or for the ones not closed:
>> > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>> >
>> > will list all blocking issues
>> >
>> > Ive added one, for testing that, i intend to add more if i see something
>> >
>> > What is blocking? (IMHO)
>> > * regressions (unless its non possible to fix before release)
>> > * crashes
>> > * security issues
>> > * data loss
>> > * privacy issues
>> > * anything the commuity agrees should be in the release
>> >
>>
>> On my side, what I want:
>> Vulkan AV1. It's ready to be posted once the spec goes public very very soon.
>> This shouldn't even become a blocker unless you want a release tagged immediately.
>>
>> And those that I don't consider as blockers, just something nice to have:
>>
>> Vulkan encode (H264). Needs about a week of work.
>> HE-AAC 960-point.
>> Preliminary xHE-AAC support. Not sure.
>> AAC prepad fixes - perhaps partial (off by one sample for SBR).
>>
>
> Sigh. We already had this drama last time, must we do it again?
> If you haven't even started working on it yet, then it shouldn't be a
> blocker for the release, it can wait half a year for 7.1.
>

Which part of "don't consider as blockers" did you find difficult to understand?
I even added newlines top and bottom for you to laser onto that sentence.

I have started on everything, and two things are finished but need polish,
one is difficult and needs debugging while the other is more difficult.

And with that release rate attitude, how do you think we can go to our one
release every few months promise?
_______________________________________________
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 7.0 blocking issues

[Anton Khirnov]

Quoting Lynne (2024-01-24 13:07:51)
> Which part of "don't consider as blockers" did you find difficult to understand?
> I even added newlines top and bottom for you to laser onto that sentence.

Then why are you mentioning them in a thread specifically about release
blockers.

> I have started on everything, and two things are finished but need polish,
> one is difficult and needs debugging while the other is more difficult.
> 
> And with that release rate attitude, how do you think we can go to our one
> release every few months promise?

I don't understand what you mean by this.

-- 
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] FFmpeg 7.0 blocking issues

[Lynne]

Jan 24, 2024, 13:30 by anton@khirnov.net:

> Quoting Lynne (2024-01-24 13:07:51)
>
>> Which part of "don't consider as blockers" did you find difficult to understand?
>> I even added newlines top and bottom for you to laser onto that sentence.
>>
>
> Then why are you mentioning them in a thread specifically about release
> blockers.
>

Because it was a question about blockers, and I mentioned one.
Then I thought I'd share what I'm working on, that someone else might
find interesting, and if so, they could either help or express interest?
Hence, "would be nice to have". I will not argue that they should be
blockers, hence "not a blocker".


>> I have started on everything, and two things are finished but need polish,
>> one is difficult and needs debugging while the other is more difficult.
>>
>> And with that release rate attitude, how do you think we can go to our one
>> release every few months promise?
>>
>
> I don't understand what you mean by this.
>

You mentioned half a year, but we planned to make a release every
two months under the new release model from 2 years ago.
So I just think rather than aiming for half a year, we should aim for
a few months, that's all.
_______________________________________________
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 7.0 blocking issues

[Anton Khirnov]

Quoting Lynne (2024-01-24 14:14:00)
> Jan 24, 2024, 13:30 by anton@khirnov.net:
> >> I have started on everything, and two things are finished but need polish,
> >> one is difficult and needs debugging while the other is more difficult.
> >>
> >> And with that release rate attitude, how do you think we can go to our one
> >> release every few months promise?
> >>
> >
> > I don't understand what you mean by this.
> >
> 
> You mentioned half a year, but we planned to make a release every
> two months under the new release model from 2 years ago.

I am not aware of such plans, and this sounds unfeasible to me. We
can barely follow the twice-per-year schedule.

-- 
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] FFmpeg 7.0 blocking issues

[Lynne]

Jan 24, 2024, 14:24 by anton@khirnov.net:

> Quoting Lynne (2024-01-24 14:14:00)
>
>> Jan 24, 2024, 13:30 by anton@khirnov.net:
>> >> I have started on everything, and two things are finished but need polish,
>> >> one is difficult and needs debugging while the other is more difficult.
>> >>
>> >> And with that release rate attitude, how do you think we can go to our one
>> >> release every few months promise?
>> >>
>> >
>> > I don't understand what you mean by this.
>> >
>>
>> You mentioned half a year, but we planned to make a release every
>> two months under the new release model from 2 years ago.
>>
>
> I am not aware of such plans, and this sounds unfeasible to me. We
> can barely follow the twice-per-year schedule.
>

https://ffmpeg.org//index.html#news

> February 28th, 2023, FFmpeg 6.0 "Von Neumann"> Another release-specific change is that deprecated APIs will be removed after 3    releases, upon the > next major bump.    This means that releases will be done more often and will be more organized.

It's in the original proposal from 2 years ago.
Releases will be much easier if we just do releases more often.
_______________________________________________
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 7.0 blocking issues

[James Almer]

On 1/24/2024 4:40 AM, Anton Khirnov wrote:
> Quoting Lynne (2024-01-23 21:18:29)
>> Jan 23, 2024, 20:22 by michael@niedermayer.cc:
>>
>>> Hi all
>>>
>>> As it was a little difficult for me to not loose track of what is
>>> blocking a release. I suggest that for all release blocking issues
>>> open a ticket and set Blocking to 7.0
>>> that way this:
>>> https://trac.ffmpeg.org/query?blocking=~7.0
>>>
>>> or for the ones not closed:
>>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>>>
>>> will list all blocking issues
>>>
>>> Ive added one, for testing that, i intend to add more if i see something
>>>
>>> What is blocking? (IMHO)
>>> * regressions (unless its non possible to fix before release)
>>> * crashes
>>> * security issues
>>> * data loss
>>> * privacy issues
>>> * anything the commuity agrees should be in the release
>>>
>>
>> On my side, what I want:
>> Vulkan AV1. It's ready to be posted once the spec goes public very very soon.
>> This shouldn't even become a blocker unless you want a release tagged immediately.
>>
>> And those that I don't consider as blockers, just something nice to have:
>>
>> Vulkan encode (H264). Needs about a week of work.
>> HE-AAC 960-point.
>> Preliminary xHE-AAC support. Not sure.
>> AAC prepad fixes - perhaps partial (off by one sample for SBR).
> 
> Sigh. We already had this drama last time, must we do it again?

She said these are not blockers. But i do agree that even if they are 
finished on time, if they are too big or require some proper testing 
after being merged, then perhaps it would be best to wait until the 
following release. Otherwise it could result in having to rush a 7.0.1 
point release.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues

[Anton Khirnov]

Quoting Michael Niedermayer (2024-01-23 20:22:41)
> Hi all
> 
> As it was a little difficult for me to not loose track of what is
> blocking a release. I suggest that for all release blocking issues
> open a ticket and set Blocking to 7.0
> that way this:
> https://trac.ffmpeg.org/query?blocking=~7.0
> 
> or for the ones not closed:
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> 
> will list all blocking issues
> 
> Ive added one, for testing that, i intend to add more if i see something
> 
> What is blocking? (IMHO)
> * anything the commuity agrees should be in the release

IIUC we wanted to do a major bump before 7.0

-- 
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] FFmpeg 7.0 blocking issues

[James Almer]

On 1/24/2024 4:45 AM, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-01-23 20:22:41)
>> Hi all
>>
>> As it was a little difficult for me to not loose track of what is
>> blocking a release. I suggest that for all release blocking issues
>> open a ticket and set Blocking to 7.0
>> that way this:
>> https://trac.ffmpeg.org/query?blocking=~7.0
>>
>> or for the ones not closed:
>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>>
>> will list all blocking issues
>>
>> Ive added one, for testing that, i intend to add more if i see something
>>
>> What is blocking? (IMHO)
>> * anything the commuity agrees should be in the release
> 
> IIUC we wanted to do a major bump before 7.0

Yes, I have a set for that. Will be sending it soon.
_______________________________________________
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 7.0 blocking issues

[Niklas Haas]

On Tue, 23 Jan 2024 20:22:41 +0100 Michael Niedermayer <michael@niedermayer.cc> wrote:
> Hi all
> 
> As it was a little difficult for me to not loose track of what is
> blocking a release. I suggest that for all release blocking issues
> open a ticket and set Blocking to 7.0
> that way this:
> https://trac.ffmpeg.org/query?blocking=~7.0
> 
> or for the ones not closed:
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> 
> will list all blocking issues
> 
> Ive added one, for testing that, i intend to add more if i see something
> 
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
> * data loss
> * privacy issues
> * anything the commuity agrees should be in the release

I'd like to discuss YUVJ deprecation/removal. To what extent do we need to put
an additional deprecation warning on these? libswscale already prints a warning
on every use, informing the user that they need to set metadata correctly.

Is it feasible to replace YUVJ pixfmts by #define for their non-YUV equivalent
analogs in 7.0? 7.1?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues

[Anton Khirnov]

Quoting Niklas Haas (2024-01-24 13:45:33)
> On Tue, 23 Jan 2024 20:22:41 +0100 Michael Niedermayer <michael@niedermayer.cc> wrote:
> > Hi all
> > 
> > As it was a little difficult for me to not loose track of what is
> > blocking a release. I suggest that for all release blocking issues
> > open a ticket and set Blocking to 7.0
> > that way this:
> > https://trac.ffmpeg.org/query?blocking=~7.0
> > 
> > or for the ones not closed:
> > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > 
> > will list all blocking issues
> > 
> > Ive added one, for testing that, i intend to add more if i see something
> > 
> > What is blocking? (IMHO)
> > * regressions (unless its non possible to fix before release)
> > * crashes
> > * security issues
> > * data loss
> > * privacy issues
> > * anything the commuity agrees should be in the release
> 
> I'd like to discuss YUVJ deprecation/removal. To what extent do we need to put
> an additional deprecation warning on these? libswscale already prints a warning
> on every use, informing the user that they need to set metadata correctly.
> 
> Is it feasible to replace YUVJ pixfmts by #define for their non-YUV equivalent
> analogs in 7.0? 7.1?

What would then happens to current lavc and lavfi callers that still use
them? AFAIU you cannot avoid them until your patchset goes in, right?

-- 
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] FFmpeg 7.0 blocking issues

[Kieran Kunhya]

>
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
>

Is VVC being run through oss-fuzz yet? I think it would be a shame for 7.0
to be released then a ton of CVEs come out and the security community
hysterically saying FFmpeg is insecure.

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 7.0 blocking issues

[Derek Buitenhuis]

Hi,

On 1/23/2024 7:22 PM, Michael Niedermayer wrote:
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
> * data loss
> * privacy issues
> * anything the commuity agrees should be in the release

We discussed it at FOSDEM, but I forgot to mark it as blocking at the time:

Curently master is broken when files have both stream and frame level metadata
of the same type.

We all agreed on the fix, so nothing controversial, though - should be in meeting
notes.

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

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

Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues

[Michael Niedermayer]

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

On Wed, Feb 07, 2024 at 02:54:23PM +0000, Derek Buitenhuis wrote:
> Hi,
> 
> On 1/23/2024 7:22 PM, Michael Niedermayer wrote:
> > What is blocking? (IMHO)
> > * regressions (unless its non possible to fix before release)
> > * crashes
> > * security issues
> > * data loss
> > * privacy issues
> > * anything the commuity agrees should be in the release
> 
> We discussed it at FOSDEM, but I forgot to mark it as blocking at the time:
> 
> Curently master is broken when files have both stream and frame level metadata
> of the same type.
> 
> We all agreed on the fix, so nothing controversial, though - should be in meeting
> notes.

please make sure its marked on the bug tracker so it shows up here:

https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0

thx

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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.

[-- 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 7.0 blocking issues

[Derek Buitenhuis]

On 2/9/2024 3:32 AM, Michael Niedermayer wrote:
> please make sure its marked on the bug tracker so it shows up here:
> 
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> 
> thx

Done: https://trac.ffmpeg.org/ticket/10857

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

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

Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues

[Leo Izen]

[-- Attachment #1.1.1: Type: text/plain, Size: 949 bytes --]

On 1/23/24 14:22, Michael Niedermayer wrote:
> Hi all
> 
> As it was a little difficult for me to not loose track of what is
> blocking a release. I suggest that for all release blocking issues
> open a ticket and set Blocking to 7.0
> that way this:
> https://trac.ffmpeg.org/query?blocking=~7.0
> 
> or for the ones not closed:
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> 
> will list all blocking issues
> 
> Ive added one, for testing that, i intend to add more if i see something
> 
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
> * data loss
> * privacy issues
> * anything the commuity agrees should be in the release
> 
> thx
> 
> 

My EXIF overhaul is going to be an ABI break so I'd like to get it in, 
if and only if we are doing an ABI break with the release.

- Leo Izen (Traneptora)

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 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 7.0 blocking issues

[Andreas Rheinhardt]

Leo Izen:
> On 1/23/24 14:22, Michael Niedermayer wrote:
>> Hi all
>>
>> As it was a little difficult for me to not loose track of what is
>> blocking a release. I suggest that for all release blocking issues
>> open a ticket and set Blocking to 7.0
>> that way this:
>> https://trac.ffmpeg.org/query?blocking=~7.0
>>
>> or for the ones not closed:
>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>>
>> will list all blocking issues
>>
>> Ive added one, for testing that, i intend to add more if i see something
>>
>> What is blocking? (IMHO)
>> * regressions (unless its non possible to fix before release)
>> * crashes
>> * security issues
>> * data loss
>> * privacy issues
>> * anything the commuity agrees should be in the release
>>
>> thx
>>
>>
> 
> My EXIF overhaul is going to be an ABI break so I'd like to get it in,
> if and only if we are doing an ABI break with the release.
> 

What EXIF overhaul? Since when is EXIF part of the ABI?

- Andreas

_______________________________________________
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 7.0 blocking issues

[Leo Izen]

[-- Attachment #1.1.1: Type: text/plain, Size: 1762 bytes --]



On 2/7/24 13:56, Andreas Rheinhardt wrote:
> Leo Izen:
>> On 1/23/24 14:22, Michael Niedermayer wrote:
>>> Hi all
>>>
>>> As it was a little difficult for me to not loose track of what is
>>> blocking a release. I suggest that for all release blocking issues
>>> open a ticket and set Blocking to 7.0
>>> that way this:
>>> https://trac.ffmpeg.org/query?blocking=~7.0
>>>
>>> or for the ones not closed:
>>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>>>
>>> will list all blocking issues
>>>
>>> Ive added one, for testing that, i intend to add more if i see something
>>>
>>> What is blocking? (IMHO)
>>> * regressions (unless its non possible to fix before release)
>>> * crashes
>>> * security issues
>>> * data loss
>>> * privacy issues
>>> * anything the commuity agrees should be in the release
>>>
>>> thx
>>>
>>>
>>
>> My EXIF overhaul is going to be an ABI break so I'd like to get it in,
>> if and only if we are doing an ABI break with the release.
>>
> 
> What EXIF overhaul? Since when is EXIF part of the ABI?
> 
> - Andreas
> 

I'm working on a patch to centralize a lot of the exif logic and make it 
easier for decoders to attach it to an AVFrame as side data, rather than 
dumping all the key/value pairs into AVFrame.metadata and then hoping 
that an encoder can serialize them out properly.

As for ABI, there's an avpriv in libavcodec/exif.c that is called by the 
AVI demuxer in avformat. My plan is to expose some of these exif parse 
routines as a proper av_ API, and replace that avpriv_ call with a call 
to the new API. I mentioned this to James on IRC and he said it would 
have to go in during an ABI flexibility period.

- Leo Izen



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 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 7.0 blocking issues

[James Almer]

On 2/7/2024 10:27 PM, Leo Izen wrote:
> 
> 
> On 2/7/24 13:56, Andreas Rheinhardt wrote:
>> Leo Izen:
>>> On 1/23/24 14:22, Michael Niedermayer wrote:
>>>> Hi all
>>>>
>>>> As it was a little difficult for me to not loose track of what is
>>>> blocking a release. I suggest that for all release blocking issues
>>>> open a ticket and set Blocking to 7.0
>>>> that way this:
>>>> https://trac.ffmpeg.org/query?blocking=~7.0
>>>>
>>>> or for the ones not closed:
>>>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>>>>
>>>> will list all blocking issues
>>>>
>>>> Ive added one, for testing that, i intend to add more if i see 
>>>> something
>>>>
>>>> What is blocking? (IMHO)
>>>> * regressions (unless its non possible to fix before release)
>>>> * crashes
>>>> * security issues
>>>> * data loss
>>>> * privacy issues
>>>> * anything the commuity agrees should be in the release
>>>>
>>>> thx
>>>>
>>>>
>>>
>>> My EXIF overhaul is going to be an ABI break so I'd like to get it in,
>>> if and only if we are doing an ABI break with the release.
>>>
>>
>> What EXIF overhaul? Since when is EXIF part of the ABI?
>>
>> - Andreas
>>
> 
> I'm working on a patch to centralize a lot of the exif logic and make it 
> easier for decoders to attach it to an AVFrame as side data, rather than 
> dumping all the key/value pairs into AVFrame.metadata and then hoping 
> that an encoder can serialize them out properly.
> 
> As for ABI, there's an avpriv in libavcodec/exif.c that is called by the 
> AVI demuxer in avformat. My plan is to expose some of these exif parse 
> routines as a proper av_ API, and replace that avpriv_ call with a call 
> to the new API. I mentioned this to James on IRC and he said it would 
> have to go in during an ABI flexibility period.

Removing avpriv_ symbols has to be during a major bump, but they can 
always just remain in place until the next.
If your work can't be finished on time (or reviews end up taking too 
long), then removing said symbols can wait, so we don't delay 7.0 just 
for it.

> 
> - Leo Izen
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
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 7.0 blocking issues

[Cosmin Stejerean via ffmpeg-devel]

> On Jan 23, 2024, at 11:22 AM, Michael Niedermayer <michael@niedermayer.cc> wrote:
> 
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
> * data loss
> * privacy issues
> * anything the commuity agrees should be in the release

Can we get the animated WebP decoding in before this release?

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

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

Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues

[James Almer]

On 1/23/2024 4:22 PM, Michael Niedermayer wrote:
> Hi all
> 
> As it was a little difficult for me to not loose track of what is
> blocking a release. I suggest that for all release blocking issues
> open a ticket and set Blocking to 7.0
> that way this:
> https://trac.ffmpeg.org/query?blocking=~7.0
> 
> or for the ones not closed:
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> 
> will list all blocking issues
> 
> Ive added one, for testing that, i intend to add more if i see something
> 
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
> * data loss
> * privacy issues
> * anything the commuity agrees should be in the release
> 
> thx

There are currently issues with the hevc decoder after some of the 
commits that shared code with the vvc decoder were pushed. You can see 
it by running the hevc conformance suite in FATE under GCC ubsan.

Nuo Mi said he's looking at them, but if it takes him too much time we 
can revert the faulty commits before the release, in either master or 
even the actual 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".

Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues

[Michael Niedermayer]

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

On Sat, Feb 10, 2024 at 06:03:57PM -0300, James Almer wrote:
> On 1/23/2024 4:22 PM, Michael Niedermayer wrote:
> > Hi all
> > 
> > As it was a little difficult for me to not loose track of what is
> > blocking a release. I suggest that for all release blocking issues
> > open a ticket and set Blocking to 7.0
> > that way this:
> > https://trac.ffmpeg.org/query?blocking=~7.0
> > 
> > or for the ones not closed:
> > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > 
> > will list all blocking issues
> > 
> > Ive added one, for testing that, i intend to add more if i see something
> > 
> > What is blocking? (IMHO)
> > * regressions (unless its non possible to fix before release)
> > * crashes
> > * security issues
> > * data loss
> > * privacy issues
> > * anything the commuity agrees should be in the release
> > 
> > thx
> 
> There are currently issues with the hevc decoder after some of the commits
> that shared code with the vvc decoder were pushed. You can see it by running
> the hevc conformance suite in FATE under GCC ubsan.
> 
> Nuo Mi said he's looking at them, but if it takes him too much time we can
> revert the faulty commits before the release, in either master or even the
> actual release branch.

Please create a ticket for this and add blocking: 7.0
So it cannot be forgotten

thx

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

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott


[-- 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 7.0 blocking issues

[Nuo Mi]

On Sun, Feb 11, 2024 at 9:35 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Sat, Feb 10, 2024 at 06:03:57PM -0300, James Almer wrote:
> > On 1/23/2024 4:22 PM, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > As it was a little difficult for me to not loose track of what is
> > > blocking a release. I suggest that for all release blocking issues
> > > open a ticket and set Blocking to 7.0
> > > that way this:
> > > https://trac.ffmpeg.org/query?blocking=~7.0
> > >
> > > or for the ones not closed:
> > >
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > >
> > > will list all blocking issues
> > >
> > > Ive added one, for testing that, i intend to add more if i see
> something
> > >
> > > What is blocking? (IMHO)
> > > * regressions (unless its non possible to fix before release)
> > > * crashes
> > > * security issues
> > > * data loss
> > > * privacy issues
> > > * anything the commuity agrees should be in the release
> > >
> > > thx
> >
> > There are currently issues with the hevc decoder after some of the
> commits
> > that shared code with the vvc decoder were pushed. You can see it by
> running
> > the hevc conformance suite in FATE under GCC ubsan.
> >
> > Nuo Mi said he's looking at them, but if it takes him too much time we
> can
> > revert the faulty commits before the release, in either master or even
> the
> > actual release branch.
>
> Please create a ticket for this and add blocking: 7.0
> So it cannot be forgotten
>
Will be fixed by
https://patchwork.ffmpeg.org/project/ffmpeg/patch/TYSPR06MB6433517914B4C4432D6799E5AA492@TYSPR06MB6433.apcprd06.prod.outlook.com/

>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> "Nothing to hide" only works if the folks in power share the values of
> you and everyone you know entirely and always will -- Tom Scott
>
> _______________________________________________
> 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 7.0 blocking issues

[Michael Niedermayer]

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

Hi all

about a month has passed
wanted to remind that we seem to have 2 blocking issues on trac

#10826	Short trim inside filter_complex leads to empty output	                                        new	defect	critical	ffmpeg	unspecified
#10857	Stream-level side data propagated to frames is indistinguishable from frame-level side data	new	defect	important	avcodec	git-master

https://trac.ffmpeg.org/ticket/10826
https://trac.ffmpeg.org/ticket/10857

I will create the branch once there are no blocking issues remaining.
If people dont care about the release, thats ok too, we dont need to make
one

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu

[-- 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 7.0 blocking issues

[James Almer]

On 2/25/2024 8:18 PM, Michael Niedermayer wrote:
> Hi all
> 
> about a month has passed
> wanted to remind that we seem to have 2 blocking issues on trac
> 
> #10826	Short trim inside filter_complex leads to empty output	                                        new	defect	critical	ffmpeg	unspecified
> #10857	Stream-level side data propagated to frames is indistinguishable from frame-level side data	new	defect	important	avcodec	git-master

Anton sent a patchset for this on.

> 
> https://trac.ffmpeg.org/ticket/10826
> https://trac.ffmpeg.org/ticket/10857
> 
> I will create the branch once there are no blocking issues remaining.
> If people dont care about the release, thats ok too, we dont need to make
> one

We do, it's been a while.
_______________________________________________
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 7.0 blocking issues

[Michael Niedermayer]

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

On Sun, Feb 25, 2024 at 08:20:13PM -0300, James Almer wrote:
> On 2/25/2024 8:18 PM, Michael Niedermayer wrote:
> > Hi all
> > 
> > about a month has passed
> > wanted to remind that we seem to have 2 blocking issues on trac
> > 
> > #10826	Short trim inside filter_complex leads to empty output	                                        new	defect	critical	ffmpeg	unspecified
> > #10857	Stream-level side data propagated to frames is indistinguishable from frame-level side data	new	defect	important	avcodec	git-master
> 
> Anton sent a patchset for this on.

good


> 
> > 
> > https://trac.ffmpeg.org/ticket/10826
> > https://trac.ffmpeg.org/ticket/10857
> > 
> > I will create the branch once there are no blocking issues remaining.
> > If people dont care about the release, thats ok too, we dont need to make
> > one
> 
> We do, it's been a while.

good, wanted to make sure as the issues are "new" not even "open"

thx

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

Some people wanted to paint the bikeshed green, some blue and some pink.
People argued and fought, when they finally agreed, only rust was left.

[-- 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 7.0 blocking issues

[Michael Niedermayer]

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

On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> Hi all
> 
> As it was a little difficult for me to not loose track of what is
> blocking a release. I suggest that for all release blocking issues
> open a ticket and set Blocking to 7.0
> that way this:
> https://trac.ffmpeg.org/query?blocking=~7.0
> 
> or for the ones not closed:
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> 
> will list all blocking issues
> 
> Ive added one, for testing that, i intend to add more if i see something
> 
> What is blocking? (IMHO)
> * regressions (unless its non possible to fix before release)
> * crashes
> * security issues
> * data loss
> * privacy issues
> * anything the commuity agrees should be in the release

We still have 3 blocking issues on trac

do people want me to wait or ignore them and branch ?
Iam not sure when the exact deadline is but if we keep waiting
we will not get into ubuntu 24.04 LTS

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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

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

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

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

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

Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues

[Sebastian Ramacher]

On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> > Hi all
> > 
> > As it was a little difficult for me to not loose track of what is
> > blocking a release. I suggest that for all release blocking issues
> > open a ticket and set Blocking to 7.0
> > that way this:
> > https://trac.ffmpeg.org/query?blocking=~7.0
> > 
> > or for the ones not closed:
> > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > 
> > will list all blocking issues
> > 
> > Ive added one, for testing that, i intend to add more if i see something
> > 
> > What is blocking? (IMHO)
> > * regressions (unless its non possible to fix before release)
> > * crashes
> > * security issues
> > * data loss
> > * privacy issues
> > * anything the commuity agrees should be in the release
> 
> We still have 3 blocking issues on trac
> 
> do people want me to wait or ignore them and branch ?
> Iam not sure when the exact deadline is but if we keep waiting
> we will not get into ubuntu 24.04 LTS

24.04 is past feature freeze, so it's too late for that.

Cheers
-- 
Sebastian Ramacher
_______________________________________________
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 7.0 blocking issues

[Michael Niedermayer]

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

On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
> On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> > > Hi all
> > > 
> > > As it was a little difficult for me to not loose track of what is
> > > blocking a release. I suggest that for all release blocking issues
> > > open a ticket and set Blocking to 7.0
> > > that way this:
> > > https://trac.ffmpeg.org/query?blocking=~7.0
> > > 
> > > or for the ones not closed:
> > > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > > 
> > > will list all blocking issues
> > > 
> > > Ive added one, for testing that, i intend to add more if i see something
> > > 
> > > What is blocking? (IMHO)
> > > * regressions (unless its non possible to fix before release)
> > > * crashes
> > > * security issues
> > > * data loss
> > > * privacy issues
> > > * anything the commuity agrees should be in the release
> > 
> > We still have 3 blocking issues on trac
> > 
> > do people want me to wait or ignore them and branch ?
> > Iam not sure when the exact deadline is but if we keep waiting
> > we will not get into ubuntu 24.04 LTS
> 
> 24.04 is past feature freeze, so it's too late for that.

we should aim earlier in the future then.

thx

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

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


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

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

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

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

Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues

[Sean McGovern]

On Sat, Mar 2, 2024, 18:19 Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
> > On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> > > > Hi all
> > > >
> > > > As it was a little difficult for me to not loose track of what is
> > > > blocking a release. I suggest that for all release blocking issues
> > > > open a ticket and set Blocking to 7.0
> > > > that way this:
> > > > https://trac.ffmpeg.org/query?blocking=~7.0
> > > >
> > > > or for the ones not closed:
> > > >
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > > >
> > > > will list all blocking issues
> > > >
> > > > Ive added one, for testing that, i intend to add more if i see
> something
> > > >
> > > > What is blocking? (IMHO)
> > > > * regressions (unless its non possible to fix before release)
> > > > * crashes
> > > > * security issues
> > > > * data loss
> > > > * privacy issues
> > > > * anything the commuity agrees should be in the release
> > >
> > > We still have 3 blocking issues on trac
> > >
> > > do people want me to wait or ignore them and branch ?
> > > Iam not sure when the exact deadline is but if we keep waiting
> > > we will not get into ubuntu 24.04 LTS
> >
> > 24.04 is past feature freeze, so it's too late for that.
>
> we should aim earlier in the future then.
>
>

LTS is only every 2 years, yes?

How do we make sure this doesn't happen in 2026? How much of a gap is there
between feature freeze and release?

-- Sean McGovern
_______________________________________________
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 7.0 blocking issues

[Sebastian Ramacher]

On 2024-03-02 20:39:08 -0500, Sean McGovern wrote:
> On Sat, Mar 2, 2024, 18:19 Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
> > > On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> > > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> > > > > Hi all
> > > > >
> > > > > As it was a little difficult for me to not loose track of what is
> > > > > blocking a release. I suggest that for all release blocking issues
> > > > > open a ticket and set Blocking to 7.0
> > > > > that way this:
> > > > > https://trac.ffmpeg.org/query?blocking=~7.0
> > > > >
> > > > > or for the ones not closed:
> > > > >
> > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > > > >
> > > > > will list all blocking issues
> > > > >
> > > > > Ive added one, for testing that, i intend to add more if i see
> > something
> > > > >
> > > > > What is blocking? (IMHO)
> > > > > * regressions (unless its non possible to fix before release)
> > > > > * crashes
> > > > > * security issues
> > > > > * data loss
> > > > > * privacy issues
> > > > > * anything the commuity agrees should be in the release
> > > >
> > > > We still have 3 blocking issues on trac
> > > >
> > > > do people want me to wait or ignore them and branch ?
> > > > Iam not sure when the exact deadline is but if we keep waiting
> > > > we will not get into ubuntu 24.04 LTS
> > >
> > > 24.04 is past feature freeze, so it's too late for that.
> >
> > we should aim earlier in the future then.
> >
> >
> 
> LTS is only every 2 years, yes?

Yes

> How do we make sure this doesn't happen in 2026? How much of a gap is there
> between feature freeze and release?

Not involved in Ubuntu, so that's from past experience: feature
freeze is usually about two months before the release.

So here's the catch: Debian's timeline also needs to be taken into
account. If the ffmpeg release does not involve the removal of deprecated API and
a SONAME bump, then the time from ffmpeg to release to upload to Debian
unstable and then import in Ubuntu is short. In this case, I am sure
that I could convince Ubuntu maintainers to import it even during
feature freeze.

But with SONAME bumps and changes in the API, it takes a lot more time
to work through the high number of ffmpeg reverse dependencies. In that
case, plan a release at least 6 months before an Ubuntu LTS release.

We usually have to rely on upstream maintainers to adopt to the
changes and that take times. Many moons ago Anton helped with providing
patches, but for the last couple of API changes it took some months from
"dear maintainer, here is ffmpeg X for testing, please fix the build of
your package" to actually doing all uploads and rebuilds. For example,
the transition to ffmpeg 6.0 was started in July 2023 and was done in
December 2023.

Cheers
-- 
Sebastian Ramacher
_______________________________________________
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 7.0 blocking issues

[Sebastian Ramacher]

On 2024-03-03 09:55:15 +0100, Sebastian Ramacher wrote:
> On 2024-03-02 20:39:08 -0500, Sean McGovern wrote:
> > On Sat, Mar 2, 2024, 18:19 Michael Niedermayer <michael@niedermayer.cc>
> > wrote:
> > 
> > > On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
> > > > On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> > > > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> > > > > > Hi all
> > > > > >
> > > > > > As it was a little difficult for me to not loose track of what is
> > > > > > blocking a release. I suggest that for all release blocking issues
> > > > > > open a ticket and set Blocking to 7.0
> > > > > > that way this:
> > > > > > https://trac.ffmpeg.org/query?blocking=~7.0
> > > > > >
> > > > > > or for the ones not closed:
> > > > > >
> > > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > > > > >
> > > > > > will list all blocking issues
> > > > > >
> > > > > > Ive added one, for testing that, i intend to add more if i see
> > > something
> > > > > >
> > > > > > What is blocking? (IMHO)
> > > > > > * regressions (unless its non possible to fix before release)
> > > > > > * crashes
> > > > > > * security issues
> > > > > > * data loss
> > > > > > * privacy issues
> > > > > > * anything the commuity agrees should be in the release
> > > > >
> > > > > We still have 3 blocking issues on trac
> > > > >
> > > > > do people want me to wait or ignore them and branch ?
> > > > > Iam not sure when the exact deadline is but if we keep waiting
> > > > > we will not get into ubuntu 24.04 LTS
> > > >
> > > > 24.04 is past feature freeze, so it's too late for that.
> > >
> > > we should aim earlier in the future then.
> > >
> > >
> > 
> > LTS is only every 2 years, yes?
> 
> Yes
> 
> > How do we make sure this doesn't happen in 2026? How much of a gap is there
> > between feature freeze and release?
> 
> Not involved in Ubuntu, so that's from past experience: feature
> freeze is usually about two months before the release.
> 
> So here's the catch: Debian's timeline also needs to be taken into
> account. If the ffmpeg release does not involve the removal of deprecated API and
> a SONAME bump, then the time from ffmpeg to release to upload to Debian
> unstable and then import in Ubuntu is short. In this case, I am sure
> that I could convince Ubuntu maintainers to import it even during
> feature freeze.
> 
> But with SONAME bumps and changes in the API, it takes a lot more time
> to work through the high number of ffmpeg reverse dependencies. In that
> case, plan a release at least 6 months before an Ubuntu LTS release.



> 
> We usually have to rely on upstream maintainers to adopt to the
> changes and that take times. Many moons ago Anton helped with providing
> patches, but for the last couple of API changes it took some months from
> "dear maintainer, here is ffmpeg X for testing, please fix the build of
> your package" to actually doing all uploads and rebuilds. For example,
> the transition to ffmpeg 6.0 was started in July 2023 and was done in
> December 2023.

Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
Debian. The list is available at [1]. So if you want ffmpeg X to be in
Debian Y or Ubuntu Z, X needs to be released at least half a year before
Y or Z freeze.

Cheers

[1] https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=sramacher@debian.org&tag=ffmpeg-7.0
-- 
Sebastian Ramacher
_______________________________________________
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 7.0 blocking issues

[Michael Niedermayer]

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

On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
> On 2024-03-03 09:55:15 +0100, Sebastian Ramacher wrote:
> > On 2024-03-02 20:39:08 -0500, Sean McGovern wrote:
> > > On Sat, Mar 2, 2024, 18:19 Michael Niedermayer <michael@niedermayer.cc>
> > > wrote:
> > > 
> > > > On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
> > > > > On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> > > > > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> > > > > > > Hi all
> > > > > > >
> > > > > > > As it was a little difficult for me to not loose track of what is
> > > > > > > blocking a release. I suggest that for all release blocking issues
> > > > > > > open a ticket and set Blocking to 7.0
> > > > > > > that way this:
> > > > > > > https://trac.ffmpeg.org/query?blocking=~7.0
> > > > > > >
> > > > > > > or for the ones not closed:
> > > > > > >
> > > > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > > > > > >
> > > > > > > will list all blocking issues
> > > > > > >
> > > > > > > Ive added one, for testing that, i intend to add more if i see
> > > > something
> > > > > > >
> > > > > > > What is blocking? (IMHO)
> > > > > > > * regressions (unless its non possible to fix before release)
> > > > > > > * crashes
> > > > > > > * security issues
> > > > > > > * data loss
> > > > > > > * privacy issues
> > > > > > > * anything the commuity agrees should be in the release
> > > > > >
> > > > > > We still have 3 blocking issues on trac
> > > > > >
> > > > > > do people want me to wait or ignore them and branch ?
> > > > > > Iam not sure when the exact deadline is but if we keep waiting
> > > > > > we will not get into ubuntu 24.04 LTS
> > > > >
> > > > > 24.04 is past feature freeze, so it's too late for that.
> > > >
> > > > we should aim earlier in the future then.
> > > >
> > > >
> > > 
> > > LTS is only every 2 years, yes?
> > 
> > Yes
> > 
> > > How do we make sure this doesn't happen in 2026? How much of a gap is there
> > > between feature freeze and release?
> > 
> > Not involved in Ubuntu, so that's from past experience: feature
> > freeze is usually about two months before the release.
> > 
> > So here's the catch: Debian's timeline also needs to be taken into
> > account. If the ffmpeg release does not involve the removal of deprecated API and
> > a SONAME bump, then the time from ffmpeg to release to upload to Debian
> > unstable and then import in Ubuntu is short. In this case, I am sure
> > that I could convince Ubuntu maintainers to import it even during
> > feature freeze.
> > 
> > But with SONAME bumps and changes in the API, it takes a lot more time
> > to work through the high number of ffmpeg reverse dependencies. In that
> > case, plan a release at least 6 months before an Ubuntu LTS release.
> 
> 
> 
> > 
> > We usually have to rely on upstream maintainers to adopt to the
> > changes and that take times. Many moons ago Anton helped with providing
> > patches, but for the last couple of API changes it took some months from
> > "dear maintainer, here is ffmpeg X for testing, please fix the build of
> > your package" to actually doing all uploads and rebuilds. For example,
> > the transition to ffmpeg 6.0 was started in July 2023 and was done in
> > December 2023.
> 
> Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
> Debian. The list is available at [1]. So if you want ffmpeg X to be in
> Debian Y or Ubuntu Z, X needs to be released at least half a year before
> Y or Z freeze.

Is there something that ffmpeg can do to reduce this breakage ?
(i know its a bit of a lame question as its API brekages but i mean
can the policy we have about deprecating API/ABI be amended in some way
to make this easier ?

Also am i correct that it should be easier if a X.1 with same API/ABI that is
released 6 month after X.0 is targetet for the release ? Thats in fact kind
of what i would have preferred anyway as the .1 likely has also fewer bugs

And last but not least, someone needs to write down when .0 and .1 releases should
be made so I dont forget it :)

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 7.0 blocking issues

[Sean McGovern]

On Mon, Jun 3, 2024, 17:32 Michael Niedermayer <michael@niedermayer.cc>
wrote:

> On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
> > On 2024-03-03 09:55:15 +0100, Sebastian Ramacher wrote:
> > > On 2024-03-02 20:39:08 -0500, Sean McGovern wrote:
> > > > On Sat, Mar 2, 2024, 18:19 Michael Niedermayer <
> michael@niedermayer.cc>
> > > > wrote:
> > > >
> > > > > On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
> > > > > > On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> > > > > > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer
> wrote:
> > > > > > > > Hi all
> > > > > > > >
> > > > > > > > As it was a little difficult for me to not loose track of
> what is
> > > > > > > > blocking a release. I suggest that for all release blocking
> issues
> > > > > > > > open a ticket and set Blocking to 7.0
> > > > > > > > that way this:
> > > > > > > > https://trac.ffmpeg.org/query?blocking=~7.0
> > > > > > > >
> > > > > > > > or for the ones not closed:
> > > > > > > >
> > > > >
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > > > > > > >
> > > > > > > > will list all blocking issues
> > > > > > > >
> > > > > > > > Ive added one, for testing that, i intend to add more if i
> see
> > > > > something
> > > > > > > >
> > > > > > > > What is blocking? (IMHO)
> > > > > > > > * regressions (unless its non possible to fix before release)
> > > > > > > > * crashes
> > > > > > > > * security issues
> > > > > > > > * data loss
> > > > > > > > * privacy issues
> > > > > > > > * anything the commuity agrees should be in the release
> > > > > > >
> > > > > > > We still have 3 blocking issues on trac
> > > > > > >
> > > > > > > do people want me to wait or ignore them and branch ?
> > > > > > > Iam not sure when the exact deadline is but if we keep waiting
> > > > > > > we will not get into ubuntu 24.04 LTS
> > > > > >
> > > > > > 24.04 is past feature freeze, so it's too late for that.
> > > > >
> > > > > we should aim earlier in the future then.
> > > > >
> > > > >
> > > >
> > > > LTS is only every 2 years, yes?
> > >
> > > Yes
> > >
> > > > How do we make sure this doesn't happen in 2026? How much of a gap
> is there
> > > > between feature freeze and release?
> > >
> > > Not involved in Ubuntu, so that's from past experience: feature
> > > freeze is usually about two months before the release.
> > >
> > > So here's the catch: Debian's timeline also needs to be taken into
> > > account. If the ffmpeg release does not involve the removal of
> deprecated API and
> > > a SONAME bump, then the time from ffmpeg to release to upload to Debian
> > > unstable and then import in Ubuntu is short. In this case, I am sure
> > > that I could convince Ubuntu maintainers to import it even during
> > > feature freeze.
> > >
> > > But with SONAME bumps and changes in the API, it takes a lot more time
> > > to work through the high number of ffmpeg reverse dependencies. In that
> > > case, plan a release at least 6 months before an Ubuntu LTS release.
> >
> >
> >
> > >
> > > We usually have to rely on upstream maintainers to adopt to the
> > > changes and that take times. Many moons ago Anton helped with providing
> > > patches, but for the last couple of API changes it took some months
> from
> > > "dear maintainer, here is ffmpeg X for testing, please fix the build of
> > > your package" to actually doing all uploads and rebuilds. For example,
> > > the transition to ffmpeg 6.0 was started in July 2023 and was done in
> > > December 2023.
> >
> > Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
> > Debian. The list is available at [1]. So if you want ffmpeg X to be in
> > Debian Y or Ubuntu Z, X needs to be released at least half a year before
> > Y or Z freeze.
>
> Is there something that ffmpeg can do to reduce this breakage ?
> (i know its a bit of a lame question as its API brekages but i mean
> can the policy we have about deprecating API/ABI be amended in some way
> to make this easier ?
>
> Also am i correct that it should be easier if a X.1 with same API/ABI that
> is
> released 6 month after X.0 is targetet for the release ? Thats in fact kind
> of what i would have preferred anyway as the .1 likely has also fewer bugs
>
> And last but not least, someone needs to write down when .0 and .1
> releases should
> be made so I dont forget it :)
>
> thx
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Nations do behave wisely once they have exhausted all other alternatives.
> -- Abba Eban
> _______________________________________________
> 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".
>

There are so many downstreams that this is probably a fool's errand.

-- Sean McGovern

>
_______________________________________________
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 7.0 blocking issues

[James Almer]

On 6/3/2024 6:32 PM, Michael Niedermayer wrote:
> On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
>> On 2024-03-03 09:55:15 +0100, Sebastian Ramacher wrote:
>>> On 2024-03-02 20:39:08 -0500, Sean McGovern wrote:
>>>> On Sat, Mar 2, 2024, 18:19 Michael Niedermayer <michael@niedermayer.cc>
>>>> wrote:
>>>>
>>>>> On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
>>>>>> On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
>>>>>>> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
>>>>>>>> Hi all
>>>>>>>>
>>>>>>>> As it was a little difficult for me to not loose track of what is
>>>>>>>> blocking a release. I suggest that for all release blocking issues
>>>>>>>> open a ticket and set Blocking to 7.0
>>>>>>>> that way this:
>>>>>>>> https://trac.ffmpeg.org/query?blocking=~7.0
>>>>>>>>
>>>>>>>> or for the ones not closed:
>>>>>>>>
>>>>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>>>>>>>>
>>>>>>>> will list all blocking issues
>>>>>>>>
>>>>>>>> Ive added one, for testing that, i intend to add more if i see
>>>>> something
>>>>>>>>
>>>>>>>> What is blocking? (IMHO)
>>>>>>>> * regressions (unless its non possible to fix before release)
>>>>>>>> * crashes
>>>>>>>> * security issues
>>>>>>>> * data loss
>>>>>>>> * privacy issues
>>>>>>>> * anything the commuity agrees should be in the release
>>>>>>>
>>>>>>> We still have 3 blocking issues on trac
>>>>>>>
>>>>>>> do people want me to wait or ignore them and branch ?
>>>>>>> Iam not sure when the exact deadline is but if we keep waiting
>>>>>>> we will not get into ubuntu 24.04 LTS
>>>>>>
>>>>>> 24.04 is past feature freeze, so it's too late for that.
>>>>>
>>>>> we should aim earlier in the future then.
>>>>>
>>>>>
>>>>
>>>> LTS is only every 2 years, yes?
>>>
>>> Yes
>>>
>>>> How do we make sure this doesn't happen in 2026? How much of a gap is there
>>>> between feature freeze and release?
>>>
>>> Not involved in Ubuntu, so that's from past experience: feature
>>> freeze is usually about two months before the release.
>>>
>>> So here's the catch: Debian's timeline also needs to be taken into
>>> account. If the ffmpeg release does not involve the removal of deprecated API and
>>> a SONAME bump, then the time from ffmpeg to release to upload to Debian
>>> unstable and then import in Ubuntu is short. In this case, I am sure
>>> that I could convince Ubuntu maintainers to import it even during
>>> feature freeze.
>>>
>>> But with SONAME bumps and changes in the API, it takes a lot more time
>>> to work through the high number of ffmpeg reverse dependencies. In that
>>> case, plan a release at least 6 months before an Ubuntu LTS release.
>>
>>
>>
>>>
>>> We usually have to rely on upstream maintainers to adopt to the
>>> changes and that take times. Many moons ago Anton helped with providing
>>> patches, but for the last couple of API changes it took some months from
>>> "dear maintainer, here is ffmpeg X for testing, please fix the build of
>>> your package" to actually doing all uploads and rebuilds. For example,
>>> the transition to ffmpeg 6.0 was started in July 2023 and was done in
>>> December 2023.
>>
>> Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
>> Debian. The list is available at [1]. So if you want ffmpeg X to be in
>> Debian Y or Ubuntu Z, X needs to be released at least half a year before
>> Y or Z freeze.
> 
> Is there something that ffmpeg can do to reduce this breakage ?
> (i know its a bit of a lame question as its API brekages but i mean
> can the policy we have about deprecating API/ABI be amended in some way
> to make this easier ?

Well, no. Breakages are expected when you remove API. The real question 
is why so many projects wait until the old API is gone to migrate. What 
we removed in 7.0 has had its replacement in place for a couple years, 
since 5.1.

> 
> Also am i correct that it should be easier if a X.1 with same API/ABI that is
> released 6 month after X.0 is targetet for the release ? Thats in fact kind
> of what i would have preferred anyway as the .1 likely has also fewer bugs

IMO yes, it would be best if we aim at having distros shipping X.1 or 
higher rather than the first version after a major bump. Debian stable 
currently ships 5.1, for example.

> 
> And last but not least, someone needs to write down when .0 and .1 releases should
> be made so I dont forget it :)
> 
> 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 7.0 blocking issues

[Michael Niedermayer]

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

On Mon, Jun 03, 2024 at 06:41:03PM -0300, James Almer wrote:
> On 6/3/2024 6:32 PM, Michael Niedermayer wrote:
> > On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
> > > On 2024-03-03 09:55:15 +0100, Sebastian Ramacher wrote:
> > > > On 2024-03-02 20:39:08 -0500, Sean McGovern wrote:
> > > > > On Sat, Mar 2, 2024, 18:19 Michael Niedermayer <michael@niedermayer.cc>
> > > > > wrote:
> > > > > 
> > > > > > On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
> > > > > > > On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> > > > > > > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> > > > > > > > > Hi all
> > > > > > > > > 
> > > > > > > > > As it was a little difficult for me to not loose track of what is
> > > > > > > > > blocking a release. I suggest that for all release blocking issues
> > > > > > > > > open a ticket and set Blocking to 7.0
> > > > > > > > > that way this:
> > > > > > > > > https://trac.ffmpeg.org/query?blocking=~7.0
> > > > > > > > > 
> > > > > > > > > or for the ones not closed:
> > > > > > > > > 
> > > > > > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > > > > > > > > 
> > > > > > > > > will list all blocking issues
> > > > > > > > > 
> > > > > > > > > Ive added one, for testing that, i intend to add more if i see
> > > > > > something
> > > > > > > > > 
> > > > > > > > > What is blocking? (IMHO)
> > > > > > > > > * regressions (unless its non possible to fix before release)
> > > > > > > > > * crashes
> > > > > > > > > * security issues
> > > > > > > > > * data loss
> > > > > > > > > * privacy issues
> > > > > > > > > * anything the commuity agrees should be in the release
> > > > > > > > 
> > > > > > > > We still have 3 blocking issues on trac
> > > > > > > > 
> > > > > > > > do people want me to wait or ignore them and branch ?
> > > > > > > > Iam not sure when the exact deadline is but if we keep waiting
> > > > > > > > we will not get into ubuntu 24.04 LTS
> > > > > > > 
> > > > > > > 24.04 is past feature freeze, so it's too late for that.
> > > > > > 
> > > > > > we should aim earlier in the future then.
> > > > > > 
> > > > > > 
> > > > > 
> > > > > LTS is only every 2 years, yes?
> > > > 
> > > > Yes
> > > > 
> > > > > How do we make sure this doesn't happen in 2026? How much of a gap is there
> > > > > between feature freeze and release?
> > > > 
> > > > Not involved in Ubuntu, so that's from past experience: feature
> > > > freeze is usually about two months before the release.
> > > > 
> > > > So here's the catch: Debian's timeline also needs to be taken into
> > > > account. If the ffmpeg release does not involve the removal of deprecated API and
> > > > a SONAME bump, then the time from ffmpeg to release to upload to Debian
> > > > unstable and then import in Ubuntu is short. In this case, I am sure
> > > > that I could convince Ubuntu maintainers to import it even during
> > > > feature freeze.
> > > > 
> > > > But with SONAME bumps and changes in the API, it takes a lot more time
> > > > to work through the high number of ffmpeg reverse dependencies. In that
> > > > case, plan a release at least 6 months before an Ubuntu LTS release.
> > > 
> > > 
> > > 
> > > > 
> > > > We usually have to rely on upstream maintainers to adopt to the
> > > > changes and that take times. Many moons ago Anton helped with providing
> > > > patches, but for the last couple of API changes it took some months from
> > > > "dear maintainer, here is ffmpeg X for testing, please fix the build of
> > > > your package" to actually doing all uploads and rebuilds. For example,
> > > > the transition to ffmpeg 6.0 was started in July 2023 and was done in
> > > > December 2023.
> > > 
> > > Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
> > > Debian. The list is available at [1]. So if you want ffmpeg X to be in
> > > Debian Y or Ubuntu Z, X needs to be released at least half a year before
> > > Y or Z freeze.
> > 
> > Is there something that ffmpeg can do to reduce this breakage ?
> > (i know its a bit of a lame question as its API brekages but i mean
> > can the policy we have about deprecating API/ABI be amended in some way
> > to make this easier ?
> 
> Well, no.

> Breakages are expected when you remove API.

Are Breakages also expected when you do not remove API ?


> The real question is
> why so many projects wait until the old API is gone to migrate. What we
> removed in 7.0 has had its replacement in place for a couple years, since
> 5.1.

Because few need or want to migrate to a new API every year.

Also continous migrations can introduce bugs into user programs.
How many of these 70 reverse dependancies will be properly tested or
tested at all beyond build and one runtime check when the build error
is fixed ?

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] FFmpeg 7.0 blocking issues

[Vittorio Giovara]

On Tue, Jun 4, 2024 at 3:16 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> > Breakages are expected when you remove API.
>
> Are Breakages also expected when you do not remove API ?
>

If a tree falls in a forest and no one is around to hear it, does it make a
sound?
-- 
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 7.0 blocking issues

[Anton Khirnov]

Quoting Michael Niedermayer (2024-06-04 03:16:11)
> > The real question is
> > why so many projects wait until the old API is gone to migrate. What we
> > removed in 7.0 has had its replacement in place for a couple years, since
> > 5.1.
> 
> Because few need or want to migrate to a new API every year.

IME smaller and more frequent changes are both easier to manage and have
a lower risk of bugs than a massive all-breaking API migration once in
five years.

-- 
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] FFmpeg 7.0 blocking issues

[Rémi Denis-Courmont]

Le 4 juin 2024 00:41:03 GMT+03:00, James Almer <jamrial@gmail.com> a écrit :
>Well, no. Breakages are expected when you remove API. The real question is why so many projects wait until the old API is gone to migrate. What we removed in 7.0 has had its replacement in place for a couple years, since 5.1.

Because nobody cares to fix it until it breaks.

Before that it takes a long time for the breakage to be visible since most down-stream projects get FFmpeg as a pinned vendored release and/or from stable Linux distros.

And then you have projects that are dead or in a never-ending release cycle due to their own reasons (VLC...), holding back any stable release source update.
_______________________________________________
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 7.0 blocking issues

[Sebastian Ramacher]

On 2024-06-04 09:31:38 +0300, Rémi Denis-Courmont wrote:
> 
> 
> Le 4 juin 2024 00:41:03 GMT+03:00, James Almer <jamrial@gmail.com> a écrit :
> >Well, no. Breakages are expected when you remove API. The real question is why so many projects wait until the old API is gone to migrate. What we removed in 7.0 has had its replacement in place for a couple years, since 5.1.
> 
> Because nobody cares to fix it until it breaks.
> 
> Before that it takes a long time for the breakage to be visible since most down-stream projects get FFmpeg as a pinned vendored release and/or from stable Linux distros.
> 
> And then you have projects that are dead or in a never-ending release cycle due to their own reasons (VLC...), holding back any stable release source update.

vlc is in a state where it cannot keep up with the changes in its
dependencies from a packagers viewpoint. If there weren't changes in the
git repository, I would almost say that the project is dead. The last
changes I made to the vlc package in Debian are all disabling features
(libplacebo, hardware decoding, ...). The recent changes in ffmpeg may
put the final nail into the coffin and we need to start looking at its
removal [1].

Best
Sebastian

[1] I don't usually like to threaten removal, but there is a limit of
what volunteer package maintainers can handle.
-- 
Sebastian Ramacher
_______________________________________________
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 7.0 blocking issues

[Kacper Michajlow]

On Mon, 3 Jun 2024 at 23:41, James Almer <jamrial@gmail.com> wrote:
>
> On 6/3/2024 6:32 PM, Michael Niedermayer wrote:
> > On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
> >> On 2024-03-03 09:55:15 +0100, Sebastian Ramacher wrote:
> >>> On 2024-03-02 20:39:08 -0500, Sean McGovern wrote:
> >>>> On Sat, Mar 2, 2024, 18:19 Michael Niedermayer <michael@niedermayer.cc>
> >>>> wrote:
> >>>>
> >>>>> On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
> >>>>>> On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> >>>>>>> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> >>>>>>>> Hi all
> >>>>>>>>
> >>>>>>>> As it was a little difficult for me to not loose track of what is
> >>>>>>>> blocking a release. I suggest that for all release blocking issues
> >>>>>>>> open a ticket and set Blocking to 7.0
> >>>>>>>> that way this:
> >>>>>>>> https://trac.ffmpeg.org/query?blocking=~7.0
> >>>>>>>>
> >>>>>>>> or for the ones not closed:
> >>>>>>>>
> >>>>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> >>>>>>>>
> >>>>>>>> will list all blocking issues
> >>>>>>>>
> >>>>>>>> Ive added one, for testing that, i intend to add more if i see
> >>>>> something
> >>>>>>>>
> >>>>>>>> What is blocking? (IMHO)
> >>>>>>>> * regressions (unless its non possible to fix before release)
> >>>>>>>> * crashes
> >>>>>>>> * security issues
> >>>>>>>> * data loss
> >>>>>>>> * privacy issues
> >>>>>>>> * anything the commuity agrees should be in the release
> >>>>>>>
> >>>>>>> We still have 3 blocking issues on trac
> >>>>>>>
> >>>>>>> do people want me to wait or ignore them and branch ?
> >>>>>>> Iam not sure when the exact deadline is but if we keep waiting
> >>>>>>> we will not get into ubuntu 24.04 LTS
> >>>>>>
> >>>>>> 24.04 is past feature freeze, so it's too late for that.
> >>>>>
> >>>>> we should aim earlier in the future then.
> >>>>>
> >>>>>
> >>>>
> >>>> LTS is only every 2 years, yes?
> >>>
> >>> Yes
> >>>
> >>>> How do we make sure this doesn't happen in 2026? How much of a gap is there
> >>>> between feature freeze and release?
> >>>
> >>> Not involved in Ubuntu, so that's from past experience: feature
> >>> freeze is usually about two months before the release.
> >>>
> >>> So here's the catch: Debian's timeline also needs to be taken into
> >>> account. If the ffmpeg release does not involve the removal of deprecated API and
> >>> a SONAME bump, then the time from ffmpeg to release to upload to Debian
> >>> unstable and then import in Ubuntu is short. In this case, I am sure
> >>> that I could convince Ubuntu maintainers to import it even during
> >>> feature freeze.
> >>>
> >>> But with SONAME bumps and changes in the API, it takes a lot more time
> >>> to work through the high number of ffmpeg reverse dependencies. In that
> >>> case, plan a release at least 6 months before an Ubuntu LTS release.
> >>
> >>
> >>
> >>>
> >>> We usually have to rely on upstream maintainers to adopt to the
> >>> changes and that take times. Many moons ago Anton helped with providing
> >>> patches, but for the last couple of API changes it took some months from
> >>> "dear maintainer, here is ffmpeg X for testing, please fix the build of
> >>> your package" to actually doing all uploads and rebuilds. For example,
> >>> the transition to ffmpeg 6.0 was started in July 2023 and was done in
> >>> December 2023.
> >>
> >> Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
> >> Debian. The list is available at [1]. So if you want ffmpeg X to be in
> >> Debian Y or Ubuntu Z, X needs to be released at least half a year before
> >> Y or Z freeze.
> >
> > Is there something that ffmpeg can do to reduce this breakage ?
> > (i know its a bit of a lame question as its API brekages but i mean
> > can the policy we have about deprecating API/ABI be amended in some way
> > to make this easier ?
>
> Well, no. Breakages are expected when you remove API. The real question
> is why so many projects wait until the old API is gone to migrate. What
> we removed in 7.0 has had its replacement in place for a couple years,
> since 5.1.

Is it the real question, though? I think it is unrealistic to expect
every single developer to track FFmpeg changes and immediately adjust
their projects to the latest API. Not only can this time be allocated
in different areas, but any change also introduces an additional risk
of breakage. Until the old API stops working, it is really up to
individual project maintainers to decide when they want to upgrade. If
they choose to upgrade in bulk after the new stable version is
released, it is perfectly understandable.

Even if a project is updated to a new API, as in the case of mpv, we
still experienced breakage after the removal of the old API. One build
[1] and one runtime [2] issue occurred simply because the deprecation
itself was not sufficiently visible, or not visible at all, and those
two small pieces were missing. Sure, you can blame developers for not
reading the API changes or forget about something, but until things
work, it is easy to just omit something.

[1] https://github.com/mpv-player/mpv/commit/78447c4b91634aa91dcace1cc6a9805fb93b9252
[2] https://github.com/mpv-player/mpv/commit/9ef614d6a3b5e56474ec91626b06247ac60ed746

As for solutions, I think there will always be a "breakage" period;
you cannot sync everyone on the development timelines. What would help
is to build FFmpeg with all deprecated bits and pieces removed, using
one configuration flag. This way, such a build can be validated before
the deprecated elements are actually removed. As I said above, not all
deprecations are visible. `-Werror=deprecated` is not enough.

- Kacper
_______________________________________________
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 7.0 blocking issues

[Andrew Sayers]

On Mon, Jun 03, 2024 at 11:32:37PM +0200, Michael Niedermayer wrote:
> On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
[...]
> > Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
> > Debian. The list is available at [1]. So if you want ffmpeg X to be in
> > Debian Y or Ubuntu Z, X needs to be released at least half a year before
> > Y or Z freeze.
> 
> Is there something that ffmpeg can do to reduce this breakage ?
> (i know its a bit of a lame question as its API brekages but i mean
> can the policy we have about deprecating API/ABI be amended in some way
> to make this easier ?

A quick look through Sebastian's list suggests two main groups of issues:

* channel layout migration
* things that didn't have attribute_deprecated before being removed

There are probably ways to reduce migration issues (e.g. Anton's point about
frequent small changes), but the quick win is to use attribute_deprecated more.

To be clear - attribute_deprecated is already used a lot.  If those messages
were being ignored, we would expect to see more bugs reported for those things.
The fact that channel layout is the only deprecated functionality to get this
far suggests that attribute_deprecated is a good way to notify people about
all but the largest changes.

> Also am i correct that it should be easier if a X.1 with same API/ABI that is
> released 6 month after X.0 is targetet for the release ? Thats in fact kind
> of what i would have preferred anyway as the .1 likely has also fewer bugs
> 
> And last but not least, someone needs to write down when .0 and .1 releases should
> be made so I dont forget it :)

Whatever decision is made about this, it would be good to update the
attribute_deprecated macro to point to a URL that lays out the policy.
Something like:

#define attribute_deprecated __attribute__((deprecated("see <url> for details")))
_______________________________________________
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 7.0 blocking issues

[Sebastian Ramacher]

On 2024-06-03 23:32:37 +0200, Michael Niedermayer wrote:
> On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
> > On 2024-03-03 09:55:15 +0100, Sebastian Ramacher wrote:
> > > On 2024-03-02 20:39:08 -0500, Sean McGovern wrote:
> > > > On Sat, Mar 2, 2024, 18:19 Michael Niedermayer <michael@niedermayer.cc>
> > > > wrote:
> > > > 
> > > > > On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
> > > > > > On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> > > > > > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> > > > > > > > Hi all
> > > > > > > >
> > > > > > > > As it was a little difficult for me to not loose track of what is
> > > > > > > > blocking a release. I suggest that for all release blocking issues
> > > > > > > > open a ticket and set Blocking to 7.0
> > > > > > > > that way this:
> > > > > > > > https://trac.ffmpeg.org/query?blocking=~7.0
> > > > > > > >
> > > > > > > > or for the ones not closed:
> > > > > > > >
> > > > > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > > > > > > >
> > > > > > > > will list all blocking issues
> > > > > > > >
> > > > > > > > Ive added one, for testing that, i intend to add more if i see
> > > > > something
> > > > > > > >
> > > > > > > > What is blocking? (IMHO)
> > > > > > > > * regressions (unless its non possible to fix before release)
> > > > > > > > * crashes
> > > > > > > > * security issues
> > > > > > > > * data loss
> > > > > > > > * privacy issues
> > > > > > > > * anything the commuity agrees should be in the release
> > > > > > >
> > > > > > > We still have 3 blocking issues on trac
> > > > > > >
> > > > > > > do people want me to wait or ignore them and branch ?
> > > > > > > Iam not sure when the exact deadline is but if we keep waiting
> > > > > > > we will not get into ubuntu 24.04 LTS
> > > > > >
> > > > > > 24.04 is past feature freeze, so it's too late for that.
> > > > >
> > > > > we should aim earlier in the future then.
> > > > >
> > > > >
> > > > 
> > > > LTS is only every 2 years, yes?
> > > 
> > > Yes
> > > 
> > > > How do we make sure this doesn't happen in 2026? How much of a gap is there
> > > > between feature freeze and release?
> > > 
> > > Not involved in Ubuntu, so that's from past experience: feature
> > > freeze is usually about two months before the release.
> > > 
> > > So here's the catch: Debian's timeline also needs to be taken into
> > > account. If the ffmpeg release does not involve the removal of deprecated API and
> > > a SONAME bump, then the time from ffmpeg to release to upload to Debian
> > > unstable and then import in Ubuntu is short. In this case, I am sure
> > > that I could convince Ubuntu maintainers to import it even during
> > > feature freeze.
> > > 
> > > But with SONAME bumps and changes in the API, it takes a lot more time
> > > to work through the high number of ffmpeg reverse dependencies. In that
> > > case, plan a release at least 6 months before an Ubuntu LTS release.
> > 
> > 
> > 
> > > 
> > > We usually have to rely on upstream maintainers to adopt to the
> > > changes and that take times. Many moons ago Anton helped with providing
> > > patches, but for the last couple of API changes it took some months from
> > > "dear maintainer, here is ffmpeg X for testing, please fix the build of
> > > your package" to actually doing all uploads and rebuilds. For example,
> > > the transition to ffmpeg 6.0 was started in July 2023 and was done in
> > > December 2023.
> > 
> > Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
> > Debian. The list is available at [1]. So if you want ffmpeg X to be in
> > Debian Y or Ubuntu Z, X needs to be released at least half a year before
> > Y or Z freeze.
> 
> Is there something that ffmpeg can do to reduce this breakage ?
> (i know its a bit of a lame question as its API brekages but i mean
> can the policy we have about deprecating API/ABI be amended in some way
> to make this easier ?

Maintainers and developers of reverse dependencies repeatedly ask for
upgrade guides that go beyond "use this function instead". I just did a
quick check through the documentation of 7.0 (doxygen and APIchanges)
for the changes of the channel layout handling. This is what I can find:

2022-03-15 - cdba98bb80 - lavc 59.24.100 - avcodec.h codec_par.h
  Update AVCodecParameters for the new channel layout API: add ch_layout,
  deprecate channels/channel_layout.

  Update AVCodecContext for the new channel layout API: add ch_layout,
  deprecate channels/channel_layout.

  Update AVCodec for the new channel layout API: add ch_layouts,
  deprecate channel_layouts.

2022-03-15 - cdba98bb80 - lavu 57.24.100 - channel_layout.h frame.h opt.h
  Add new channel layout API based on the AVChannelLayout struct.
  Add support for Ambisonic audio.
  Deprecate previous channel layout API based on uint64 bitmasks.

  Add AV_OPT_TYPE_CHLAYOUT option type, deprecate AV_OPT_TYPE_CHANNEL_LAYOUT.
  Update AVFrame for the new channel layout API: add ch_layout, deprecate
  channels/channel_layout.

This only describes what has changed, but gives no indication for users
how to change their codebase. If there is such documentation, its
discoverability can certainly be improved.

I can understand the desire to improve the API, but with a lack of
upgrade documentation, every other release requires a non-negligible
number of developers to figure out the required changes themselves.

> Also am i correct that it should be easier if a X.1 with same API/ABI that is
> released 6 month after X.0 is targetet for the release ? Thats in fact kind
> of what i would have preferred anyway as the .1 likely has also fewer bugs

In the end we still have to deal with the breakage from X.0. But once we
completed the switch to to X.0, breakage from X.1 is usually small.

Then there are also the peculiar cases such as chromaprint which is a
dependency of ffmpeg and also a user. It started to break around ffmpeg
5.0 or 6.0 (due changes in ffmpeg's FFT code) and is now again affected
by the changes to channel layout. It would help a lot of at least the
dependencies of ffmpeg are tested with API changes.

Cheers
-- 
Sebastian Ramacher
_______________________________________________
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 7.0 blocking issues

[Jean-Baptiste Kempf]

n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote:
> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
>> Hi all
>> 
>> As it was a little difficult for me to not loose track of what is
>> blocking a release. I suggest that for all release blocking issues
>> open a ticket and set Blocking to 7.0
>> that way this:
>> https://trac.ffmpeg.org/query?blocking=~7.0
>> 
>> or for the ones not closed:
>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>> 
>> will list all blocking issues
>> 
>> Ive added one, for testing that, i intend to add more if i see something
>> 
>> What is blocking? (IMHO)
>> * regressions (unless its non possible to fix before release)
>> * crashes
>> * security issues
>> * data loss
>> * privacy issues
>> * anything the commuity agrees should be in the release
>
> We still have 3 blocking issues on trac
>
> do people want me to wait or ignore them and branch ?

I think you can branch soon.
However, those 3 bugs are quite important, tbh.

-- 
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 7.0 blocking issues

[James Almer]

On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote:
> 
> n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote:
>> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
>>> Hi all
>>>
>>> As it was a little difficult for me to not loose track of what is
>>> blocking a release. I suggest that for all release blocking issues
>>> open a ticket and set Blocking to 7.0
>>> that way this:
>>> https://trac.ffmpeg.org/query?blocking=~7.0
>>>
>>> or for the ones not closed:
>>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>>>
>>> will list all blocking issues
>>>
>>> Ive added one, for testing that, i intend to add more if i see something
>>>
>>> What is blocking? (IMHO)
>>> * regressions (unless its non possible to fix before release)
>>> * crashes
>>> * security issues
>>> * data loss
>>> * privacy issues
>>> * anything the commuity agrees should be in the release
>>
>> We still have 3 blocking issues on trac
>>
>> do people want me to wait or ignore them and branch ?
> 
> I think you can branch soon.
> However, those 3 bugs are quite important, tbh.

The side data bug depends on an AVOption change, which needs to happen 
alongside the major bump, and afair we wanted 7.0 happen after said bump.
_______________________________________________
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 7.0 blocking issues

[James Almer]

On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote:
> 
> n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote:
>> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
>>> Hi all
>>>
>>> As it was a little difficult for me to not loose track of what is
>>> blocking a release. I suggest that for all release blocking issues
>>> open a ticket and set Blocking to 7.0
>>> that way this:
>>> https://trac.ffmpeg.org/query?blocking=~7.0
>>>
>>> or for the ones not closed:
>>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>>>
>>> will list all blocking issues
>>>
>>> Ive added one, for testing that, i intend to add more if i see something
>>>
>>> What is blocking? (IMHO)
>>> * regressions (unless its non possible to fix before release)
>>> * crashes
>>> * security issues
>>> * data loss
>>> * privacy issues
>>> * anything the commuity agrees should be in the release
>>
>> We still have 3 blocking issues on trac
>>
>> do people want me to wait or ignore them and branch ?
> 
> I think you can branch soon.
> However, those 3 bugs are quite important, tbh.

The bump and the AVOption changes were already applied, so IMO we can 
branch.
The two remaining issues should not be blocking as they can be 
backported to 7.0 in a point release.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues

[Kieran Kunhya]

On Fri, 8 Mar 2024 at 14:00, James Almer <jamrial@gmail.com> wrote:

> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote:
> >
> > n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote:
> >> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> >>> Hi all
> >>>
> >>> As it was a little difficult for me to not loose track of what is
> >>> blocking a release. I suggest that for all release blocking issues
> >>> open a ticket and set Blocking to 7.0
> >>> that way this:
> >>> https://trac.ffmpeg.org/query?blocking=~7.0
> >>>
> >>> or for the ones not closed:
> >>>
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> >>>
> >>> will list all blocking issues
> >>>
> >>> Ive added one, for testing that, i intend to add more if i see
> something
> >>>
> >>> What is blocking? (IMHO)
> >>> * regressions (unless its non possible to fix before release)
> >>> * crashes
> >>> * security issues
> >>> * data loss
> >>> * privacy issues
> >>> * anything the commuity agrees should be in the release
> >>
> >> We still have 3 blocking issues on trac
> >>
> >> do people want me to wait or ignore them and branch ?
> >
> > I think you can branch soon.
> > However, those 3 bugs are quite important, tbh.
>
> The bump and the AVOption changes were already applied, so IMO we can
> branch.
> The two remaining issues should not be blocking as they can be
> backported to 7.0 in a point release.
>

VVC experimental flag is blocking.

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 7.0 blocking issues

[James Almer]

On 3/8/2024 11:02 AM, Kieran Kunhya wrote:
> On Fri, 8 Mar 2024 at 14:00, James Almer <jamrial@gmail.com> wrote:
> 
>> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote:
>>>
>>> n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote:
>>>> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
>>>>> Hi all
>>>>>
>>>>> As it was a little difficult for me to not loose track of what is
>>>>> blocking a release. I suggest that for all release blocking issues
>>>>> open a ticket and set Blocking to 7.0
>>>>> that way this:
>>>>> https://trac.ffmpeg.org/query?blocking=~7.0
>>>>>
>>>>> or for the ones not closed:
>>>>>
>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>>>>>
>>>>> will list all blocking issues
>>>>>
>>>>> Ive added one, for testing that, i intend to add more if i see
>> something
>>>>>
>>>>> What is blocking? (IMHO)
>>>>> * regressions (unless its non possible to fix before release)
>>>>> * crashes
>>>>> * security issues
>>>>> * data loss
>>>>> * privacy issues
>>>>> * anything the commuity agrees should be in the release
>>>>
>>>> We still have 3 blocking issues on trac
>>>>
>>>> do people want me to wait or ignore them and branch ?
>>>
>>> I think you can branch soon.
>>> However, those 3 bugs are quite important, tbh.
>>
>> The bump and the AVOption changes were already applied, so IMO we can
>> branch.
>> The two remaining issues should not be blocking as they can be
>> backported to 7.0 in a point release.
>>
> 
> VVC experimental flag is blocking.
> 
> Kieran

Is there a patch for that?
_______________________________________________
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 7.0 blocking issues

[Frank Plowman]

On 08/03/2024 14:04, James Almer wrote:
> On 3/8/2024 11:02 AM, Kieran Kunhya wrote:
>> On Fri, 8 Mar 2024 at 14:00, James Almer <jamrial@gmail.com> wrote:
>>
>>> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote:
>>>>
>>>> n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote:
>>>>> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
>>>>>> Hi all
>>>>>>
>>>>>> As it was a little difficult for me to not loose track of what is
>>>>>> blocking a release. I suggest that for all release blocking issues
>>>>>> open a ticket and set Blocking to 7.0
>>>>>> that way this:
>>>>>> https://trac.ffmpeg.org/query?blocking=~7.0
>>>>>>
>>>>>> or for the ones not closed:
>>>>>>
>>> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
>>>>>>
>>>>>> will list all blocking issues
>>>>>>
>>>>>> Ive added one, for testing that, i intend to add more if i see
>>> something
>>>>>>
>>>>>> What is blocking? (IMHO)
>>>>>> * regressions (unless its non possible to fix before release)
>>>>>> * crashes
>>>>>> * security issues
>>>>>> * data loss
>>>>>> * privacy issues
>>>>>> * anything the commuity agrees should be in the release
>>>>>
>>>>> We still have 3 blocking issues on trac
>>>>>
>>>>> do people want me to wait or ignore them and branch ?
>>>>
>>>> I think you can branch soon.
>>>> However, those 3 bugs are quite important, tbh.
>>>
>>> The bump and the AVOption changes were already applied, so IMO we can
>>> branch.
>>> The two remaining issues should not be blocking as they can be
>>> backported to 7.0 in a point release.
>>>
>>
>> VVC experimental flag is blocking.
>>
>> Kieran
> 
> Is there a patch for that?

There is this:
https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321060.html
(missing from patchwork for some reason), but it looks like it causes
FATE to fail as is.
_______________________________________________
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 7.0 blocking issues

[Kieran Kunhya]

On Fri, 8 Mar 2024 at 15:04, Frank Plowman <post@frankplowman.com> wrote:

> On 08/03/2024 14:04, James Almer wrote:
> > On 3/8/2024 11:02 AM, Kieran Kunhya wrote:
> >> On Fri, 8 Mar 2024 at 14:00, James Almer <jamrial@gmail.com> wrote:
> >>
> >>> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote:
> >>>>
> >>>> n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote:
> >>>>> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> >>>>>> Hi all
> >>>>>>
> >>>>>> As it was a little difficult for me to not loose track of what is
> >>>>>> blocking a release. I suggest that for all release blocking issues
> >>>>>> open a ticket and set Blocking to 7.0
> >>>>>> that way this:
> >>>>>> https://trac.ffmpeg.org/query?blocking=~7.0
> >>>>>>
> >>>>>> or for the ones not closed:
> >>>>>>
> >>>
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> >>>>>>
> >>>>>> will list all blocking issues
> >>>>>>
> >>>>>> Ive added one, for testing that, i intend to add more if i see
> >>> something
> >>>>>>
> >>>>>> What is blocking? (IMHO)
> >>>>>> * regressions (unless its non possible to fix before release)
> >>>>>> * crashes
> >>>>>> * security issues
> >>>>>> * data loss
> >>>>>> * privacy issues
> >>>>>> * anything the commuity agrees should be in the release
> >>>>>
> >>>>> We still have 3 blocking issues on trac
> >>>>>
> >>>>> do people want me to wait or ignore them and branch ?
> >>>>
> >>>> I think you can branch soon.
> >>>> However, those 3 bugs are quite important, tbh.
> >>>
> >>> The bump and the AVOption changes were already applied, so IMO we can
> >>> branch.
> >>> The two remaining issues should not be blocking as they can be
> >>> backported to 7.0 in a point release.
> >>>
> >>
> >> VVC experimental flag is blocking.
> >>
> >> Kieran
> >
> > Is there a patch for that?
>
> There is this:
> https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321060.html
> (missing from patchwork for some reason), but it looks like it causes
> FATE to fail as is.
>

Yes it does not update FATE to account for 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 7.0 blocking issues

[Nuo Mi]

On Fri, Mar 8, 2024 at 11:41 PM Kieran Kunhya <kierank@obe.tv> wrote:

> On Fri, 8 Mar 2024 at 15:04, Frank Plowman <post@frankplowman.com> wrote:
>
> > On 08/03/2024 14:04, James Almer wrote:
> > > On 3/8/2024 11:02 AM, Kieran Kunhya wrote:
> > >> On Fri, 8 Mar 2024 at 14:00, James Almer <jamrial@gmail.com> wrote:
> > >>
> > >>> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote:
> > >>>>
> > >>>> n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote:
> > >>>>> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer
> wrote:
> > >>>>>> Hi all
> > >>>>>>
> > >>>>>> As it was a little difficult for me to not loose track of what is
> > >>>>>> blocking a release. I suggest that for all release blocking issues
> > >>>>>> open a ticket and set Blocking to 7.0
> > >>>>>> that way this:
> > >>>>>> https://trac.ffmpeg.org/query?blocking=~7.0
> > >>>>>>
> > >>>>>> or for the ones not closed:
> > >>>>>>
> > >>>
> >
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > >>>>>>
> > >>>>>> will list all blocking issues
> > >>>>>>
> > >>>>>> Ive added one, for testing that, i intend to add more if i see
> > >>> something
> > >>>>>>
> > >>>>>> What is blocking? (IMHO)
> > >>>>>> * regressions (unless its non possible to fix before release)
> > >>>>>> * crashes
> > >>>>>> * security issues
> > >>>>>> * data loss
> > >>>>>> * privacy issues
> > >>>>>> * anything the commuity agrees should be in the release
> > >>>>>
> > >>>>> We still have 3 blocking issues on trac
> > >>>>>
> > >>>>> do people want me to wait or ignore them and branch ?
> > >>>>
> > >>>> I think you can branch soon.
> > >>>> However, those 3 bugs are quite important, tbh.
> > >>>
> > >>> The bump and the AVOption changes were already applied, so IMO we can
> > >>> branch.
> > >>> The two remaining issues should not be blocking as they can be
> > >>> backported to 7.0 in a point release.
> > >>>
> > >>
> > >> VVC experimental flag is blocking.
> > >>
> > >> Kieran
> > >
> > > Is there a patch for that?
> >
> > There is this:
> > https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321060.html
> > (missing from patchwork for some reason), but it looks like it causes
> > FATE to fail as is.
> >
>
> Yes it does not update FATE to account for experimental.
>
Hi Kieran,
Could you help send a new patch to make the FATE pass
thank you


>
> 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".
>
_______________________________________________
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 7.0 blocking issues

[Marth64]

It is by no means a blocker but I think it would be nice for users to be
able view subtitle colors with the dvdvideo demuxer, after all it is part
of the presentation. There is a patch for this that has gone through
several reviews. I have (hopefully) addressed the last round of feedback,
but I will stay alert and ready to address anything else that comes up.
Thank you.

On Sat, Mar 9, 2024 at 6:33 AM Nuo Mi <nuomi2021@gmail.com> wrote:

> On Fri, Mar 8, 2024 at 11:41 PM Kieran Kunhya <kierank@obe.tv> wrote:
>
> > On Fri, 8 Mar 2024 at 15:04, Frank Plowman <post@frankplowman.com>
> wrote:
> >
> > > On 08/03/2024 14:04, James Almer wrote:
> > > > On 3/8/2024 11:02 AM, Kieran Kunhya wrote:
> > > >> On Fri, 8 Mar 2024 at 14:00, James Almer <jamrial@gmail.com> wrote:
> > > >>
> > > >>> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote:
> > > >>>>
> > > >>>> n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote:
> > > >>>>> On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer
> > wrote:
> > > >>>>>> Hi all
> > > >>>>>>
> > > >>>>>> As it was a little difficult for me to not loose track of what
> is
> > > >>>>>> blocking a release. I suggest that for all release blocking
> issues
> > > >>>>>> open a ticket and set Blocking to 7.0
> > > >>>>>> that way this:
> > > >>>>>> https://trac.ffmpeg.org/query?blocking=~7.0
> > > >>>>>>
> > > >>>>>> or for the ones not closed:
> > > >>>>>>
> > > >>>
> > >
> >
> https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > > >>>>>>
> > > >>>>>> will list all blocking issues
> > > >>>>>>
> > > >>>>>> Ive added one, for testing that, i intend to add more if i see
> > > >>> something
> > > >>>>>>
> > > >>>>>> What is blocking? (IMHO)
> > > >>>>>> * regressions (unless its non possible to fix before release)
> > > >>>>>> * crashes
> > > >>>>>> * security issues
> > > >>>>>> * data loss
> > > >>>>>> * privacy issues
> > > >>>>>> * anything the commuity agrees should be in the release
> > > >>>>>
> > > >>>>> We still have 3 blocking issues on trac
> > > >>>>>
> > > >>>>> do people want me to wait or ignore them and branch ?
> > > >>>>
> > > >>>> I think you can branch soon.
> > > >>>> However, those 3 bugs are quite important, tbh.
> > > >>>
> > > >>> The bump and the AVOption changes were already applied, so IMO we
> can
> > > >>> branch.
> > > >>> The two remaining issues should not be blocking as they can be
> > > >>> backported to 7.0 in a point release.
> > > >>>
> > > >>
> > > >> VVC experimental flag is blocking.
> > > >>
> > > >> Kieran
> > > >
> > > > Is there a patch for that?
> > >
> > > There is this:
> > > https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321060.html
> > > (missing from patchwork for some reason), but it looks like it causes
> > > FATE to fail as is.
> > >
> >
> > Yes it does not update FATE to account for experimental.
> >
> Hi Kieran,
> Could you help send a new patch to make the FATE pass
> thank you
>
>
> >
> > 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".
> >
> _______________________________________________
> 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 7.0 blocking issues

[Xiang, Haihao]

Hi Mark,

Do you think the broken vaapi dec-filter-encode (and other hw acceleration
method using fixed-size pool) is a blocking issue ? See more info below:

https://patchwork.ffmpeg.org/project/ffmpeg/patch/20231220071050.3175819-11-haihao.xiang@intel.com/
https://patchwork.ffmpeg.org/project/ffmpeg/patch/817dc1ea-495e-4c7f-8615-264e755ff6bd@jkqxz.net/

Thanks
Haihao

> It is by no means a blocker but I think it would be nice for users to be
> able view subtitle colors with the dvdvideo demuxer, after all it is part
> of the presentation. There is a patch for this that has gone through
> several reviews. I have (hopefully) addressed the last round of feedback,
> but I will stay alert and ready to address anything else that comes up.
> Thank you.
> 
> On Sat, Mar 9, 2024 at 6:33 AM Nuo Mi <nuomi2021@gmail.com> wrote:
> 
> > On Fri, Mar 8, 2024 at 11:41 PM Kieran Kunhya <kierank@obe.tv> wrote:
> > 
> > > On Fri, 8 Mar 2024 at 15:04, Frank Plowman <post@frankplowman.com>
> > wrote:
> > > 
> > > > On 08/03/2024 14:04, James Almer wrote:
> > > > > On 3/8/2024 11:02 AM, Kieran Kunhya wrote:
> > > > > > On Fri, 8 Mar 2024 at 14:00, James Almer <jamrial@gmail.com> wrote:
> > > > > > 
> > > > > > > On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote:
> > > > > > > > 
> > > > > > > > n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote:
> > > > > > > > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer
> > > wrote:
> > > > > > > > > > Hi all
> > > > > > > > > > 
> > > > > > > > > > As it was a little difficult for me to not loose track of
> > > > > > > > > > what
> > is
> > > > > > > > > > blocking a release. I suggest that for all release blocking
> > issues
> > > > > > > > > > open a ticket and set Blocking to 7.0
> > > > > > > > > > that way this:
> > > > > > > > > > https://trac.ffmpeg.org/query?blocking=~7.0
> > > > > > > > > > 
> > > > > > > > > > or for the ones not closed:
> > > > > > > > > > 
> > > > > > > 
> > > > 
> > > 
> > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > > > > > > > > > 
> > > > > > > > > > will list all blocking issues
> > > > > > > > > > 
> > > > > > > > > > Ive added one, for testing that, i intend to add more if i
> > > > > > > > > > see
> > > > > > > something
> > > > > > > > > > 
> > > > > > > > > > What is blocking? (IMHO)
> > > > > > > > > > * regressions (unless its non possible to fix before
> > > > > > > > > > release)
> > > > > > > > > > * crashes
> > > > > > > > > > * security issues
> > > > > > > > > > * data loss
> > > > > > > > > > * privacy issues
> > > > > > > > > > * anything the commuity agrees should be in the release
> > > > > > > > > 
> > > > > > > > > We still have 3 blocking issues on trac
> > > > > > > > > 
> > > > > > > > > do people want me to wait or ignore them and branch ?
> > > > > > > > 
> > > > > > > > I think you can branch soon.
> > > > > > > > However, those 3 bugs are quite important, tbh.
> > > > > > > 
> > > > > > > The bump and the AVOption changes were already applied, so IMO we
> > can
> > > > > > > branch.
> > > > > > > The two remaining issues should not be blocking as they can be
> > > > > > > backported to 7.0 in a point release.
> > > > > > > 
> > > > > > 
> > > > > > VVC experimental flag is blocking.
> > > > > > 
> > > > > > Kieran
> > > > > 
> > > > > Is there a patch for that?
> > > > 
> > > > There is this:
> > > > https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321060.html
> > > > (missing from patchwork for some reason), but it looks like it causes
> > > > FATE to fail as is.
> > > > 
> > > 
> > > Yes it does not update FATE to account for experimental.
> > > 
> > Hi Kieran,
> > Could you help send a new patch to make the FATE pass
> > thank you
> > 
> > 
> > > 
> > > 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".
> > > 
> > _______________________________________________
> > 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".

_______________________________________________
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 7.0 blocking issues

[Michael Niedermayer]

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

On Fri, Mar 08, 2024 at 11:00:50AM -0300, James Almer wrote:
> On 3/3/2024 4:35 AM, Jean-Baptiste Kempf wrote:
> > 
> > n Sat, 2 Mar 2024, at 23:55, Michael Niedermayer wrote:
> > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer wrote:
> > > > Hi all
> > > > 
> > > > As it was a little difficult for me to not loose track of what is
> > > > blocking a release. I suggest that for all release blocking issues
> > > > open a ticket and set Blocking to 7.0
> > > > that way this:
> > > > https://trac.ffmpeg.org/query?blocking=~7.0
> > > > 
> > > > or for the ones not closed:
> > > > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > > > 
> > > > will list all blocking issues
> > > > 
> > > > Ive added one, for testing that, i intend to add more if i see something
> > > > 
> > > > What is blocking? (IMHO)
> > > > * regressions (unless its non possible to fix before release)
> > > > * crashes
> > > > * security issues
> > > > * data loss
> > > > * privacy issues
> > > > * anything the commuity agrees should be in the release
> > > 
> > > We still have 3 blocking issues on trac
> > > 
> > > do people want me to wait or ignore them and branch ?
> > 
> > I think you can branch soon.
> > However, those 3 bugs are quite important, tbh.
> 
> The bump and the AVOption changes were already applied, so IMO we can
> branch.
> The two remaining issues should not be blocking as they can be backported to
> 7.0 in a point release.

If issues are not blocking, then please remove the blokcing thing on trac
or update it to a higher version


thx

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus

[-- 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".