[FFmpeg-devel] [PATCH] Mention that AV_OPT_TYPE_IMAGE_SIZE can be unsigned

[FFmpeg-devel] [PATCH] Mention that AV_OPT_TYPE_IMAGE_SIZE can be unsigned

[Andrew Sayers]

TileContext in libavfilter/vf_tile.c and
UntileContext in libavfilter/vf_untile.c
point to unsigned ints - confirm this is OK.
---
 libavutil/opt.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/opt.h b/libavutil/opt.h
index 07e27a9208..9339b1a6ac 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -252,7 +252,7 @@ enum AVOptionType{
     AV_OPT_TYPE_DICT,
     AV_OPT_TYPE_UINT64,
     AV_OPT_TYPE_CONST,
-    AV_OPT_TYPE_IMAGE_SIZE, ///< offset must point to two consecutive ints
+    AV_OPT_TYPE_IMAGE_SIZE, ///< offset must point to two consecutive ints (or unsigned ints)
     AV_OPT_TYPE_PIXEL_FMT,
     AV_OPT_TYPE_SAMPLE_FMT,
     AV_OPT_TYPE_VIDEO_RATE, ///< offset must point to AVRational
-- 
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".

Re: [FFmpeg-devel] [PATCH] Mention that AV_OPT_TYPE_IMAGE_SIZE can be unsigned

[Marcus B Spencer]

On Monday, July 8th, 2024 at 2:00 PM, Andrew Sayers <ffmpeg-devel@pileofstuff.org> wrote:

> Mention that AV_OPT_TYPE_IMAGE_SIZE can be unsigned

Commit messages must start with a context terminated by a colon and a space. In this case "lavu/opt: " or "avutil/opt: " is an appropriate prefix.

>
> TileContext in libavfilter/vf_tile.c and
> UntileContext in libavfilter/vf_untile.c
> point to unsigned ints - confirm this is OK.
> ---
> libavutil/opt.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/opt.h b/libavutil/opt.h
> index 07e27a9208..9339b1a6ac 100644
> --- a/libavutil/opt.h
> +++ b/libavutil/opt.h
> @@ -252,7 +252,7 @@ enum AVOptionType{
> AV_OPT_TYPE_DICT,
> AV_OPT_TYPE_UINT64,
> AV_OPT_TYPE_CONST,
> - AV_OPT_TYPE_IMAGE_SIZE, ///< offset must point to two consecutive ints
> + AV_OPT_TYPE_IMAGE_SIZE, ///< offset must point to two consecutive ints (or unsigned ints)
> AV_OPT_TYPE_PIXEL_FMT,
> AV_OPT_TYPE_SAMPLE_FMT,
> AV_OPT_TYPE_VIDEO_RATE, ///< offset must point to AVRational
> --
> 2.45.2

Other than that, looks good to me.

Regards,
Marcus B Spencer
_______________________________________________
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] [PATCH v2] lavu/opt: Mention that AV_OPT_TYPE_IMAGE_SIZE can be unsigned

[Andrew Sayers]

TileContext in libavfilter/vf_tile.c and
UntileContext in libavfilter/vf_untile.c
point to unsigned ints - confirm this is OK.
---

Thanks Marcus - have updated my e-mail script to remind myself in future.

 libavutil/opt.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/opt.h b/libavutil/opt.h
index 07e27a9208..9339b1a6ac 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -252,7 +252,7 @@ enum AVOptionType{
     AV_OPT_TYPE_DICT,
     AV_OPT_TYPE_UINT64,
     AV_OPT_TYPE_CONST,
-    AV_OPT_TYPE_IMAGE_SIZE, ///< offset must point to two consecutive ints
+    AV_OPT_TYPE_IMAGE_SIZE, ///< offset must point to two consecutive ints (or unsigned ints)
     AV_OPT_TYPE_PIXEL_FMT,
     AV_OPT_TYPE_SAMPLE_FMT,
     AV_OPT_TYPE_VIDEO_RATE, ///< offset must point to AVRational
-- 
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".

Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Mention that AV_OPT_TYPE_IMAGE_SIZE can be unsigned

[Paul B Mahol]

tile and untile are wrong
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Mention that AV_OPT_TYPE_IMAGE_SIZE can be unsigned

[Andrew Sayers]

On Wed, Jul 10, 2024 at 04:01:44PM +0200, Paul B Mahol wrote:
> tile and untile are wrong

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

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

Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Mention that AV_OPT_TYPE_IMAGE_SIZE can be unsigned

[James Almer]

On 7/10/2024 11:54 AM, Andrew Sayers wrote:
> On Wed, Jul 10, 2024 at 04:01:44PM +0200, Paul B Mahol wrote:
>> tile and untile are wrong
> 
> How so?

I think it's better to just make those filters use ints than changing 
what the API is documented to handle.
_______________________________________________
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] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Andrew Sayers]

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Paul B Mahol]

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".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Andrew Sayers]

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/
_______________________________________________
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] [PATCH v4] avfilter: fix data type for {Tile, Untile}Context's image size

[Andrew Sayers]

These are accessed as AV_OPT_TYPE_IMAGE_SIZE AVOptions,
so must be implemented as (signed) int's
---
 libavfilter/vf_tile.c   | 2 +-
 libavfilter/vf_untile.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_tile.c b/libavfilter/vf_tile.c
index b45e739bb6..95ac3a1992 100644
--- a/libavfilter/vf_tile.c
+++ b/libavfilter/vf_tile.c
@@ -34,7 +34,7 @@
 
 typedef struct TileContext {
     const AVClass *class;
-    unsigned w, h;
+    int w, h;
     unsigned margin;
     unsigned padding;
     unsigned overlap;
diff --git a/libavfilter/vf_untile.c b/libavfilter/vf_untile.c
index f32f3e186b..bfc0998b46 100644
--- a/libavfilter/vf_untile.c
+++ b/libavfilter/vf_untile.c
@@ -28,7 +28,7 @@
 
 typedef struct UntileContext {
     const AVClass *class;
-    unsigned w, h;
+    int w, h;
     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".

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[James Almer]

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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Paul B Mahol]

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".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Paul B Mahol]

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".
>>
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[James Almer]

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".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Ronald S. Bultje]

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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Michael Niedermayer]

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

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell

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

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

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

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Michael Niedermayer]

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

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

[...]

-- 
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

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

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

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

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Marvin Scholz (ePirat)]

> 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>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Michael Niedermayer]

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

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

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein

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

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

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

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Rémi Denis-Courmont]

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.

-- 
レミ・デニ-クールモン
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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Ronald S. Bultje]

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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] avfilter: fix data type for {Tile, Untile}Context's image size

[Rémi Denis-Courmont]

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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Mention that AV_OPT_TYPE_IMAGE_SIZE can be unsigned

[Andrew Sayers]

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

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

Re: [FFmpeg-devel] [PATCH v2] lavu/opt: Mention that AV_OPT_TYPE_IMAGE_SIZE can be unsigned

[Paul B Mahol]

Rudimentary programming skills.
Unsigned range of values is different from signed range.

On Fri, Jul 19, 2024 at 10:34 AM Andrew Sayers <ffmpeg-devel@pileofstuff.org>
wrote:

> Ping
> _______________________________________________
> 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".