[FFmpeg-user] Levels and Primaries

Robert Krüger krueger at lesspain.de
Thu Feb 13 13:56:39 CET 2014


On Thu, Feb 13, 2014 at 11:26 AM, Phil Rhodes
<phil_rhodes at rocketmail.com> wrote:
>>  it would be worth a try if a bug report proving that swscale
>> produced incorrect colors or inferior scaling quality for a certain
>> conversion (which may very well be the case) with a reproducible test
>> case would get ignored.
>
> As you probably know, there can be quite a lot of work in producing such a test case.

Yes, it is indeed.

>
> Recent comments on this list suggest strongly to me that information about behavioural anomalies in ffmpeg are not particularly welcome. I appreciate the issue - it isn't nice to have one's work criticised - but that's part of being a software engineer.

>From my own experience as someone who has submitted a number of bug
reports here, I think it would be fair to say it depends on the
individual case. I've had bug reports that resulted in an immediate
fix (mostly the ones with an easy to reproduce test case) and others
that haven't been touched in months/years just because nobody cared
but since nobody is paid for this, I consider this aspect of using OSS
a fair deal, no matter how serious I think the individual problem is.
Being a software developer myself, however, I do understand that in
many cases an hour spent in the problem definition simply saves a
multiple in hours bug fixing and since there are far fewer people
available for fixing bugs than there are people reporting them. Having
said that, I have also had and observed cases where I thought it
should have been made easier for the bug reporter without it costing
an ffmpeg developer significant time.

>
> Personally I would be concerned that I would simply be asked for more and more information until we got to something I couldn't provide (I still have only the haziest idea what a "gdb backtrace" is). I think this sort of thing is used as an excuse to ignore the problem. Not everyone is a software engineer (nor should they be) and the development team need to be willing to do some of the legwork themselves. It's part of the job.

I agree there is room for improvement in this area but again, my
experience in the last few years was that it depends on the case and
maybe person. In many cases I perceived it rather as "I will only
spend time on your report if you make it convenient/less
time-consuming to diagnose/reproduce the issue" rather than an excuse.
I think for free support that is fair. I won't criticize an ffmpeg
developer who wrote support for mov files until it worked for their
use cases, if I run into a case where it is unusable for certain some
broadcast formats (case from real life). If the developer simply does
not care about that I can make them care by offering to pay them (or
someone else) to do the work (if I cannot fix it myself with
reasonable effort). Of course, when dealing with people there are
occasions where one runs into, let's say, attitude
differences/problems.


More information about the ffmpeg-user mailing list