[0.33.1 regression] A/V desync for videos cut by ffmpeg

This is a regression, no idea when it started but 0.29.1 works fine, while 0.33.1 is buggy.

If I cut any of my MP4 videos (shot on a smartphone, H.264/AAC) using ffmpeg this way, ffmpeg -ss 00:01:00 -i source.mp4 -t 10 -c copy out.mp4, mpv struggles to play them:

[cplayer] starting audio playback
[ao/pulse] starting AO
[vd] Allocating new DR image...
[statusline] AV: 00:00:00 / 00:00:10 (0%) A-V:  0.000
[cplayer] 
[cplayer] Audio/Video desynchronisation detected! Possible reasons include too slow
[cplayer] hardware, temporary CPU spikes, broken drivers, and broken files. Audio
[cplayer] position will not match to the video (see A-V status field).
[cplayer]

Visually it looks like when starting to play a video, mpv chokes for a second then resumes. Strangely it doesn't happen for full (uncut) videos.

Software:

• Fedora 33, XFCE, no compositing
• mpv 0.33.1/0.29.1 built from the original source, linked against ffmpeg-4.4 built from the original source
• Proprietary NVIDIA drivers 465.27 with the only conf option being: Option "metamodes" "nvidia-auto-select +0+0 {ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}"

Hardware: Ryzen 7 3700X, NVIDIA 1660 Ti

My PC is perfectly capable of playing AV1 8K 60fps videos, so the problem is not with my HW. Maybe ffmpeg cuts video incorrectly, but then mpv-0.29.1 plays them just fine.

Specifically for the test I've removed all mpv configuration files to exclude any issues stemming from "wrong" settings.

A sample video

mpv-0.33.1.vv.log

Reproduce the regression with the linked sample video, the ffmpeg cut command, and mpv 0.33.1, then compare playback and the verbose log with mpv 0.29.1. Trace the audio/video startup and timestamp handling involved in cut MP4 files; done means the sample plays without the reported desynchronisation while full videos remain unaffected.