[FFmpeg-devel] API enhancements / broken promises

[Michael Niedermayer]

Hi

On Mon, Aug 15, 2022 at 06:47:34PM +0200, Nicolas George wrote:
> Hi.
> 
> Over the years, I have promised quite a few enhancement to FFmpeg's API,
> some of them connecting to user interface: stored error messages instead
> of just logging, universal serialization of objects into various formats
> (JSON, XML, etc.), a way to exfiltrate data from filters and other
> components, better options parsing avoiding multiple levels of escaping,
> asynchronous interface for protocols and later formats, avoiding global
> state including a more reliable control of allowed components, and I
> might be forgetting a few of them.
> 
> I will not be able to make good on these promises, mostly for no fault
> of mine.
> 
> I have detailed plans on how to achieve any of these goals; I would not
> have proposed otherwise. I can explain them if somebody is interested.
> 
> A lot of these projects require a good string API. Unfortunately, my
> proposal for that is being blocked by a member of the tech committee
> who, by their own admission, almost never deals with strings and never
> used BPrint, and whose arguments amount to “I am not convinced we need
> it”, and the others members of the committee do not care enough to
> override them.

As i said elsewhere i think replacing BPrint by AVWriter is a good idea.
and also that the TC does to the best of my knowledge have no power in
this case. We first need some patch and disagreement the TC could vote
on. ATM there is no public disagreement on a patch i think

But i didnt hit reply to repeat that. Rather i wanted to comment on
XML and JSON and FFmpeg.

I saw on IRC this (authors removed because their names are not important here,
iam really replying to the statments not the people)
A>       but I, IMVHO, dont think this project should get a XML parser
B>      "nice and limited" XML parser sounds like all sorts of "fun"
C>      Yeah, xml/json/... parser in ffmpeg is just... no

Whats the purpose of FFmpeg ?
"A complete, cross-platform solution to record, convert and stream audio and video."
first actually i think that should be chnaged to something like this:
"A complete, cross-platform solution to your multmedia needs"
Because there are subtitles and many other things we do care about that this
misses 

Now to achieve this do we need xml and json ?
grep tells me we have 500 matches (not counting docs) for xml and almost 100
for json
Also for streaming and some cases filtering being able to serialize objects
would be useful. xml and json seem better choices than some ad-hoc format
So i would awnser the question do we need XML and JSON, with yes we live
in a world that uses XML and JSON so if we give the option to use it too
that makes it easier for others to interact.

now do we need our own implementation of it ? I dont know but we have
in almost all cases favored our native implementations when someone wrote
one. And libxml2 has had so many security issues that i think we should
at least consider replacing it.


The 2nd thing that comes to mind with "purpose of FFmpeg" is FF stands for
"Fast Forward". To move fast forward we should not lose developers because of
rather minor disagreements.
IMO if Nicolas wants to write and maintain AVWriter and a simple xml parser
(which i presume has the goal to parse the XML we would generate for 
serialization and in other places). I really think telling Nicolas "no" is 
a unwise choice. But if someone is against very basic xml or json parsers
please speak up now and here because its still better to say "no" now than
after nicolas did the work.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220817/102036c0/attachment.sig>