This was broken at some unknown point (even before the recent cache
changes). There are several problems:
- stream_dvd returning a random stream position, confusing the cache
layer (cached data and stream data lost their 1:1 corrospondence by
position)
- this also confused the mechanism added with commit a9671524, which
basically triggered random seeking (although this was not the only
problem)
- demux_lavf requesting seeks in the stream layer, which resulted in
seeks in the cache or the real stream
Fix this by completely removing byte-based seeking from stream_dvd. This
already works fine for stream_dvdnav and stream_bluray. Now all these
streams do time-based seeks, and pretend to be infinite streams of data,
and the rest of the player simply doesn't care about the stream byte
positions.
resize_cache() checks the size itself and clamps the size to the valid
range if necessary, so we don't need these checks. In fact, the checks
are different. Also, output the cache size after clamping, instead of
before.
Use NtQueryVolumeInformationFile instead of GetDriveType for detecting
remote filesystems on Windows. This has the advantage of working
directly on the file handle instead of needing a path and it works
unmodified in Cygwin where the previous code wouldn't understand Cygwin
paths or symlinks.
There is some risk in using NtQueryVolumeInformationFile, since it's an
internal function and its behaviour could change at any time or it could
be removed in a future version of Windows, however it's documented[1] in
the WDK and it's used successfully by Cygwin, so it should be fine. If
it's removed, the code should fail gracefully by treating all files as
local.
[1]: http://msdn.microsoft.com/en-us/library/windows/hardware/ff567070.aspx
Signed-off-by: wm4 <wm4@nowhere>
Merge the cache_read function into cache_fill_buffer, since there's
not much reason to keep them separate. Also, simply call read_buffer()
to see if there's any readable data, instead of checking for the
condition manually.
The only tricky part is keeping the cache contents, which is made simple
by allocating the new cache while still keeping the old cache around,
and then copying the old data.
To explain the "Don't use this when playing DVD or Bluray." comment: the
cache also associates timestamps to blocks of bytes, but throws away the
timestamps on seek. Thus you will experience strange behavior after
resizing the cache until the old cached region is exhausted.
The only difference is that the MP_DBG message is not printed anymore if
the current user read position is outside of the current cache range.
(In order to handle seek_limit==0 gracefully in the normal case of
linear reading, change the comparison from ">=" to ">".)
Until now, this could never happen, because new data was simply always
appended to the end of the cache. But for making stream cache resizing
easier, doing it this way seems advantageous. It also makes it harder to
make the internal state inconsistent. (Before this change it could
happen that cache and stream position went out of sync if the read
position was adjusted "inappropriately".)
Until now, cache_read() (which calls read_buffer()) could return short
reads. This was a simplification allowed by the stream interface. But
for cache resizing, it will be more practical to make read_buffer() do
a full read.
Seems like a good idea. One possible bad effect would be slowing down
uncached controls, but they're already slow. The good thing is that
many controls make intrusive changes to the stream (at least controls
which do write accesses), so the cached parameters should be updated.
There are two kind of encryption for Blu-ray disc, AACS and BD+,
and both of them can be checked through BLURAY_DISC_INFO object.
This commit makes the bluray and bdnav streams refuse playback
if AACS/BD+ is detected and decryption is failed.
The angles should be set and queried only if a valid title is
selected. Also, in navigation mode, there are some limitations
which make it impossible to query current title/angle.
This commit introduces new stream protocols: bdnav(and others).
bdnav stream shares lots of codes with original bluray stream, so
it's not separated in different source file.
Major difference from bluray is that bdnav does not support longest
title because there is no way to query that information.
bdnav://menu and bdnav://first correspond to top menu title and
first play title respectively, though they often point same title.
Also, binary position based seeking has been removed, because it
didn't have no point.
This was actually supposed to be removed with pull reuqest #671, but
I accidentally re-added it with a rebasing mistake.
This probably also coincidentally fixes compilation with older
libbluray (issue #672).
Use bd_get_playlist_info() instead of bd_get_title_info(). The
previous implementation couldn't query current playlist and this
made it impossible to call bd_get_playlist_info() which is more
desirable than bd_get_title_info() because, for Blu-rays, playlist
is the unit of playback not title. This commit fixes that.
The cost of calling bd_get_title_info() is quite expensive and
requires lots of CPU usage. Using BD_EVENT_PLAYLIST and
BD_EVENT_TITLE, it's possible to cache BLURAY_TITLE_INFO object for
current title and BD_EVENT_ANGLE handler caches current angle. In
my test case, with this commit, CPU usage can be saved about 15-20%.
demux_mf.c explicitly checks for the stream type to check whether images
are opened via pattern (mf://..., i.e. stream_mf.c) or directly. Of
course the stream type is not set to STREAMTYPE_MF if the stream is
wrapped through the cache, so it tried to open the pattern directly as
file, which failed.
Fix this by disabling caching for mf://. The cache doesn't make sense
here anyway, because each file is opened and closed every frame (perhaps
to avoid memory bloat).
This cd_info_t struct was practically unused. The only thing it did was
storing the track name of the form "Track %d" in a very roundabout way.
Remove it. (It made more sense when there was still CDDB support.)
Don't use an integer division to get the time, since that would round on
second boundaries. Also round up the time by sector size. Seeking rounds
down due to alignment constraints, but if we round up the time, we can
make it land on the exact destination sector.
This fixes that the track change code printed the previous track when
seeking by chapter.
dvdnav.c did not handle event in regular sequence. Usually this
does not make any trouble except around MP_NAV_EVENT_RESET_ALL.
Those events should be handled in regular sequence. If they're
mixed, it can make wrong result.
For instance, MP_NAV_EVENT_HIGHLIGHT right after
MP_NAV_EVENT_RESET_ALL should not be ignored but it might be
because MP_NAV_EVENT_RESET_ALL makes the demuxer reloaded and osd
hidden.
Stream-level chapters (like DVD etc.) did potentially not have
timestamps for each chapter, so STREAM_CTRL_SEEK_TO_CHAPTER and
STREAM_CTRL_GET_CURRENT_CHAPTER were needed to navigate chapters. We've
switched everything to use timestamps and that seems to work, so we can
simplify the code and remove this old mechanism.
Report the time for each chapter (tracks are treated as chapters). This
allows us to get rid of the "old" chapter mechanism, and also behaves
better with the frontend.
This makes assumptions about the audio formats, but that format is
hardcoded anyway in the rawaudio demuxer defaults (and always was).
The title for stream_bluray DID start from 1 and I misunderstood
that it started from 0 because mpv accepted bd://0 as a proper
argument. In fact, 0 title was an alias for the longest title but
it was not handled as a special value. This commit fixes these
behavious. 'disc-title' property for Blu-ray now starts from 0 and
the default title can be specified by 'longest' title just like
stream_dvdnav: bd://longest. Of course, 'longest' can be omitted.
This commit makes 'disc-title' property writable using
STREAM_CTRL_SET_CURRENT_TITLE. This commit also contains
implementation of STREAM_CTRL_SET_CURRENT_TITLE for stream_bluray.
Currently, 'disc-title' is writable only for stream_dvdnav and
stream_bluray and stream_dvd is not supported.
This commit makes 'disc-title' properties for DVDs start from 0.
There was an inconsistency around 'disc-title' property between
DVDs (from 1) and Blu-rays (from 0). This fixes#648.
Signed-off-by: wm4 <wm4@nowhere>
This commit provides impelmentation of STREAM_CTRL_GET_NUM_TITLES
for dvdnav stream. Other streams for DVD or Blu-ray are already
provide STREAM_CTRL_GET_NUM_TITLES.
Detected 'protocols' are AFP, nfs, smb and webdav. This can be extended on
request.
This is currently only implemented for BSD systems (using fstatfs). This
addresses issue #558 on the above platforms.
Note that this still happens in the stream level, so we can't have
nice highlevel behavior restricting seeking. Instead, if a seek leads
to the demuxer requesting data outside of the cached range, the seek
will simply fail. This might confuse the demuxer, and the resulting
behavior is not necessarily useful.
Note that this also doesn't try to skip data on a forward seek. This
would just freeze the stream with slow unseekable streams.
One nice thing is that stream.h has a separate function for merely
skipping data (separate from seeking forward), which is pretty useful
in this case: we want skipping of data to work, even if we reject
seeking forward by skipping data as too expensive. This probably is
or will be useful for demux_mkv.c.
This is probably ok. Probing could hit this case very often, since it'll
mean running this function on potentially binary data, but on the other
hand, probing usually uses a memory stream (to limit the amount of data
read), and memory streams have s->log silenced (details see
open_memory_stream()).
