summaryrefslogtreecommitdiffstats
path: root/stream/stream.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2013-06-06 20:06:32 +0200
committerwm4 <wm4@nowhere>2013-06-16 22:05:10 +0200
commita2212ed11e1dd31a1711b730c51cc42a3f51199e (patch)
tree73a082521cfe9724415c09f545cb378b82b9455a /stream/stream.c
parentc90ddd4ec18bfcd0280c2b1fb36a51a924f070c5 (diff)
downloadmpv-a2212ed11e1dd31a1711b730c51cc42a3f51199e.tar.bz2
mpv-a2212ed11e1dd31a1711b730c51cc42a3f51199e.tar.xz
cache: report more precise stream time
DVD and bluray packet streams carry (essentially) random timestamps, which don't start at 0, can wrap, etc. libdvdread and libbluray provide a linear timestamp additionally. This timestamp can be retrieved with STREAM_CTRL_GET_CURRENT_TIME. The problem is that this timestamp is bound to the current raw file position, and the stream cache can be ahead of playback by an arbitrary amount. This is a big problem for the user, because the displayed playback time and actual time don't match (depending on cache size), and relative seeking is broken completely. Attempt to fix this by saving the linear timestamp all N bytes (where N = BYTE_META_CHUNK_SIZE = 16 KB). This is a rather crappy hack, but also very effective. A proper solution would probably try to offset the playback time with the packet PTS, but that would require at least knowing how the PTS can wrap (e.g. how many bits is the PTS comprised of, and what are the maximum and reset values). Another solution would be putting the cache between libdvdread and the filesystem/DVD device, but that can't be done currently. (Also isn't that the operating system's responsibility?)
Diffstat (limited to 'stream/stream.c')
0 files changed, 0 insertions, 0 deletions