summaryrefslogtreecommitdiffstats
path: root/video/filter
diff options
context:
space:
mode:
authorDudemanguy <random342@airmail.cc>2023-10-29 00:22:02 -0500
committerDudemanguy <random342@airmail.cc>2023-10-30 17:18:35 +0000
commitcb2b579f61764452652c6cf5c6a94ae5e67c77ed (patch)
tree95c925f23e2bb1112bea29fbd508c46d8b952526 /video/filter
parent1f9d137153a696e42179a836377538535281eef9 (diff)
downloadmpv-cb2b579f61764452652c6cf5c6a94ae5e67c77ed.tar.bz2
mpv-cb2b579f61764452652c6cf5c6a94ae5e67c77ed.tar.xz
player/video: loosen logic checks for adjust_sync
Previously, the av sync change calculation was only done if the audio_status was STATUS_PLAYING, but there is at least one or two more states where this should be done. player/audio is capable of adding delay if the state is anything besides STATUS_EOF. This means that while calling adjust_sync, the delay value could have changed from the audio side of the equation from the previous playloop, and it doesn't necessarily mean that the current audio_status is STATUS_PLAYING either. So the old code would technically skip this case. In practice, this is just one frame so it hardly matters, but it should be taken into account. For example, STATUS_READY is definitely possible here in adjust_sync. I'm not sure if it's actually possible for STATUS_SYNCING to happen but the audio code can change add delay with that status, so it doesn't hurt. STATUS_DRAINING is probably not relevant, but again include it to mirror the audio code logic. Of course, STATUS_EOF is obviously a no-no since that means no audio at all, so we return from there. I didn't take hard measurements or anything, but this does seem to result in slightly smaller av sync fluctuations on discontinuities (like seeking) which makes sense because we're now making an additional correction that wasn't previously done. Another change is to always try adjust_sync as long as the frame_time is nonzero. The old logic only did this if the video_status was playing or greater, but it is possible to get new frames with a different PTS that do not have that status. The audio is still playing so logically it should be adjusted as well. Again, this happens for just one frame, so it doesn't really matter in practice but it should make more sense. A zero frame_time is skipped since that would mean the pts did not advance and the previous playloop should have done the adjustment for that time already.
Diffstat (limited to 'video/filter')
0 files changed, 0 insertions, 0 deletions