[FFmpeg-user] xfade timing ambiguity

[Arif Driessen]

Yikes!!!! In the example script please change:

color=blue,
trim=0:3
[blue];

to be 5 seconds long (trim=0:5), then follow along with the text below.
SORRY!

On Thu, Sep 30, 2021 at 11:57 AM Arif Driessen <arifd86 at gmail.com> wrote:

> Consider this script:
>
> ---
> #!/bin/bash
>
> ffmpeg \
>     -v error \
>     -filter_complex \
>     "
>         color=blue,
>         trim=0:3
>         [blue];
>
>         color=red,
>         trim=0:5
>         [red];
>
>         [blue][red]
>         xfade
>     " \
>     -vcodec libx264 \
>     -f matroska out.mkv && \
>     ffprobe -v error \
>     -select_streams v \
>     -of csv=print_section=0 \
>     -show_entries format=duration \
>     out.mkv
>
> exit 0
> ---
>
> It will report the duration of the resultant mkv file is 5 seconds.
> Intuition would tell me to expect it to be 10 seconds long.
>
> Change the duration of [blue] to 3 seconds, and the resultant duration is
> still 5 seconds. Aha! So xfade blends the first input INTO the second. I
> don't believe the documentation is clear on this:
>
> > Apply cross fade from one input video stream to another input video
> stream. The cross fade is applied for specified duration
>
> Out of curiosity, what would happen if we keep the duration of [blue] to
> 3, but set the xfade=offset to 2 seconds, since xfade=duration by default
> is 1... Now the resultant mkv file is 7 seconds long!? Can you explain the
> rationale?
>
> Even weirder, now let's set the duration of [blue] to 3 seconds and make
> xfade=offset 3 seconds also... Now the resultant mkv file is 3 seconds
> long!! Is this just undefined behaviour because we have attempted illegal
> behaviour? (offset + duration >= input_duration)
>
> Should we update the documentation to be clearer on this? (I am happy to
> do the work). It was the source of a frustating timing issue that took me
> all day to resolve. (back when I was emailing here about concating and
> fading sources).
>
> Btw, acrossfade, works intuitively, and thus (for me) without fault. This
> concern/ambiguity is also expressed in Michael Koch's FFmpeg book.
>
> Thanks,
> Arif Driessen
>
>