[Libav-user] Encoding with variable frame rate

[Paul B Mahol]

On 5/22/13, Robert Krueger <krueger at lesspain.de> wrote:
> 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 Krueger <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.

About what you are refering to?

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

There is place where everyone can open new bug/feature request report.

>
> 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
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>