[Libav-user] Encoding with variable frame rate

[Robert Krüger]

On Wed, May 22, 2013 at 6:53 PM, Brad O'Hearne
<brado at bighillsoftware.com> wrote:
> On May 22, 2013, at 9:02 AM, Robert Krüger <krueger at lesspain.de> wrote:
>
>> After all, most of the work is
>> done by people in their spare time and I haven't found many developers
>> who enjoy writing documentation (no matter how important docs are, I
>> think we all agree on that).
>
> The problem, Robert, is bigger than just finding someone to document FFmpeg, getting volunteers, or motivating people. The bigger problem is that producing good documentation and discussion of a particular technical domain requires an inquisitive and exhaustive approach, willing to drill down to details, and ask questions which put design decisions and potentially either weaknesses or needs in the spotlight. The tone of this mailing list just doesn't have a thick-enough skin for that. The discourse on this list consistently demonstrates an inability to treat machinery as machinery, nuts and bolts, and instead quickly degenerates into personal attacks when a good answer isn't quickly obvious, or when someone refuses to consider that there may be a problem in some part of FFmpeg which someone has adopted as their turf.
>
> There is absolutely zero question in my mind, from the several projects I've had to solve with FFmpeg, discussions with others, numerous blog posts which lament the undocumented and unknown nature of various parts of FFmpeg, that save bug-fixing, adding a single additional line of code to FFmpeg pales in importance to thoroughly documenting the API with adequate discussion, documenting use, and producing some examples that address real-world use-cases, not "let's just generate some audio samples or a sample images for video", which avoids the real problems of building a robust app.
>
> I love writing, have written technical documentation and technical articles, and had several book deals offered. Given my frustrations and time loss due to a lack of documentation, if it were mine to script, I'd document the whole thing myself, and produce either a book or user guide on this. But given both my personal experiences thus far and observing others as well on this mailing list, I won't go anywhere near it. Too much shoot-the-messenger on this mailing list. Too much condescension if you ask a question without demonstrating deep expertise of a particular concept. Too much passion for sniping people because they don't just by default know something. That, Robert, is the primary problem --  with people making personal attacks, and an inability to drill into minutia with patience, people who would otherwise offer their services are driven away.
>
> I'm not just referring to my own experiences here, I've been on this mailing list a year and a half, and I've watched it with others, too. It's a shame. Entirely unnecessary.
>
> Brad

my last reply to that, I promise.

For the record, in (I think) about 5 years on this list, I would say
that in about 70% of the occasions I properly documented a problem
(reproducible test case or comparable) I got help (for free).

Have there been occasions when I thought someone could have been more
polite? Yes, but that's people and that happens everywhere. It's not
ffmpeg policy to drive people away AFAICS. Especially in the past two
years IMHO the tone has changed quite a bit (not claiming it is
perfect).

Have there been occasions where I disagreed with things developers
have decided to do or been frustrated about it? Yes, but I am not
really a contributor so the people doing the work have their decision
making process and that's what I have to live with or go find another
project or product to get the job done.

Do I have my own opinion what ffmpeg should have their priorities set
to? Sure, but hey, for every person actually making something happen
in this project, there are probably at least a hundred out there
thinking they know how things should be done so I bite my tongue most
of the time. It's not my company/project and the way to get a say in
these things is contributing, it's as simple as that.

Has sponsoring someone to get a problem solved worked? Yes. Maybe it
is something you can consider if you're stuck in a situation with
ffmpeg for a paid job. I guess you are still going to pay less than
you would have to, if you were licensing a commercial library by
Mainconcept et al. If you think betting on that to work is too risky
you _have_ to get a commercial alternative.

Has complaining about the way things were run in this project by a
non-contributor ever worked making anything better? Not that I know of
and I swear, this is just meant as advice/observation not an attempt
to attack or to diss you.

Cheers and peace,

Robert