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

[Jim DeLaHunt]

Mark:

On 2024-02-19 17:31, Mark Filipak wrote:
> On 19/02/2024 18.49, Jim DeLaHunt wrote:
>> On 2024-02-19 15:04, Mark Filipak wrote:
>>> 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.
>
> The 27 GB sources are _not_ the problem.

The topic in my messages[1][2], to which you reply[3], is whether you 
have have "have created a (1) minimal, (2) reproducible (3) usecase with 
(4) all required files to reproduce it, and (5) said files uploaded 
somewhere accessible".

You brought up "each of the two segments" in response to my asking if 
what you created was (1) minimal. It is not clear what are these "two 
segments", and how they diff from "the two sources".  Your initial 
message[3] showed ffmpeg command lines with took one input, a file named 
"this.m2ts".

When you say "The 27 GB sources are _not_ the problem", it seems like 
you are digressing to a different topic: whether the 27 GB sources are 
structurally correct. So let's go back to the need for a minimal usecase.

What is the command which invokes ffmpeg for the minimal usecase?

What are the required files to run that command?  One "this.m2s", or 
"two sources [totalling 27 GB], or "two segments [of] a couple hundred 
bytes"?

Describe the files, as an interim step before uploading them. File 
names, for the purpose of clear discussion?  File formats? File byte counts?

> The two trims are a large problem if '-ss -to -i' is used. They are a 
> huge problem if '-i -ss -to' is used.
>
> But the two trims are not the problem if '-bsf noise' is used to trim 
> the sources. So, I used '-bsf noise'. The two trims are structurally 
> beautiful, seemingly perfect.

Your initial message[4] gave three ffmpeg invocations, each operating on 
a single input "this.m2s", each using "-bsf:v noise=". So this talk 
about "the two trims are a large problem" seems to be a different 
subject, and should be a different email thread and a different trac 
submission.

> The problem occurs after the join. The final B-frame before the ending 
> I-frame (at the join) is flagged as corrupt. Is it corrupted when cut? 
> Or is it corrupted when concatenated? Or is the complaint that it's 
> corrupt bogus? I don't know any of the answers.

OK, which "problem" are you referring to now? Do you mean, the error 
message which indicates a problem occurs after you run ffmpeg to join 
two short video files together?  That itself is a third bug subject.  
Maybe the error indicates that ffmpeg is taking perfect input files and 
making a mistake during the join. Maybe the error indicates that ffmpeg 
is doing the join operation perfectly, but that input files are 
structurally incorrect, and this is not apparent until the join 
operation reveals it.

> How can I prepare a trac submission on so little information?
By being clear and methodical about the topic, by staying on topic, and 
by creating (1) minimal, (2) reproducible (3) usecase with (4) all 
required files to reproduce it, and (5) said files uploaded somewhere 
accessible".
> I need help. I need help to determine the truth. Then I can prepare a 
> trac report. I cannot prepare a trac report until then. You are asking 
> for a miracle.

I think you have the wrong sequence in mind.  First, create the usecase. 
Second, file the trac report about the usecase. Third, use the minimal, 
reproducible usecase in the trac report to diagnose the root cause of 
the problem.  Fourth, fix the root cause.

You are getting lots of help to create a minimal, reproducible usecase. 
You will get help to make a trac report. But you need to accept it.

Best regards,
       —Jim DeLaHunt

[1] <https://ffmpeg.org/pipermail/ffmpeg-user/2024-February/057674.html> 
Mon Feb 19 23:45:11 EET 2024
[2] <https://ffmpeg.org/pipermail/ffmpeg-user/2024-February/057676.html> 
Tue Feb 20 01:49:55 EET 2024
[3] <https://ffmpeg.org/pipermail/ffmpeg-user/2024-February/057677.html> 
Tue Feb 20 03:31:13 EET 2024
[3] <https://ffmpeg.org/pipermail/ffmpeg-user/2024-February/057655.html> 
Sun Feb 18 10:15:31 EET 2024