[FFmpeg-user] Towards better trims & concatenations

[Jim DeLaHunt]

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