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