diff options
author | wm4 <wm4@nowhere> | 2013-06-06 20:06:32 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2013-06-16 22:05:10 +0200 |
commit | a2212ed11e1dd31a1711b730c51cc42a3f51199e (patch) | |
tree | 73a082521cfe9724415c09f545cb378b82b9455a /stream/stream_dvb.c | |
parent | c90ddd4ec18bfcd0280c2b1fb36a51a924f070c5 (diff) | |
download | mpv-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_dvb.c')
0 files changed, 0 insertions, 0 deletions