search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
27.81k stars 2.87k forks source link

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

Open birdie-github opened 3 years ago

birdie-github commented 3 years ago

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:

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

TheAMM commented 3 years ago

Use --log-file=foobar.log instead of -v in the future, though the console output already shows the issue, and it's with the file:

[cplayer] starting video playback
[cplayer] delaying audio start 0.000000 vs. -0.805400, diff=0.805400
[cplayer] playback restart complete @ -0.805400, audio=ready, video=playing
[vd] Allocating new DR image...
[statusline] AV: -00:00:00 / 00:00:10 (0%) A-V:  0.000
[cplayer] delaying audio start 0.000000 vs. -0.771900, diff=0.771900
[cplayer] Run command: change-list, flags=64, args=[name="shared-script-properties", operation="append", value="osc-margins=0.000000,0.000000,0.000000,0.000000"]
[cplayer] Set property: shared-script-properties -> 1
[vo/gpu/x11] Disabling screensaver.
[statusline] AV: -00:00:00 / 00:00:10 (0%) A-V:  0.000
[cplayer] delaying audio start 0.000000 vs. -0.738400, diff=0.738400
[statusline] AV: -00:00:00 / 00:00:10 (0%) A-V:  0.000

ffprobe -of compact -show_packets -show_entries packet=codec_type,pts_time 100-10.mp4 confirms the leading audio:

packet|codec_type=video|pts_time=0.000000
packet|codec_type=audio|pts_time=-0.803479
packet|codec_type=audio|pts_time=-0.782146
packet|codec_type=video|pts_time=0.000000
packet|codec_type=audio|pts_time=-0.760813
packet|codec_type=audio|pts_time=-0.739479
packet|codec_type=video|pts_time=0.000000
packet|codec_type=audio|pts_time=-0.718146
packet|codec_type=video|pts_time=0.000000
packet|codec_type=audio|pts_time=-0.696812
packet|codec_type=audio|pts_time=-0.675479
packet|codec_type=video|pts_time=0.000000

Your file's just weird. Look into ffmepg options to deal with negative timestamps, or some other way to clean up the pts.

birdie-github commented 3 years ago

But ... mpv-0.29.1 has no troubles playing it :-) Why? :-)

You sound like the audio is being played backwards.

I've cut the source file using the slow seek (-ss time option after the input) and it works OK. Will file a bug against ffmpeg. Still curious while the old mpv works.

ffmpeg bug report: https://trac.ffmpeg.org/ticket/9269

Totorrr commented 2 years ago

Please check the FFMPEG wiki @ https://trac.ffmpeg.org/wiki/Seeking#Seekingwhiledoingacodeccopy

It says:

Using -ss as input option together with -c:v copy might not be accurate since ffmpeg is forced to only use/split on i-frames. Though it will—if possible—adjust the start time of the stream to a negative value to compensate for that. Basically, if you specify "second 157" and there is no key frame until second 159, it will include two seconds of audio (with no video) at the start, then will start from the first key frame. So be careful when splitting and doing codec copy.

So, for now, even though this is tricky, it is also wanted behaviour. The audio begins before the video does.

My question is: is this illegal behaviour (according to standards)?

And if it is legal, could we update mpv's behaviour to play this file as intended?

That would be:

So this issue now is more like a feature request or so. :)

Totorrr commented 2 years ago

Forgot to ping @TheAMM :)

Dudemanguy commented 1 year ago

Linked sample plays without any problems here + this is an old issue so I will assume somebody somewhere fixed something.

birdie-github commented 1 year ago

I can reproduce the issue with mpv-0.35/ffmpeg-5.1.2 but maybe you're running something really fresh.

Dudemanguy commented 1 year ago

Well just mpv from master which shouldn't really be terribly different. Bummer, guess this is still a problem then so I'll reopen it, but really it works fine here for whatever reason.