diff options
author | wm4 <wm4@nowhere> | 2016-01-29 22:43:59 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2016-01-29 22:43:59 +0100 |
commit | 340deb4e6eb1cf09c19cef5bd19c7eab51d6862b (patch) | |
tree | 5536838b6fec62dd7217df68bf24522c20c3e1e2 /sub/img_convert.c | |
parent | d980fd0856c3773d488f4649d77d44cd8c1baf0e (diff) | |
download | mpv-340deb4e6eb1cf09c19cef5bd19c7eab51d6862b.tar.bz2 mpv-340deb4e6eb1cf09c19cef5bd19c7eab51d6862b.tar.xz |
player: fix initial audio sync in certain cases
Regression caused by commit 3b95dd47. Also see commit 4c25b000. We can
either use video_next_pts and add "delay", or we just use video_pts. Any
other combination breaks. The reason why the assumption that delay==0 at
this point was wrong exactly because after displaying the first video
frame (usually done before audio resync) a new frame might be "added"
immediately, resulting in a new video_next_pts and "delay", which will
still amount to video_pts.
Fixes #2770. (The reason why display-sync was blamed in this issue is
because enabling display-sync in the options forces a prefetch by 2
instead of 1 frames for seeks/playback restart, which triggers the
issue, even if display-sync is not actually enabled. In this case,
display-sync is never enabled because the frames have a unusually high
frame duration. This is also what exposed the initial desync issue.)
Diffstat (limited to 'sub/img_convert.c')
0 files changed, 0 insertions, 0 deletions