summaryrefslogtreecommitdiffstats
path: root/common/av_log.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2015-01-19 21:25:30 +0100
committerwm4 <wm4@nowhere>2015-01-19 21:30:05 +0100
commit7a7d8d50e23776fb3fb863df9b6cd0b84cf85d92 (patch)
tree1fbb58fa6bc4ee1fcf09f62bc6395ab840ca4964 /common/av_log.c
parent966f0a41a4182cf4027a5d49b248a26ff49368f3 (diff)
downloadmpv-7a7d8d50e23776fb3fb863df9b6cd0b84cf85d92.tar.bz2
mpv-7a7d8d50e23776fb3fb863df9b6cd0b84cf85d92.tar.xz
dvd: try to improve seeking
libdvdnav is garbage. Seeking by time is incredibly inexact, which is in part due to the fact that it does not use the DVD seek tables. Instead, it assumes CBR for certain ranges within the DVD, which makes especially small seeks unreliable. I have no good fix for this, other than hacking libdvdnav (I'd rather prefer to remove mpv DVD support completely than doing this). So here's a shitty hack that tries to workaround these problems. A basic observation is that seeking in VLC seems to work quite well; however it seems to be based on seeking by blocks (unless there is a subtle "trick" I didn't see in the source code). mpv usually seeks by timestamps, so this is not an option for us. However, we can pretend we are doing this in the DVD layer. The previous commit added a way to pass through relative seeks. This commit uses the relative seek. STREAM_CTRL_SEEK_TO_TIME is backwards compatible (there's still dvdread and bluray), so most code is about extracing the relative seek information and turning it into a block seek. (Another way would have been using SEEK_FACTOR stuff, but that would probably make for a less reliable way to handle this situation.) Additionally, if a hr-seek is done, add an offset by 10 seconds. As long as the error done by libdvdnav is not worse, this should help with hr- seeks - although it makes them much slower.
Diffstat (limited to 'common/av_log.c')
0 files changed, 0 insertions, 0 deletions