| Message ID | 20230616222048.6562-2-michael@niedermayer.cc |
|---|---|
| State | Accepted |
| Commit | 8f48a62151f4a299574959df9a48813303ef4edb |
| Headers | show |
| Series | add sdr support | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
On Sat, Jun 17, 2023 at 12:20:44AM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > --- > libavutil/tx_template.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) will apply patches 1-4 (this should reduce the differences in the avradio repository in libavcodec/libavutil) [...]
lör 2023-07-22 klockan 17:40 +0200 skrev Michael Niedermayer: > On Sat, Jun 17, 2023 at 12:20:44AM +0200, Michael Niedermayer wrote: > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > > --- > > libavutil/tx_template.c | 12 ++++++++++++ > > 1 file changed, 12 insertions(+) > > will apply patches 1-4 > (this should reduce the differences in the avradio repository in > libavcodec/libavutil) I warned that this stuff would affect other parts of the code, and now PCM codecs can suddenly change channel count among other things. You can't just sneak stuff like this in when people think you're working on a fork, and also expect people to not notice. Please revert this and move discussions about your fork to a separate mailing list so as to reduce chatter on this one. If you want patches to be cherry-picked into ffmpeg then please create explicit ML threads about that. /Tomas
Michael Niedermayer: > On Sat, Jun 17, 2023 at 12:20:44AM +0200, Michael Niedermayer wrote: >> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> >> --- >> libavutil/tx_template.c | 12 ++++++++++++ >> 1 file changed, 12 insertions(+) > > will apply patches 1-4 > (this should reduce the differences in the avradio repository in libavcodec/libavutil) > I actually wanted to complain about this; but then I saw that it had already been applied. Before that, I believed that this patchset was meant to be applied to the fork only and therefore didn't give it any scrutiny. These patches should have only been applied after the decision to merge the fork. I am against applying patches to simplify maintaining a fork. E.g. I am against further avpriv functions (but not absolutely) like you added in 4/5. Your patches are even very suboptimal in this regard: You added two avpriv functions, yet only one of them (the non-fixed-point) is used by your fork. Furthermore, you only need these 2MB windows for floats, not for int or doubles. - Andreas
On Mon, Jul 24, 2023 at 10:34 AM Andreas Rheinhardt < andreas.rheinhardt@outlook.com> wrote: > Michael Niedermayer: > > On Sat, Jun 17, 2023 at 12:20:44AM +0200, Michael Niedermayer wrote: > >> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > >> --- > >> libavutil/tx_template.c | 12 ++++++++++++ > >> 1 file changed, 12 insertions(+) > > > > will apply patches 1-4 > > (this should reduce the differences in the avradio repository in > libavcodec/libavutil) > > > > I actually wanted to complain about this; but then I saw that it had > already been applied. Before that, I believed that this patchset was > meant to be applied to the fork only and therefore didn't give it any > scrutiny. These patches should have only been applied after the decision > to merge the fork. > > I am against applying patches to simplify maintaining a fork. E.g. I am > against further avpriv functions (but not absolutely) like you added in > 4/5. Your patches are even very suboptimal in this regard: You added two > avpriv functions, yet only one of them (the non-fixed-point) is used by > your fork. Furthermore, you only need these 2MB windows for floats, not > for int or doubles. > > I need this, and only this patch to stay in tree. > - Andreas > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
On Sun, Jul 23, 2023 at 07:48:27PM +0200, Tomas Härdin wrote: > lör 2023-07-22 klockan 17:40 +0200 skrev Michael Niedermayer: > > On Sat, Jun 17, 2023 at 12:20:44AM +0200, Michael Niedermayer wrote: > > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > > > --- > > > libavutil/tx_template.c | 12 ++++++++++++ > > > 1 file changed, 12 insertions(+) > > > > will apply patches 1-4 > > (this should reduce the differences in the avradio repository in > > libavcodec/libavutil) > > I warned that this stuff would affect other parts of the code, and now Make sure you are wearing your N95 mask and get vaccinated as soon as possible or you might get infected by radio-23 ;) sorry for the joke, i couldnt resist. (no ill intend iam just trying to lighten up spirits with this joke and explicitly saying so, so its not misunderstood as anything with hostile meaning) > PCM codecs can suddenly change channel count among other things. You > can't just sneak stuff like this in when people think you're working on > a fork, and also expect people to not notice. Please revert this and > move discussions about your fork to a separate mailing list so as to > reduce chatter on this one. If you want patches to be cherry-picked > into ffmpeg then please create explicit ML threads about that. what ? libavradio is part of FFmpeg its just a seperate repository. libavradio will also be part of the 6.1 release, it was even officially announced. The tweet had over 500 likes IIRC. No sneaking here. The patches you object to btw are not needed for the libavradio release, they just reduce maintaince work on my side and maybe headaches on more than just my side. Also my contributions to ffmpeg are limited by time, so the more work i have teh less i can contribute. Its not even resulting in more time for me working (because there just isnt more time in a day) nor less payment. Its truely just less that gets done. More delay on other FFmpeg things iam doing ... thx [...]
On 7/24/23 04:59, Michael Niedermayer wrote: > > what ? > libavradio is part of FFmpeg its just a seperate repository. > libavradio will also be part of the 6.1 release, it was even officially > announced. The tweet had over 500 likes IIRC. No sneaking here. > And who made that tweet? Or the decision to tweet it in the first place? - Leo Izen
Am 24.07.23 um 13:06 schrieb Leo Izen: > > > On 7/24/23 04:59, Michael Niedermayer wrote: >> >> what ? >> libavradio is part of FFmpeg its just a seperate repository. >> libavradio will also be part of the 6.1 release, it was even officially >> announced. The tweet had over 500 likes IIRC. No sneaking here. >> > > And who made that tweet? Or the decision to tweet it in the first place? That is a good point. Right now, several people just post what they want on several channels, at least Twitter and Linked.in. Without the community involved. We should do a <news post / tweet / whatever you call it> via the means of posting a regular patch for a new news entry to the website - once ok'd on the list, post that as news on the website (push the patch) and trigger all channels to post a similar thing. -Thilo
Hi, That doesn't sound really viable for regular "day-to-day" operations of social network channels, and it's superfluous for stuff that's already been agreed upon. The problem is abusing your account privileges to push forward something that was obviously not agreed upon in the first place, such as a controversial feature proposal (as was the case here), or a feature whose implementation is as yet missing or incomplete. You shouldn't post this, period. It's not a matter of discussing the post first: if the feature is completed and merged, then you can announce it. If it's not, then you shouldn't make any announcements. Le 24 juillet 2023 15:39:39 GMT+03:00, Thilo Borgmann <thilo.borgmann@mail.de> a écrit : >Am 24.07.23 um 13:06 schrieb Leo Izen: >> >> >> On 7/24/23 04:59, Michael Niedermayer wrote: >>> >>> what ? >>> libavradio is part of FFmpeg its just a seperate repository. >>> libavradio will also be part of the 6.1 release, it was even officially >>> announced. The tweet had over 500 likes IIRC. No sneaking here. >>> >> >> And who made that tweet? Or the decision to tweet it in the first place? > >That is a good point. Right now, several people just post what they want on several channels, at least Twitter and Linked.in. Without the community involved. > >We should do a <news post / tweet / whatever you call it> via the means of posting a regular patch for a new news entry to the website - once ok'd on the list, post that as news on the website (push the patch) and trigger all channels to post a similar thing. > >-Thilo > > >_______________________________________________ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >To unsubscribe, visit link above, or email >ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
Pls don't top-post. Am 24.07.23 um 15:04 schrieb Rémi Denis-Courmont: > Hi, > > That doesn't sound really viable for regular "day-to-day" operations of social network channels, and it's superfluous for stuff that's already been agreed upon. If you think in patches, I see it would be superfluous. Not that I think that this is the way to look at it - news and patches not necessarily correlate in a 1-1 manner. About viability, I don't see your argument. Patches, incl their acknowledgement or rejection, already is our day-to-day procedure and the project does not benefit from a faster news-release than this (maybe relaxed for news) scheme would yield. The benefit of doing it the news-patch way, you give yourself: > The problem is abusing your account privileges to push forward something that was obviously not agreed upon in the first place, such as a controversial feature proposal (as was the case here), or a feature whose implementation is as yet missing or incomplete. > > You shouldn't post this, period. It's not a matter of discussing the post first: if the feature is completed and merged, then you can announce it. If it's not, then you shouldn't make any announcements. The problem of such controversial posts would completely be solved if a news post goes as patch to the list. No more rules or assumptions needed - ok'd or not. Like we iterate many times a day for code. Would it not? Otherwise we'd be having more controversial posts, yet not as easily to spot as the git log and impossible to correct. I like the overhead of news-patches more. > Le 24 juillet 2023 15:39:39 GMT+03:00, Thilo Borgmann <thilo.borgmann@mail.de> a écrit : >> Am 24.07.23 um 13:06 schrieb Leo Izen: >>> >>> >>> On 7/24/23 04:59, Michael Niedermayer wrote: >>>> >>>> what ? >>>> libavradio is part of FFmpeg its just a seperate repository. >>>> libavradio will also be part of the 6.1 release, it was even officially >>>> announced. The tweet had over 500 likes IIRC. No sneaking here. >>>> >>> >>> And who made that tweet? Or the decision to tweet it in the first place? >> >> That is a good point. Right now, several people just post what they want on several channels, at least Twitter and Linked.in. Without the community involved. >> >> We should do a <news post / tweet / whatever you call it> via the means of posting a regular patch for a new news entry to the website - once ok'd on the list, post that as news on the website (push the patch) and trigger all channels to post a similar thing. -Thilo
mån 2023-07-24 klockan 10:57 +0200 skrev Paul B Mahol: > On Mon, Jul 24, 2023 at 10:34 AM Andreas Rheinhardt < > andreas.rheinhardt@outlook.com> wrote: > > > Michael Niedermayer: > > > On Sat, Jun 17, 2023 at 12:20:44AM +0200, Michael Niedermayer > > > wrote: > > > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > > > > --- > > > > libavutil/tx_template.c | 12 ++++++++++++ > > > > 1 file changed, 12 insertions(+) > > > > > > will apply patches 1-4 > > > (this should reduce the differences in the avradio repository in > > libavcodec/libavutil) > > > > > > > I actually wanted to complain about this; but then I saw that it > > had > > already been applied. Before that, I believed that this patchset > > was > > meant to be applied to the fork only and therefore didn't give it > > any > > scrutiny. These patches should have only been applied after the > > decision > > to merge the fork. > > > > I am against applying patches to simplify maintaining a fork. E.g. > > I am > > against further avpriv functions (but not absolutely) like you > > added in > > 4/5. Your patches are even very suboptimal in this regard: You > > added two > > avpriv functions, yet only one of them (the non-fixed-point) is > > used by > > your fork. Furthermore, you only need these 2MB windows for floats, > > not > > for int or doubles. > > > > > I need this, and only this patch to stay in tree. For what? avfilter stuff? /Tomas
On Mon, Jul 24, 2023 at 8:46 PM Tomas Härdin <git@haerdin.se> wrote: > mån 2023-07-24 klockan 10:57 +0200 skrev Paul B Mahol: > > On Mon, Jul 24, 2023 at 10:34 AM Andreas Rheinhardt < > > andreas.rheinhardt@outlook.com> wrote: > > > > > Michael Niedermayer: > > > > On Sat, Jun 17, 2023 at 12:20:44AM +0200, Michael Niedermayer > > > > wrote: > > > > > Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> > > > > > --- > > > > > libavutil/tx_template.c | 12 ++++++++++++ > > > > > 1 file changed, 12 insertions(+) > > > > > > > > will apply patches 1-4 > > > > (this should reduce the differences in the avradio repository in > > > libavcodec/libavutil) > > > > > > > > > > I actually wanted to complain about this; but then I saw that it > > > had > > > already been applied. Before that, I believed that this patchset > > > was > > > meant to be applied to the fork only and therefore didn't give it > > > any > > > scrutiny. These patches should have only been applied after the > > > decision > > > to merge the fork. > > > > > > I am against applying patches to simplify maintaining a fork. E.g. > > > I am > > > against further avpriv functions (but not absolutely) like you > > > added in > > > 4/5. Your patches are even very suboptimal in this regard: You > > > added two > > > avpriv functions, yet only one of them (the non-fixed-point) is > > > used by > > > your fork. Furthermore, you only need these 2MB windows for floats, > > > not > > > for int or doubles. > > > > > > > > I need this, and only this patch to stay in tree. > > For what? avfilter stuff? > This or alternative solution, I think Lynne is working on it.... > > /Tomas > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >
diff --git a/libavutil/tx_template.c b/libavutil/tx_template.c index 983de75a47..c4ec9502e0 100644 --- a/libavutil/tx_template.c +++ b/libavutil/tx_template.c @@ -43,6 +43,10 @@ SR_TABLE(32768) \ SR_TABLE(65536) \ SR_TABLE(131072) \ + SR_TABLE(262144) \ + SR_TABLE(524288) \ + SR_TABLE(1048576) \ + SR_TABLE(2097152) \ #define SR_TABLE(len) \ TABLE_DEF(len, len/4 + 1); @@ -717,6 +721,10 @@ DECL_SR_CODELET(16384,8192,4096) DECL_SR_CODELET(32768,16384,8192) DECL_SR_CODELET(65536,32768,16384) DECL_SR_CODELET(131072,65536,32768) +DECL_SR_CODELET(262144,131072,65536) +DECL_SR_CODELET(524288,262144,131072) +DECL_SR_CODELET(1048576,524288,262144) +DECL_SR_CODELET(2097152,1048576,524288) static av_cold int TX_NAME(ff_tx_fft_init)(AVTXContext *s, const FFTXCodelet *cd, @@ -1947,6 +1955,10 @@ const FFTXCodelet * const TX_NAME(ff_tx_codelet_list)[] = { &TX_NAME(ff_tx_fft32768_ns_def), &TX_NAME(ff_tx_fft65536_ns_def), &TX_NAME(ff_tx_fft131072_ns_def), + &TX_NAME(ff_tx_fft262144_ns_def), + &TX_NAME(ff_tx_fft524288_ns_def), + &TX_NAME(ff_tx_fft1048576_ns_def), + &TX_NAME(ff_tx_fft2097152_ns_def), /* Prime factor codelets */ &TX_NAME(ff_tx_fft3_ns_def),
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc> --- libavutil/tx_template.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)