This reverts part of PR #15899 (commit dd6e3a0ece).
"Why is this even useful?": It's very useful for multi-disc playlists. Compare:
`mpv bd:///DISC{1..4}`
`mpv -\{ bd:// --bluray-device=DISC1 -\} -\{ bd:// --bluray-device=DISC2 -\} -\{ bd:// --bluray-device=DISC3 -\} -\{ bd:// --bluray-device=DISC4 -\}`
You probably wouldn't guess what this does from the name alone, but it
actually selects a range of tracks to play. It's slightly different than
using --start because it confines the range to just that track and you
cannot seek before it. The functionality is useful, but you can
accomplish exactly the same thing with --start and --end. Also the
implementation of the cdda option is weird because starting from a track
after 1 makes it impossible to seek before it. There's no reason to have
this when using the core option is simply better and works fine.
This is allowed but it's pretty weird. You'd end up typing something
like dvd:////dev/sr0 or cdda:///dev/sr0 (notice the differing amount of
/). Why is this even useful? Just use the matching --cdda-device option.
There's no need to have two ways to do the same thing here.
Amusingly, this was not working correctly for at least a decade. For
all OSes, the default drive is the same except for macOS. It had
"/dev/diskN" as the default dvd drive. Back in the mplayer days, there
was actually dynamic compile time generation (only for mac) that
replaced the N with the actual number*. But this didn't actually work
for all stream types. It seems like it never worked for stream_dvdnav
and was only a stream_dvd (libdvdread) feature. And then later that
stream got removed completely. So at least for macOS users, they had a
fallback device of "/dev/diskN" for certain stream types and for a very
long time.
We can't really do better here, but we should at least pick a default
string that has a chance of working. So /dev/disk1 it is then. With
that, all of the devices become the same so we can combine it all and
use the same default optical drive for both CDs and DVDs. BD will be
added in the next commit. Also /dev/dvd is some antiquated thing that
doesn't really exist anymore. Linux systems will likely still have
/dev/cdrom which has a decent chance of being usable. /dev/dvd probably
won't be there.
*: f215e84339
Sometimes there was an immediate return on error and other times it
destroyed things before returning the error. Make this consistent
whenever something fails while we open. Also remove the destruct
function since it is completely redundant with bluray_stream_close.
Sometimes a CD can have non-audio data at the start that is not
playable. libcdio/paranoia is smart enough to already skip this, but our
calculations for when the tracks/chapters start completely fall apart.
The beginning bytes are not valid CD audio so it should just be
subtracted and ignored. This probably doesn't work if a CD somehow has
its audio tracks in a non-continuous manner with non-audio data
in between tracks at random points. There's likely not much we could do
in such a case, and probably nobody has an audio CD like that anyways.
Ref: #8322
There's several path-related options that do not handle common shortcuts
(like ~/). Fix this by using mp_get_user_path where appropriate which
expands the path so users get more intuitive behavior. Fixes#15598.
This ensures that we don't open some other fd, for example when loading
playlist. Also filters out loading any local files.
This also allows to remove custom filtering from fuzzer itself.
Fixes reading EMBL sizes in some files and makes this function readable
while at it.
Would be good to inline mp_log2(), but should be good enough.
Fixes: #15691
This allows to select DVD/Blu-Ray title easily. Titles are listed as
editions with their duration and number.
I wanted to include Angles also in this selection, but currently Angles
are not that well supported, so let's stick with titles and leave the
rest for the future changes.
We might migrate to lavf demuxer for DVD/Blu-Ray in the future, the mpv
implementation is rotted anyway.
Fixes#14586
Also rename the field to appropriately reflect what it is supposed to be
used for. The only other use of this was to search for ordered chapter
sources, and that makes no sense for mkv files from stdin.
This also fixes autocreate-playlist loading in the current directory
when the input file is stdin.
The naming of these conflict with existing mpv protocols, so skip if we
get them. Users can still use them via lavf://bluray: or lavf://dvd: if
they wish.
Previously, all stream protocols were a static list in mpv. This is okay
for own builtin stuff, but for protocols that depend on ffmpeg it's not
so great. Support for certain protocols may or may not be enabled in a
user's ffmpeg and the protocol list that mpv generates should ideally
match this. Fix this by implementing a get_protocols method for
stream_lavf that will have different results depending on the ffmpeg mpv
is built against. We keep the safe and unsafe protocols separation. The
former is essentially a whitelist. Any protocol that is found in ffmpeg
but is not in the safe whitelist is considered unsafe. In the stream
list, ffmpeg is moved to the bottom so any possible protocols that are
added in the future don't automatically take precedence over any builtin
mpv ones.
Reading an entire file is a common operation, meanwhile
stream_file will happily open a directory. This doesn't match well.
Analogously for open_output_stream().
The stream layer is just not the right place to make this change
since it's also used for completely unrelated purposes such as reading
configs.
This reverts commit bb7a485c09.
```
dd if=/dev/zero of=/tmp/10g.empty bs=1 seek=10G count=0
dd if=/dev/zero of=/tmp/10m.empty bs=1 seek=10M count=0
time mpv /tmp/10{g,m}.empty
```
I keep files with the name format `${name}-${hash}.${ext}.empty`
around, where the original is removed, and a sparse file with
the size of the original is created instead.
A lot of time is wasted on such files when going through
playlists/directories that include some of them.
This admittedly may not be that common of a use-case.
Signed-off-by: Mohammad AlSaleh <[email protected]>
Kacper Michajłow