[FFmpeg-devel] [PATCH 1/2] doc/plans: add a file to list approved projects

[FFmpeg-devel] [PATCH 1/2] doc/plans: add a file to list approved projects

[Nicolas George]

This file makes it easier to engage in ambitious and/or long-term
projects for enhancing FFmpeg by removing earlier the uncertainty of
acceptance on principle.

Signed-off-by: Nicolas George <george@nsup.org>
---
 doc/plans.md | 6 ++++++
 1 file changed, 6 insertions(+)
 create mode 100644 doc/plans.md


Reference to discussion:

https://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300193.html


diff --git a/doc/plans.md b/doc/plans.md
new file mode 100644
index 0000000000..0d7336e8b4
--- /dev/null
+++ b/doc/plans.md
@@ -0,0 +1,6 @@
+# Plans for future developments
+
+Projects listed below have been approved by the FFmpeg developers community,
+and their author(s) can invest time and effort implementing them. The
+resulting patches will be subject to technical review like any other
+patches, but they can no longer be rejected on principle.
-- 
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/2] doc/plans: add AVWriter

[Nicolas George]

Signed-off-by: Nicolas George <george@nsup.org>
---
 doc/plans.md | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/doc/plans.md b/doc/plans.md
index 0d7336e8b4..d96328aabc 100644
--- a/doc/plans.md
+++ b/doc/plans.md
@@ -4,3 +4,41 @@ Projects listed below have been approved by the FFmpeg developers community,
 and their author(s) can invest time and effort implementing them. The
 resulting patches will be subject to technical review like any other
 patches, but they can no longer be rejected on principle.
+
+## AVWriter: a unified API for building and returning strings
+
+**Author:** Nicolas George
+
+An API that can be used everywhere a function needs to return a string, or
+really an arbitrary buffer of bytes, and everywhere code needs to build a
+string from parts. It needs to be fast and lightweight enough to be used in
+tight loops, like once per frame, without limiting the size of the returned
+string when needed. It should make checking for overflows and possible
+memory allocation errors simple. It should easily be compatible with other
+uses of strings, especially standard C buffers.
+
+AVWriter is an enhancement on the AVBPrint API; AVBPrint already achieves
+some of these objectives but not all.
+
+Like other FFmpeg components, AVWriter is designed as a limited
+object-oriented virtual class / interface with multiple implementations. To
+let applications define their own writers and allocate structures on the
+stack or as part of their data, structures contain their own size and the
+code only accesses fields that exist.
+
+Some functions are specific to a particular implementation of AVWriter; for
+example getting a mallocated buffer from a dynamic AVWriter. It is the
+responsibility of the caller to use the right type, which will usually be
+enforced by an assert.
+
+**Future plans where AVWriter will help:**
+
+A universal API to return the string associated with an elementary type
+(pixel format, channel layout, etc.) and to serialize complex types,
+especially side data.
+
+A system to store error messages in contexts instead of logging them, to
+make it easier for applications, especially GUI, to display them cleanly.
+
+An extension to `avwriter_printf()` to use any serializable object directly
+from the format string.
-- 
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/2] doc/plans: add AVWriter

[Paul B Mahol]

Why reinventing yet another  ad-hoc thing.
_______________________________________________
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 1/2] doc/plans: add a file to list approved projects

[Anton Khirnov]

I am very strongly against this.

You keep trying to preemptively shield your code from criticism that
you're unable to deal with, rather than actually build consensus. Stop
that, it will lead to nothing good for you or the project.

You also keep insinuating that I'm "blocking" your precious avwriter.
I am not blocking anything. You asked for opinions on it, I gave you my
personal opinion. I even gave suggestions on how to proceed with it.
Rather than engage with them, you started ranting at me, as you always
do when someone disagrees with you, followed by melodramatic theatrics.
You're going to have a bad time around here until you learn how to deal
with disagreements constructively.

-- 
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/2] doc/plans: add AVWriter

[Jean-Baptiste Kempf]

On Wed, 17 Aug 2022, at 23:49, Nicolas George wrote:
> +An API that can be used everywhere a function needs to return a 
> string, or
> +really an arbitrary buffer of bytes, and everywhere code needs to 
> build a
> +string from parts. It needs to be fast and lightweight enough to be 
> used in
> +tight loops, like once per frame, without limiting the size of the 

How is that different from open_memstream?
-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/2] doc/plans: add a file to list approved projects

[Jean-Baptiste Kempf]

n Wed, 17 Aug 2022, at 23:49, Nicolas George wrote:
>  doc/plans.md | 6 ++++++
>  1 file changed, 6 insertions(+)

Those plans files become outdated very quickly and are often not maintained.
Or they become infinite unicorn-wishlist things.
Or they become a blocking task for the project.

I have NO opinion on AVWriter, but just show the API and documentation before implementing it.
Once people agree on the API need and form, just implement it, I don't see the need for a plans.md file for that.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/2] doc/plans: add a file to list approved projects

[Nicolas George]

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

Jean-Baptiste Kempf (12022-08-18):
> Those plans files become outdated very quickly and are often not maintained.
> Or they become infinite unicorn-wishlist things.
> Or they become a blocking task for the project.

Or I might be hit by a bus. Or I might decide to try heroin and overdose
because it was cut with fentanyl. Or… If we always focus on the
worst-case scenario, we never go forward. Worst case scenario here? It
becomes blocking, we discuss to remove it, wasted a little time. Less
worst case scenario: it becomes an unicorn-wishlist, somebody finds
something doable in it and starts contributing to the project.

Anyway…

> I have NO opinion on AVWriter, but just show the API and documentation before implementing it.
> Once people agree on the API need and form, just implement it, I don't see the need for a plans.md file for that.

Hum, I like that idea. For AVWriter, much of the API itself is macros
and inline functions, but it is a minor issue that I can work around.
“Once people agree” means applying it; I hope nobody will bikeshed the
idea of pushing a .h file with no implementation

I insist that I am not doing this to “preemptively shield [my] code from
criticism”, like Anton disingenuously said. If that was the case, I
would not have written “The resulting patches will be subject to
technical review like any other patches”.

What I am trying to do is to find a way to discuss broad strokes before
investing time in details, because without it the project is condemned
to immobility because of naysayers. It is not specific to AVWriter, it
is not specific to me.

If we had that procedure at the time the new channel layout API was
implemented, then we could have discussed it to take into account the
needs of users, filters, advanced formats and devices and now have a
great channel layout API. Instead, we had to salvage one that was not
designed with these considerations in mind, but because it was a series
of 279 patches, nobody dared send it back for complete redesign as we
should have. I find this borderline dishonest.

Depending on the responses to this mail, I will send a patch to add
avwriter.h and doc/avwriter.md and start the actual discussion.

Regards,

-- 
  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 1/2] doc/plans: add a file to list approved projects

[Jean-Baptiste Kempf]

On Fri, 19 Aug 2022, at 18:01, Nicolas George wrote:
> Or I might be hit by a bus. Or I might decide to try heroin and overdose
> because it was cut with fentanyl. Or… If we always focus on the

Exactly. This is called the bus-factor and is important in all volunteers open source communities.

Which is why the norm is "show us the code" and not wait for future things.

Because as we are volunteers working when we can, shit happens in real life, so you cannot block a project with future plans until they are done. Because maybe it's a 6months time or a 2 years time, or never. And then you never ship your software.
For the same reason, something "ready to merge, not optimal but better than the current state" is Always better than "I'll do an optimal solution in 3 years". Especially since the first solution does not block the latter one.

Therefore, I don't think those plans documents are useful: "show us the code!".

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/2] doc/plans: add a file to list approved projects

[Nicolas George]

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

Jean-Baptiste Kempf (12022-08-19):
> Exactly. This is called the bus-factor and is important in all
> volunteers open source communities.
> 
> Which is why the norm is "show us the code" and not wait for future
> things.
> 
> Because as we are volunteers working when we can, shit happens in real
> life, so you cannot block a project with future plans until they are
> done. Because maybe it's a 6months time or a 2 years time, or never.
> And then you never ship your software.
> For the same reason, something "ready to merge, not optimal but better
> than the current state" is Always better than "I'll do an optimal
> solution in 3 years". Especially since the first solution does not
> block the latter one.

I do not agree with this absolutist statement. There is a balance to
find between quick-and-dirty solutions that make further enhancements
harder and vague plans on the comet.

Anyway, this does not apply to AVWriter since the only things it is
blocking are my own projects. Also, AVWriter is in greatest part done.

> Therefore, I don't think those plans documents are useful: "show us
> the code!".

Try this with your plumber: “Show me my shower fixed and I'll pay you if
I'm satisfied.” It does not work that way, you have to sign a sales
quote before the plumber gets to work. This is the kind of mechanism I
want to find for FFmpeg.

I have asked you to clarify your previous suggestion:

Are you suggesting that I propose the headers and documentation for
AVWriter, that we discuss it and hopefully push it before investing more
time in the implementation?

Please answer.

Regards,

-- 
  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 1/2] doc/plans: add a file to list approved projects

[Jean-Baptiste Kempf]

On Mon, 22 Aug 2022, at 14:43, Nicolas George wrote:
>> Therefore, I don't think those plans documents are useful: "show us
>> the code!".
>
> Try this with your plumber: “Show me my shower fixed and I'll pay you if
> I'm satisfied.” It does not work that way, you have to sign a sales

This is a contract, with paid money and clear objectives.

> quote before the plumber gets to work. This is the kind of mechanism I
> want to find for FFmpeg.

FFmpeg is a volunteer open source project, not a contracting or plumbing initiative.
If the SoW is not done, the money is not paid. This does not work for open source communities.

> Are you suggesting that I propose the headers and documentation for
> AVWriter, that we discuss it and hopefully push it before investing more
> time in the implementation?

You provide a full header and documentation, and then get it discussed.
When there is a consensus for approval of the headers, then, you can code the core of it that matches the headers.
That avoids the "I spent time for nothing" issue.


-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/2] doc/plans: add AVWriter

[Leo Izen]

On 8/18/22 13:23, Jean-Baptiste Kempf wrote:
> On Wed, 17 Aug 2022, at 23:49, Nicolas George wrote:
>> +An API that can be used everywhere a function needs to return a
>> string, or
>> +really an arbitrary buffer of bytes, and everywhere code needs to
>> build a
>> +string from parts. It needs to be fast and lightweight enough to be
>> used in
>> +tight loops, like once per frame, without limiting the size of the
> 
> How is that different from open_memstream?

I'm not sure open_memstream is available on all platforms, in particular 
I think it's missing on MinGW.

But otherwise, it looks like it, so maybe it makes more sense to just 
use a compatibility shimmy on windows?

- Leo Izen (thebombzen)
_______________________________________________
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/2] doc/plans: add AVWriter

[Nicolas George]

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

Leo Izen (12022-08-22):
> > > +An API that can be used everywhere a function needs to return a
> > > string, or
> > > +really an arbitrary buffer of bytes, and everywhere code needs to
> > > build a
> > > +string from parts. It needs to be fast and lightweight enough to be
> > > used in
> > > +tight loops, like once per frame, without limiting the size of the
> > 
> > How is that different from open_memstream?
> 
> I'm not sure open_memstream is available on all platforms, in particular I
> think it's missing on MinGW.
> 
> But otherwise, it looks like it, so maybe it makes more sense to just use a
> compatibility shimmy on windows?

open_memstream() does not even qualify for “fast and lightweight enough
to be used in tight loops”, let alone all the features AVWriter has.

Regards,

-- 
  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 1/2] doc/plans: add a file to list approved projects

[Nicolas George]

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

Jean-Baptiste Kempf (12022-08-22):
> This is a contract, with paid money and clear objectives.

> FFmpeg is a volunteer open source project, not a contracting or plumbing initiative.
> If the SoW is not done, the money is not paid. This does not work for open source communities.

I was not asking money from the project, so… you just did not understand
the simile. Too bad for you.

> You provide a full header and documentation, and then get it discussed.
> When there is a consensus for approval of the headers, then, you can code the core of it that matches the headers.
> That avoids the "I spent time for nothing" issue.

I will try that. And I will count you as support if naysayers start
whining “we don't apply headers and documentation without the code”.

Regards,

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