[FFmpeg-devel] [PATCH 1/4] doc/developer.texi: improve the introductory text

[FFmpeg-devel] [PATCH 1/4] doc/developer.texi: improve the introductory text

[Anton Khirnov]

Remove confusing references to "external" vs. "internal" developers.
---
 doc/developer.texi | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index addee0d826..5cf3b19ee0 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -10,13 +10,19 @@
 
 @contents
 
-@chapter Notes for external developers
+@chapter Introduction
 
-This document is mostly useful for internal FFmpeg developers.
-External developers who need to use the API in their application should
-refer to the API doxygen documentation in the public headers, and
-check the examples in @file{doc/examples} and in the source code to
-see how the public API is employed.
+This text is concerned with the development @emph{of} FFmpeg itself. Information
+on using the FFmpeg libraries in other programs can be found elsewhere, e.g. in:
+@itemize @bullet
+@item
+the installed header files
+@item
+@url{http://ffmpeg.org/doxygen/trunk/index.html, the Doxygen documentation}
+generated from the headers
+@item
+the examples under @file{doc/examples}
+@end itemize
 
 You can use the FFmpeg libraries in your commercial program, but you
 are encouraged to @emph{publish any patch you make}. In this case the
-- 
2.35.1

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

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

[FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches

[Anton Khirnov]

Stop talking about commercial programs, since this applies to any
downstream user.
---
 doc/developer.texi | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 5cf3b19ee0..2f0d2b7daa 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -24,11 +24,21 @@ generated from the headers
 the examples under @file{doc/examples}
 @end itemize
 
-You can use the FFmpeg libraries in your commercial program, but you
-are encouraged to @emph{publish any patch you make}. In this case the
-best way to proceed is to send your patches to the ffmpeg-devel
-mailing list following the guidelines illustrated in the remainder of
-this document.
+If you modify FFmpeg code for your own use case, you are highly encouraged to
+@emph{submit your changes back to us}, using this document as a guide. There are
+both pragmatic and ideological reasons to do so:
+@itemize @bullet
+@item
+Maintaining external changes to keep up with upstream development is
+time-consuming and error-prone. With your code in the main tree, it will be
+maintained by FFmpeg developers.
+@item
+FFmpeg developers include leading experts in the field who can find bugs or
+design flaws in your code.
+@item
+By supporting the project you find useful you ensure it continues to be
+maintained and developed.
+@end itemize
 
 For more detailed legal information about the use of FFmpeg in
 external programs read the @file{LICENSE} file in the source tree and
-- 
2.35.1

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

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

[FFmpeg-devel] [PATCH 3/4] doc/developer.texi: demote the "contributing" chapter to a section

[Anton Khirnov]

It is very short and its main functions is linking to the
coding rules/submitting patches chapters.
---
 doc/developer.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 2f0d2b7daa..2e050edc6a 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -44,7 +44,7 @@ For more detailed legal information about the use of FFmpeg in
 external programs read the @file{LICENSE} file in the source tree and
 consult @url{https://ffmpeg.org/legal.html}.
 
-@chapter Contributing
+@section Contributing code
 
 There are 2 ways by which code gets into FFmpeg:
 @itemize @bullet
-- 
2.35.1

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

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

[FFmpeg-devel] [PATCH 4/4] doc/developer.texi: refine the "contributing code" section

[Anton Khirnov]

Drop the reference to directly committing code, because
- it is highly discouraged and very rarely done these days
- there is no good reason NOT to submit patches for review

Add a link to the development policy chapter.
---
 doc/developer.texi | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 2e050edc6a..cf918ac6b1 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -46,15 +46,10 @@ consult @url{https://ffmpeg.org/legal.html}.
 
 @section Contributing code
 
-There are 2 ways by which code gets into FFmpeg:
-@itemize @bullet
-@item Submitting patches to the ffmpeg-devel mailing list.
-      See @ref{Submitting patches} for details.
-@item Directly committing changes to the main tree.
-@end itemize
-
-Whichever way, changes should be reviewed by the maintainer of the code
-before they are committed. And they should follow the @ref{Coding Rules}.
+All proposed code changes should be submitted for review to
+@url{mailto:ffmpeg-devel@@ffmpeg.org, the development mailing list}, as
+described in more detail in the @ref{Submitting patches} chapter. The code
+should comply with the @ref{Development Policy} and follow the @ref{Coding Rules}.
 The developer making the commit and the author are responsible for their changes
 and should try to fix issues their commit causes.
 
@@ -267,6 +262,7 @@ For Emacs, add these roughly equivalent lines to your @file{.emacs.d/init.el}:
 (setq c-default-style "ffmpeg")
 @end lisp
 
+@anchor{Development Policy}
 @chapter Development Policy
 
 @section Patches/Committing
-- 
2.35.1

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

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

Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 10:13 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the
> argument for submitting patches
> 
> Stop talking about commercial programs, since this applies to any
> downstream user.
> ---
>  doc/developer.texi | 20 +++++++++++++++-----
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 5cf3b19ee0..2f0d2b7daa 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -24,11 +24,21 @@ generated from the headers
>  the examples under @file{doc/examples}
>  @end itemize
> 
> -You can use the FFmpeg libraries in your commercial program, but you
> -are encouraged to @emph{publish any patch you make}. In this case
> the
> -best way to proceed is to send your patches to the ffmpeg-devel
> -mailing list following the guidelines illustrated in the remainder
> of
> -this document.
> +If you modify FFmpeg code for your own use case, you are highly
> encouraged to
> +@emph{submit your changes back to us}, using this document as a
> guide. There are
> +both pragmatic and ideological reasons to do so:
> +@itemize @bullet
> +@item
> +Maintaining external changes to keep up with upstream development is
> +time-consuming and error-prone. With your code in the main tree, it
> will be
> +maintained by FFmpeg developers.

You should mention that sometimes it's not really worth to take the effort,
because waiting for reviews and permanent rebasing and re-submitting,
explaining, defending, getting insulted or ignored and whatsoever,
might end up taking much more time than just to keep and maintain your 
changes privately. Eventually you might regret that you have even
started going that way.

Regards,
softworkz
_______________________________________________
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 2/4] doc/developer.texi: extend the argument for submitting patches

[Anton Khirnov]

Quoting Soft Works (2022-11-14 10:35:40)
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Anton Khirnov
> > Sent: Monday, November 14, 2022 10:13 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the
> > argument for submitting patches
> > 
> > Stop talking about commercial programs, since this applies to any
> > downstream user.
> > ---
> >  doc/developer.texi | 20 +++++++++++++++-----
> >  1 file changed, 15 insertions(+), 5 deletions(-)
> > 
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index 5cf3b19ee0..2f0d2b7daa 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -24,11 +24,21 @@ generated from the headers
> >  the examples under @file{doc/examples}
> >  @end itemize
> > 
> > -You can use the FFmpeg libraries in your commercial program, but you
> > -are encouraged to @emph{publish any patch you make}. In this case
> > the
> > -best way to proceed is to send your patches to the ffmpeg-devel
> > -mailing list following the guidelines illustrated in the remainder
> > of
> > -this document.
> > +If you modify FFmpeg code for your own use case, you are highly
> > encouraged to
> > +@emph{submit your changes back to us}, using this document as a
> > guide. There are
> > +both pragmatic and ideological reasons to do so:
> > +@itemize @bullet
> > +@item
> > +Maintaining external changes to keep up with upstream development is
> > +time-consuming and error-prone. With your code in the main tree, it
> > will be
> > +maintained by FFmpeg developers.
> 
> You should mention that sometimes it's not really worth to take the effort,
> because waiting for reviews and permanent rebasing and re-submitting,
> explaining, defending, getting insulted or ignored and whatsoever,
> might end up taking much more time than just to keep and maintain your 
> changes privately. Eventually you might regret that you have even
> started going that way.

Sorry, but you problems are entirely self-inflicted. You have been told
what changes need to happen right from the beginning, repeatedly, and by
several developers independently. Instead of implementing them you chose
to compose ever-more-elaborate explanations and justifications that, as
far as I can tell, boil down to "doing things properly is too much
work". Seems to me that actually doing this work would take less time
than you have already spent arguing.

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

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

Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 10:53 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> Quoting Soft Works (2022-11-14 10:35:40)
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Anton Khirnov
> > > Sent: Monday, November 14, 2022 10:13 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the
> > > argument for submitting patches
> > >
> > > Stop talking about commercial programs, since this applies to any
> > > downstream user.
> > > ---
> > >  doc/developer.texi | 20 +++++++++++++++-----
> > >  1 file changed, 15 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/doc/developer.texi b/doc/developer.texi
> > > index 5cf3b19ee0..2f0d2b7daa 100644
> > > --- a/doc/developer.texi
> > > +++ b/doc/developer.texi
> > > @@ -24,11 +24,21 @@ generated from the headers
> > >  the examples under @file{doc/examples}
> > >  @end itemize
> > >
> > > -You can use the FFmpeg libraries in your commercial program, but
> you
> > > -are encouraged to @emph{publish any patch you make}. In this
> case
> > > the
> > > -best way to proceed is to send your patches to the ffmpeg-devel
> > > -mailing list following the guidelines illustrated in the
> remainder
> > > of
> > > -this document.
> > > +If you modify FFmpeg code for your own use case, you are highly
> > > encouraged to
> > > +@emph{submit your changes back to us}, using this document as a
> > > guide. There are
> > > +both pragmatic and ideological reasons to do so:
> > > +@itemize @bullet
> > > +@item
> > > +Maintaining external changes to keep up with upstream
> development is
> > > +time-consuming and error-prone. With your code in the main tree,
> it
> > > will be
> > > +maintained by FFmpeg developers.
> >
> > You should mention that sometimes it's not really worth to take the
> effort,
> > because waiting for reviews and permanent rebasing and re-
> submitting,
> > explaining, defending, getting insulted or ignored and whatsoever,
> > might end up taking much more time than just to keep and maintain
> your
> > changes privately. Eventually you might regret that you have even
> > started going that way.
> 
> Sorry, but you problems are entirely self-inflicted. You have been
> told
> what changes need to happen right from the beginning, repeatedly, and
> by
> several developers independently. 

And those are completed and settled, like I had state multiple times.
It's ready for review for months already.

softworkz


_______________________________________________
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 2/4] doc/developer.texi: extend the argument for submitting patches

[Anton Khirnov]

Quoting Soft Works (2022-11-14 11:46:49)
> > Sorry, but you problems are entirely self-inflicted. You have been
> > told what changes need to happen right from the beginning,
> > repeatedly, and by several developers independently.
> 
> And those are completed and settled, like I had state multiple times.
> It's ready for review for months already.

Your stating something does not make it true, no matter how many times
you do it.

My objections were not addressed.

In your last resend, Hendrik yet again raised the start_pts question. As
far as I can tell, your explanation for why it's supposedly needed did
not convince ANYONE.

Some random quotes from IRC:
2022-09-01 00:25:21     @Lynne  elenril: I never retracted my insistence on using the native frame fields for subtitles
2022-09-01 00:25:27     @Lynne  not sure how softworks got that idea

2022-09-01 02:23:50     @BBB    subtitle.start_pts is really the emblem of the whole problem, I feel
2022-09-01 02:24:04     @BBB    there's many issues. but that one demonstrates it

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

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

Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 12:08 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> Quoting Soft Works (2022-11-14 11:46:49)
> > > Sorry, but you problems are entirely self-inflicted. You have
> been
> > > told what changes need to happen right from the beginning,
> > > repeatedly, and by several developers independently.
> >
> > And those are completed and settled, like I had state multiple
> times.
> > It's ready for review for months already.
> 
> Your stating something does not make it true, no matter how many
> times
> you do it.
> 
> My objections were not addressed.
> 
> In your last resend, Hendrik yet again raised the start_pts question.
> As
> far as I can tell, your explanation for why it's supposedly needed
> did
> not convince ANYONE.

What means "as far as I can tell" here? Do you have something to 
say about it, then please do?

I cannot talk and respond to any "ghost" statements which I'm not 
aware of.

And regarding the IRC snippet: Well, interesting, but I can neither
know not respond to anything I'm not aware of.


I had taken the effort to explain the reasons this in this article:

https://github.com/softworkz/SubtitleFilteringDemos/issues/1

and Hendrik didn't respond. So whom should I talk to, in order 
to find a solution, especially, considering the fact, that
nobody has really taken the effort to ACTUALLY understand what
the problem is?


Thanks,
softworkz



_______________________________________________
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 2/4] doc/developer.texi: extend the argument for submitting patches

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 12:08 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> Quoting Soft Works (2022-11-14 11:46:49)
> > > Sorry, but you problems are entirely self-inflicted. You have
> been
> > > told what changes need to happen right from the beginning,
> > > repeatedly, and by several developers independently.
> >
> > And those are completed and settled, like I had state multiple
> times.
> > It's ready for review for months already.

[...]

> 
> Some random quotes from IRC:
> 2022-09-01 00:25:21     @Lynne  elenril: I never retracted my
> insistence on using the native frame fields for subtitles
> 2022-09-01 00:25:27     @Lynne  not sure how softworks got that idea

I got that "idea" from this discussion:

Jan 14 02:46:02 <Lynne>	can't you really not hide away everything to do with repetition, subtitle pts, and subtitle duration all into the private opqaue field, and give the user what they expect when the frames go out of lavfi?
Jan 14 02:46:55 <softworkz>	worth a thought, but I'm not sure
Jan 14 02:49:32 <softworkz>	I think it's better to make it more transparent. the heartbeat mechanism has been a hidden thing and that's why it wasn't an ideal solution
Jan 14 02:50:10 <softworkz>	when you already need to understand when and why you need to insert a subfeed filter, then there's no point in hiding the effect imo
Jan 14 02:50:53 <Lynne>	I think that's worth a really good look
Jan 14 02:50:56 <softworkz>	the good thing is, that often none of that is needed at all
Jan 14 02:51:15 <softworkz>	(say sometimes..)
Jan 14 02:52:04 <Lynne>	if you could hide all of that into the opaque field, I'd be happy with the patch

This IS a retraction from the "insistence on using the native frame 
fields for subtitles."

(because the actual subtitle timings would be in that opaque field)

Regards,
softworkz

_______________________________________________
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 2/4] doc/developer.texi: extend the argument for submitting patches

[Nicolas George]

Anton Khirnov (12022-11-14):
> In your last resend, Hendrik yet again raised the start_pts question. As
> far as I can tell, your explanation for why it's supposedly needed did
> not convince ANYONE.

Not only that: this series is completely broken with regard to
negotiation, scheduling and utility filters. Not remotely ready for
review.

-- 
  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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches

[Anton Khirnov]

Quoting Soft Works (2022-11-14 12:20:00)
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Anton Khirnov
> > Sent: Monday, November 14, 2022 12:08 PM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> > the argument for submitting patches
> > 
> > Quoting Soft Works (2022-11-14 11:46:49)
> > > > Sorry, but you problems are entirely self-inflicted. You have
> > been
> > > > told what changes need to happen right from the beginning,
> > > > repeatedly, and by several developers independently.
> > >
> > > And those are completed and settled, like I had state multiple
> > times.
> > > It's ready for review for months already.
> > 
> > Your stating something does not make it true, no matter how many
> > times
> > you do it.
> > 
> > My objections were not addressed.
> > 
> > In your last resend, Hendrik yet again raised the start_pts question.
> > As
> > far as I can tell, your explanation for why it's supposedly needed
> > did
> > not convince ANYONE.
> 
> What means "as far as I can tell" here? Do you have something to 
> say about it, then please do?

It means that I am not aware of anyone who changed their stance based on
your arguments, but cannot prove that no such person exists.

> 
> I cannot talk and respond to any "ghost" statements which I'm not 
> aware of.
> 
> And regarding the IRC snippet: Well, interesting, but I can neither
> know not respond to anything I'm not aware of.
> 
> 
> I had taken the effort to explain the reasons this in this article:
> 
> https://github.com/softworkz/SubtitleFilteringDemos/issues/1
> 
> and Hendrik didn't respond. So whom should I talk to, in order 
> to find a solution, especially, considering the fact, that
> nobody has really taken the effort to ACTUALLY understand what
> the problem is?

I did read your document, and my takeaway message from it is "doing it
properly is too hard". As long as that continues to be your position,
you might as well not bother.

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

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

Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 3:35 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> Quoting Soft Works (2022-11-14 12:20:00)
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Anton Khirnov
> > > Sent: Monday, November 14, 2022 12:08 PM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi:
> extend
> > > the argument for submitting patches
> > >
> > > Quoting Soft Works (2022-11-14 11:46:49)
> > > > > Sorry, but you problems are entirely self-inflicted. You have
> > > been
> > > > > told what changes need to happen right from the beginning,
> > > > > repeatedly, and by several developers independently.
> > > >
> > > > And those are completed and settled, like I had state multiple
> > > times.
> > > > It's ready for review for months already.
> > >
> > > Your stating something does not make it true, no matter how many
> > > times
> > > you do it.
> > >
> > > My objections were not addressed.
> > >
> > > In your last resend, Hendrik yet again raised the start_pts
> question.
> > > As
> > > far as I can tell, your explanation for why it's supposedly
> needed
> > > did
> > > not convince ANYONE.
> >
> > What means "as far as I can tell" here? Do you have something to
> > say about it, then please do?
> 
> It means that I am not aware of anyone who changed their stance based
> on
> your arguments, but cannot prove that no such person exists.

I'm afraid, but everything you are writing is making references to 
others and what they would think or what you are assuming that they
might think.

> I did read your document, and my takeaway message from it is "doing
> it
> properly is too hard". As long as that continues to be your position,
> you might as well not bother.

This is ridiculous, and you know that. Or at least you would know
if you would have really tried to understand the problem.

And that unfortunately applies to some others as well. Nobody is 
willing to go deep enough to the point where it becomes clear
that a "perfect" solution would only be possible by making fundamental
changes to libavfilter, which are complex, risky and something
that would never be accepted from me, even when it would be 
the most excellent solution. I think this is pretty clear to 
everybody here, and trying to present this in a light as if
I would just be too lazy to go for it, is just despicable, 
I'm afraid.

I wish you could stop referring to others potential opinions 
and get yourself as much into the subject as it is required to 
understand the actual problem and talk for yourself.

Because I would happily discuss alternatives 
with you and follow your advice, no matter when it takes 
a little more effort - as long as it will still be possible
to handle all cases like with the current patchset.
But I mean substantial and detailed advice based on an 
understanding of the problems, not the kind of "no, that's
bad, I don't believe you that it couldn't be done like I
think it's gotta be".

I will happily, gladly and friendly work and converse with 
anybody who would be so kind to leave one's peripheral 
spectator position and get down with me to the core 
problem and discuss potential solutions.

Thanks,
softworkz
_______________________________________________
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 2/4] doc/developer.texi: extend the argument for submitting patches

[Paul B Mahol]

On 11/14/22, Soft Works <softworkz@hotmail.com> wrote:
>
>
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> Anton Khirnov
>> Sent: Monday, November 14, 2022 3:35 PM
>> To: FFmpeg development discussions and patches <ffmpeg-
>> devel@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
>> the argument for submitting patches
>>
>> Quoting Soft Works (2022-11-14 12:20:00)
>> >
>> >
>> > > -----Original Message-----
>> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> > > Anton Khirnov
>> > > Sent: Monday, November 14, 2022 12:08 PM
>> > > To: FFmpeg development discussions and patches <ffmpeg-
>> > > devel@ffmpeg.org>
>> > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi:
>> extend
>> > > the argument for submitting patches
>> > >
>> > > Quoting Soft Works (2022-11-14 11:46:49)
>> > > > > Sorry, but you problems are entirely self-inflicted. You have
>> > > been
>> > > > > told what changes need to happen right from the beginning,
>> > > > > repeatedly, and by several developers independently.
>> > > >
>> > > > And those are completed and settled, like I had state multiple
>> > > times.
>> > > > It's ready for review for months already.
>> > >
>> > > Your stating something does not make it true, no matter how many
>> > > times
>> > > you do it.
>> > >
>> > > My objections were not addressed.
>> > >
>> > > In your last resend, Hendrik yet again raised the start_pts
>> question.
>> > > As
>> > > far as I can tell, your explanation for why it's supposedly
>> needed
>> > > did
>> > > not convince ANYONE.
>> >
>> > What means "as far as I can tell" here? Do you have something to
>> > say about it, then please do?
>>
>> It means that I am not aware of anyone who changed their stance based
>> on
>> your arguments, but cannot prove that no such person exists.
>
> I'm afraid, but everything you are writing is making references to
> others and what they would think or what you are assuming that they
> might think.
>
>> I did read your document, and my takeaway message from it is "doing
>> it
>> properly is too hard". As long as that continues to be your position,
>> you might as well not bother.
>
> This is ridiculous, and you know that. Or at least you would know
> if you would have really tried to understand the problem.
>
> And that unfortunately applies to some others as well. Nobody is
> willing to go deep enough to the point where it becomes clear
> that a "perfect" solution would only be possible by making fundamental
> changes to libavfilter, which are complex, risky and something
> that would never be accepted from me, even when it would be
> the most excellent solution. I think this is pretty clear to
> everybody here, and trying to present this in a light as if
> I would just be too lazy to go for it, is just despicable,
> I'm afraid.
>
> I wish you could stop referring to others potential opinions
> and get yourself as much into the subject as it is required to
> understand the actual problem and talk for yourself.
>
> Because I would happily discuss alternatives
> with you and follow your advice, no matter when it takes
> a little more effort - as long as it will still be possible
> to handle all cases like with the current patchset.
> But I mean substantial and detailed advice based on an
> understanding of the problems, not the kind of "no, that's
> bad, I don't believe you that it couldn't be done like I
> think it's gotta be".
>
> I will happily, gladly and friendly work and converse with
> anybody who would be so kind to leave one's peripheral
> spectator position and get down with me to the core
> problem and discuss potential solutions.

They can not admit they have zero understanding why and how code works
Instead they propose some nonsense that hardly can be implemented.

>
> Thanks,
> softworkz
> _______________________________________________
> 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 2/4] doc/developer.texi: extend the argument for submitting patches

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Paul B Mahol
> Sent: Monday, November 14, 2022 4:18 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> On 11/14/22, Soft Works <softworkz@hotmail.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >> Anton Khirnov
> >> Sent: Monday, November 14, 2022 3:35 PM
> >> To: FFmpeg development discussions and patches <ffmpeg-
> >> devel@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> >> the argument for submitting patches
> >>
> >> Quoting Soft Works (2022-11-14 12:20:00)
> >> >
> >> >
> >> > > -----Original Message-----
> >> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> Of
> >> > > Anton Khirnov
> >> > > Sent: Monday, November 14, 2022 12:08 PM
> >> > > To: FFmpeg development discussions and patches <ffmpeg-
> >> > > devel@ffmpeg.org>
> >> > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi:
> >> extend
> >> > > the argument for submitting patches
> >> > >
> >> > > Quoting Soft Works (2022-11-14 11:46:49)
> >> > > > > Sorry, but you problems are entirely self-inflicted. You
> have
> >> > > been
> >> > > > > told what changes need to happen right from the beginning,
> >> > > > > repeatedly, and by several developers independently.
> >> > > >
> >> > > > And those are completed and settled, like I had state
> multiple
> >> > > times.
> >> > > > It's ready for review for months already.
> >> > >
> >> > > Your stating something does not make it true, no matter how
> many
> >> > > times
> >> > > you do it.
> >> > >
> >> > > My objections were not addressed.
> >> > >
> >> > > In your last resend, Hendrik yet again raised the start_pts
> >> question.
> >> > > As
> >> > > far as I can tell, your explanation for why it's supposedly
> >> needed
> >> > > did
> >> > > not convince ANYONE.
> >> >
> >> > What means "as far as I can tell" here? Do you have something to
> >> > say about it, then please do?
> >>
> >> It means that I am not aware of anyone who changed their stance
> based
> >> on
> >> your arguments, but cannot prove that no such person exists.
> >
> > I'm afraid, but everything you are writing is making references to
> > others and what they would think or what you are assuming that they
> > might think.
> >
> >> I did read your document, and my takeaway message from it is
> "doing
> >> it
> >> properly is too hard". As long as that continues to be your
> position,
> >> you might as well not bother.
> >
> > This is ridiculous, and you know that. Or at least you would know
> > if you would have really tried to understand the problem.
> >
> > And that unfortunately applies to some others as well. Nobody is
> > willing to go deep enough to the point where it becomes clear
> > that a "perfect" solution would only be possible by making
> fundamental
> > changes to libavfilter, which are complex, risky and something
> > that would never be accepted from me, even when it would be
> > the most excellent solution. I think this is pretty clear to
> > everybody here, and trying to present this in a light as if
> > I would just be too lazy to go for it, is just despicable,
> > I'm afraid.
> >
> > I wish you could stop referring to others potential opinions
> > and get yourself as much into the subject as it is required to
> > understand the actual problem and talk for yourself.
> >
> > Because I would happily discuss alternatives
> > with you and follow your advice, no matter when it takes
> > a little more effort - as long as it will still be possible
> > to handle all cases like with the current patchset.
> > But I mean substantial and detailed advice based on an
> > understanding of the problems, not the kind of "no, that's
> > bad, I don't believe you that it couldn't be done like I
> > think it's gotta be".
> >
> > I will happily, gladly and friendly work and converse with
> > anybody who would be so kind to leave one's peripheral
> > spectator position and get down with me to the core
> > problem and discuss potential solutions.
> 
> They can not admit they have zero understanding why and how code
> works
> Instead they propose some nonsense that hardly can be implemented.

I'm not saying that and I have no doubt they could..

sw







_______________________________________________
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 2/4] doc/developer.texi: extend the argument for submitting patches

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Paul B Mahol
> Sent: Monday, November 14, 2022 4:18 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> On 11/14/22, Soft Works <softworkz@hotmail.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >> Anton Khirnov
> >> Sent: Monday, November 14, 2022 3:35 PM
> >> To: FFmpeg development discussions and patches <ffmpeg-
> >> devel@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> >> the argument for submitting patches
> >>
> >> Quoting Soft Works (2022-11-14 12:20:00)
> >> >
> >> >
> >> > > -----Original Message-----
> >> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> Of
> >> > > Anton Khirnov
> >> > > Sent: Monday, November 14, 2022 12:08 PM
> >> > > To: FFmpeg development discussions and patches <ffmpeg-
> >> > > devel@ffmpeg.org>
> >> > > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi:
> >> extend
> >> > > the argument for submitting patches
> >> > >
> >> > > Quoting Soft Works (2022-11-14 11:46:49)
> >> > > > > Sorry, but you problems are entirely self-inflicted. You
> have
> >> > > been
> >> > > > > told what changes need to happen right from the beginning,
> >> > > > > repeatedly, and by several developers independently.
> >> > > >
> >> > > > And those are completed and settled, like I had state
> multiple
> >> > > times.
> >> > > > It's ready for review for months already.
> >> > >
> >> > > Your stating something does not make it true, no matter how
> many
> >> > > times
> >> > > you do it.
> >> > >
> >> > > My objections were not addressed.
> >> > >
> >> > > In your last resend, Hendrik yet again raised the start_pts
> >> question.
> >> > > As
> >> > > far as I can tell, your explanation for why it's supposedly
> >> needed
> >> > > did
> >> > > not convince ANYONE.
> >> >
> >> > What means "as far as I can tell" here? Do you have something to
> >> > say about it, then please do?
> >>
> >> It means that I am not aware of anyone who changed their stance
> based
> >> on
> >> your arguments, but cannot prove that no such person exists.
> >
> > I'm afraid, but everything you are writing is making references to
> > others and what they would think or what you are assuming that they
> > might think.
> >
> >> I did read your document, and my takeaway message from it is
> "doing
> >> it
> >> properly is too hard". As long as that continues to be your
> position,
> >> you might as well not bother.
> >
> > This is ridiculous, and you know that. Or at least you would know
> > if you would have really tried to understand the problem.
> >
> > And that unfortunately applies to some others as well. Nobody is
> > willing to go deep enough to the point where it becomes clear
> > that a "perfect" solution would only be possible by making
> fundamental
> > changes to libavfilter, which are complex, risky and something
> > that would never be accepted from me, even when it would be
> > the most excellent solution. I think this is pretty clear to
> > everybody here, and trying to present this in a light as if
> > I would just be too lazy to go for it, is just despicable,
> > I'm afraid.
> >
> > I wish you could stop referring to others potential opinions
> > and get yourself as much into the subject as it is required to
> > understand the actual problem and talk for yourself.
> >
> > Because I would happily discuss alternatives
> > with you and follow your advice, no matter when it takes
> > a little more effort - as long as it will still be possible
> > to handle all cases like with the current patchset.
> > But I mean substantial and detailed advice based on an
> > understanding of the problems, not the kind of "no, that's
> > bad, I don't believe you that it couldn't be done like I
> > think it's gotta be".
> >
> > I will happily, gladly and friendly work and converse with
> > anybody who would be so kind to leave one's peripheral
> > spectator position and get down with me to the core
> > problem and discuss potential solutions.
> 
> They can not admit they have zero understanding why and how code
> works
> Instead they propose some nonsense that hardly can be implemented.

Nobody has actually proposed anything. I wish somebody had.

"No, not like this, I don't care whether and how it can be 
done otherwise" - is not a proposal.

sw

_______________________________________________
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 2/4] doc/developer.texi: extend the argument for submitting patches

[Anton Khirnov]

Quoting Soft Works (2022-11-14 16:13:29)
> > I did read your document, and my takeaway message from it is "doing
> > it
> > properly is too hard". As long as that continues to be your position,
> > you might as well not bother.
> 
> This is ridiculous, and you know that. Or at least you would know
> if you would have really tried to understand the problem.
> 
> And that unfortunately applies to some others as well. Nobody is 
> willing to go deep enough to the point where it becomes clear
> that a "perfect" solution would only be possible by making fundamental
> changes to libavfilter, which are complex, risky and something
> that would never be accepted from me, even when it would be 
> the most excellent solution.

Stop with the drama, please. You are not a persecuted misunderstood
genius. Nobody here has a personal grudge against you. The reason
people, including me, are objecting to your patches is that they are not
fundamental enough. You want to redo the subtitle API in a major way,
but keep it saddled with legacy hacks right from the start. We have
enough of those already to know we don't want any more.

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

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

Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Anton Khirnov
> Sent: Monday, November 14, 2022 5:14 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> Quoting Soft Works (2022-11-14 16:13:29)
> > > I did read your document, and my takeaway message from it is
> "doing
> > > it
> > > properly is too hard". As long as that continues to be your
> position,
> > > you might as well not bother.
> >
> > This is ridiculous, and you know that. Or at least you would know
> > if you would have really tried to understand the problem.
> >
> > And that unfortunately applies to some others as well. Nobody is
> > willing to go deep enough to the point where it becomes clear
> > that a "perfect" solution would only be possible by making
> fundamental
> > changes to libavfilter, which are complex, risky and something
> > that would never be accepted from me, even when it would be
> > the most excellent solution.
> 
> Stop with the drama, please. You are not a persecuted misunderstood
> genius. Nobody here has a personal grudge against you. The reason
> people, including me, are objecting to your patches is that they are
> not
> fundamental enough. You want to redo the subtitle API in a major way,
> but keep it saddled with legacy hacks right from the start. We have
> enough of those already to know we don't want any more.

This is so disgusting!

Why can't you just point at those "legacy hacks" and tell how you 
want to have it done instead?

"not fundamental enough"?

Where why and how? 
And why do you keep bullshitting me with such nonsense statements?

What are your points? Which are your objections? Please show the 
code that you think is wrong and say how it should be done instead.

Thanks,
softworkz





_______________________________________________
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 2/4] doc/developer.texi: extend the argument for submitting patches

[Nicolas George]

Soft Works (12022-11-14):
> What are your points? Which are your objections? Please show the 
> code that you think is wrong and say how it should be done instead.

For the record, I have, multiple times.

-- 
  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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Monday, November 14, 2022 5:40 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> Soft Works (12022-11-14):
> > What are your points? Which are your objections? Please show the
> > code that you think is wrong and say how it should be done instead.
> 
> For the record, I have, multiple times.

You’ve been destructive from the very first moment when you realized 
that I was going to do something that you had been planning for a 
long time.
You haven't missed a single occasion to discredit me or my work, 
keeping it vague just like Anton does right now, to keep things at 
a level where credibility weighs - instead than a technical facts.

Ah, wait - there's one occasion where you never jumped on, never 
mentioned, talked about or objected: 

The separate subtitle timing fields. You know exactly why I have
them and why these are needed, but you would rather bite your
tongue than saying it, and so you kept quiet each time when others
were criticizing it.

Now you'll have to say that I'm wrong. 
I'm curious how you'll say it.

PS: I'm sorry that I got in your way, I understood that much 
    later only. It was just that I needed this functionality,
    not that I would have had a choice.

Thanks,
softworkz
_______________________________________________
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 2/4] doc/developer.texi: extend the argument for submitting patches

[Nicolas George]

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

Soft Works (12022-11-14):
> You’ve been destructive from the very first moment when you realized 
> that I was going to do something that you had been planning for a 
> long time.

I would have been very happy if you had worked on doing properly, or at
least in a way compatible with doing it properly. This is exactly what
Anton says.

I have not read the rest of your message, since it is built on a lie.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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 2/4] doc/developer.texi: extend the argument for submitting patches

[Michael Niedermayer]

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

On Mon, Nov 14, 2022 at 05:13:40PM +0100, Anton Khirnov wrote:
> Quoting Soft Works (2022-11-14 16:13:29)
> > > I did read your document, and my takeaway message from it is "doing
> > > it
> > > properly is too hard". As long as that continues to be your position,
> > > you might as well not bother.
> > 
> > This is ridiculous, and you know that. Or at least you would know
> > if you would have really tried to understand the problem.
> > 
> > And that unfortunately applies to some others as well. Nobody is 
> > willing to go deep enough to the point where it becomes clear
> > that a "perfect" solution would only be possible by making fundamental
> > changes to libavfilter, which are complex, risky and something
> > that would never be accepted from me, even when it would be 
> > the most excellent solution.
> 
> Stop with the drama, please. You are not a persecuted misunderstood
> genius. Nobody here has a personal grudge against you. The reason
> people, including me, are objecting to your patches is that they are not
> fundamental enough. You want to redo the subtitle API in a major way,
> but keep it saddled with legacy hacks right from the start. We have
> enough of those already to know we don't want any more.

Maybe people should take a step back and together discuss with softworks
what changes need to be done.

This thread is a bit odd becasue from reading just it its very clear there
are objections but what exactly needs to be done to move this forward is
not so clear (to me at least).

I think a patch review should result in a clear list of things that need
to be done.
Then these things can be gone through one by one. What can be done what not
where there is consensus, where not and why ...

If a request to a fundamental redesign is there then thats what it is
and maybe noone will do it but IMHO it should be clear so everyone understands
what is requested

As it is, this thread simply makes me sad because its deadlocked, there is
some will and effort on one side and that isnt directed into anything that
goes into the ffmpeg codebase ...

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.

[-- 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 2/4] doc/developer.texi: extend the argument for submitting patches

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Michael Niedermayer
> Sent: Monday, November 14, 2022 11:06 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend
> the argument for submitting patches
> 
> On Mon, Nov 14, 2022 at 05:13:40PM +0100, Anton Khirnov wrote:
> > Quoting Soft Works (2022-11-14 16:13:29)
> > > > I did read your document, and my takeaway message from it is
> "doing
> > > > it
> > > > properly is too hard". As long as that continues to be your
> position,
> > > > you might as well not bother.
> > >
> > > This is ridiculous, and you know that. Or at least you would know
> > > if you would have really tried to understand the problem.
> > >
> > > And that unfortunately applies to some others as well. Nobody is
> > > willing to go deep enough to the point where it becomes clear
> > > that a "perfect" solution would only be possible by making
> fundamental
> > > changes to libavfilter, which are complex, risky and something
> > > that would never be accepted from me, even when it would be
> > > the most excellent solution.
> >
> > Stop with the drama, please. You are not a persecuted misunderstood
> > genius. Nobody here has a personal grudge against you. The reason
> > people, including me, are objecting to your patches is that they
> are not
> > fundamental enough. You want to redo the subtitle API in a major
> way,
> > but keep it saddled with legacy hacks right from the start. We have
> > enough of those already to know we don't want any more.
> 
> Maybe people should take a step back and together discuss with
> softworks
> what changes need to be done.
> 
> This thread is a bit odd becasue from reading just it its very clear
> there
> are objections but what exactly needs to be done to move this forward
> is
> not so clear (to me at least).

To me neither. Until today.

> I think a patch review should result in a clear list of things that
> need
> to be done.
> Then these things can be gone through one by one. What can be done
> what not
> where there is consensus, where not and why ...
> 
> If a request to a fundamental redesign is there then thats what it is
> and maybe noone will do it but IMHO it should be clear so everyone
> understands
> what is requested
> 
> As it is, this thread simply makes me sad because its deadlocked,
> there is
> some will and effort on one side and that isnt directed into anything
> that
> goes into the ffmpeg codebase ...

I had a friendly chat with Anton on IRC about it. Bottom line is that
he insists that I re-work libavfilter filtering from the ground up to
support non-monotonous pts values in graph processing.

The reason is that the single time_64t field that I want to add as a member
to AVFrame would not be acceptable because it would make timestamp handling
"too messy".

Other objections haven't been made. I asked multiple times whether he
would be serious about this, demanding me to take on a possibly multi-
month work for the reason that having a single additional field in 
AVFrame would be messy, which he confirmed. 

I said it would be a huge amount of work and too much for me to take.
He doubted, saying it can't be that much, I asked what he would expect
me to change and how:

Nov 14 19:08:02 <elenril>	i can't say what to change exactly without actually doing it
Nov 14 19:08:22 <elenril>	i didn't write that code, I only have a very rought idea what it does

Full transcript on request.


I got no more words. Except about the irony that reveals 
when looking at the subject and who wrote it.

Thanks, Michael!

softworkz






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