[FFmpeg-user] Towards better trims & concatenations

[Mark Filipak]

On 1/6/24 17:20, Jim DeLaHunt wrote:
> Mark:

Hi Jim,

> On 2024-01-06 11:52, Mark Filipak wrote:
>> Below is what I plan to submit to trac. I welcome comments and corrections. …
> 
> Good for you, digging into the details and specifics of how FFMpeg performs trims and concatenations.
> 
> But what I am missing here is a concise problem statement.

There are many errors.

> You say you plan to "submit to trac". Is this a bug report?

Yes. It's hard to figure out how many bugs and whether all of my experiences really _are_ bugs or 
are just misunderstanding of what the ffmpeg directives are supposed to do. I'm quite experienced in 
these tasks, so the former is more probable.
Certainly getting PTSs wrong from mother's clone to mother's son is a bug.
Certainly getting trim time wrong from mother's clone to mother's son is a bug.
Are those bugs specific to this use-case. Based on my experience and the reported experiences of 
others I'd say the bugs are endemic. I think there are other functions in ffmpeg that have 'learned' 
how to work around the bugs, and there are others that have not 'learned', so those use-cases fail. 
I'm guessing of course.

> If it is a bug report, what is the bug title? It should be a concise (1-10 words) statement of what 
> is incorrect.

That's good advice but there are multiple bugs. They may be interacting. I can't separate them into 
individual trac reports.

> What is the bug summary? It should a concise (1 paragraph) summary of the problem.
> 
> 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. The 'mother' can be any video. I reckon 
that different 'mothers' will expose differing symptoms. More than that, 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.

> What is the "observed behaviour"?  Is it something to do with the total number of packets in the 
> "son" videos?

Yes, for some sons. For other sons it's PTS errors that put packets and the images out of order.

>  Or the frame number of the first non-black frame?

Yes, for those sons that have a bogus total number of packets.

If there is a single thing that produces all the bogus results, it's probably deep within ffmpeg, 
where the mapping happens. There must be a table built that relates the packets by packet index, by 
audio v video v chapter v subtitle, by DTS, by PTS, by frame number if video, etc. That table may be 
being built wrongly or the methods that access that table may be where the bugs are. From the 
outside, I can't tell. I just know what goes wrong.

> What is the "expected behaviour"?

I see where you're going. The expected behavior is that all cuts are on N=481, that there are no 
extra audio packets in front of it, that the resulting PTSs have the same order as the original 
PTSs, and so on. I'll rewrite with that in mind.

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

> I don't see that you explain that. Without having the same source material as 
> you, it is hard to reproduce the same results.

The clone is a copy of the 'mother'. It is available. Do you want it? (Note that all the sons can be 
made from the clone instead of from the mother, though that's not the correct way to proceed.)

> It may be that this test methodology reveals multiple bugs, which might be better pursued if 
> reported separately.

How? How can they be separated?