First frame of video does not seem to adhere to frame rate

[forthrin]

mpv Information

mpv version: git-2024-07-31-0647089
FFmpeg version: git-2024-07-31-43f702a

Other Information

System Version: macOS 14.5 (23F79)
Model Identifier: MacBookAir10,1

Reproduction Steps

Mux any set of still pictures with any/silent audio as follows:

$ magick "/Library/User Pictures/Flowers"/*.heic %d.png
$ ffmpeg -r 1/3 -i %d.png -f lavfi -i anullsrc -pix_fmt yuv420p -shortest -y out.mp4
$ mpv --no-config --log-file=out.log out.mp4

Expected Behavior

Each still picture should be shown for three seconds. It does in QuickTime.

Actual Behavior

The first still is shown for one frame only, with error message below. Subsequent stills are shown correctly (3 secs each).

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).
Consider trying --profile=fast and/or --hwdec=auto-safe as they may help.

If rewinding the video back to start, the first still is shown for 3 secs as expected.

If using a higher frame rate, the error message disappears, but the first frame is still rushed.

Log File

out.log

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[llyyr]

This happens because ffmpeg inserts a bogus audio track when you generate the final mp4, you can add -an to the command to not add the audio track then mpv will display the file correctly.

Although we shouldn't skip the first frame even if the bogus audio track exists, so this is indeed a mpv bug.

[forthrin]

Thanks for confirming. FYI, the issue happens with an actual (any) audio file too. A silent audio file was just used for simplicity. (It's a good thing if the bogus track uncovered another/broader issue, leading to a more resilient fix.)

[llyyr]

This was broken by b0e6ac3 which was trying to fix a different sample where audio started after the video.

#14616 fixes this issue without breaking the other sample

[forthrin]

Thanks for the quick pounce. The two patches do indeed improve the issue. However, the first frame seems to display somewhat longer than expected (about 4 seconds), as opposed to the 3 expected seconds in subsequent frames.

[forthrin]

By all accounts, e06e9c3 consistently displays each frame, including the first, for the expected 3 seconds. Well done!