On 2024-01-06 19:24, Mark Filipak wrote:
On 1/6/24 17:20, Jim DeLaHunt wrote:
But what I am missing here is a concise problem statement.
There are many errors.
In that case you should file many bug reports. Each report should
describe one problem. Maybe you can include multiple test cases to
reproduce that one problem.
If you are not sure whether two test cases are demonstrating a single
problem or two problem, err on the side of filing two bug reports. Bug
tracking systems make it easier to mark one bug report as a duplicate of
(caused by the same underlying problem as) another, than to split one
report describing two problems into two bug reports.
It may be that this test methodology reveals multiple bugs, which
might be better pursued if reported separately.
How? How can they be separated?
Take one procedure for reproducing a problem. If that procedure
demonstrates multiple problems (e.g. the PTSs are wrong, and the trim
time is wrong), then treat each problem statement as a separate bug.
e.g. Bug report 1 is:
- with command line "ffmpeg <a> <b> <c>..."
- Using mother video V_M.def...
- Produces son video V_S.def...
- Observed PTS of first frame is 1
- Expected PTS of first frame is 0
and Bug report 2 is:
- with command line "ffmpeg <a> <b> <c>..."
- Using mother video V_M.def...
- Produces son video V_S.def...
- Observed trim time is 1.23 sec
- Expected trim time is 4.56 sec
The example commands you give seem to be a pretty specific set of
instructions for "how to reproduce".
It's a Windows command script that makes the clone and sons. ...it's a
systematic method to investigate the trimming procedure to determine
whether it works properly. That method mostly uses '-framecrc'. Some
use '-showinfo' and others show what happens in MPV during play.
It's great that you have a systematic method to investigate the trimming
procedure. Don't put it in a bug report _as a systematic method_. Write
instructions which use the method to produce a specific result. Put
those instructions in the bug report.
One systematic method might discover multiple problems, and lead to
multiple bug reports. There is nothing wrong with that.
Also, what does "h:\BDMV\STREAM\00305.m2ts" refer to?
That's the mother video from which the clone and sons are made.
Is that a standard video which I can get a copy of somewhere?
Nope.
That presents an obstacle to getting your reports acted on. It is
important that your report let someone else be able to reproduce exactly
what you are seeing. If the mother video is what your instructions call
for, but no-one else can get a copy of the mother video, then no-one
else will be able to reproduce your bug.
What is the smallest, shortest, simplest video which will demonstrate
these problems?
Can you use a video which is generated by another FFmpeg command, e.g.
containing a test pattern?
Can you use a video which is already in the FFmpeg test suite?
Can you use a standard video which anyone can get a copy of, easily?
All those would be better than this unreachable mother video on which
your instructions now rely.
Coming up with good bug reports can be gruelling, but without them, it
is hard to get bugs fixed. Good luck!
—Jim DeLaHunt
_______________________________________________
ffmpeg-user mailing list
[email protected]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
