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.

The other projects require other kinds of preliminary framework APIs
equally at risk of getting blocked for the same flimsy reasons, and I am
not so fond of wasting my time as to start implementing them in these
circumstances.

I have the hubris to believe that if I am not good at micro-optimizing
code and implementing compression standards, my skills as an architect
have proved useful to the project in the past and can be useful in the
future too, that they cover an area that complements the skills of
others.

(Regarding past architecture changes, the refcounted packets system and
the send/receive libavcodec interface are sound architecture, but they
are also quite obvious, not requiring a lot of creativity. Also, I
suspect I could have avoided one level of annoying indirection on the
refcounted buffers had I had my word to say at the time.)

The first steps of all these projects are not fancy, they will not make
the code spectacularly simpler. On the other hand, I have made sure they
are unobtrusive: a pair of files for the implementation, a few examples
of where they already help a little, not 100+ patch series that have to
absolutely be applied at once and/or steps on everybody's toes. If they
happen to completely fail, we just remove them, no harm done.

But they are necessary to move forward.

Yet they are blocked.

I will not install you a jacuzzi if you do not trust my judgement as an
architect that you need proper water drainage first.

This project is dying, for lack of leadership and vision.

In fact, this project has been dying ever since we wondered how we
should change to entice the forkers back instead of wondering how the
forkers needed to change to be accepted back. As a result, we changed in
the very direction that caused the fork to die.

And due to that change, I am more and more losing interest in FFmpeg. I
will probably continue to enhance the framework of libavfilter at a
snail's pace, because at least the battles I have to lead there are not
uphill, but do not expect much more from me.

Unless there is a surge of interest from the others core developers and
it is made clear that you want to move forward towards a better API and
you trust my planning as long as the code itself is good and either
unobtrusive or really useful.

But I am not holding my breath. Fortunately, I have others projects of
my own, and I will have more time to invest into them. A lot of the
thinking I have done for FFmpeg I will be able to reuse for my own
benefit.

Which leads me to my last point: I have confirmation that my appetence
as a teacher will be starved in the near future, so if somebody is
looking for tutoring in low-level Unix/C system and network programming,
a collaboration could be greatly appreciated and mutually beneficial.

I think it is all I have to say for now.

Regards,

-- 
  Nicolas George