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.
There is zero reason for this to be an MPOpt. Because of how the
OPT_SUBSTRACT works, the option gets renamed to cdda-device instead, but
probably not a big deal since the old alias is still in place.
We've got an ungodly amount of OPT_REPLACED and OPT_REMOVED sitting
around in the code. This is harmless, but the vast majority of these are
ancient. 26f4f18c06 is the last commit
that touched the majority of these and of course that only changed how
options were declared so all of this stuff was deprecated even before
that. No use in keeping these, so just delete them all. As an aside,
there was actually a cocoa_opts but it had only a single option which
was replaced by something else and empty otherwise. So that entire thing
was just simply removed. OPT_REPLACED/OPT_REMOVED declarations that were
added in 0.35 or later were kept as is.
The GNOME Nautilus file manager supports browsing of dav:// and davs:// links only. Additionally, dav:// and davs:// are also types of webdav links. Therefore, adding an "or" operation to include support for dav:// and davs:// links.
While ZAP config files should contain strings in most fields,
their field number in the DVB-T / ISDBT case matches the number of fields
for VDR config files, and some channel list writers (namely, dvbv5-scan)
may insert "0" in unused string fields.
To disentangle such config files from real VDR config files,
add a check for the "INVERSION_" field which should always be filled.
dvb_get_channels is expected to append to an existing channel list.
For adapters supporting many delivery systems, a subsequent channel list
may turn up with a non-existent channel config, and the pointer
to the previously parsed channel list may be lost
(i.e. the list will be leaked and no channels detected).
Fix this by passing through the existing list (which may be NULL)
in case no new channels are found.
This is similar to DVB-T, but requires slightly different treatment
as there is no T/T2 differentiation.
Use a new channels.conf.isdbt file as channels config file.
