[FFmpeg-user] Packet corrupt on cut, notice on concat

[Jim DeLaHunt]

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