summaryrefslogtreecommitdiffstats
path: root/demux
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2014-04-08 19:02:57 +0200
committerwm4 <wm4@nowhere>2014-04-08 19:02:57 +0200
commita748b6270934717063797aba646072b95f141acc (patch)
treef4987c44fe3d7788b447ee34e69aba68497ec99a /demux
parent929793be7f8e0a02006ac5915f39ca12dece72fd (diff)
downloadmpv-a748b6270934717063797aba646072b95f141acc.tar.bz2
mpv-a748b6270934717063797aba646072b95f141acc.tar.xz
vo_vdpau: simplify previous vsync timestamp calculation
The strange thing about this code was the shift parameter of the prev_vs2 function. The parameter is used to handle timestamps before the last vsync, since the % operator handles negative values incorrectly. Most callers set shift to 0, and _usually_ pass a timestamp after the last vsync. One caller sets it to 16, and can pass a timestamp before the last timestamp. The mystery is why prev_vs2 doesn't just compensate for the % operator semantics in the most simple way: if the result of the operator is negative, add the divisor to it. Instead, it adds a huge value to it (how huge is influenced by shift). If shift is 0, the result of the function will not be aligned to vsyncs. I have no idea why it was written in this way. Were there concerns about certain numeric overflows that could happen in the calculations? But I can't think of any (the difference between ts and vc->recent_vsync_time is usually not that huge). Or is there something more clever about it, which is important for the timing code? I can't think of anything either. So scrap it and simplify it.
Diffstat (limited to 'demux')
0 files changed, 0 insertions, 0 deletions