[FFmpeg-user] Towards better trims & concatenations

[Rob Hallam]

On Mon, 8 Jan 2024 at 12:37, Mark Filipak <markfilipak.imdb at gmail.com> wrote:
>
> On 1/8/24 07:16, Rob Hallam wrote:
> > On Mon, 8 Jan 2024 at 12:07, Mark Filipak <markfilipak.imdb at gmail.com> wrote:
> >
> >> For example, if 'v' (video) and 'a' (audio) packets go from
> >> v-a-a-a-a-v-a-a-a-a-v... to
> >> a-a-a-a-a-a-a-a-v-v-v..., then somethings wrong, eh? That's the kind of difference I'm seeing
> >> between the two versions of 01.mp4.
> >
> > Forgive me for jumping in in the middle here, but is that strictly
> > true? Honest question, perhaps the spec says that they should be
> > identical.
>
> Sorry, I don't understand you. Are you asking if I'm lying? I doubt it, but I don't know the
> antecedent of "that". Also, when you wrote "the spec", what spec did you have in mind?

For clarity, I wasn't accusing you of lying and it certainly wasn't my
intention to imply that; my apologies if it sounded that way!

The 'that' in the above-quoted case was your example of packets-
clearly they are ordered differently, something has changed and
perhaps it shouldn't have changed. I wondered if there was a practical
difference; to go back to the multiplication example, if you get 120
either way, does it matter if you do 3*4*10 versus 10*3*4 ? Sometimes
it does matter -- like in cases of floating-point maths -- but  I am
wondering if ffmpeg here is producing something that appears different
but looks and sounds the same.

I didn't have a particular spec in mind, but candidates would be
ffmpeg specs and/or specs for the container and codec formats in use-
ie does this behaviour contradict those.

> > In much the same way a*b*c is equivalent to b*a*c, does the order of
> > packets necessarily matter if the output is perceptually the same?
>
> The packets are in PTS order. Does the order of the packets matter? No, it's the order of the PTSs
> that matters.
>
> > If the output is not perceptually the same, or there are timing issues
> > / desync / other problems as a result then I can see that being a
> > potentially important bug.
>
> The MPV player misbehaves for all 6 of the sons. The starting running time is not "00:00:00.000".

Does it matter that the starting running time is not "00:00:00.000" ?
I presume it does, otherwise you might not be raising this issue; but
in my ignorance I can see the possibility that the reported starting
running time is a 'cosmetic' issue rather than a functional one. I am
happy to be corrected and educated, which is partly why I am still
subscribed to this ML.

I ask these questions because "ffmpeg produces output that plays
incorrectly" is a different bug to "ffmpeg produces output that plays
correctly but has a different file structure". Both are bugs, but it's
worth being clear to which one the issues have identified belong so
you and devs are on the same page.

> > PS I've been following along as I am also interested in cutting and
> > re-joining- my first query to this ML was about whether there's a way
> > to chop off the starts and ends of some clips, add transitions and
> > re-encode those short overlapping bits, and then join them back on to
> > their parent clips to avoid having to re-encode the whole lot
>
> You should be able to do all that without recoding except for the transitions, as you wrote. I and
> others have had lots of problems with concats. There are 3 concat methods. They all have problems
> with cuts. I think the real problem is deep inside ffmpeg affecting how the packet table is built
> and/or accessed.

I agree it should be possible conceptually, but in practice I couldn't
refine a process to the point where it felt sufficiently robust to
trust. I am quite open to the possibility that the fault may have been
mine though! I may look into it again when I have sufficient
quantities of time and need :)

Cheers,
Rob