Mark:

On 2024-02-19 15:04, Mark Filipak wrote:
On 19/02/2024 16.45, Jim DeLaHunt wrote:
Mark:

On 2024-02-19 13:23, Mark Filipak wrote:

Best to create minimal reproducible usecase with all required files to
reproduce it, upload it somewhere and link it on ffmpeg trac site.

I did that. It didn't get any interest.
Really, you "did that"? I do not recall that you have created a (1) minimal,

Yes I did. ...

OK, it looks like we move on to the "what is a minimal, reproducible usecase" tutorial.

…If I recall correctly, each of the two segments was a couple hundred bytes. The two sources total 27 GB and are copyrighted.

If the sources are 27GB, then that is not really minimal.  Find alternate sources which are much smaller, and still demonstrate the problem.  Is that easy?  Often, no. But _someone_ has to do that in order to fix the bug. If the bug reporter does not do that work, then they are expecting the developer to do it.

And if the sources are copyrighted, that may be an obstacle to sharing with others. That means the usecase is not reproducible.


(2) reproducible

I don't know what makes something reproducible. Do you mean I should run the test twice?

Reproducible means both that you can make the behaviour happen on demand — it is not intermittent — and that others can follow your instructions to make it happen on demand. What is lacking in the current case is a set of steps which someone else can follow, with their own copy of ffmpeg on their own computer, to make the behaviour happen.


(3) usecase with

Is that the command lines? Is that a description? I've certainly done that.

It is a set of specific instructions for how to reproduce the behaviour, and a description of what behaviour you observe and believe is incorrect, and a description of what the correct behaviour is that you expect.

Here is a pretty good tutorial: "Bug Writing Guidelines", by the Bugzilla team <https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html>. But search for "how to write a good bug report", and you will find any number of guides.

The exact commands lines, which refer to the minimal input files, and are reproducible by others, are certainly part of a good report. Parts of the output from the command might be relevant, parts will not be. Often it's good to include the complete output from the command anyway.


(4) all required files to reproduce it, and

Like I wrote, the two sources total 27 GB and are copyrighted.

Then you have the challenge of finding other, smaller sources which demonstrate the problem and which you can share.


(5) said files uploaded somewhere accessible, and

I did not do that. What I did was attach the framecrc files to my posting.

And without the files to reproduce it, your report is probably not reproducible.


(6) written an FFmepg Trac report

I did not do that. In all projects in which I've participated, there are design reviews prior to commitment.

Filing a bug report is not the same as committing changes to the program's code.  In all the projects in which you've participated, did you have to go through a design review in order to report, "this thing ain't working right"?

For the FFmpeg project, the instructions on reporting bugs is at <https://ffmpeg.org/bugreports.html>.  It says, "Once you have gathered this information, you can submit a report to the FFmpeg bug tracker." No design review required.


I've asked for help and have gotten no response.

I think you have gotten lots of responses. Many were of the form, you need to do (1) (2) (3) (4) (5) (6) to take the next step. I understand that you probably don't want that response. But you have gotten it.

Yes, it is tedious. But at least the pay (for this volunteer labour) is lousy.

     —Jim DeLaHunt
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to