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.
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.
c784820454 introduced a bool option type
as a replacement for the flag type, but didn't actually transition and
remove the flag type because it would have been too much mundane work.
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with
{"name", ...
followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.
I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.
Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.
Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.
In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
This was mostly unused, and has certain problems. Just get rid of it.
It was still used in CDDA (--cdda-span) and a debug option for OpenGL
(--opengl-check-pattern). Replace both of these with 2 options, where
each sets the start/end values of the former span. Both were
undocumented somehow (normally we require all options to be documented),
so I'm not caring about compatibility, and not bothering to add it to
the API changelog.
The cdio API always reads in sectors (fixed CDIO_CD_FRAMESIZE_RAW
blocks). In the past, mpv/MPlayer streams had a way for a stream to
signal a sector size, so the stream's fill_buffer implementation could
ignore the length argument. Later, that was removed, but stream_cdda.c
was left with assuming that the read size was always larger than the
sector size (rightfully at the time). Even later, this assumption was
broken with commit f37f4de, when it was suddenly possibly that smaller
reads were performed (at ring buffer boundaries). It returned EOF if the
buffer size was too small, so playback stopped very early.
Fix this by explicitly handling arbitrary sizes.
Tested with a .cue/.bin file only.
Fixes: #7384
mpv has a very weak and very annoying policy that determines whether a
playlist should be used or not. For example, if you play a remote
playlist, you usually don't want it to be able to read local filesystem
entries. (Although for a media player the impact is small I guess.)
It's weak and annoying as in that it does not prevent certain cases
which could be interpreted as bad in some cases, such as allowing
playlists on the local filesystem to reference remote URLs. It probably
barely makes sense, but we just want to exclude some other "definitely
not a good idea" things, all while playlists generally just work, so
whatever.
The policy is:
- from the command line anything is played
- local playlists can reference anything except "unsafe" streams
("unsafe" means special stream inputs like libavfilter graphs)
- remote playlists can reference only remote URLs
- things like "memory://" and archives are "transparent" to this
This commit does... something. It replaces the weird stream flags with a
slightly clearer "origin" value, which is now consequently passed down
and used everywhere. It fixes some deviations from the described policy.
I wanted to force archives to reference only content within them, but
this would probably have been more complicated (or required different
abstractions), and I'm too lazy to figure it out, so archives are now
"transparent" (playlists within archives behave the same outside).
There may be a lot of bugs in this.
This is unfortunately a very noisy commit because:
- every stream open call now needs to pass the origin
- so does every demuxer open call (=> params param. gets mandatory)
- most stream were changed to provide the "origin" value
- the origin value needed to be passed along in a lot of places
- I was too lazy to split the commit
Fixes: #7274
This partially reverts commit a9d83eac40
("Remove optical disc fancification layers").
Mostly due to the timestamp crap, this was never really going to work.
The playback layer is sensitive to timestamps, and derives the playback
time directly from the low level packet timestamps. DVD/BD works
differently, and libdvdnav/libbluray do not make it easy at all to
compensate for this. Which is why it never worked well, but not doing it
at all is even more awful.
demux_disc.c tried this and rewrote packet timestamps from low level TS
to playback time. So restore demux_disc.c, which should bring behavior
back to the old often non-working but slightly better state.
I did not revert anything that affects components above the demuxer
layer. For example, the properties for switching DVD angles or listing
disc titles are still gone. (Disc titles could be reimplemented as
editions. But not by me.)
This commit modifies the reverted code a bit; this can't be avoided,
because the internal API changed quite a bit. The old seek resync in
demux_lavf.c (which was a hack) is replaced with a hack. SEEK_FORCE and
demux_params.external_stream are new additions.
Some of this could/should be further cleaned up. If you don't want
"proper" DVD/BD support to disappear, you should probably volunteer.
Now why am I wasting my time for this? Just because some idiot users are
too lazy to rip their ever-wearing out shitty physical discs? Then why
should I not be lazy and drop support completely? They won't even be
thankful for me maintaining this horrible garbage for no compensation.
This was possibly needed by libdvdread, and/or old CD drivers on some
system. It still works with on-filesystem DVD and BD test images, so
this can go.
This removes anything related to DVD/BD/CD that negatively affected the
core code. It includes trying to rewrite timestamps (since DVDs and
Blurays do not set packet stream timestamps to playback time, and can
even have resets mid-stream), export of chapters, stream languages,
export of title/track lists, and all that.
Only basic seeking is supported. It is very much possible that seeking
completely fails on some discs (on some parts of the timeline), because
timestamp rewriting was removed.
Note that I don't give a shit about optical media. If you want to watch
them, rip them. Keeping some bare support for DVD/BD is the most I'm
going to do to appease the type of lazy, obnoxious users who will care.
There are other players which are better at optical discs.
This should actually cover all of them, if you take into account that
some unchanged GPL source files include header files with such checks.
Also this was done already for the libaf derived code.
This is only for "safety" and to avoid misunderstandings.
Because it's kind of dumb. (But not sure if it was worth the trouble.)
For stream_file.c, we add new explicit fields. The rest are rather
special uses and can be killed by comparing the stream impl. name.
The changes to DVD/BD/CD/TV are entirely untested.
Mostly untested.
This is not compatible. It removes the URL fields for track range and
cdrom speed (what did this even do). The device is not not to be
prefixed with an additional "/" if it's put into the URL. I can't be
bothered to keep these things compatible, just rip your damn CDs
instead.
Most things stopped using this field for better support of growing
files. Go through the trouble to repalce the remaining uses, so it can
be removed.
Also move the "streaming" field; saves 4 bytes (wow!).
Looks like a bunch of off-by-one errors.
The track number was mistakenly offset by 1 - this shifted all chapters
by one, and make the first chapter start on the second track (so the
"chapter" property returned -1 in the first track since it was before
the first chapter).
Also, the calculation of the sector destination was messed up. This
comes from commit 32d818f0, where I apparently attempted to calculate
the position to one byte before the section, but unfortunately math
doesn't work this way and it was nonsense. Just drop this idea; while it
may help with seeking (probably...), it also returns slightly different
times. The user shall use hr-seeks if accurate seeking is required.
Hopefully fixes#1560.
Apparently, we treat different tracks as titles, so returning the number
of titles (which is user-visible as "disc-titles" property) is
completely misguided.
stream_cdda's output format is linked to demux_raw's default audio
format, and at least we don't care enough to provide a separate
mechanism to let stream_cdda explicitly set the format, so they must
match.
Judging from the existing code, it looks like CDDA always outputs little
endian. stream_cdda.c changed this back to native endian (what demux_raw
expects). Just make them both little endian. This requires less code,
and also having a raw demuxer's behavior depend on the endianness of the
machine isn't very sane anyway.
bstr.c doesn't really deserve its own directory, and compat had just
a few files, most of which may as well be in osdep. There isn't really
any justification for these extra directories, so get rid of them.
The compat/libav.h was empty - just delete it. We changed our approach
to API compatibility, and will likely not need it anymore.
There is no standard mechanism for detecting endianess. Doing it at
compile time in a portable way is probably hard. Doing it properly
with a configure check is probably hard too. Using the endian
definitions in <sys/types.h> (usually includes <endian.h>, which is
not available everywhere) works under circumstances, but the previous
commit broke it on OSX.
Ideally all code should be endian dependent, but that is not possible
due to the dependencies (such as FFmpeg, some video output APIs, some
audio output APIs).
Create a header osdep/endian.h, which contains various fallbacks.
Note that the last fallback uses libavutil; however, it's not clear
whether AV_HAVE_BIGENDIAN is a public symbol, or whether including
<libavutil/bswap.h> really makes it visible. And in fact we don't want
to pollute the namespace with libavutil definitions either. Thus it's
only the last fallback.
DVD and Bluray (and to some extent cdda) require awful hacks all over
the codebase to make them work. The main reason is that they act like
container, but are entirely implemented on the stream layer. The raw
mpeg data resulting from these streams must be "extended" with the
container-like metadata transported via STREAM_CTRLs. The result were
hacks all over demux.c and some higher-level parts.
Add a "disc" pseudo-demuxer, and move all these hacks and special-cases
to it.
While I'm not very fond of "const", it's important for declarations
(it decides whether a symbol is emitted in a read-only or read/write
section). Fix all these cases, so we have writeable global data only
when we really need.
For some reason, we support writeable streams. (Only encoding uses that,
and the use of it looks messy enough that I want to replace it with FILE
or avio today.)
It's a chaos: most streams do not actually check the mode parameter like
they should. Simplify it, and let streams signal availability of write
mode by setting a flag in the stream info struct.
Stop using it in most places, and prefer STREAM_CTRL_GET_SIZE. The
advantage is that always the correct size will be used. There can be no
doubt anymore whether the end_pos value is outdated (as it happens often
with files that are being downloaded).
Some streams still use end_pos. They don't change size, and it's easier
to emulate STREAM_CTRL_GET_SIZE using end_pos, instead of adding a
STREAM_CTRL_GET_SIZE implementation to these streams.
Make sure int64_t is always used for STREAM_CTRL_GET_SIZE (it was
uint64_t before).
Remove the seek flags mess, and replace them with a seekable flag. Every
stream must set it consistently now, and an assertion in stream.c checks
this. Don't distinguish between streams that can only be forward or
backwards seeked, since we have no such stream types.
stream.start_pos was needed for optical media only, and (apparently) not
for very good reasons. Just get rid of it.
For stream_dvd, we don't need to do anything. Byte seeking was already
removed from it earlier.
For stream_cdda and stream_vcd, emulate the start_pos by offsetting the
stream pos as seen by the rest of mpv.
The bits in discnav.c and loadfile.c were for dealing with the code
seeking back to the start in demux.c. Handle this differently by
assuming the demuxer is always initialized with the stream at start
position, and instead seek back if initializing the demuxer fails.
Remove the --sb option, which worked by modifying stream.start_pos. If
someone really wants this option, it could be added back by creating a
"slice" stream (actually ffmpeg already has such a thing).
Fix all include statements of the form:
#include "libav.../..."
These come from MPlayer times, when FFmpeg was somehow part of the
MPlayer build tree, and this form was needed to prefer the local files
over system FFmpeg.
In some cases, the include statement wasn't needed or could be replaced
with mpv defined symbols.
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.
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).
Since m_option.h and options.h are extremely often included, a lot of
files have to be changed.
Moving path.c/h to options/ is a bit questionable, but since this is
mainly about access to config files (which are also handled in
options/), it's probably ok.
The tmsg stuff was for the internal gettext() based translation system,
which nobody ever attempted to use and thus was removed. mp_gtext() and
set_osd_tmsg() were also for this.
mp_dbg was once enabled in debug mode only, but since we have log level
for enabling debug messages, it seems utterly useless.
The problem with DVD/BD and playback resume is that most often, the
filename is just "dvd://", while the actual path to the DVD disk image
is given with --dvd-device. But playback resume works on the filename
only.
Add a pretty bad hack that includes the path to the disk image if the
filename starts with dvd://, and the same for BD respectively. (It's a
bad hack, but I want to go to bed, so here we go. I might revert or
improve it later, depending on user feedback.)
We have to cleanup the global variable mess around the dvd_device.
Ideally, this should go into MPOpts, but it isn't yet. Make the code
paths in mplayer.c take MPOpts anyway.
The way the url_options field was handled was not entirely sane: it's
actually a flexible array member, so it points to garbage for streams
which do not initialize this member (it just points to the data right
after the struct, which is garbage in theory and practice). This was
not actually a problem, since the field is only used if priv_size is
set (due to how this stuff is used). But it doesn't allow setting
priv_size only, which might be useful in some cases.
Also, make the protocols array not a fixed size array. Most stream
implementations have only 1 protocol prefix, but stream_lavf.c has
over 10 (whitelists ffmpeg protocols). The high size of the fixed
size protocol array wastes space, and it is _still_ annoying to
add new prefixes to stream_lavf (have to bump the maximum length),
so make it arbitrary length.
The two changes (plus some more cosmetic changes) arte conflated into
one, because it was annoying going over all the stream implementations.
Dudemanguy
Kacper Michajłow
Christoph Heinrich
wm4
Dmitrij D. Czarkoff
Marcin Kurczewski
Bruno George Moraes