summaryrefslogtreecommitdiffstats
path: root/player/audio.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2016-08-07 14:06:54 +0200
committerwm4 <wm4@nowhere>2016-08-07 14:14:32 +0200
commit32cc190a552551cc7e7150e8603b6a75e0a6d94f (patch)
tree9e79b1ebe3aeb91ea7c2f82bf2797d452c72569a /player/audio.c
parent39ae261cc59598426b6e6beea2c849a6c8a9d20f (diff)
downloadmpv-32cc190a552551cc7e7150e8603b6a75e0a6d94f.tar.bz2
mpv-32cc190a552551cc7e7150e8603b6a75e0a6d94f.tar.xz
player: fix display-sync timing if audio take long on resume
In display-sync mode, the very first video frame is idiotically fully timed, even though audio has not been synced yet at this point, and the video frame is more like a "preview" frame. But since it's fully timed, an underflow is detected if audio takes longer than the display time of the frame (we send the second frame only after audio is done). The timing code will try to compensate for the determined desync, but it really shouldn't. So explicitly discard the timing info in this specific case. On the other hand, if the first frame still hasn't finished display, we can pretend everything is ok. This is a hack - ideally, we either would send a frame without timing info (and then send it again or so when playback starts properly), or we would add real pause support to the VO, and pause it during syncing.
Diffstat (limited to 'player/audio.c')
0 files changed, 0 insertions, 0 deletions