Re: [FFmpeg-devel] [RFC] Release 6.1
On Thu, Nov 09, 2023 at 09:20:33AM +0100, Lynne wrote: > Nov 7, 2023, 08:36 by d...@lynne.ee: > > > Oct 29, 2023, 06:57 by d...@lynne.ee: > > > >> Oct 29, 2023, 05:51 by mich...@niedermayer.cc: > >> > >>> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote: > >>> > Oct 28, 2023, 18:49 by mich...@niedermayer.cc: > > > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > > > >> It's been a while since we've had a release, and we've had > >> a lot of new features in. > >> We did say we would make releases more often, and I think > >> it's about time we have a new release. > >> > >> Anything anyone wants to have merged or should we branch > >> off 6.1 in a few days? > >> > > > > Whats the status of this ? > > I can branch 6.1 anytime > > > > It was just that jb told me > > "6.1 opportunity is gone. > > We're too late on the schedule, and noone had time to work on it, so > > it is wiser to target 7.0 in January" > > > > but now i see on IRC > > make a damn release already > > j-b: drop MiNi from release maintership and nominate > > Lynne > > I pledge to bring back /slap IRC messages to those who fail to > > push the patches they want for release! > > durandal_1707: good point, we should look at doing another 5.1.x > > release and a 6.0.x release. > > > > noone mentioned 5.1.x and 6.0.x to me before > > > > anyway, ill try to make releases from all maintained branches, > > > > and will branch 6.1 as soon as Lynne or others say everything is ready. > > > > thx > > > > It's never too late to make a release. If we do a release now, nothing's > stopping > us from doing a 7.0 and getting back on track with releases every two > months or so, > like the plan was. > > 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) > AAC+fixes, D3D12 hwdec, > Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a > good idea to > have a release before all this lands. > > I think the tree is in a pretty good state ATM, you should go ahead and > branch if you're > comfortable with it as well. > > >>> > >>> branch made > >>> > >> > >> Thanks. I'll get a blog post ready for the transform work, as kierank > >> wanted to post something, > >> and if users can know to who to point fingers to in case it degrades > >> performance on RPI1 devices. > >> > >> > Let's aim for a release by Sunday next week. That should give everyone > enough time to > backport fixes they want in. > > >>> > >>> I would aim for 1-3 weeks (when code and developers are ready) > >>> dont want to aim for a specific day, better pick a day when everything is > >>> fine > >>> not too many distractions, ... > >>> > >>> Or is there something that favors us to be before a specific date ? > >>> > >> > >> Not really a reason, Sunday is just an optimistic date to aim for. > >> If there are no big fixes to backport to the branch, I think we can target > >> it. > >> > > > > The nlmeans_vulkan patch I just sent is the last patch I'd like to have in > > 6.1. > > Does anyone else have any patches they would like in 6.1? > > > > Pushed the 2 patches. > > Michael, do you think you can tag the release late tonight? > No one has said anything yet. > I'll write release notes for the website by then as well. ill try to make the release tomorrow if i do it now before going to bed likely something will go wrong thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On 2023-11-09 03:16 pm, epira...@gmail.com wrote: If 6.1 will be cut from master, my tpad fix I sent yesterday should probably be applied first to prevent having a release with broken tpad. The branch is already cut. Will need to be cherry-picked. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On 9 Nov 2023, at 9:20, Lynne wrote: > Nov 7, 2023, 08:36 by d...@lynne.ee: > >> Oct 29, 2023, 06:57 by d...@lynne.ee: >> >>> Oct 29, 2023, 05:51 by mich...@niedermayer.cc: >>> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote: > Oct 28, 2023, 18:49 by mich...@niedermayer.cc: > >> On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: >> >>> It's been a while since we've had a release, and we've had >>> a lot of new features in. >>> We did say we would make releases more often, and I think >>> it's about time we have a new release. >>> >>> Anything anyone wants to have merged or should we branch >>> off 6.1 in a few days? >>> >> >> Whats the status of this ? >> I can branch 6.1 anytime >> >> It was just that jb told me >> "6.1 opportunity is gone. >> We're too late on the schedule, and noone had time to work on it, so it >> is wiser to target 7.0 in January" >> >> but now i see on IRC >> make a damn release already >> j-b: drop MiNi from release maintership and nominate >> Lynne >> I pledge to bring back /slap IRC messages to those who fail to >> push the patches they want for release! >> durandal_1707: good point, we should look at doing another 5.1.x >> release and a 6.0.x release. >> >> noone mentioned 5.1.x and 6.0.x to me before >> >> anyway, ill try to make releases from all maintained branches, >> >> and will branch 6.1 as soon as Lynne or others say everything is ready. >> >> thx >> > > It's never too late to make a release. If we do a release now, nothing's > stopping > us from doing a 7.0 and getting back on track with releases every two > months or so, > like the plan was. > > 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) > AAC+fixes, D3D12 hwdec, > Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a > good idea to > have a release before all this lands. > > I think the tree is in a pretty good state ATM, you should go ahead and > branch if you're > comfortable with it as well. > branch made >>> >>> Thanks. I'll get a blog post ready for the transform work, as kierank >>> wanted to post something, >>> and if users can know to who to point fingers to in case it degrades >>> performance on RPI1 devices. >>> >>> > Let's aim for a release by Sunday next week. That should give everyone > enough time to > backport fixes they want in. > I would aim for 1-3 weeks (when code and developers are ready) dont want to aim for a specific day, better pick a day when everything is fine not too many distractions, ... Or is there something that favors us to be before a specific date ? >>> >>> Not really a reason, Sunday is just an optimistic date to aim for. >>> If there are no big fixes to backport to the branch, I think we can target >>> it. >>> >> >> The nlmeans_vulkan patch I just sent is the last patch I'd like to have in >> 6.1. >> Does anyone else have any patches they would like in 6.1? If 6.1 will be cut from master, my tpad fix I sent yesterday should probably be applied first to prevent having a release with broken tpad. >> > > Pushed the 2 patches. > > Michael, do you think you can tag the release late tonight? > No one has said anything yet. > I'll write release notes for the website by then as well. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Nov 7, 2023, 08:36 by d...@lynne.ee: > Oct 29, 2023, 06:57 by d...@lynne.ee: > >> Oct 29, 2023, 05:51 by mich...@niedermayer.cc: >> >>> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote: >>> Oct 28, 2023, 18:49 by mich...@niedermayer.cc: > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > >> It's been a while since we've had a release, and we've had >> a lot of new features in. >> We did say we would make releases more often, and I think >> it's about time we have a new release. >> >> Anything anyone wants to have merged or should we branch >> off 6.1 in a few days? >> > > Whats the status of this ? > I can branch 6.1 anytime > > It was just that jb told me > "6.1 opportunity is gone. > We're too late on the schedule, and noone had time to work on it, so it > is wiser to target 7.0 in January" > > but now i see on IRC > make a damn release already > j-b: drop MiNi from release maintership and nominate > Lynne > I pledge to bring back /slap IRC messages to those who fail to > push the patches they want for release! > durandal_1707: good point, we should look at doing another 5.1.x > release and a 6.0.x release. > > noone mentioned 5.1.x and 6.0.x to me before > > anyway, ill try to make releases from all maintained branches, > > and will branch 6.1 as soon as Lynne or others say everything is ready. > > thx > It's never too late to make a release. If we do a release now, nothing's stopping us from doing a 7.0 and getting back on track with releases every two months or so, like the plan was. 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec, Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to have a release before all this lands. I think the tree is in a pretty good state ATM, you should go ahead and branch if you're comfortable with it as well. >>> >>> branch made >>> >> >> Thanks. I'll get a blog post ready for the transform work, as kierank wanted >> to post something, >> and if users can know to who to point fingers to in case it degrades >> performance on RPI1 devices. >> >> Let's aim for a release by Sunday next week. That should give everyone enough time to backport fixes they want in. >>> >>> I would aim for 1-3 weeks (when code and developers are ready) >>> dont want to aim for a specific day, better pick a day when everything is >>> fine >>> not too many distractions, ... >>> >>> Or is there something that favors us to be before a specific date ? >>> >> >> Not really a reason, Sunday is just an optimistic date to aim for. >> If there are no big fixes to backport to the branch, I think we can target >> it. >> > > The nlmeans_vulkan patch I just sent is the last patch I'd like to have in > 6.1. > Does anyone else have any patches they would like in 6.1? > Pushed the 2 patches. Michael, do you think you can tag the release late tonight? No one has said anything yet. I'll write release notes for the website by then as well. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Steven Liu 于2023年11月8日周三 09:26写道： > > Tristan Matthews 于2023年11月8日周三 00:47写道： > > > > On Tue, Nov 7, 2023 at 2:36 AM Lynne wrote: > > > > > > Oct 29, 2023, 06:57 by d...@lynne.ee: > > > > > > > Oct 29, 2023, 05:51 by mich...@niedermayer.cc: > > > > > > > >> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote: > > > >> > > > >>> Oct 28, 2023, 18:49 by mich...@niedermayer.cc: > > > >>> > > > >>> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > > > >>> > > > > >>> >> It's been a while since we've had a release, and we've had > > > >>> >> a lot of new features in. > > > >>> >> We did say we would make releases more often, and I think > > > >>> >> it's about time we have a new release. > > > >>> >> > > > >>> >> Anything anyone wants to have merged or should we branch > > > >>> >> off 6.1 in a few days? > > > >>> >> > > > >>> > > > > >>> > Whats the status of this ? > > > >>> > I can branch 6.1 anytime > > > >>> > > > > >>> > It was just that jb told me > > > >>> > "6.1 opportunity is gone. > > > >>> > We're too late on the schedule, and noone had time to work on it, > > > >>> > so it is wiser to target 7.0 in January" > > > >>> > > > > >>> > but now i see on IRC > > > >>> > make a damn release already > > > >>> > j-b: drop MiNi from release maintership and > > > >>> > nominate Lynne > > > >>> > I pledge to bring back /slap IRC messages to those who fail > > > >>> > to push the patches they want for release! > > > >>> > durandal_1707: good point, we should look at doing another > > > >>> > 5.1.x release and a 6.0.x release. > > > >>> > > > > >>> > noone mentioned 5.1.x and 6.0.x to me before > > > >>> > > > > >>> > anyway, ill try to make releases from all maintained branches, > > > >>> > > > > >>> > and will branch 6.1 as soon as Lynne or others say everything is > > > >>> > ready. > > > >>> > > > > >>> > thx > > > >>> > > > > >>> > > > >>> It's never too late to make a release. If we do a release now, > > > >>> nothing's stopping > > > >>> us from doing a 7.0 and getting back on track with releases every two > > > >>> months or so, > > > >>> like the plan was. > > > >>> > > > >>> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) > > > >>> AAC+fixes, D3D12 hwdec, > > > >>> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so > > > >>> it's a good idea to > > > >>> have a release before all this lands. > > > >>> > > > >>> I think the tree is in a pretty good state ATM, you should go ahead > > > >>> and branch if you're > > > >>> comfortable with it as well. > > > >>> > > > >> > > > >> branch made > > > >> > > > > > > > > Thanks. I'll get a blog post ready for the transform work, as kierank > > > > wanted to post something, > > > > and if users can know to who to point fingers to in case it degrades > > > > performance on RPI1 devices. > > > > > > > > > > > >>> Let's aim for a release by Sunday next week. That should give > > > >>> everyone enough time to > > > >>> backport fixes they want in. > > > >>> > > > >> > > > >> I would aim for 1-3 weeks (when code and developers are ready) > > > >> dont want to aim for a specific day, better pick a day when everything > > > >> is fine > > > >> not too many distractions, ... > > > >> > > > >> Or is there something that favors us to be before a specific date ? > > > >> > > > > > > > > Not really a reason, Sunday is just an optimistic date to aim for. > > > > If there are no big fixes to backport to the branch, I think we can > > > > target it. > > > > > > > > > > The nlmeans_vulkan patch I just sent is the last patch I'd like to have > > > in 6.1. > > > Does anyone else have any patches they would like in 6.1? > > > > I was going to request Steven Liu's enhanced RTMP set but it looks > > like those are already in the release/6.1 branch, so cheers. > :-) Thanks ttmath s/ttmath/tmatth/g > > > > -t > > Thanks > Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Tristan Matthews 于2023年11月8日周三 00:47写道： > > On Tue, Nov 7, 2023 at 2:36 AM Lynne wrote: > > > > Oct 29, 2023, 06:57 by d...@lynne.ee: > > > > > Oct 29, 2023, 05:51 by mich...@niedermayer.cc: > > > > > >> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote: > > >> > > >>> Oct 28, 2023, 18:49 by mich...@niedermayer.cc: > > >>> > > >>> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > > >>> > > > >>> >> It's been a while since we've had a release, and we've had > > >>> >> a lot of new features in. > > >>> >> We did say we would make releases more often, and I think > > >>> >> it's about time we have a new release. > > >>> >> > > >>> >> Anything anyone wants to have merged or should we branch > > >>> >> off 6.1 in a few days? > > >>> >> > > >>> > > > >>> > Whats the status of this ? > > >>> > I can branch 6.1 anytime > > >>> > > > >>> > It was just that jb told me > > >>> > "6.1 opportunity is gone. > > >>> > We're too late on the schedule, and noone had time to work on it, so > > >>> > it is wiser to target 7.0 in January" > > >>> > > > >>> > but now i see on IRC > > >>> > make a damn release already > > >>> > j-b: drop MiNi from release maintership and nominate > > >>> > Lynne > > >>> > I pledge to bring back /slap IRC messages to those who fail > > >>> > to push the patches they want for release! > > >>> > durandal_1707: good point, we should look at doing another > > >>> > 5.1.x release and a 6.0.x release. > > >>> > > > >>> > noone mentioned 5.1.x and 6.0.x to me before > > >>> > > > >>> > anyway, ill try to make releases from all maintained branches, > > >>> > > > >>> > and will branch 6.1 as soon as Lynne or others say everything is > > >>> > ready. > > >>> > > > >>> > thx > > >>> > > > >>> > > >>> It's never too late to make a release. If we do a release now, > > >>> nothing's stopping > > >>> us from doing a 7.0 and getting back on track with releases every two > > >>> months or so, > > >>> like the plan was. > > >>> > > >>> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) > > >>> AAC+fixes, D3D12 hwdec, > > >>> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's > > >>> a good idea to > > >>> have a release before all this lands. > > >>> > > >>> I think the tree is in a pretty good state ATM, you should go ahead and > > >>> branch if you're > > >>> comfortable with it as well. > > >>> > > >> > > >> branch made > > >> > > > > > > Thanks. I'll get a blog post ready for the transform work, as kierank > > > wanted to post something, > > > and if users can know to who to point fingers to in case it degrades > > > performance on RPI1 devices. > > > > > > > > >>> Let's aim for a release by Sunday next week. That should give everyone > > >>> enough time to > > >>> backport fixes they want in. > > >>> > > >> > > >> I would aim for 1-3 weeks (when code and developers are ready) > > >> dont want to aim for a specific day, better pick a day when everything > > >> is fine > > >> not too many distractions, ... > > >> > > >> Or is there something that favors us to be before a specific date ? > > >> > > > > > > Not really a reason, Sunday is just an optimistic date to aim for. > > > If there are no big fixes to backport to the branch, I think we can > > > target it. > > > > > > > The nlmeans_vulkan patch I just sent is the last patch I'd like to have in > > 6.1. > > Does anyone else have any patches they would like in 6.1? > > I was going to request Steven Liu's enhanced RTMP set but it looks > like those are already in the release/6.1 branch, so cheers. :-) Thanks ttmath > > -t Thanks Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Tue, Nov 7, 2023 at 2:36 AM Lynne wrote: > > Oct 29, 2023, 06:57 by d...@lynne.ee: > > > Oct 29, 2023, 05:51 by mich...@niedermayer.cc: > > > >> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote: > >> > >>> Oct 28, 2023, 18:49 by mich...@niedermayer.cc: > >>> > >>> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > >>> > > >>> >> It's been a while since we've had a release, and we've had > >>> >> a lot of new features in. > >>> >> We did say we would make releases more often, and I think > >>> >> it's about time we have a new release. > >>> >> > >>> >> Anything anyone wants to have merged or should we branch > >>> >> off 6.1 in a few days? > >>> >> > >>> > > >>> > Whats the status of this ? > >>> > I can branch 6.1 anytime > >>> > > >>> > It was just that jb told me > >>> > "6.1 opportunity is gone. > >>> > We're too late on the schedule, and noone had time to work on it, so > >>> > it is wiser to target 7.0 in January" > >>> > > >>> > but now i see on IRC > >>> > make a damn release already > >>> > j-b: drop MiNi from release maintership and nominate > >>> > Lynne > >>> > I pledge to bring back /slap IRC messages to those who fail to > >>> > push the patches they want for release! > >>> > durandal_1707: good point, we should look at doing another 5.1.x > >>> > release and a 6.0.x release. > >>> > > >>> > noone mentioned 5.1.x and 6.0.x to me before > >>> > > >>> > anyway, ill try to make releases from all maintained branches, > >>> > > >>> > and will branch 6.1 as soon as Lynne or others say everything is ready. > >>> > > >>> > thx > >>> > > >>> > >>> It's never too late to make a release. If we do a release now, nothing's > >>> stopping > >>> us from doing a 7.0 and getting back on track with releases every two > >>> months or so, > >>> like the plan was. > >>> > >>> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) > >>> AAC+fixes, D3D12 hwdec, > >>> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a > >>> good idea to > >>> have a release before all this lands. > >>> > >>> I think the tree is in a pretty good state ATM, you should go ahead and > >>> branch if you're > >>> comfortable with it as well. > >>> > >> > >> branch made > >> > > > > Thanks. I'll get a blog post ready for the transform work, as kierank > > wanted to post something, > > and if users can know to who to point fingers to in case it degrades > > performance on RPI1 devices. > > > > > >>> Let's aim for a release by Sunday next week. That should give everyone > >>> enough time to > >>> backport fixes they want in. > >>> > >> > >> I would aim for 1-3 weeks (when code and developers are ready) > >> dont want to aim for a specific day, better pick a day when everything is > >> fine > >> not too many distractions, ... > >> > >> Or is there something that favors us to be before a specific date ? > >> > > > > Not really a reason, Sunday is just an optimistic date to aim for. > > If there are no big fixes to backport to the branch, I think we can target > > it. > > > > The nlmeans_vulkan patch I just sent is the last patch I'd like to have in > 6.1. > Does anyone else have any patches they would like in 6.1? I was going to request Steven Liu's enhanced RTMP set but it looks like those are already in the release/6.1 branch, so cheers. -t ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Oct 29, 2023, 06:57 by d...@lynne.ee: > Oct 29, 2023, 05:51 by mich...@niedermayer.cc: > >> On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote: >> >>> Oct 28, 2023, 18:49 by mich...@niedermayer.cc: >>> >>> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: >>> > >>> >> It's been a while since we've had a release, and we've had >>> >> a lot of new features in. >>> >> We did say we would make releases more often, and I think >>> >> it's about time we have a new release. >>> >> >>> >> Anything anyone wants to have merged or should we branch >>> >> off 6.1 in a few days? >>> >> >>> > >>> > Whats the status of this ? >>> > I can branch 6.1 anytime >>> > >>> > It was just that jb told me >>> > "6.1 opportunity is gone. >>> > We're too late on the schedule, and noone had time to work on it, so it >>> > is wiser to target 7.0 in January" >>> > >>> > but now i see on IRC >>> > make a damn release already >>> > j-b: drop MiNi from release maintership and nominate Lynne >>> > I pledge to bring back /slap IRC messages to those who fail to >>> > push the patches they want for release! >>> > durandal_1707: good point, we should look at doing another 5.1.x >>> > release and a 6.0.x release. >>> > >>> > noone mentioned 5.1.x and 6.0.x to me before >>> > >>> > anyway, ill try to make releases from all maintained branches, >>> > >>> > and will branch 6.1 as soon as Lynne or others say everything is ready. >>> > >>> > thx >>> > >>> >>> It's never too late to make a release. If we do a release now, nothing's >>> stopping >>> us from doing a 7.0 and getting back on track with releases every two >>> months or so, >>> like the plan was. >>> >>> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) >>> AAC+fixes, D3D12 hwdec, >>> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a >>> good idea to >>> have a release before all this lands. >>> >>> I think the tree is in a pretty good state ATM, you should go ahead and >>> branch if you're >>> comfortable with it as well. >>> >> >> branch made >> > > Thanks. I'll get a blog post ready for the transform work, as kierank wanted > to post something, > and if users can know to who to point fingers to in case it degrades > performance on RPI1 devices. > > >>> Let's aim for a release by Sunday next week. That should give everyone >>> enough time to >>> backport fixes they want in. >>> >> >> I would aim for 1-3 weeks (when code and developers are ready) >> dont want to aim for a specific day, better pick a day when everything is >> fine >> not too many distractions, ... >> >> Or is there something that favors us to be before a specific date ? >> > > Not really a reason, Sunday is just an optimistic date to aim for. > If there are no big fixes to backport to the branch, I think we can target it. > The nlmeans_vulkan patch I just sent is the last patch I'd like to have in 6.1. Does anyone else have any patches they would like in 6.1? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Am 29.10.23 um 20:27 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 19:46, Thilo Borgmann via ffmpeg-devel wrote: Am 29.10.23 um 18:56 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote: In this case as well, I think you should have transported your reasoning back to this thread on the ML - It's actually in this very thread on the ML about the timing and prefering 7.0 over 6.1. I even send a longer email to explain. I wonder why you didn't say that one iteration back when I asked you where to find it. (Your answer was "at VDD & on IRC", just not to delete too much history here.) Anyway, in this very thread (and in the Release 6.1 thread started from Michael before this thread of Lynne) I can see exactly 3 prior mails from you. Mail are not just from me, but about me. Quoting the mail that supposedly quotes me: "6.1 opportunity is gone. We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January" I think it's very clear about "opportunity" and "late on the schedule" and what they mean. You decided then it was not clear and "unsubstantiated", and therefore that my opinion had no value, so I had to expand on it. I did not. So, I spoke about it at VDD, several time, on IRC and it refers to me on this very mailing list. And instead of asking me to clarify, you started to say that my opinion had no value, and then attacking me. Asking for clarification is exactly what I did by asking you where to find your elaborations. You are attacking me here. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sun, 29 Oct 2023, at 19:46, Thilo Borgmann via ffmpeg-devel wrote: > Am 29.10.23 um 18:56 schrieb Jean-Baptiste Kempf: >> On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote: >>> In this case as well, I think you >>> should have transported your reasoning back to this thread on the ML - >> >> It's actually in this very thread on the ML about the timing and prefering >> 7.0 over 6.1. >> >> I even send a longer email to explain. > > I wonder why you didn't say that one iteration back when I asked you > where to > find it. (Your answer was "at VDD & on IRC", just not to delete too > much history > here.) > > Anyway, in this very thread (and in the Release 6.1 thread started from > Michael > before this thread of Lynne) I can see exactly 3 prior mails from you. Mail are not just from me, but about me. Quoting the mail that supposedly quotes me: "6.1 opportunity is gone. We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January" I think it's very clear about "opportunity" and "late on the schedule" and what they mean. You decided then it was not clear and "unsubstantiated", and therefore that my opinion had no value, so I had to expand on it. So, I spoke about it at VDD, several time, on IRC and it refers to me on this very mailing list. And instead of asking me to clarify, you started to say that my opinion had no value, and then attacking me. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > IRC has logs That are good to know what has been said, not for participating in the decision making. Therefore IRC is unacceptable for making decisions. > and many people having fixed work hours are on IRC. The problem is the people who cannot be. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sun, 29 Oct 2023, at 19:31, Nicolas George wrote: > Jean-Baptiste Kempf (12023-10-29): >> We'll have to agree to disagree. > > So you disagree that ffmpeg is not a corporate project where developers > can be forced to have fixed work hours. Interesting. IRC has logs and many people having fixed work hours are on IRC. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Am 29.10.23 um 19:12 schrieb Nicolas George: Jean-Baptiste Kempf (12023-10-29): Sorry, I can. Being on IRC is necessary, IMHO. Completely unacceptable and fortunately not true at all. The mailing-list has always been the main channel of development, anything synchronous, that requires people to be on line at the same time, is unsuited for a project on multiple timezones where everybody is equal but nobody has an obligation. And I think it is very bad that some body with apparent authority suggests otherwise. +1 -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Am 29.10.23 um 18:56 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote: In this case as well, I think you should have transported your reasoning back to this thread on the ML - It's actually in this very thread on the ML about the timing and prefering 7.0 over 6.1. I even send a longer email to explain. I wonder why you didn't say that one iteration back when I asked you where to find it. (Your answer was "at VDD & on IRC", just not to delete too much history here.) Anyway, in this very thread (and in the Release 6.1 thread started from Michael before this thread of Lynne) I can see exactly 3 prior mails from you. 06.07.23, "good idea lets do 6.1" 26.09.23, "calling people liars is bad" 21.09.23, "+1" As well as the many mails from today, of course. So is this problem on my mail client end? Can you provide links into the archives regarding the mails you are referring to? -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > We'll have to agree to disagree. So you disagree that ffmpeg is not a corporate project where developers can be forced to have fixed work hours. Interesting. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sun, 29 Oct 2023, at 19:12, Nicolas George wrote: > Jean-Baptiste Kempf (12023-10-29): >> Sorry, I can. Being on IRC is necessary, IMHO. > > Completely unacceptable and fortunately not true at all. We'll have to agree to disagree. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > Sorry, I can. Being on IRC is necessary, IMHO. Completely unacceptable and fortunately not true at all. The mailing-list has always been the main channel of development, anything synchronous, that requires people to be on line at the same time, is unsuited for a project on multiple timezones where everybody is equal but nobody has an obligation. And I think it is very bad that some body with apparent authority suggests otherwise. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sun, 29 Oct 2023, at 18:20, Thilo Borgmann via ffmpeg-devel wrote: > In this case as well, I think you > should have transported your reasoning back to this thread on the ML - It's actually in this very thread on the ML about the timing and prefering 7.0 over 6.1. I even send a longer email to explain. > cannot blame anyone for not following live discussion like VDD or IRC. Sorry, I can. Being on IRC is necessary, IMHO. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Am 29.10.23 um 17:25 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 16:10, Thilo Borgmann via ffmpeg-devel wrote: Where? I don't see you saying that in this thread. If you said so at VDD, that's not many times. Explained three times at VDD and several time on IRC. Very well. Assuming with "explained" you mean that you gave your reasoning as well, instead of just that statement which was quoted. Because the lack of that is what Nicolas led to refuse your opinion. Not being at where you say s.th. does not imply anything and is not an argument. Refusing to attend the developer meetups and also refusing to be on one of the major discussion media and then complaining about not receiving information is a problem in an open source community. Communication is the biggest problem indeed. In this case as well, I think you should have transported your reasoning back to this thread on the ML - you cannot blame anyone for not following live discussion like VDD or IRC. If you would have done so, your opinion could not have been waived away like Nicolas did. -Thilo p.s. sure, IRC is not really live, yet we expect to follow up on history only on the ML. Which is one reason why we say things like "as agreed on by X on IRC" in patch threads, for example. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sun, 29 Oct 2023, at 17:49, James Almer wrote: > On 10/29/2023 1:42 PM, Jean-Baptiste Kempf wrote: >> Hello, >> >> On Sat, 28 Oct 2023, at 18:49, Michael Niedermayer wrote: >>> noone mentioned 5.1.x and 6.0.x to me before >> >> Our last releases from our two major bracnhes, are a 5.1.3 (which is a LTS >> branch) and a 6.0.0. >> >> Both of those have not had backports and releases of all the security >> issues, nor on the major regressions found (if any). >> >> Also, if they had some commits for security reasons, we should have a >> release at least every 90 days (3 months), because this is the standard for >> the security issues reporting (after that time, the security community makes >> them public). >> And seeing the number of fuzzing fixes, this is likely important. >> >> So, yes, I think having a 5.1.4 and 6.0.1 with the security fixes is of the >> utmost importance. >> >>> It was just that jb told me >>> "6.1 opportunity is gone. >>> We're too late on the schedule, and noone had time to work on it, so >>> it is wiser to target 7.0 in January" >> >> Yes, we said we would make a new major version for January (which will slip >> in February, as usual :D). >> So, doing a 6.1.0 now, while 7.0 is not far away, might be a lot of work and >> it might not worth it. >> Notably since at the time of 7.0, there might be not enough new things to >> cut a release. >> >> So I'm not against a release for 6.1 at all, but I believe focusing on minor >> releases for security and on 7.0 with the next major deprecations is more >> important. >> If we can do all of those, and keep more or less the timing for 7.0, please >> be my guest for 6.1. > > Lynne made a list of the things that should (hopefully) make it to 7.0 > for early 2024 (E.g. YUVJ removal, D3D12 hwdec, Vulkan encode, VVC, > IAMF) plus Anton's CLI scheduler work, not to mention it will feature a > major version bump and all the deprecated API removal that brings. So > even with not a lot of things, the few it will get in these few months > will be pretty big and appealing. > > 6.1 doesn't need to be supported for too long, but it's a good release > to have as it will feature a year worth of development while being 6.0 > ABI compatible, for those distros that care. Excellent then. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On 10/29/2023 1:42 PM, Jean-Baptiste Kempf wrote: Hello, On Sat, 28 Oct 2023, at 18:49, Michael Niedermayer wrote: noone mentioned 5.1.x and 6.0.x to me before Our last releases from our two major bracnhes, are a 5.1.3 (which is a LTS branch) and a 6.0.0. Both of those have not had backports and releases of all the security issues, nor on the major regressions found (if any). Also, if they had some commits for security reasons, we should have a release at least every 90 days (3 months), because this is the standard for the security issues reporting (after that time, the security community makes them public). And seeing the number of fuzzing fixes, this is likely important. So, yes, I think having a 5.1.4 and 6.0.1 with the security fixes is of the utmost importance. It was just that jb told me "6.1 opportunity is gone. We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January" Yes, we said we would make a new major version for January (which will slip in February, as usual :D). So, doing a 6.1.0 now, while 7.0 is not far away, might be a lot of work and it might not worth it. Notably since at the time of 7.0, there might be not enough new things to cut a release. So I'm not against a release for 6.1 at all, but I believe focusing on minor releases for security and on 7.0 with the next major deprecations is more important. If we can do all of those, and keep more or less the timing for 7.0, please be my guest for 6.1. Lynne made a list of the things that should (hopefully) make it to 7.0 for early 2024 (E.g. YUVJ removal, D3D12 hwdec, Vulkan encode, VVC, IAMF) plus Anton's CLI scheduler work, not to mention it will feature a major version bump and all the deprecated API removal that brings. So even with not a lot of things, the few it will get in these few months will be pretty big and appealing. 6.1 doesn't need to be supported for too long, but it's a good release to have as it will feature a year worth of development while being 6.0 ABI compatible, for those distros that care. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > Being not polite to someone is a personal attack. No. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sun, 29 Oct 2023, at 17:40, Nicolas George wrote: > Jean-Baptiste Kempf (12023-10-29): >> Because instead of doing the polite and normal thing which would be: > > Politeness or not does not make it a personal attack. Moving goalposts > much? Being not polite to someone is a personal attack. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Hello, On Sat, 28 Oct 2023, at 18:49, Michael Niedermayer wrote: > noone mentioned 5.1.x and 6.0.x to me before Our last releases from our two major bracnhes, are a 5.1.3 (which is a LTS branch) and a 6.0.0. Both of those have not had backports and releases of all the security issues, nor on the major regressions found (if any). Also, if they had some commits for security reasons, we should have a release at least every 90 days (3 months), because this is the standard for the security issues reporting (after that time, the security community makes them public). And seeing the number of fuzzing fixes, this is likely important. So, yes, I think having a 5.1.4 and 6.0.1 with the security fixes is of the utmost importance. > It was just that jb told me > "6.1 opportunity is gone. > We're too late on the schedule, and noone had time to work on it, so > it is wiser to target 7.0 in January" Yes, we said we would make a new major version for January (which will slip in February, as usual :D). So, doing a 6.1.0 now, while 7.0 is not far away, might be a lot of work and it might not worth it. Notably since at the time of 7.0, there might be not enough new things to cut a release. So I'm not against a release for 6.1 at all, but I believe focusing on minor releases for security and on 7.0 with the next major deprecations is more important. If we can do all of those, and keep more or less the timing for 7.0, please be my guest for 6.1. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > Because instead of doing the polite and normal thing which would be: Politeness or not does not make it a personal attack. Moving goalposts much? -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sun, 29 Oct 2023, at 15:17, Nicolas George wrote: > Jean-Baptiste Kempf (12023-10-29): >> > Unsubstantiated opinion, let us ignore it. >> Again, a personal attack, from you. > > YOU are not an OPINION, so, no, this is not a personal attack, Because instead of doing the polite and normal thing which would be: "jb, I did not hear your opinion, can you restate it?" you said "jb, I did not hear his opinion, he should be ignored". -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sun, 29 Oct 2023, at 16:10, Thilo Borgmann via ffmpeg-devel wrote: > Where? I don't see you saying that in this thread. > If you said so at VDD, that's not many times. Explained three times at VDD and several time on IRC. > Not being at where you say s.th. does not imply anything and is not an > argument. Refusing to attend the developer meetups and also refusing to be on one of the major discussion media and then complaining about not receiving information is a problem in an open source community. jb -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Am 29.10.23 um 14:51 schrieb Jean-Baptiste Kempf: On Sun, 29 Oct 2023, at 10:30, Nicolas George wrote: Michael Niedermayer (12023-10-28): It was just that jb told me "6.1 opportunity is gone. Unsubstantiated opinion, let us ignore it. Not like your opinions that are always substantiated... Except I explain many times why the opportunity has passed for 6.1, but you, once again, don't listen, or refuse to be on the means where we discuss. Where? I don't see you saying that in this thread. If you said so at VDD, that's not many times. Not being at where you say s.th. does not imply anything and is not an argument. Again, a personal attack, from you. If you find calling your opinion unsubstantiated a personal attack, then why do you reply with the same personal attack? -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jean-Baptiste Kempf (12023-10-29): > > Unsubstantiated opinion, let us ignore it. > Again, a personal attack, from you. YOU are not an OPINION, so, no, this is not a personal attack, this is a lie. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sun, 29 Oct 2023, at 10:30, Nicolas George wrote: > Michael Niedermayer (12023-10-28): >> It was just that jb told me >> "6.1 opportunity is gone. > > Unsubstantiated opinion, let us ignore it. Not like your opinions that are always substantiated... Except I explain many times why the opportunity has passed for 6.1, but you, once again, don't listen, or refuse to be on the means where we discuss. Again, a personal attack, from you. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Michael Niedermayer (12023-10-28): > It was just that jb told me > "6.1 opportunity is gone. Unsubstantiated opinion, let us ignore it. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Oct 29, 2023, 05:51 by mich...@niedermayer.cc: > On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote: > >> Oct 28, 2023, 18:49 by mich...@niedermayer.cc: >> >> > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: >> > >> >> It's been a while since we've had a release, and we've had >> >> a lot of new features in. >> >> We did say we would make releases more often, and I think >> >> it's about time we have a new release. >> >> >> >> Anything anyone wants to have merged or should we branch >> >> off 6.1 in a few days? >> >> >> > >> > Whats the status of this ? >> > I can branch 6.1 anytime >> > >> > It was just that jb told me >> > "6.1 opportunity is gone. >> > We're too late on the schedule, and noone had time to work on it, so it >> > is wiser to target 7.0 in January" >> > >> > but now i see on IRC >> > make a damn release already >> > j-b: drop MiNi from release maintership and nominate Lynne >> > I pledge to bring back /slap IRC messages to those who fail to >> > push the patches they want for release! >> > durandal_1707: good point, we should look at doing another 5.1.x >> > release and a 6.0.x release. >> > >> > noone mentioned 5.1.x and 6.0.x to me before >> > >> > anyway, ill try to make releases from all maintained branches, >> > >> > and will branch 6.1 as soon as Lynne or others say everything is ready. >> > >> > thx >> > >> >> It's never too late to make a release. If we do a release now, nothing's >> stopping >> us from doing a 7.0 and getting back on track with releases every two months >> or so, >> like the plan was. >> >> 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) >> AAC+fixes, D3D12 hwdec, >> Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a >> good idea to >> have a release before all this lands. >> >> I think the tree is in a pretty good state ATM, you should go ahead and >> branch if you're >> comfortable with it as well. >> > > branch made > Thanks. I'll get a blog post ready for the transform work, as kierank wanted to post something, and if users can know to who to point fingers to in case it degrades performance on RPI1 devices. >> Let's aim for a release by Sunday next week. That should give everyone >> enough time to >> backport fixes they want in. >> > > I would aim for 1-3 weeks (when code and developers are ready) > dont want to aim for a specific day, better pick a day when everything is fine > not too many distractions, ... > > Or is there something that favors us to be before a specific date ? > Not really a reason, Sunday is just an optimistic date to aim for. If there are no big fixes to backport to the branch, I think we can target it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sat, Oct 28, 2023 at 09:23:45PM +0200, Lynne wrote: > Oct 28, 2023, 18:49 by mich...@niedermayer.cc: > > > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > > > >> It's been a while since we've had a release, and we've had > >> a lot of new features in. > >> We did say we would make releases more often, and I think > >> it's about time we have a new release. > >> > >> Anything anyone wants to have merged or should we branch > >> off 6.1 in a few days? > >> > > > > Whats the status of this ? > > I can branch 6.1 anytime > > > > It was just that jb told me > > "6.1 opportunity is gone. > > We're too late on the schedule, and noone had time to work on it, so it is > > wiser to target 7.0 in January" > > > > but now i see on IRC > > make a damn release already > > j-b: drop MiNi from release maintership and nominate Lynne > > I pledge to bring back /slap IRC messages to those who fail to push > > the patches they want for release! > > durandal_1707: good point, we should look at doing another 5.1.x > > release and a 6.0.x release. > > > > noone mentioned 5.1.x and 6.0.x to me before > > > > anyway, ill try to make releases from all maintained branches, > > > > and will branch 6.1 as soon as Lynne or others say everything is ready. > > > > thx > > > > It's never too late to make a release. If we do a release now, nothing's > stopping > us from doing a 7.0 and getting back on track with releases every two months > or so, > like the plan was. > > 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, > D3D12 hwdec, > Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good > idea to > have a release before all this lands. > > I think the tree is in a pretty good state ATM, you should go ahead and > branch if you're > comfortable with it as well. branch made > Let's aim for a release by Sunday next week. That should give everyone enough > time to > backport fixes they want in. I would aim for 1-3 weeks (when code and developers are ready) dont want to aim for a specific day, better pick a day when everything is fine not too many distractions, ... Or is there something that favors us to be before a specific date ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Oct 28, 2023, 18:49 by mich...@niedermayer.cc: > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > >> It's been a while since we've had a release, and we've had >> a lot of new features in. >> We did say we would make releases more often, and I think >> it's about time we have a new release. >> >> Anything anyone wants to have merged or should we branch >> off 6.1 in a few days? >> > > Whats the status of this ? > I can branch 6.1 anytime > > It was just that jb told me > "6.1 opportunity is gone. > We're too late on the schedule, and noone had time to work on it, so it is > wiser to target 7.0 in January" > > but now i see on IRC > make a damn release already > j-b: drop MiNi from release maintership and nominate Lynne > I pledge to bring back /slap IRC messages to those who fail to push > the patches they want for release! > durandal_1707: good point, we should look at doing another 5.1.x > release and a 6.0.x release. > > noone mentioned 5.1.x and 6.0.x to me before > > anyway, ill try to make releases from all maintained branches, > > and will branch 6.1 as soon as Lynne or others say everything is ready. > > thx > It's never too late to make a release. If we do a release now, nothing's stopping us from doing a 7.0 and getting back on track with releases every two months or so, like the plan was. 7.0 is likely to be a pretty big release, with YUVJ removal, (xHE) AAC+fixes, D3D12 hwdec, Vulkan encode and Vulkan AV1, and VVC, and IAMF, and MLP work, so it's a good idea to have a release before all this lands. I think the tree is in a pretty good state ATM, you should go ahead and branch if you're comfortable with it as well. Let's aim for a release by Sunday next week. That should give everyone enough time to backport fixes they want in. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On 10/28/2023 1:49 PM, Michael Niedermayer wrote: On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: It's been a while since we've had a release, and we've had a lot of new features in. We did say we would make releases more often, and I think it's about time we have a new release. Anything anyone wants to have merged or should we branch off 6.1 in a few days? Whats the status of this ? I can branch 6.1 anytime It was just that jb told me "6.1 opportunity is gone. We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January" but now i see on IRC make a damn release already j-b: drop MiNi from release maintership and nominate Lynne I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release! durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release. noone mentioned 5.1.x and 6.0.x to me before Point releases are in general up to you. 6.0 could have gotten one during the past few months, to be honest, but unless there were critical bugs there was probably no hurry. anyway, ill try to make releases from all maintained branches, and will branch 6.1 as soon as Lynne or others say everything is ready. I'd branch a 6.1 with the tree in its current state (doesn't need to be right now, i mean API wise). 7.0 will feature a major bump and deprecated API removal, so it'd be nice to have one more release with the current sonames. And IMO it's fine if we release 7.0 in January despite not having much development done post 6.1. But i want other people's opinions. I forgot, which release was supposed to be LTS? 6.0 or 6.1? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > It's been a while since we've had a release, and we've had > a lot of new features in. > We did say we would make releases more often, and I think > it's about time we have a new release. > > Anything anyone wants to have merged or should we branch > off 6.1 in a few days? Whats the status of this ? I can branch 6.1 anytime It was just that jb told me "6.1 opportunity is gone. We're too late on the schedule, and noone had time to work on it, so it is wiser to target 7.0 in January" but now i see on IRC make a damn release already j-b: drop MiNi from release maintership and nominate Lynne I pledge to bring back /slap IRC messages to those who fail to push the patches they want for release! durandal_1707: good point, we should look at doing another 5.1.x release and a 6.0.x release. noone mentioned 5.1.x and 6.0.x to me before anyway, ill try to make releases from all maintained branches, and will branch 6.1 as soon as Lynne or others say everything is ready. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Mon, Oct 9, 2023 at 1:42 PM Michael Niedermayer wrote: > > On Mon, Oct 09, 2023 at 05:37:42AM +0200, Lynne wrote: > > Jul 6, 2023, 18:04 by d...@lynne.ee: > > > > > It's been a while since we've had a release, and we've had > > > a lot of new features in. > > > We did say we would make releases more often, and I think > > > it's about time we have a new release. > > > > > > Anything anyone wants to have merged or should we branch > > > off 6.1 in a few days? > > > > > > > Could we consider at least branching off 6.1? > > we can consider branching whenever theres a consensus to do so > People are always quick in saying what they want in / done before > releases/branching. But its rare that people later reply and say that an issue > was resolved. > This makes monitoring for what blockers remain painfull > i think for the next release we should automate this > because trac has a "Blocking" field and that could be set to 6.1 > for example and then one can just query trac for all open tickets > that are blocking "6.1" > Which would make it MUCH easier to know what is blocking it and would > make it easier to know when all blockers are gone > ATM one has to go over multiple threads and then figure out what people > asked for to be done first and then find out if the things are still > not done. > Sorry if I haven't chimed in about this. From my point of view, the things I need in 6.1 have landed. So I'm fine with 6.1 being released now. -- 真実はいつも一つ！/ Always, there's only one truth! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Mon, Oct 09, 2023 at 05:37:42AM +0200, Lynne wrote: > Jul 6, 2023, 18:04 by d...@lynne.ee: > > > It's been a while since we've had a release, and we've had > > a lot of new features in. > > We did say we would make releases more often, and I think > > it's about time we have a new release. > > > > Anything anyone wants to have merged or should we branch > > off 6.1 in a few days? > > > > Could we consider at least branching off 6.1? we can consider branching whenever theres a consensus to do so People are always quick in saying what they want in / done before releases/branching. But its rare that people later reply and say that an issue was resolved. This makes monitoring for what blockers remain painfull i think for the next release we should automate this because trac has a "Blocking" field and that could be set to 6.1 for example and then one can just query trac for all open tickets that are blocking "6.1" Which would make it MUCH easier to know what is blocking it and would make it easier to know when all blockers are gone ATM one has to go over multiple threads and then figure out what people asked for to be done first and then find out if the things are still not done. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jul 6, 2023, 18:04 by d...@lynne.ee: > It's been a while since we've had a release, and we've had > a lot of new features in. > We did say we would make releases more often, and I think > it's about time we have a new release. > > Anything anyone wants to have merged or should we branch > off 6.1 in a few days? > Could we consider at least branching off 6.1? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Wed, Oct 04, 2023 at 05:19:17PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-10-03 21:22:58) > > On Tue, Sep 26, 2023 at 08:14:37PM +0200, Anton Khirnov wrote: > > > You keep framing this as some kind of a personal campaign against you. > > > It is not. From my perspective, the objections to SDR have been largely > > > technical, and most of the "heat" comes from your refusal to accept that > > > many active developers are against it. > > > > Technical arguments ? > > Yes, several people had technical arguments, I remember Tomas and Remi and > > some > > others. But at least subjectively i felt that the bulk of people where alot > > more > > emotional than technical > > > > But let me list a few observations, from memory > > First objection was because processing is done in an external library. > > Then it was found out that was wrong and actually processing is done in the > > new code > > so the objection flipped and people demanded it to be moved into an > > external library. > > > > If you object to pink and want blue and when you find out its actually blue > > you have > > to be happy and become a supporter but what happened was the opposit, the > > objection > > was simply adjusted to object to whatever was the case and demand whatever > > was not. > > > > Ok so thats at least one developers "Technical objection" down here, maybe > > more > > i dont know if anyone else expressed that same initial objection. but lets > > move on > > > > In all cases we prefer not to have external dependancies, this is the > > Technical position of FFmpeg > > no, there is no technical argument in this. > > Also personal preferrances of people is not a technical argument. Noone > > explained why a > > avdevice module with more external depandancies would be ok but a avdevice > > module with > > fewer external depandancies was not. <-- This last sentance is a technical > > argument > > I could go as far as call this a proof by contradiction. > > > > If people are happy with a avdevice module and FFmpeg prefers fewer > > external dependancies > > then my suggestion of first starting with a plain simple self contained > > avdevice/avformat > > module, would have to be fine too. > > We can always move this to an external library once there is a technical > > reason for that > > like for example some other software wants to use it > > > > About the attack/rallying/compaign stuff. Ill keep it very brief as its not > > useful i think. > > Also this is my own personal and subjective view. In fact the whole mail is > > There was alot of (negative) emotion from 1-2 people about SDR. This > > emotion was what spread > > slash rallied other developers. That came before any technical arguments. > > Now people have picked their flag and march to war. > > > > Everyone will deny it, same as every patriot will fight to the death for > > the colors of > > the flag of the country and religion they where born into. > > > > My claim, sorry to be stubborn, is that had this started a slight bit > > different there > > would be little opposition to SDR. Iam not denying that now there are > > several people > > against it. > > These are largely unfalsifiable claims, so I don't see how they can > productively contribute to this discussion. > > But dismissing people's concerns as "patriotic" or "religious" isn't > helping your case IMO. That was not my intend i had not intended to dismiss anyones concern What i was trying to do with this 2nd part of the mail was to document a subjective observation. The reason was simply _IF_ this observation is somewhat correct, then awareness of this could help people next time. As i stated i expect noone to change their position here. But maybe next time we have a similar growing disagreement being aware of the possible effects of emotional statements from fellow developers could be helpfull. thx, and ill try to end this debate in this thread, this minor comment just felt it fits better here [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
This discussion has drifted far away from any topic set upfront. It's gotten to the point where there's no way for anyone outside to join and give their own opinion, as it's not possible to know the entire discussion that's happened up to this point. Hence, spin this off in multiple threads. Maybe the one summarizing a discussion will find it's pointless and we could focus on a smaller set of things to worry about for 6.1's release. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Quoting Michael Niedermayer (2023-10-03 21:22:58) > On Tue, Sep 26, 2023 at 08:14:37PM +0200, Anton Khirnov wrote: > > You keep framing this as some kind of a personal campaign against you. > > It is not. From my perspective, the objections to SDR have been largely > > technical, and most of the "heat" comes from your refusal to accept that > > many active developers are against it. > > Technical arguments ? > Yes, several people had technical arguments, I remember Tomas and Remi and > some > others. But at least subjectively i felt that the bulk of people where alot > more > emotional than technical > > But let me list a few observations, from memory > First objection was because processing is done in an external library. > Then it was found out that was wrong and actually processing is done in the > new code > so the objection flipped and people demanded it to be moved into an external > library. > > If you object to pink and want blue and when you find out its actually blue > you have > to be happy and become a supporter but what happened was the opposit, the > objection > was simply adjusted to object to whatever was the case and demand whatever > was not. > > Ok so thats at least one developers "Technical objection" down here, maybe > more > i dont know if anyone else expressed that same initial objection. but lets > move on > > In all cases we prefer not to have external dependancies, this is the > Technical position of FFmpeg > no, there is no technical argument in this. > Also personal preferrances of people is not a technical argument. Noone > explained why a > avdevice module with more external depandancies would be ok but a avdevice > module with > fewer external depandancies was not. <-- This last sentance is a technical > argument > I could go as far as call this a proof by contradiction. > > If people are happy with a avdevice module and FFmpeg prefers fewer external > dependancies > then my suggestion of first starting with a plain simple self contained > avdevice/avformat > module, would have to be fine too. > We can always move this to an external library once there is a technical > reason for that > like for example some other software wants to use it > > About the attack/rallying/compaign stuff. Ill keep it very brief as its not > useful i think. > Also this is my own personal and subjective view. In fact the whole mail is > There was alot of (negative) emotion from 1-2 people about SDR. This emotion > was what spread > slash rallied other developers. That came before any technical arguments. > Now people have picked their flag and march to war. > > Everyone will deny it, same as every patriot will fight to the death for the > colors of > the flag of the country and religion they where born into. > > My claim, sorry to be stubborn, is that had this started a slight bit > different there > would be little opposition to SDR. Iam not denying that now there are several > people > against it. These are largely unfalsifiable claims, so I don't see how they can productively contribute to this discussion. But dismissing people's concerns as "patriotic" or "religious" isn't helping your case IMO. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Tue, Sep 26, 2023 at 08:14:37PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-09-26 19:16:30) > > On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2023-09-26 17:09:47) > > > > On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote: > > > > > Quoting Michael Niedermayer (2023-09-22 11:27:54) > > > > > > The idea was really just, that i said ill include SDR and i want to > > > > > > keep this word > > > > > > > > > > Well, you should not have spoken for the entire project without > > > > > consulting the rest of the community first. Nobody here is entitled to > > > > > > > > This statement is a little misleading, i think > > > > > > > > Iam part of the community, i would think and for 99% of the tweets made > > > > on the official twitter account i have never been asked or even had a > > > > chance to comment before they where made. So what you suggest here is > > > > "the correct way", has never been applied. > > > > > > This is disingenuous sophistry, and honestly I find it insulting that > > > you expect people to swallow it. > > > > > > You made the tweet in question long after it was clear that the feature > > > is controversial. Then you tried to use it as an argument in favor of > > > pushing SDR to master. In other words, you used the fact that you have > > > Twitter posting rights to promote your opinion over that of other > > > developers. If that is not abuse of power then I don't know what is. > > > > ok > > I wrote a SDR input device for free, wanted to give it to the users > > as i believed it was a cool and usefull feature > > > > i tried to argue for it, i tried to promote it. > > And as the person doing all releases of FFmpeg since a very long time > > i thought yeah we will be able to resolve the disagreements and get it > > in 6.1 with everyone geing happy. > > I was wrong, i announced this before i actually got people to agree yes > > I still belive if people where not so "excited" on this whole and if it > > was just a technical question we could get SDR in 6.1 with everyone > > agreeing. > > But now heres a man to be burned at the stake, and thats more important. > > You keep framing this as some kind of a personal campaign against you. > It is not. From my perspective, the objections to SDR have been largely > technical, and most of the "heat" comes from your refusal to accept that > many active developers are against it. Technical arguments ? Yes, several people had technical arguments, I remember Tomas and Remi and some others. But at least subjectively i felt that the bulk of people where alot more emotional than technical But let me list a few observations, from memory First objection was because processing is done in an external library. Then it was found out that was wrong and actually processing is done in the new code so the objection flipped and people demanded it to be moved into an external library. If you object to pink and want blue and when you find out its actually blue you have to be happy and become a supporter but what happened was the opposit, the objection was simply adjusted to object to whatever was the case and demand whatever was not. Ok so thats at least one developers "Technical objection" down here, maybe more i dont know if anyone else expressed that same initial objection. but lets move on In all cases we prefer not to have external dependancies, this is the Technical position of FFmpeg no, there is no technical argument in this. Also personal preferrances of people is not a technical argument. Noone explained why a avdevice module with more external depandancies would be ok but a avdevice module with fewer external depandancies was not. <-- This last sentance is a technical argument I could go as far as call this a proof by contradiction. If people are happy with a avdevice module and FFmpeg prefers fewer external dependancies then my suggestion of first starting with a plain simple self contained avdevice/avformat module, would have to be fine too. We can always move this to an external library once there is a technical reason for that like for example some other software wants to use it About the attack/rallying/compaign stuff. Ill keep it very brief as its not useful i think. Also this is my own personal and subjective view. In fact the whole mail is There was alot of (negative) emotion from 1-2 people about SDR. This emotion was what spread slash rallied other developers. That came before any technical arguments. Now people have picked their flag and march to war. Everyone will deny it, same as every patriot will fight to the death for the colors of the flag of the country and religion they where born into. My claim, sorry to be stubborn, is that had this started a slight bit different there would be little opposition to SDR. Iam not denying that now there are several people against it. thx [...] -- Michael GnuPG fingerprint:
Re: [FFmpeg-devel] [RFC] Release 6.1
Le torstaina 28. syyskuuta 2023, 19.43.57 EEST Nicolas George a écrit : > Rémi Denis-Courmont (12023-09-28): > > Calling BBB, Kieran and myself dishonest is. > > I call your arguments dishonest. You almost had me doubting my recollection for a minute. But: Michael wrote: > > People did not ask that to be put in a seperate general purpose fractal > > library. > > With SDR they do ask for a seperate library. And you then wrote: > And they are being dishonest in that Arguments cannot "ask for separate library". "They" were explicitly "people", specifically people asking for a separate library. Later on: > Nobody honest would seriously try to argue the opposite. [after I had indeed argued the opposite] Feel free to call me captain obvious: "nobody" is a negative pronoun for people, not for abstract concepts such as arguments, for which the pronoun would be "nothing". But hey, I shall not reproduce Paul's mistake that got him admonished by JB. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > Calling BBB, Kieran and myself dishonest is. I call your arguments dishonest. > I take that as an admission of guilt. Take it as you want. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > And this puts me in a bit of a conundrum. See, if you did figure that much > out, > then you would be willfully committing defamation against me, by calling me > dishonest. I am calling your argument dishonest. I stand by it. >I suppose that I am going to have to assume that you are somehow ^^^ > temporarily incapacitated. Now, *this* is an ad-hominem argument indeed. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Le torstaina 28. syyskuuta 2023, 19.41.06 EEST Nicolas George a écrit : > (1) There was no violations in my message. Calling your arguments > bullshit is not a personal attack, by definition. Calling BBB, Kieran and myself dishonest is. > (2) Even if there were any violation, there is nobody to report it to > anyway. I take that as an admission of guilt. -- レミ・デニ-クールモン http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > Literally the exact same verb even. So what are you saying, that I noticed you moved the goalposts one message too late? > P.S.: Your repeated CoC violations will be reported shortly. So, for your information: (1) There was no violations in my message. Calling your arguments bullshit is not a personal attack, by definition. (2) Even if there were any violation, there is nobody to report it to anyway. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Le torstaina 28. syyskuuta 2023, 19.32.44 EEST Nicolas George a écrit : > Rémi Denis-Courmont (12023-09-28): > > Err, it is very much an issue w.r.t. "catching on". > > Moving the goalpost much. I think obviously not, considering the original quote (EMPHASIS ADDED): > In fact, the SDR code has quite a number of impediments that all but > guarantee that IT WILL NOT CATCH ON in FFmpeg: > - it requires niche hardware, > - it only works on some limited set of OSes (if not only Linux), Literally the exact same verb even. P.S.: Your repeated CoC violations will be reported shortly. -- レミ・デニ-クールモン http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On 9/28/23, Nicolas George wrote: > Rémi Denis-Courmont (12023-09-28): >> Err, it is very much an issue w.r.t. "catching on". > > Moving the goalpost much. > >> Also that's an ad hominem attack, which violates the CC. > > No it is not. > > This mail is no longer part of a honest discussion, and therefore I will > save myself the time of answering it in details. > > Stop moving the goalposts, stop wasting everybody's time by turning > arguments on their head and emptying them of their value at the same > time. > > You can sate what you want about SDR and why you want it, that might > make the discussion progress. Or you can continue wasting your time with > bullshit arguments. This is again against the CC. > > -- > Nico > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Le torstaina 28. syyskuuta 2023, 19.13.37 EEST Nicolas George a écrit : > Rémi Denis-Courmont (12023-09-28): > > Thanks for making my point. > > Stealing the other person rhetoric device does not make you right. > > > That does not change the fact that it won't make it any popular, and thus > > your postulate is wrong. > > It reach more popular included in FFmpeg than if users have to download > it separately. If this were a feature that would be somehow automatically enabled or highly visible, that would make sense. But not only is it no such thing, it requires special hardware. With that noted, for any reasonable understanding of "popularity", it would be less popular. That is the point. People who want to do SDR will be burdened with the other 99% of FFmpeg that they don't need for SDR. And that's if they find out that FFmpeg can actually do SDR - but in all likelihood, they wouldn't, because of the brand recognition of FFmpeg. Instead, they'd end up with some SDR-specific projects. That's why, if Michael does not want to join an existing SDR project, he is much better off making a new one, than bundling in FFmpeg. > Nobody honest would seriously try to argue the opposite. I believe that you have high IQ, and good English skill, enough that you should be able to more or less figure out what was noted above and up-thread. And this puts me in a bit of a conundrum. See, if you did figure that much out, then you would be willfully committing defamation against me, by calling me dishonest. I suppose that I am going to have to assume that you are somehow temporarily incapacitated. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > Err, it is very much an issue w.r.t. "catching on". Moving the goalpost much. > Also that's an ad hominem attack, which violates the CC. No it is not. This mail is no longer part of a honest discussion, and therefore I will save myself the time of answering it in details. Stop moving the goalposts, stop wasting everybody's time by turning arguments on their head and emptying them of their value at the same time. You can sate what you want about SDR and why you want it, that might make the discussion progress. Or you can continue wasting your time with bullshit arguments. -- Nico signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Le torstaina 28. syyskuuta 2023, 18.28.50 EEST Nicolas George a écrit : > Rémi Denis-Courmont (12023-09-28): > > You can repeat the contrary as much as you want, we do not believe that > > your SDR code fits in FFmpeg. Why do you not understand this? > > We understand that very well. Once again, it is you who do not > understand something: your BELIEF that SDR does not belong in ffmpeg is > nothing more than that, a belief, an opinion, and it weighs nothing in > front of the argument that some users want it. "We understand that very well. Once again, it is you who do not understand something: your BELIEF tha SDR does beling in FFmpeg is nothing more than that, a belief, an opinion, and it weighs" very little in the face of repeated technical arguments by several members of the development community as well as common sense. > it weighs nothing in front of the argument that some users want it. Literally ABSOLUTELY ZERO *users* said that they wanted it, except for Michael himself. Other people (including you) did say that they wanted it, yes, but none of them were users or even potential users of SDR. Some even explicitly said that (although it sounded cool) they would not use it. So you fail at logical argumentation again. > > Like no, seriously. If you really want to generic support for AM and FM RX > > in FFmpeg, then you should use implement frontends for the already > > *existing* HAL (that would be V4L radio and ALSA on Linux), or perhaps, > > write a new user- space HAL library that would accomodate both hardware > > radio RX devices and SDR. > > Did you miss the part where he explained he was not interesting in doing > it like that? He said that he did not want to join an existing SDR project. That's completely orthogonal. And in any case, this is one of several technical argument. You cannot "disprove" it with the subjective opinions and authority fallacies. > > In fact, the SDR code has quite a number of impediments that all but > > guarantee that it will not "catch on" in FFmpeg: > > - it requires niche hardware, > > Like a few components of libavdevice, that is not an issue. Err, it is very much an issue w.r.t. "catching on". You even left the original quote up there. This makes your highly intellectually dishonest attempt at distorting my statements all the more blatant. > > - it only works on some limited set of OSes (if not only Linux), > > Like a few components of libavdevice, that is not an issue. Same thing. > > - it will be subject to all the FFmpeg processes and drama, > > This problem does not come from SDR, it comes from you. I was not the one to start this drama (on either side of the argument), and there have been plenty more people on my side than yours. I am indeed part of the problem in a sense. Though if I follow that logic, you are a proportionally bigger part of the problem, FWIW. Now you could argue that my argument si a self-realising prophecy. But regardless of who is to blame, my argument holds: the drame will continue (with or without me, by the way) unless Michael compromises and takes SDR out of FFmpeg.git and FFmpeg-devel. > > - it will be obscured by FFmpeg's existing own fame, remaining an obscure > > feature set that hardly anybody outside FFmpeg-devel knows about. > > Like a lot of features. Probably indeed like a lot of features, who failed to catch on and will continue to fail to catch on. My point exactly! > Scrapping the bottom of drawers for arguments are you? I think that I made it clear that this was about how/why SDR will not be *popular* inside FFmpeg. Maybe those are bottom of the drawer arguments against SDR in FFmpeg. That does not exactly matter in this context, since that is not what they were about. Also that's an ad hominem attack, which violates the CC. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > Thanks for making my point. Stealing the other person rhetoric device does not make you right. > That does not change the fact that it won't make it any popular, and thus > your > postulate is wrong. It reach more popular included in FFmpeg than if users have to download it separately. Nobody honest would seriously try to argue the opposite. > It should be blatantly obvious to anybody with a modicum of modesty that "fit > nicely together" is intrinsically a very subjective value judgement, not a > technical argument in favor or disfavor of anything. What you are describing here is your “does not belong”. “Fit nicely together” means it allows to do things that were not possible previously or required more work and were more fragile (pipelines and shell scripts). It is a technical argument. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Le torstaina 28. syyskuuta 2023, 18.33.33 EEST Nicolas George a écrit : > Rémi Denis-Courmont (12023-09-28): > > Strange, I thought FFmpeg really became popular as a back-end library for > > mplayer, before it was picked up by all other OSS multimedia at the time > > (gstreamer, VLC, Xine, etc.). > > Fortunately, I know the history of our projects better than you: > > First, FFmpeg was already a feature-rich self-contained program when > MPlayer started using it. Just being feature-rich does not make it popular. I never said anything about being or not being feature-rich at that point in time. But congratulations on disproving a point that nobody made anyway. > Second, MPlayer did not start using it FFmpeg as a library, it started — > and still does in part — using it as embedded code. Sure and that is in fact one way to use a software library. There is even a name for that practice nowadays: vendoring. Thanks for making my point. > Too bad your attempt at disproving my point just proves it. Just providing some historical facts (that I don't challenge) does not disprove my point. You pretty much confirmed my point actually. And besides, one example (FFmpeg) does not prove a general rule, such as you up-thread postulate that started-as-library software is never popular. Indeed, anybody who knows open-source in general knows that there are plenty of libraries that are popular. In fact, there are far more popular libraries than popular applications in terms of user base, and often in terms of development activity and community strength. (And I don't count libraries with reference command line tools as applications, otherwise everything is an application and your implied dichotomy would not make sense to begin with.) > > Force-feeding the SDR code to all FFmpeg packagers is not going to make it > > popular. Most of them will just disable it, especially if it brings new > > dependencies and/or doesn't work on the popular proprietary platforms. > > So, they can “just disable it” and ignore it. That does not change the fact that it won't make it any popular, and thus your postulate is wrong. > They have no ground to oppose, and neither do you. I neither needed nor sought new ground here. I just disprove your postulate, not that I expect you to be able to grasp the possibility of such occurrence, in light of your past and present show of self-assurance (to put it politely). > > FWIW, Fabrice Bellard didn't bundle all his initially hobby projects > > together. Several of them became popular. > > He bundled together the things that fit nicely together. > Once again an argument in favor of SDR integration. It should be blatantly obvious to anybody with a modicum of modesty that "fit nicely together" is intrinsically a very subjective value judgement, not a technical argument in favor or disfavor of anything. -- レミ・デニ-クールモン http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > Strange, I thought FFmpeg really became popular as a back-end library for > mplayer, before it was picked up by all other OSS multimedia at the time > (gstreamer, VLC, Xine, etc.). Fortunately, I know the history of our projects better than you: First, FFmpeg was already a feature-rich self-contained program when MPlayer started using it. Second, MPlayer did not start using it FFmpeg as a library, it started — and still does in part — using it as embedded code. Too bad your attempt at disproving my point just proves it. > Force-feeding the SDR code to all FFmpeg packagers is not going to make it > popular. Most of them will just disable it, especially if it brings new > dependencies and/or doesn't work on the popular proprietary platforms. So, they can “just disable it” and ignore it. They have no ground to oppose, and neither do you. > FWIW, Fabrice Bellard didn't bundle all his initially hobby projects > together. > Several of them became popular. He bundled together the things that fit nicely together. Once again an argument in favor of SDR integration. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Rémi Denis-Courmont (12023-09-28): > You can repeat the contrary as much as you want, we do not believe that your > SDR code fits in FFmpeg. Why do you not understand this? We understand that very well. Once again, it is you who do not understand something: your BELIEF that SDR does not belong in ffmpeg is nothing more than that, a belief, an opinion, and it weighs nothing in front of the argument that some users want it. > Like no, seriously. If you really want to generic support for AM and FM RX in > FFmpeg, then you should use implement frontends for the already *existing* > HAL > (that would be V4L radio and ALSA on Linux), or perhaps, write a new user- > space HAL library that would accomodate both hardware radio RX devices and > SDR. Did you miss the part where he explained he was not interesting in doing it like that? > In fact, the SDR code has quite a number of impediments that all but > guarantee > that it will not "catch on" in FFmpeg: > - it requires niche hardware, Like a few components of libavdevice, that is not an issue. > - it only works on some limited set of OSes (if not only Linux), Like a few components of libavdevice, that is not an issue. > - it will be subject to all the FFmpeg processes and drama, This problem does not come from SDR, it comes from you. > - it will be obscured by FFmpeg's existing own fame, remaining an obscure > feature set that hardly anybody outside FFmpeg-devel knows about. Like a lot of features. Scrapping the bottom of drawers for arguments are you? -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Le keskiviikkona 27. syyskuuta 2023, 23.27.40 EEST Nicolas George a écrit : > Michael Niedermayer (12023-09-27): > > With SDR they do ask for a seperate library. > > And they are being dishonest in that. Nothing successful starts as a > library, Strange, I thought FFmpeg really became popular as a back-end library for mplayer, before it was picked up by all other OSS multimedia at the time (gstreamer, VLC, Xine, etc.). Force-feeding the SDR code to all FFmpeg packagers is not going to make it popular. Most of them will just disable it, especially if it brings new dependencies and/or doesn't work on the popular proprietary platforms. FWIW, Fabrice Bellard didn't bundle all his initially hobby projects together. Several of them became popular. > Demanding you make a separate library and a separate project is a > hypocritical ploy to have you spend your time on boring things like > build system and packaging, so that you lose interest in SDR and go back > to doing useful things for them, like fixing fuzzing bugs and > backporting the fixes. To the contrary, I would much rather Michael uses his free time on his hobbies, including SDR-outside-FFmpeg. He can stick to spending his "time on boring things" if/when he gets paid. That will add incentives for big tech corps to actually fund FFmpeg. This community, and presumably Michael in particular, are way too good at doing those "boring things" for free. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Le keskiviikkona 27. syyskuuta 2023, 23.18.29 EEST Michael Niedermayer a écrit : > And you can repeat it as often as you want, iam not interrested. > Why do you not understand this ? You can repeat the contrary as much as you want, we do not believe that your SDR code fits in FFmpeg. Why do you not understand this? (...) > Then i looked at SDR and wrote the AM/FM demodulation. It added a feature > that was and is IMO usefull to FFmpeg and libavdevice users. Like no, seriously. If you really want to generic support for AM and FM RX in FFmpeg, then you should use implement frontends for the already *existing* HAL (that would be V4L radio and ALSA on Linux), or perhaps, write a new user- space HAL library that would accomodate both hardware radio RX devices and SDR. In fact, the SDR code has quite a number of impediments that all but guarantee that it will not "catch on" in FFmpeg: - it requires niche hardware, - it only works on some limited set of OSes (if not only Linux), - it will be subject to all the FFmpeg processes and drama, - it will be obscured by FFmpeg's existing own fame, remaining an obscure feature set that hardly anybody outside FFmpeg-devel knows about. You are doing your own work a disservice by pushing it in FFmpeg, IMO. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Hi, On Wed, Sep 27, 2023 at 10:27 PM Nicolas George wrote: > Michael Niedermayer (12023-09-27): > > With SDR they do ask for a seperate library. > > And they are being dishonest in that. Nothing successful starts as a > library > Didn't dav1d start as a library? (Or maybe it's not very successful by your standards.) x264/5 are external libs, also. I don't think we have to be absolutist about these things. Nothing's quite so black/white. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Michael Niedermayer (12023-09-27): > With SDR they do ask for a seperate library. And they are being dishonest in that. Nothing successful starts as a library, they start small and grow, and get turned into libraries once multiple projects can use them. Demanding you make a separate library and a separate project is a hypocritical ploy to have you spend your time on boring things like build system and packaging, so that you lose interest in SDR and go back to doing useful things for them, like fixing fuzzing bugs and backporting the fixes. > maybe we can organize the > existing code to make everyone happy. You will NOT make everyone happy. Some people here have made absolutely clear they will never be happy with your SDR code and will not rest until they have killed it. Acknowledge it: if you cannot make them happy, do not waste effort trying, just accept you will be making them unhappy as unavoidable, and make the rest of us — developers who would like to have fun with FFmpeg again and users who would like to use the code — very happy. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Wed, Sep 27, 2023 at 03:53:56PM +0200, Tomas Härdin wrote: > tis 2023-09-26 klockan 19:16 +0200 skrev Michael Niedermayer: > > > Anyway, i appologize for announcing SDR in 6.1. I was too much in > > love with > > SDR and how cool it would be ... > > This is why I have suggested many times that you should get involved in > actual SDR projects. For example the FreeDV people have a spinoff > project called FreeDATA (https://freedata.app/ which is all about > sending data (including IP packets) over difficult channels. There is > plenty of DSP work to be done in these projects. If you also get an > amateur radio license then a whole world of experimentation opens up. And you can repeat it as often as you want, iam not interrested. Why do you not understand this ? my interrest is/was specific to FFmpeg gaining SDR support its that and ONLY that Ive earlier this year written some code to monitor liquidations in AAVE why? for fun, it was a excercise for solidity & python. It was not usefull for anything really, only the miners can do liquidations profitably I guess i should use my blog more to write about what iam doing ... I didnt touch blockchain related coding after that IIRC Then i looked into security issues in a random number generator of a hw password manager. Then i looked at SDR and wrote the AM/FM demodulation. It added a feature that was and is IMO usefull to FFmpeg and libavdevice users. (we know the rest ...) Iam happy to maintain this code, Iam happy to improve and extend it if it has users (which requires this to be in a release used by people at some point) I have no interrest and no time to do other things in SDR outside the FFmpeg codebase. And if FFmpeg doesnt want it, ill put it in a personal fork or whatever we call it. after this ive spend some time implementing a basic transformer based NN (this was bascially just an excercise so nothing to show). There are many things i find interresting. (also non programming things like chemistry, biology and so on but i totally lack the time for these) In the past it was possible to align my random interrest with FFmpeg. Like for example a mandelbrot fractal zoom filter. People did not ask that to be put in a seperate general purpose fractal library. With SDR they do ask for a seperate library. maybe we can organize the existing code to make everyone happy. Maybe this will be a personal fork, maybe it will grow and we will have a FFmpeg with many of my and other peoples random projects. I dont know But i dont feel drawn to any SDR projects, i hope above mail explains better my point. I have too many interrests :) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
tis 2023-09-26 klockan 19:16 +0200 skrev Michael Niedermayer: > Anyway, i appologize for announcing SDR in 6.1. I was too much in > love with > SDR and how cool it would be ... This is why I have suggested many times that you should get involved in actual SDR projects. For example the FreeDV people have a spinoff project called FreeDATA (https://freedata.app/ which is all about sending data (including IP packets) over difficult channels. There is plenty of DSP work to be done in these projects. If you also get an amateur radio license then a whole world of experimentation opens up. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Hi Michael, On Tue, Sep 26, 2023 at 7:16 PM Michael Niedermayer wrote: > Should i ask the counter-question ? > are the developers who have less than 10 commits since 2017 abusing > something > by organizing and rallying the people against SDR, against the domain owner > and against me ? > Hm... That's not very nice of you. I hope this is not targeted at me. That's honestly under the belt, if it is. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Vittorio Giovara (12023-09-26): > This is not true. If you say so. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Tue, Sep 26, 2023 at 2:24 PM Nicolas George wrote: > Anton Khirnov (12023-09-26): > > It is not. From my perspective, the objections to SDR have been largely > > technical > > We have not read the same discussion. The objections to SDR start and > end at “it does not belong in FFmpeg”, which is not a technical > objection but an aesthetic one. > This is not true. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Anton Khirnov (12023-09-26): > It is not. From my perspective, the objections to SDR have been largely > technical We have not read the same discussion. The objections to SDR start and end at “it does not belong in FFmpeg”, which is not a technical objection but an aesthetic one. Furthermore, the way these objections were stated made it quite obvious the motivation behind them was that they wanted Michael to spend his time on more useful tasks. More useful for them, implicitly. Again, that is not technical, that is egoistical. Last, there have been some suggestions or demands, technical indeed, that looked like openings for compromise. But the same people who made them made it clear in other parts of the discussion they had no intention of meeting anybody on any kind of middle ground. Given the disingenuousness of these demands, I think Michael is entitled to feel a little paranoid. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Quoting Michael Niedermayer (2023-09-26 19:16:30) > On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-09-26 17:09:47) > > > On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote: > > > > Quoting Michael Niedermayer (2023-09-22 11:27:54) > > > > > The idea was really just, that i said ill include SDR and i want to > > > > > keep this word > > > > > > > > Well, you should not have spoken for the entire project without > > > > consulting the rest of the community first. Nobody here is entitled to > > > > > > This statement is a little misleading, i think > > > > > > Iam part of the community, i would think and for 99% of the tweets made > > > on the official twitter account i have never been asked or even had a > > > chance to comment before they where made. So what you suggest here is > > > "the correct way", has never been applied. > > > > This is disingenuous sophistry, and honestly I find it insulting that > > you expect people to swallow it. > > > > You made the tweet in question long after it was clear that the feature > > is controversial. Then you tried to use it as an argument in favor of > > pushing SDR to master. In other words, you used the fact that you have > > Twitter posting rights to promote your opinion over that of other > > developers. If that is not abuse of power then I don't know what is. > > ok > I wrote a SDR input device for free, wanted to give it to the users > as i believed it was a cool and usefull feature > > i tried to argue for it, i tried to promote it. > And as the person doing all releases of FFmpeg since a very long time > i thought yeah we will be able to resolve the disagreements and get it > in 6.1 with everyone geing happy. > I was wrong, i announced this before i actually got people to agree yes > I still belive if people where not so "excited" on this whole and if it > was just a technical question we could get SDR in 6.1 with everyone > agreeing. > But now heres a man to be burned at the stake, and thats more important. You keep framing this as some kind of a personal campaign against you. It is not. From my perspective, the objections to SDR have been largely technical, and most of the "heat" comes from your refusal to accept that many active developers are against it. > abuse of power ? > If its abuse of power to risk my position in FFmpeg to try to get users a > feature > i belive in they would like and find cool then yes i abused my power. > > Should i ask the counter-question ? > are the developers who have less than 10 commits since 2017 abusing something > by organizing and rallying the people against SDR, against the domain owner > and against me ? I see zero indication of any of the above. 1) Nobody is rallying anyone against SDR. My objections to it are entirely my own. Paul is also against it, and nobody is able to make him do anything, as far as I can tell. What evidence do you see that anyone's opinion on this question has been "organized" or otherwise manipulated? 2) Nobody is attacking Fabrice in any way. Ronald raised the (in my view entirely reasonable) observation that someone who has had almost no involvement with the project since 2003 should not have the ultimate veto power over it. That is not in any way a personal attack, and is also entirely unrelated to this. 3) Nobody is attacking you. Disagreeing about technical questions is NOT a personal attack. > Without that, i do belive we could have gotten SDR with everyone being happy > in 6.1 > > Anyway, i appologize for announcing SDR in 6.1. I was too much in love with > SDR and how cool it would be ... > > I guess there will be votes to remove me from everything. > But dont fear, i will not abuse anything, i will resign from everything that > a correct vote asks me to resign from. I really wish you would drop the drama, it is entirely unnecessary. Nobody wants you to resign from anything, people (including me) merely want you to stop trying to force your opinions on the rest of the project. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
James Almer (12023-09-26): > We don't want you to resign anything. We want a proper discussion in how to > handle SDR, if at all. Pushing it in a form that everyone agrees is not > ready for upstream is not a good idea. We can agree on this, if we consider that the opinion on whether it is ready of people who have made it clear they will never consider it “ready” is to be disregarded, just as much as somebody who says “nak” to a patch without reasons. > SDR is big, so its API needs to be designed carefully and in an extensible > way. > libavradio must absolutely not be libavdevice redux, and it must have its > own, versatile and extensible API that a lavd device can then work with, > even if not using its full potential, because libavradio can have other > users that will not be constrained to what lavf/lavd can do. SDR **will be** big. SDR **will need** to have its own versatile and extensible API. But the way to get there is to start small. First make it a module, with a very simple API to the rest. Then, as it grows, it acquires utility functions: an internal API that we can change as we discover what it needs. And progressively the API stabilizes and becomes good. Nothing successful starts as a library. Suggesting that a project starts as a library is either an expression of incompetence or a dishonest attempt at killing it. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On 9/26/2023 2:16 PM, Michael Niedermayer wrote: On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote: Quoting Michael Niedermayer (2023-09-26 17:09:47) On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote: Quoting Michael Niedermayer (2023-09-22 11:27:54) The idea was really just, that i said ill include SDR and i want to keep this word Well, you should not have spoken for the entire project without consulting the rest of the community first. Nobody here is entitled to This statement is a little misleading, i think Iam part of the community, i would think and for 99% of the tweets made on the official twitter account i have never been asked or even had a chance to comment before they where made. So what you suggest here is "the correct way", has never been applied. This is disingenuous sophistry, and honestly I find it insulting that you expect people to swallow it. You made the tweet in question long after it was clear that the feature is controversial. Then you tried to use it as an argument in favor of pushing SDR to master. In other words, you used the fact that you have Twitter posting rights to promote your opinion over that of other developers. If that is not abuse of power then I don't know what is. ok I wrote a SDR input device for free, wanted to give it to the users as i believed it was a cool and usefull feature i tried to argue for it, i tried to promote it. And as the person doing all releases of FFmpeg since a very long time i thought yeah we will be able to resolve the disagreements and get it in 6.1 with everyone geing happy. I was wrong, i announced this before i actually got people to agree yes I still belive if people where not so "excited" on this whole and if it was just a technical question we could get SDR in 6.1 with everyone agreeing. But now heres a man to be burned at the stake, and thats more important. abuse of power ? If its abuse of power to risk my position in FFmpeg to try to get users a feature i belive in they would like and find cool then yes i abused my power. No, it was not abuse of power per se. That was a bit strong from Anton's part. But tweeting it was jumping the gun about something that was controversial and still in the discussion phase of things, and then using it as argument to upstream the code bothered some people. Should i ask the counter-question ? are the developers who have less than 10 commits since 2017 abusing something by organizing and rallying the people against SDR, against the domain owner and against me ? Without that, i do belive we could have gotten SDR with everyone being happy in 6.1 Anyway, i appologize for announcing SDR in 6.1. I was too much in love with SDR and how cool it would be ... I guess there will be votes to remove me from everything. But dont fear, i will not abuse anything, i will resign from everything that a correct vote asks me to resign from. We don't want you to resign anything. We want a proper discussion in how to handle SDR, if at all. Pushing it in a form that everyone agrees is not ready for upstream is not a good idea. Best case scenario we end up with a period of having to change things around as they were made public in a release and thus part of the API, which is harder to maintain and migrate from, and worst case scenario we end up with something that doesn't get more development because it was limited from the get go. SDR is big, so its API needs to be designed carefully and in an extensible way. libavradio must absolutely not be libavdevice redux, and it must have its own, versatile and extensible API that a lavd device can then work with, even if not using its full potential, because libavradio can have other users that will not be constrained to what lavf/lavd can do. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Tue, Sep 26, 2023 at 05:27:23PM +0100, Derek Buitenhuis wrote: > On 9/26/2023 4:30 PM, Anton Khirnov wrote: > > This is disingenuous sophistry, and honestly I find it insulting that > > you expect people to swallow it. > > I have been pretty silent on list, but as one of the people who has > access to the Twitter account as a delegate (but who was locked out > at the time of the tweet), it offensive to me on a personal level to > insnuate that it is at all comparable to any tweet (few though they > are) I have made, or that the situation is comparable. > > It reads to me like purposely playing dumb. We aren't. Iam not claimining anything is comparable. Iam just asking that everyone is posting tweets for review. Same as thilo long ago suggested It is reasonable that the whole community can review public statements that are made in the name of the project This example here shows how easily this can go wrong (even if maybe you never made a comparable tweet) Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-09-26 17:09:47) > > On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2023-09-22 11:27:54) > > > > The idea was really just, that i said ill include SDR and i want to > > > > keep this word > > > > > > Well, you should not have spoken for the entire project without > > > consulting the rest of the community first. Nobody here is entitled to > > > > This statement is a little misleading, i think > > > > Iam part of the community, i would think and for 99% of the tweets made > > on the official twitter account i have never been asked or even had a > > chance to comment before they where made. So what you suggest here is > > "the correct way", has never been applied. > > This is disingenuous sophistry, and honestly I find it insulting that > you expect people to swallow it. > > You made the tweet in question long after it was clear that the feature > is controversial. Then you tried to use it as an argument in favor of > pushing SDR to master. In other words, you used the fact that you have > Twitter posting rights to promote your opinion over that of other > developers. If that is not abuse of power then I don't know what is. ok I wrote a SDR input device for free, wanted to give it to the users as i believed it was a cool and usefull feature i tried to argue for it, i tried to promote it. And as the person doing all releases of FFmpeg since a very long time i thought yeah we will be able to resolve the disagreements and get it in 6.1 with everyone geing happy. I was wrong, i announced this before i actually got people to agree yes I still belive if people where not so "excited" on this whole and if it was just a technical question we could get SDR in 6.1 with everyone agreeing. But now heres a man to be burned at the stake, and thats more important. abuse of power ? If its abuse of power to risk my position in FFmpeg to try to get users a feature i belive in they would like and find cool then yes i abused my power. Should i ask the counter-question ? are the developers who have less than 10 commits since 2017 abusing something by organizing and rallying the people against SDR, against the domain owner and against me ? Without that, i do belive we could have gotten SDR with everyone being happy in 6.1 Anyway, i appologize for announcing SDR in 6.1. I was too much in love with SDR and how cool it would be ... I guess there will be votes to remove me from everything. But dont fear, i will not abuse anything, i will resign from everything that a correct vote asks me to resign from. Thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On 9/26/2023 4:30 PM, Anton Khirnov wrote: > This is disingenuous sophistry, and honestly I find it insulting that > you expect people to swallow it. I have been pretty silent on list, but as one of the people who has access to the Twitter account as a delegate (but who was locked out at the time of the tweet), it offensive to me on a personal level to insnuate that it is at all comparable to any tweet (few though they are) I have made, or that the situation is comparable. It reads to me like purposely playing dumb. We aren't. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Quoting Michael Niedermayer (2023-09-26 17:09:47) > On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-09-22 11:27:54) > > > The idea was really just, that i said ill include SDR and i want to > > > keep this word > > > > Well, you should not have spoken for the entire project without > > consulting the rest of the community first. Nobody here is entitled to > > This statement is a little misleading, i think > > Iam part of the community, i would think and for 99% of the tweets made > on the official twitter account i have never been asked or even had a > chance to comment before they where made. So what you suggest here is > "the correct way", has never been applied. This is disingenuous sophistry, and honestly I find it insulting that you expect people to swallow it. You made the tweet in question long after it was clear that the feature is controversial. Then you tried to use it as an argument in favor of pushing SDR to master. In other words, you used the fact that you have Twitter posting rights to promote your opinion over that of other developers. If that is not abuse of power then I don't know what is. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
> Iam part of the community, i would think and for 99% of the tweets made > on the official twitter account i have never been asked or even had a > chance to comment before they where made. So what you suggest here is > "the correct way", has never been applied. Announcing feature are going to be present in a release in a tweet that the community has no consensus on is not the same as making general tweets about VDD, FFmpeg etc. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-09-22 11:27:54) > > The idea was really just, that i said ill include SDR and i want to > > keep this word > > Well, you should not have spoken for the entire project without > consulting the rest of the community first. Nobody here is entitled to This statement is a little misleading, i think Iam part of the community, i would think and for 99% of the tweets made on the official twitter account i have never been asked or even had a chance to comment before they where made. So what you suggest here is "the correct way", has never been applied. Thilo raised this very same issue already also. The tweets should all be reviewed. And i do not disagree. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is a danger to trust the dream we wish for rather than the science we have, -- Dr. Kenneth Brown signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On 7/7/23 02:40, Lynne wrote: May as well decide on a name in the meanwhile. Anyone got any suggestions? ___ Has Thomson been used? https://en.wikipedia.org/wiki/J._J._Thomson - Leo Izen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Quoting Michael Niedermayer (2023-09-22 11:27:54) > The idea was really just, that i said ill include SDR and i want to > keep this word Well, you should not have spoken for the entire project without consulting the rest of the community first. Nobody here is entitled to decide unilaterally what will or won't go in. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Yo, On Fri, 22 Sep 2023, at 17:27, Paul B Mahol wrote: >> about it because i did not know anyone else who knows perl and be willing >> to help look into a not entirely trivial (for me) issue in fate server > > Do not lie, [...] Calling people liars is not really fitting our Code of Conduct. It's not the first time I remind this fact. jb -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On 9/22/23, Michael Niedermayer wrote: > On Fri, Sep 22, 2023 at 11:32:27AM +0200, Paul B Mahol wrote: >> On Fri, Sep 22, 2023 at 11:28 AM Michael Niedermayer >> > [...] > >> If you mean real FFmpeg work, than by all means give access to services >> only you have to other >> interesting parties, like security related reports and others. > > what ? > > There are 633 open issues in coverity, every FFmpeg developer can work on. > i remember bringing this number down years ago to something rather small but > now > the statistics dwarf that with the upward trend ... > > if you mean oss-fuzz, there are 18 tickets public about FFmpeg, anyone can > work on these > https://bugs.chromium.org/p/oss-fuzz/issues/list?q=ffmpeg > > and the ffmpeg ossfuzz tickets, go to > ffmpeg-security, 3 people from google, 1 from mozilla, jb > and ffmpeg-security is me, reimar, ce, andreas cadhalpun, ubitux, rodger > combs > > so thats not just me > and a quick count, i think i have 32 open ossfuzz issues in my inbox, > with the 18 subtracted more are public with noone caring about. > if we assume i fix 5 a day, what is that, 4 days of work, to fix the ones > that are > not public. (that doesnt count ossfuzz hiding 12 issues in 62164 but yeah > these ive > already posted fixes for i think) > > Also theres our bug tracker and just the normal compiler warnings > if you want to work on this sort of thing > > where are the developers who want to work on something above but do not > have > access ? > > the only other issue i remember on ffmpeg-security thats not spam and not > ossfuzz > is a XSS issue in the fate server which i believe nicolas is working on. > If someone is interrested in working on the fate server code, please come > forth > the code is in need for a maintainer outside this issue. I just had asked > nicolas > about it because i did not know anyone else who knows perl and be willing > to help look into a not entirely trivial (for me) issue in fate server > Do not lie, you are working for FFlabs now. > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Everything should be made as simple as possible, but not simpler. > -- Albert Einstein > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Fri, Sep 22, 2023 at 11:32:27AM +0200, Paul B Mahol wrote: > On Fri, Sep 22, 2023 at 11:28 AM Michael Niedermayer [...] > If you mean real FFmpeg work, than by all means give access to services > only you have to other > interesting parties, like security related reports and others. what ? There are 633 open issues in coverity, every FFmpeg developer can work on. i remember bringing this number down years ago to something rather small but now the statistics dwarf that with the upward trend ... if you mean oss-fuzz, there are 18 tickets public about FFmpeg, anyone can work on these https://bugs.chromium.org/p/oss-fuzz/issues/list?q=ffmpeg and the ffmpeg ossfuzz tickets, go to ffmpeg-security, 3 people from google, 1 from mozilla, jb and ffmpeg-security is me, reimar, ce, andreas cadhalpun, ubitux, rodger combs so thats not just me and a quick count, i think i have 32 open ossfuzz issues in my inbox, with the 18 subtracted more are public with noone caring about. if we assume i fix 5 a day, what is that, 4 days of work, to fix the ones that are not public. (that doesnt count ossfuzz hiding 12 issues in 62164 but yeah these ive already posted fixes for i think) Also theres our bug tracker and just the normal compiler warnings if you want to work on this sort of thing where are the developers who want to work on something above but do not have access ? the only other issue i remember on ffmpeg-security thats not spam and not ossfuzz is a XSS issue in the fate server which i believe nicolas is working on. If someone is interrested in working on the fate server code, please come forth the code is in need for a maintainer outside this issue. I just had asked nicolas about it because i did not know anyone else who knows perl and be willing to help look into a not entirely trivial (for me) issue in fate server thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Fri, Sep 22, 2023 at 12:04 PM Nicolas George wrote: > Michael Niedermayer (12023-09-22): > > Now the SDR + blockings is solved by not including any SDR that the > > community doesnt like in 6.1 but instead me simply making a seperate > > release with SDR, or so i thought. > > I strongly suggest you just refuse to make any release that do not > include SDR. If somebody wants it, let them do the work. > Agreed, I want to be release maintainer. > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Michael Niedermayer (12023-09-22): > Now the SDR + blockings is solved by not including any SDR that the > community doesnt like in 6.1 but instead me simply making a seperate > release with SDR, or so i thought. I strongly suggest you just refuse to make any release that do not include SDR. If somebody wants it, let them do the work. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Fri, Sep 22, 2023 at 11:28 AM Michael Niedermayer wrote: > On Sun, Jul 09, 2023 at 12:14:09PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-07-07 17:06:54) > > > Hi > > > > > > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > > > > It's been a while since we've had a release, and we've had > > > > a lot of new features in. > > > > We did say we would make releases more often, and I think > > > > it's about time we have a new release. > > > > > > yes > > > > > > > > > > > > > > Anything anyone wants to have merged or should we branch > > > > off 6.1 in a few days? > > > > > > libavradio needs testing, at least build testing. > > > all parts of git master are tested automatically by our user base > > > but anything in seperate repositories might receive less testing > > > so we should encourage people to test these seperate repositories > > > for the release > > > > > > also note iam quite busy ATM, its not the best time for me to > > > do 6.1, so "in a few days" is a bit too optimistic i think > > > > How is libavradio related to the release? > > Right, thats a valid question > when i wrote the SDR code it seemed to me that including it in 6.1 was > very simple. But as then some people tried to block SDR by any means > (blocking patches randomly, asking for moving it into a seperate libraray > while not replying to any questions about that libraray and so on) > that made libavradio now have much more strings attached > then the original simple self contained input device > secondary, i lost the will to really work on FFmpeg around the time > of these attacks, so even without SDR i had limited motivation > and then more things that should be in 6.1 accumulated and summer and > good waether ... > And noone else took up the accumulating work either ... > What accumulating work? The SDR work for certainly nobody else wants to pick, except maybe Peter. If you mean real FFmpeg work, than by all means give access to services only you have to other interesting parties, like security related reports and others. > > Now the SDR + blockings is solved by not including any SDR that the > community doesnt like in 6.1 but instead me simply making a seperate > release with SDR, or so i thought. It seems given the replies I seem > to have touched some nerve here too > > The idea was really just, that i said ill include SDR and i want to > keep this word so i want our users to have that 6.1 with SDR that i > promised and also have everyone happy about 6.1 and the long term > design of the SDR code. > I have some more comments about the seperate libraray and SDR but > thats better in a seperate mail in the future. > Thank you for all hard FFmpeg related work, hope your continuing work on your SDR hobby related projects. > > Thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > "You are 36 times more likely to die in a bathtub than at the hands of a > terrorist. Also, you are 2.5 times more likely to become a president and > 2 times more likely to become an astronaut, than to die in a terrorist > attack." -- Thoughty2 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Sun, Jul 09, 2023 at 12:14:09PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-07-07 17:06:54) > > Hi > > > > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > > > It's been a while since we've had a release, and we've had > > > a lot of new features in. > > > We did say we would make releases more often, and I think > > > it's about time we have a new release. > > > > yes > > > > > > > > > > Anything anyone wants to have merged or should we branch > > > off 6.1 in a few days? > > > > libavradio needs testing, at least build testing. > > all parts of git master are tested automatically by our user base > > but anything in seperate repositories might receive less testing > > so we should encourage people to test these seperate repositories > > for the release > > > > also note iam quite busy ATM, its not the best time for me to > > do 6.1, so "in a few days" is a bit too optimistic i think > > How is libavradio related to the release? Right, thats a valid question when i wrote the SDR code it seemed to me that including it in 6.1 was very simple. But as then some people tried to block SDR by any means (blocking patches randomly, asking for moving it into a seperate libraray while not replying to any questions about that libraray and so on) that made libavradio now have much more strings attached then the original simple self contained input device secondary, i lost the will to really work on FFmpeg around the time of these attacks, so even without SDR i had limited motivation and then more things that should be in 6.1 accumulated and summer and good waether ... And noone else took up the accumulating work either ... Now the SDR + blockings is solved by not including any SDR that the community doesnt like in 6.1 but instead me simply making a seperate release with SDR, or so i thought. It seems given the replies I seem to have touched some nerve here too The idea was really just, that i said ill include SDR and i want to keep this word so i want our users to have that 6.1 with SDR that i promised and also have everyone happy about 6.1 and the long term design of the SDR code. I have some more comments about the seperate libraray and SDR but thats better in a seperate mail in the future. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Quoting Michael Niedermayer (2023-07-07 17:06:54) > Hi > > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > > It's been a while since we've had a release, and we've had > > a lot of new features in. > > We did say we would make releases more often, and I think > > it's about time we have a new release. > > yes > > > > > > Anything anyone wants to have merged or should we branch > > off 6.1 in a few days? > > libavradio needs testing, at least build testing. > all parts of git master are tested automatically by our user base > but anything in seperate repositories might receive less testing > so we should encourage people to test these seperate repositories > for the release > > also note iam quite busy ATM, its not the best time for me to > do 6.1, so "in a few days" is a bit too optimistic i think How is libavradio related to the release? -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Quoting Lynne (2023-07-06 18:04:41) > It's been a while since we've had a release, and we've had > a lot of new features in. > We did say we would make releases more often, and I think > it's about time we have a new release. > > Anything anyone wants to have merged or should we branch > off 6.1 in a few days? I'd like to have '[PATCH 21/22] fftools/ffmpeg: rework -enc_time_base handling' (<20230707094847.25324-21-an...@khirnov.net>), which fixes #10393, in the release. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Thu, Jul 6, 2023 at 12:04 PM Lynne wrote: > > It's been a while since we've had a release, and we've had > a lot of new features in. > We did say we would make releases more often, and I think > it's about time we have a new release. > > Anything anyone wants to have merged or should we branch > off 6.1 in a few days? I was hoping to see the enhanced RTMP/FLV stuff merged by now... And maybe the Intel person finally posting their AV1 VA-API patches... -- 真実はいつも一つ！/ Always, there's only one truth! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
On Fri, Jul 07, 2023 at 05:33:32PM +0200, Lynne wrote: > Jul 7, 2023, 17:07 by mich...@niedermayer.cc: > > > Hi > > > > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > > > >> It's been a while since we've had a release, and we've had > >> a lot of new features in. > >> We did say we would make releases more often, and I think > >> it's about time we have a new release. > >> > > > > yes > > > > > >> > >> Anything anyone wants to have merged or should we branch > >> off 6.1 in a few days? > >> > > > > libavradio needs testing, at least build testing. > > all parts of git master are tested automatically by our user base > > but anything in seperate repositories might receive less testing > > so we should encourage people to test these seperate repositories > > for the release > > > > It's still quite a new library, its API might change, I think we > should release 6.1 first, then release libavradio, so the next > FFmpeg release has a stable target API-wise to use. I think we should release early and often. also 7.0 would be a major version bump, so the 6.1 API/ABI doesnt matter. And i have not seen anyone working on changing the API ... thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jul 7, 2023, 17:07 by mich...@niedermayer.cc: > Hi > > On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > >> It's been a while since we've had a release, and we've had >> a lot of new features in. >> We did say we would make releases more often, and I think >> it's about time we have a new release. >> > > yes > > >> >> Anything anyone wants to have merged or should we branch >> off 6.1 in a few days? >> > > libavradio needs testing, at least build testing. > all parts of git master are tested automatically by our user base > but anything in seperate repositories might receive less testing > so we should encourage people to test these seperate repositories > for the release > It's still quite a new library, its API might change, I think we should release 6.1 first, then release libavradio, so the next FFmpeg release has a stable target API-wise to use. It's fine if you don't have time in the next few days, I have to remove the old FFT code, which means finishing my DCT/DST lavu/tx patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Hi On Thu, Jul 06, 2023 at 06:04:41PM +0200, Lynne wrote: > It's been a while since we've had a release, and we've had > a lot of new features in. > We did say we would make releases more often, and I think > it's about time we have a new release. yes > > Anything anyone wants to have merged or should we branch > off 6.1 in a few days? libavradio needs testing, at least build testing. all parts of git master are tested automatically by our user base but anything in seperate repositories might receive less testing so we should encourage people to test these seperate repositories for the release also note iam quite busy ATM, its not the best time for me to do 6.1, so "in a few days" is a bit too optimistic i think thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Lynne 于2023年7月7日周五 14:40写道： > > Jul 6, 2023, 18:19 by j...@videolan.org: > > > Heya, > > > > On Thu, 6 Jul 2023, at 18:04, Lynne wrote: > > > >> It's been a while since we've had a release, and we've had > >> a lot of new features in. > >> We did say we would make releases more often, and I think > >> it's about time we have a new release. > >> > > > > It's a good idea. > > > >> Anything anyone wants to have merged or should we branch > >> off 6.1 in a few days? > >> > > > > By experience, it requires a bit more than a few days... :D > > > > May as well decide on a name in the meanwhile. > Anyone got any suggestions? Ting https://en.wikipedia.org/wiki/Samuel_C._C._Ting > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Leavitt https://en.wikipedia.org/wiki/Henrietta_Swan_Leavitt > On 7 Jul 2023, at 08:40, Lynne wrote: > > Jul 6, 2023, 18:19 by j...@videolan.org: > >> Heya, >> >> On Thu, 6 Jul 2023, at 18:04, Lynne wrote: >> >>> It's been a while since we've had a release, and we've had >>> a lot of new features in. >>> We did say we would make releases more often, and I think >>> it's about time we have a new release. >>> >> >> It's a good idea. >> >>> Anything anyone wants to have merged or should we branch >>> off 6.1 in a few days? >>> >> >> By experience, it requires a bit more than a few days... :D >> > > May as well decide on a name in the meanwhile. > Anyone got any suggestions? > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Jul 6, 2023, 18:19 by j...@videolan.org: > Heya, > > On Thu, 6 Jul 2023, at 18:04, Lynne wrote: > >> It's been a while since we've had a release, and we've had >> a lot of new features in. >> We did say we would make releases more often, and I think >> it's about time we have a new release. >> > > It's a good idea. > >> Anything anyone wants to have merged or should we branch >> off 6.1 in a few days? >> > > By experience, it requires a bit more than a few days... :D > May as well decide on a name in the meanwhile. Anyone got any suggestions? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Release 6.1
Heya, On Thu, 6 Jul 2023, at 18:04, Lynne wrote: > It's been a while since we've had a release, and we've had > a lot of new features in. > We did say we would make releases more often, and I think > it's about time we have a new release. It's a good idea. > Anything anyone wants to have merged or should we branch > off 6.1 in a few days? By experience, it requires a bit more than a few days... :D jb -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC] Release 6.1
It's been a while since we've had a release, and we've had a lot of new features in. We did say we would make releases more often, and I think it's about time we have a new release. Anything anyone wants to have merged or should we branch off 6.1 in a few days? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
