[FFmpeg-devel] Politics

[Daniel Cantarín]

 >
 > As mentioned already, I have an offer to make. It might not be exactly
 > what you want, but it's all you can get.
 >
 > Everybody will need to make up his mind and decide whether the benefits
 > will outweigh the drawback from one's own point of view - or not.
 >


I don't feel I have a voice here in the same way other devs do: I don't
even have a week here, it would be a joke speaking as if I were at the
same level that people with 10+ years of experience in the community.
So let me be clear: I'm not at the same level, my words can't be valued
the same as other people here.

Also, I'm very doubtful of how to express myself here, because when I
naively tried to intervene in the patch debate I later felt all I achieved
was to ignite old grudges between very tired people that was dealing
with this patch for months. For moments, I feel I should just shut my
mouth and let the thing be, without kinda embarrasing myself and
unintendly triggering others. It's very awkward and sad.

Yet, I believe I can note some common sense and experience points
from my perspective, even without being sure about its value. My
hope is to note something perhaps other people does not realize.
I've done it before, but I see other devs involved in this thread, and
so I believe doing it again is in order. Specially if this thread is the
final frontier between accepting or rejecting the patch. So, it's just a
testimony from my experience, to be noted in the thread.

I absolutelly love the use cases implemented by this patch. It's been
years since there's people wanting this, me included, and specially
the live streaming people will benefit a lot from it.

Live streaming has problems that file handling does not. Timings are a
curse, you can't probe just like that so your setup needs always extra
parameters and filters, there's no start and finish in the same sense
as it happens with files, there's the sparseness problem (which is a big
deal for filters), and so on. Yet, so often people evaluate live streaming
problems with a file mindset, that most of the time this problems are
understood as some kind of "border cases" with no merit for "a hack";
where that hack is usually "something I can do right now without
breaking anything else".

All of this stuff can be done using other tools when it comes to files.
But real time? Live? Forget it: that's another deal, and this patch does
the job. And not only that: I've tested it, and it works amazingly well.
It's much better than what I ever had expected to find. I was looking
for useful bits and pieces of code, ideas even, that I could use to
solve live streaming problems. What I've found feels the same as
when any of us found ffmpeg for the first time when looking for a
tool: "this is amazing, it does everything!"

Of course, this does not means an even more deep refactor isn't
actually needed. However, we live streaming people keep waiting for
that use cases for years (there can be found discussions a decade
old), while the "proper way to do it" never happens.

That sounds rude to the people involved. But my intention is not to be
rude, but to express how it feels to be on the other side of the
development cycle. I said one day "I'll do it myself", then I found the
thing beyond me: I don't have the time to do all that work, to learn all
that knowledge and articulate it in a way other people with much
more knowledge than I have could accept. It's a lot. And I believe I
can speak for lots of us when I say to have keeped our code private
knowing it will never be accepted mainline as it is, because it does
not refactors ffmpeg or libavfilter and just solves something quickly.

softworkz is now clearly tired of this patchset, and so are the devs
discussing it with him. When I didn't knew that this thing had been
going on for six months, I was hoping to be able to somehow get in
the middle of the debate and try to unblock it. I was hoping to help
coding here and there, testing this and that, comparing ideas...
I was actually beginning to analize the code, in order to see if I was
able to remove the controversial subtitle_pts property. I realize now
I was sadly too late to the party.

Yet, here we are, with code that actually do the job, and even
performs pretty well.

With all this in mind, here are my feelings about this:

   - I could not care less about subtitle_pts. I know it's questionable,
     but screw it: its also questionable to wait for years with live
     streams problems as some kind of second class citizens. This
     property and all around this patchset (the good and the bad) are
     but accidents of the project's history, and those will keep on
     happening no matter what. We CAN fix subtitle_pts later,
     without having to wait forever for the concensual
     implementation in order to have the use cases implemented.
     That's not a crime: not against "good programing", and neither
     against ffmpeg.

   - I don't think subtitle_pts is the real problem here. I think there
     are grudges between devs, and things going on I don't fully
     understand. Sadly, as I have no more time to participate in
     this development (given that everybody's tired, and a call for
     a vote seems imminent), I can't also read the 6 months of
     debates to gain a better understanding before expressing
     an opinion. Sorry devs, you deserve better than this
     ignorance of mine. Perhaps somebody could make a list of
     relevant links to discussions before the vote?

   - I'm more worried about not breaking anything. I saw some
     notes from Mr. Niedermayer, and could reproduce myself some
     problems. However, softworkz seems to be willing to fix that
     kind of issues, so doesn't seem to be a big deal. I see he
     actually posted a new version of his patchset minutes ago,
     so that's great. The point is, I would find this kind of things
     actually blockers, and not subtitle_pts.

   - If this patchset get rejected, I believe a proper consensual
     design is in order. Consensual between the relevant devs,
     of course. But so far, I don't see it linked in the debates.
     Most likely it is somewhere and I just didn't saw it. But my
     point is that rejecting this kind of works should be done
     with a proper explanation, and the acceptable design
     should be part of that explanation. With that guidelines,
     perhaps others like me could progressively implement the
     thing. But, to be honest, rejecting this without a clear and
     consise designs counterpart (and not only sparse ideas, as
     we all have some of those), would be frankly rude to both
     the people who did the job and the people who wants the
     use cases: because this works, and it's right here.

   - I would also note that perhaps tiredness would be solved
     by resting, and not either by an ultimatum or a complete
     dismissal of the propossal. I would be very happy to
     collaborate (as I could, which I fear may not be much) if
     you people happen to just find the energy to take a look
     at the thing again without so much... err... "painful
     exchanges" (I speak spanish, sorry, my english is limited).
     Finally having this use cases should be something to
     celebrate, and not something depressing. I know, this is
     some kinda hippie thinking of mine. But I feel it's worth
     the note anyways.


Just my 2 cents.
Thanks,
Daniel.