search

mpv-player / mpv

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

Audio/Video desync if --start and --vf=<filter> is used if filter changes framerate #4300

Closed Vestaia closed 7 years ago

Vestaia commented 7 years ago

Version: Latest (HEAD) and Latest (Release 0.24) MacOS Sierra 10.12 In Terminal: mpv --vf=vapoursynth= --start=1:00 -o file.mp4 Video is ahead of audio, the further into the video that --start is specified, the worse the desync is; the rate seems to be about 1 second per 3 minutes. (If I do --start=1:00:00, the audio will be behind by about 20 seconds) This happens with MVTools, SVPFlow, SVPFlow2, etc...

Audio desync does not worsen as video plays. Desync seems to be only effected by the value after --start, and remains about the same desync throughout the video. There is no issue if --start is not specified. There also is no issue if --vf does not change framerate.

chainikdn commented 7 years ago

usually 'hr-seek-framedrop=no' fixes audio desync

ghost commented 7 years ago

Are you sure the scripts preserve the timestamps properly? They'd have to set the frame durations in a way there's no drift after output.

ghost commented 7 years ago

That is not the solution. Can I get a log or a sample file?

Vestaia commented 7 years ago

I don't have mpv 0.24 installed on my laptop ATM. Desktop still has desync with 0.24 log.txt Script used: high copy.txt The filter returns errors at final few frames because it needs read-ahead to determine vectors across several frames. Desync here is about 8 seconds

Vestaia commented 7 years ago

Here's another: test2.mp4.zip log.txt The source beeps when the bar is horizontal. The source is a standard YouTube encode.

ghost commented 7 years ago

That test video is out of sync even when playing normally? I don't get it.

ghost commented 7 years ago

I guess you ran mpv in encoding mode, and that's the output. I want the source. But if it's a normal youtube encode, there's probably no particular problem anyway.

I assume the source script requires constant framerate input, and can't deal with PTS skips, which is what hr-seek framedrop does (to speed up seeking). So I guess hr-seek-framedrop=no is actually the right "solution" to work around the problem with the script.