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 <CE.Mohammad.AlSaleh@gmail.com>
This is useful e.g. when the caller dup2's a socket into stdin, or
passes a socket/pipe as /dev/fd/{fd}, because it is impossible to seek
on sockets and pipes.
- Don't define _GNU_SOURCE on Windows, no need
- Define WIN32_LEAN_AND_MEAN to strip some unneded headers from
windows.h
- Define NOMINMAX and _USE_MATH_DEFINES as they are common for Windows
headers
I started going through the blame but once I got to mplayer commits from
20 years ago, I stopped bothering. This obscure option has always been
disabled by default, but there's zero reason, as far as I know, to not
just enable it today. Some CDs (particularly very old ones) have the
first sector shifted a bit and not starting exactly at 0. This makes the
logic that tries to get all the chapters completely fail and thus you
can't skip through tracks. However if you just enable this obscure
option, it just works. For anything that starts exactly at 0, the
calculated offset is just 0 anyway so it's a no-op and works exactly the
same. So basically, there's literally no reason to not just always try
to correct for the offset of the first sector by default.
Fixes#8777.
It was completely wrong. mpv will buffer data ahead of where the CD
currently is playing. When enough data was buffered into the next track,
the track info is printed regardless of where the stream position
actually is. Depending on the user settings, you can get mpv to buffer
minutes ahead. Printing a message when the track changes might be nice,
but this isn't the right place to do it. Some other mechanism would need
to be leveraged, but I'm not going to bother figuring it out.
CDIO_API_VERSION 6 has been around since libcdio 0.90. That was release
over a decade ago. There's literally no reason to keep the ugly mess of
the old api around so remove it.
a343666ab5 made demux options public, so
we can take advantage of that here as well. This lets users guess the
codepage if the stream doesn't use UTF-8 characters. Fixes#8844.
Similar to the previous commit. There's no reason for --bluray-device to
be in MPOpts. Make a specific subopt for stream_bluray and use that
instead so we can remove the mp_read_option_raw call.
nanahi
Dudemanguy
Kacper Michajłow
llyyr
sfan5
Mohammad AlSaleh
bptato