| Message ID | 20240719135409.2921601-1-ffmpeg-devel@pileofstuff.org |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel,v2] avfilter: fix data type for {Tile, Untile}Context's image size | expand |
Internal/private filter structures/API changes does not need be mentioned in that file, isn't that fact obvious even for average Joe? On Fri, Jul 19, 2024 at 4:01 PM Andrew Sayers <ffmpeg-devel@pileofstuff.org> wrote: > These are accessed as AV_OPT_TYPE_IMAGE_SIZE AVOptions, > so must be implemented as (signed) int's > --- > doc/APIchanges | 6 ++++++ > libavfilter/version_major.h | 1 + > libavfilter/vf_tile.c | 4 ++++ > libavfilter/vf_untile.c | 4 ++++ > 4 files changed, 15 insertions(+) > > diff --git a/doc/APIchanges b/doc/APIchanges > index 5751216b24..e839d1b674 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -2,6 +2,12 @@ The last version increases of all libraries were on > 2024-03-07 > > API changes, most recent first: > > +2024-07-19 - xxxxxxxxxx - lavfi 10 - vf_tile.c > + Convert TileContext::w and TileContext::h from unsigned to int > + > +2024-07-19 - xxxxxxxxxx - lavfi 10 - vf_untile.c > + Convert UntileContext::w and UntileContext::h from unsigned to int > + > 2024-07-xx - xxxxxxxxxx - lavf 61 - avformat.h > Deprecate avformat_transfer_internal_stream_timing_info() > and av_stream_get_codec_timebase() without replacement. > diff --git a/libavfilter/version_major.h b/libavfilter/version_major.h > index c5e660eeda..a8dc790c0a 100644 > --- a/libavfilter/version_major.h > +++ b/libavfilter/version_major.h > @@ -36,5 +36,6 @@ > */ > > #define FF_API_LINK_PUBLIC (LIBAVFILTER_VERSION_MAJOR < 11) > +#define FF_API_TILE_SIZE_TYPE (LIBAVFILTER_VERSION_MAJOR < 11) > > #endif /* AVFILTER_VERSION_MAJOR_H */ > diff --git a/libavfilter/vf_tile.c b/libavfilter/vf_tile.c > index b45e739bb6..0076657c92 100644 > --- a/libavfilter/vf_tile.c > +++ b/libavfilter/vf_tile.c > @@ -34,7 +34,11 @@ > > typedef struct TileContext { > const AVClass *class; > +#if FF_API_TILE_SIZE_TYPE > unsigned w, h; > +#else > + int w, h; > +#endif > unsigned margin; > unsigned padding; > unsigned overlap; > diff --git a/libavfilter/vf_untile.c b/libavfilter/vf_untile.c > index f32f3e186b..5164e2efb0 100644 > --- a/libavfilter/vf_untile.c > +++ b/libavfilter/vf_untile.c > @@ -28,7 +28,11 @@ > > typedef struct UntileContext { > const AVClass *class; > +#if FF_API_TILE_SIZE_TYPE > unsigned w, h; > +#else > + int w, h; > +#endif > unsigned current; > unsigned nb_frames; > AVFrame *frame; > -- > 2.45.2 > > _______________________________________________ > 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 Fri, Jul 19, 2024 at 05:31:53PM +0200, Paul B Mahol wrote: > Internal/private filter structures/API changes does not need be mentioned > in that file, isn't that fact obvious even for average Joe? The documentation[1] says "FFmpeg guarantees backward API and ABI compatibility for each library", followed by "Behavior in undocumented situations ... are accompanied by an entry in doc/APIchanges". It is not obvious to this average Joe why the AVOptions API would be an exception to that rule. Please submit a patch to libavutil/avutil.h that fixes the bug in the documentation. [1] https://ffmpeg.org/doxygen/trunk/
On 7/19/2024 12:31 PM, Paul B Mahol wrote: > Internal/private filter structures/API changes does not need be mentioned > in that file, isn't that fact obvious even for average Joe? There's no reason to be condescending or aggressive over something so irrelevant. Is it so hard to just state the APIChanges entry is not needed? I'm writing this representing the CC. This is not the only case you were pointlessly aggressive to someone in the past week or so. Consider it a warning before further action is taken.
On Tue, Jul 23, 2024 at 5:17 PM James Almer <jamrial@gmail.com> wrote: > On 7/19/2024 12:31 PM, Paul B Mahol wrote: > > Internal/private filter structures/API changes does not need be mentioned > > in that file, isn't that fact obvious even for average Joe? > > There's no reason to be condescending or aggressive over something so > irrelevant. Is it so hard to just state the APIChanges entry is not needed? > > I'm writing this representing the CC. This is not the only case you were > pointlessly aggressive to someone in the past week or so. Consider it a > warning before further action is taken. > Gebels is proud of you. > _______________________________________________ > 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 Tue, Jul 23, 2024 at 6:17 PM Paul B Mahol <onemda@gmail.com> wrote: > > > On Tue, Jul 23, 2024 at 5:17 PM James Almer <jamrial@gmail.com> wrote: > >> On 7/19/2024 12:31 PM, Paul B Mahol wrote: >> > Internal/private filter structures/API changes does not need be >> mentioned >> > in that file, isn't that fact obvious even for average Joe? >> >> There's no reason to be condescending or aggressive over something so >> irrelevant. Is it so hard to just state the APIChanges entry is not >> needed? >> >> I'm writing this representing the CC. This is not the only case you were >> pointlessly aggressive to someone in the past week or so. Consider it a >> warning before further action is taken. >> > > Gebels is proud of you. > Also you are not supporting any free speech whatsoever. Also you are extremely selective and biased in your judging. Also you are part of the problem. I'm also happy spectator of very slow death of this project from now on. > > >> _______________________________________________ >> 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 7/23/2024 1:24 PM, Paul B Mahol wrote: > On Tue, Jul 23, 2024 at 6:17 PM Paul B Mahol <onemda@gmail.com> wrote: > >> >> >> On Tue, Jul 23, 2024 at 5:17 PM James Almer <jamrial@gmail.com> wrote: >> >>> On 7/19/2024 12:31 PM, Paul B Mahol wrote: >>>> Internal/private filter structures/API changes does not need be >>> mentioned >>>> in that file, isn't that fact obvious even for average Joe? >>> >>> There's no reason to be condescending or aggressive over something so >>> irrelevant. Is it so hard to just state the APIChanges entry is not >>> needed? >>> >>> I'm writing this representing the CC. This is not the only case you were >>> pointlessly aggressive to someone in the past week or so. Consider it a >>> warning before further action is taken. >>> >> >> Gebels is proud of you. >> > > > Also you are not supporting any free speech whatsoever. Free speech doesn't mean mistreating others and facing no consequences for it... > > Also you are extremely selective and biased in your judging. If we missed someone being pointlessly aggressive in their reviews, please point me to it. > > Also you are part of the problem. How? > > I'm also happy spectator of very slow death of this project from now on. > > >> >> >>> _______________________________________________ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". >>> >> > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Hi Paul, On Tue, Jul 23, 2024 at 5:31 PM Paul B Mahol <onemda@gmail.com> wrote: > Also you are extremely selective and biased in your judging. > If you believe there's anything we missed, please forward relevant communication (emails or IRC logs) to us and we will have a look. I'm not online 24/7 so I certainly expect to miss a lot. I assume the same for my colleagues. Ronald
On Tue, Jul 23, 2024 at 12:17:43PM -0300, James Almer wrote: > On 7/19/2024 12:31 PM, Paul B Mahol wrote: > > Internal/private filter structures/API changes does not need be mentioned > > in that file, isn't that fact obvious even for average Joe? > > There's no reason to be condescending or aggressive over something so > irrelevant. Is it so hard to just state the APIChanges entry is not needed? "so irrelevant" sounds condescending to me too either way, i support pointing out if something sounds rude/condescending/aggressive (theres nothing bad in pointing that out, first step is always being aware one said something that others find offensive) > > I'm writing this representing the CC. This is not the only case you were > pointlessly aggressive to someone in the past week or so. Consider it a > warning before further action is taken. This part i do not agree with. First, i dont think we actually had a majority for a warning, I see 4 of 5 members of the CC replying but only 2 talking about a warning. Also (as i said previously) Politely pointing out to people when they write offensive things is a good thing, it has been effective in channeling discussions into a positive and friendlier direction, especially when done in real time. (You did the previously several times successfully) Adding a "threat" in the form of a warning maybe works for some people in some cases. But in others its more like slapping an already angry guy in the face. You get slapped harder back then have to punch and get punched back and then things spiral downward. And whetaver the exact outcome its a bad outcome thx [...]
On Wed, Jul 24, 2024 at 12:10:08AM +0200, Michael Niedermayer wrote: [...] > Adding a "threat" in the form of a warning maybe works for some people in > some cases. But in others its more like slapping an already angry guy in the face. > You get slapped harder back then have to punch and get punched back and then > things spiral downward. And whetaver the exact outcome its a bad outcome Also, if the CC needs to deliver a warning, i think its better to do that part in private. Delivering a warning to someone in front of others is normally unneccesary thx [...]
> On 24. Jul 2024, at 00:10, Michael Niedermayer <michael@niedermayer.cc> wrote: > > On Tue, Jul 23, 2024 at 12:17:43PM -0300, James Almer wrote: >>> On 7/19/2024 12:31 PM, Paul B Mahol wrote: >>> Internal/private filter structures/API changes does not need be mentioned >>> in that file, isn't that fact obvious even for average Joe? >> >> There's no reason to be condescending or aggressive over something so >> irrelevant. Is it so hard to just state the APIChanges entry is not needed? > > "so irrelevant" sounds condescending to me too > > either way, i support pointing out if something sounds rude/condescending/aggressive > (theres nothing bad in pointing that out, first step is always being aware > one said something that others find offensive) > > >> >> I'm writing this representing the CC. This is not the only case you were >> pointlessly aggressive to someone in the past week or so. Consider it a >> warning before further action is taken. > > This part i do not agree with. > First, i dont think we actually had a majority for a warning, I see 4 of 5 > members of the CC replying but only 2 talking about a warning. > What a joke is the CC if this is not warning-worthy… And if you do not point it out in public, it looks like to everyone else such behavior is tolerated, to everyone else. > Also (as i said previously) Politely pointing out to people when they write > offensive things is a good thing, it has been effective in channeling > discussions into a positive and friendlier direction, > especially when done in real time. (You did the previously several times > successfully) > > Adding a "threat" in the form of a warning maybe works for some people in > some cases. But in others its more like slapping an already angry guy in the face. > You get slapped harder back then have to punch and get punched back and then > things spiral downward. And whetaver the exact outcome its a bad outcome > Having less toxic people in the community is a bad outcome? Ok then we have different definitions of bad. > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > During times of universal deceit, telling the truth becomes a > revolutionary act. -- George Orwell > _______________________________________________ > 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". > <signature.asc>
On Wed, Jul 24, 2024 at 06:49:04AM +0200, Marvin Scholz (ePirat) wrote: > > > On 24. Jul 2024, at 00:10, Michael Niedermayer <michael@niedermayer.cc> wrote: > > > > On Tue, Jul 23, 2024 at 12:17:43PM -0300, James Almer wrote: > >>> On 7/19/2024 12:31 PM, Paul B Mahol wrote: > >>> Internal/private filter structures/API changes does not need be mentioned > >>> in that file, isn't that fact obvious even for average Joe? > >> > >> There's no reason to be condescending or aggressive over something so > >> irrelevant. Is it so hard to just state the APIChanges entry is not needed? > > > > "so irrelevant" sounds condescending to me too > > > > either way, i support pointing out if something sounds rude/condescending/aggressive > > (theres nothing bad in pointing that out, first step is always being aware > > one said something that others find offensive) > > > > > >> > >> I'm writing this representing the CC. This is not the only case you were > >> pointlessly aggressive to someone in the past week or so. Consider it a > >> warning before further action is taken. > > > > This part i do not agree with. > > First, i dont think we actually had a majority for a warning, I see 4 of 5 > > members of the CC replying but only 2 talking about a warning. > > > > > What a joke is the CC if this is not warning-worthy… The question is not if its "warning-worthy", the question is what action creates the best FFmpeg. And also an enviroment we are all happy to work in. Some people do not at all like being warned publically, some people do not at all like having the CC "Breathe into their neck". Some people dont like offensive language What we need is a middle way between all this that makes as many people happy and contributing as possible > > And if you do not point it out in public, it looks like to everyone else such behavior is tolerated, to everyone else. I think i clearly stated that i do want people to point out offensive sounding things immedeatly in realtime when they happen to the people involved. This has been done in several instances and IIRC it almost always if not always helped with noone being offended. The problem begins with it is done in a threatening tone or "from above". Having authority is ok, emphasizing that authority is not IMHO > > > Also (as i said previously) Politely pointing out to people when they write > > offensive things is a good thing, it has been effective in channeling > > discussions into a positive and friendlier direction, > > especially when done in real time. (You did the previously several times > > successfully) > > > > Adding a "threat" in the form of a warning maybe works for some people in > > some cases. But in others its more like slapping an already angry guy in the face. > > You get slapped harder back then have to punch and get punched back and then > > things spiral downward. And whetaver the exact outcome its a bad outcome > > > > Having less toxic people in the community is a bad outcome? Ok then we have different definitions of bad. Bringing a Team that considers some members toxic together and having noone considered to be toxic is the real goal. Loosing a major volunteer contributor is already not a good outcome. If some people can absolutely not work together, yes then its better for them to part ways. And if they still work both on the same codebase we should ensure that their work can still be combined while each side has their own git tree where they can maintain their code without avoidable interference from others. thx [...]
Le keskiviikkona 24. heinäkuuta 2024, 16.08.17 EEST Michael Niedermayer a écrit : > The question is not if its "warning-worthy", the question is what action > creates the best FFmpeg. And also an enviroment we are all happy to work in. That is complete nonsense. It is more obvious than patently obvious by now that that utopic environment does not exist, so that, with very contradictory wants from Paul or Nicolas on one hand, and, say Vittorio or Marvin on the other hand. Although you are correct for the wrong reasons that there is also no question about it being warning-worthy. It might have been debatable initially. But it is moot now that Paul has verified Godwin's law. That is simply wholly intolerable and there are no sane actions than for the CC to suspend him. The fact that the CC has done *nothing* in over 24 hours is already a bad enough look. > Some people do not at all like being warned publically, some people do not > at all like having the CC "Breathe into their neck". Nobody likes to be warned in public. Don't get me started on being on the receiving end of warnings in open-source projects. The whole point of a public warning are to make an example, and show consideration for the victims (if any), not to be friendly. > Some people dont like offensive language > > What we need is a middle way between all this that makes as many people > happy and contributing as possible Yes? And regrettably, Paul has repeatedly breached community rules if not common sense courtesy, and made a lot of people unhappy to contribute. He has also been warned many times and ignored or even rebuked those warnings. Yesterday was a new low (at least in the time frame that I have been subscribed to FFmpeg-devel). At this point, I unfortunately don't see a way forward other than excluding him for an extended period of time. This is extreme considering that he has been one of the most prolific contributor to FFmpeg, but then again, he de facto excluded himself by making a hostile fork.
Hi, On Wed, Jul 24, 2024 at 8:41 PM Rémi Denis-Courmont <remi@remlab.net> wrote: > but then again, he de facto excluded himself by making a hostile fork. > Forking is very much a part of the opensource spirit, and hostile is very subjective. Such a precedent would be abused over and over. (I agree with some other points you're making, but not this last one.) Ronald
Le 25 juillet 2024 10:54:15 GMT+03:00, "Ronald S. Bultje" <rsbultje@gmail.com> a écrit : >Hi, > >On Wed, Jul 24, 2024 at 8:41 PM Rémi Denis-Courmont <remi@remlab.net> wrote: > >> but then again, he de facto excluded himself by making a hostile fork. >> > >Forking is very much a part of the opensource spirit, and hostile is very >subjective. Such a precedent would be abused over and over. Hostility is subjective but the rest is just a constatation. A constatation can't establish a precedent, and thus no precedent that can be abused. The point is, whether he gets suspended or not, he would most likely not be contributing code here either way. I don't appreciate people putting words in my mouth especially CC members. I never stated that anyone should be excluded for making a fork. And in any case, I don't think that being one of the top historical contributor excuses comparing other people with Nazis.
diff --git a/doc/APIchanges b/doc/APIchanges index 5751216b24..e839d1b674 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -2,6 +2,12 @@ The last version increases of all libraries were on 2024-03-07 API changes, most recent first: +2024-07-19 - xxxxxxxxxx - lavfi 10 - vf_tile.c + Convert TileContext::w and TileContext::h from unsigned to int + +2024-07-19 - xxxxxxxxxx - lavfi 10 - vf_untile.c + Convert UntileContext::w and UntileContext::h from unsigned to int + 2024-07-xx - xxxxxxxxxx - lavf 61 - avformat.h Deprecate avformat_transfer_internal_stream_timing_info() and av_stream_get_codec_timebase() without replacement. diff --git a/libavfilter/version_major.h b/libavfilter/version_major.h index c5e660eeda..a8dc790c0a 100644 --- a/libavfilter/version_major.h +++ b/libavfilter/version_major.h @@ -36,5 +36,6 @@ */ #define FF_API_LINK_PUBLIC (LIBAVFILTER_VERSION_MAJOR < 11) +#define FF_API_TILE_SIZE_TYPE (LIBAVFILTER_VERSION_MAJOR < 11) #endif /* AVFILTER_VERSION_MAJOR_H */ diff --git a/libavfilter/vf_tile.c b/libavfilter/vf_tile.c index b45e739bb6..0076657c92 100644 --- a/libavfilter/vf_tile.c +++ b/libavfilter/vf_tile.c @@ -34,7 +34,11 @@ typedef struct TileContext { const AVClass *class; +#if FF_API_TILE_SIZE_TYPE unsigned w, h; +#else + int w, h; +#endif unsigned margin; unsigned padding; unsigned overlap; diff --git a/libavfilter/vf_untile.c b/libavfilter/vf_untile.c index f32f3e186b..5164e2efb0 100644 --- a/libavfilter/vf_untile.c +++ b/libavfilter/vf_untile.c @@ -28,7 +28,11 @@ typedef struct UntileContext { const AVClass *class; +#if FF_API_TILE_SIZE_TYPE unsigned w, h; +#else + int w, h; +#endif unsigned current; unsigned nb_frames; AVFrame *frame;