Re: [FFmpeg-devel] API enhancements / broken promises

[Nicolas George <george@nsup.org>]

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

Hi.

Michael Niedermayer (12022-08-17):
> 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.

Thank you and thank Stefano for your encouraging replies. With them and
the comments I had in private and/or earlier, I am beginning to feel
confident I can override the argument-less objection.

Note that I am not asking for a blank check to push anything I want. I
will of course submit the code for review and adhere to the technical
comments made to it.

And I want to insist, not just for me: this is a mechanism we need.

Right now, the only way to know if a change will be accepted is to
submit a patch series in its almost final shape. For something
ambitious, that can mean a lot of work, and if the patches are
eventually rejected, that work goes to waste. The possibility that it
happens is discouraging.

And with that discouragement, we only get low-hanging fruits, changes
that are sure to be accepted. Or we get intimidation: submit a 100+
patch series, present the project with a fait accopli, and count on the
fact that nobody will dare object in the face of the sheer amount of
work, even if the proposal is flawed at its core and would need a
complete rewrite.

The lack of a procedure to engage in something ambitious without the
risk of outright rejection is limiting the progress of FFmpeg, and it is
sad.

Maybe this simple idea would be enough, if people like it: doc/plans.md
containing more-or-less detailed plans of ambitious plans. Patches to
doc/plans.md are reviewed on the mailing list like any other patches.
But once a plan is accepted, patches that implement it cannot be
objected on principle by naysayers and bikeshedders, only on technical
matters.

I will try to propose a small patch for that, to get the conversation
going.

> Rather i wanted to comment on
> XML and JSON and FFmpeg.

Thanks.

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

Replacing our use of libxml2 was my reason for starting to think and
then write a XML parser, for exactly the reasons we describe, plus the
fact that libxml2 is not a system library. We need XML for at least
MPEG-DASH and IMF, which are unambiguously part of FFmpeg's purpose.

And the objective of the "limited" parser would be to be able to digest
DASH manifests found in the wild.

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

Thanks again. It is exactly my concern. If we collectively decide we do
not want some project, I can work on something else. But the uncertainty
is killing my motivation.

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