Menu-domain seeks: menu PGCs sequence intro/transition segments and
the looping button segment as programs of one PGC, and the menu
subpicture is a one-shot packet at a cell start. dvdnav's time search
lands mid-cell (erratically so in menu VOBs, which often lack usable
time maps), skipping the subpicture and leaving the menu without
visible buttons until its next loop. Map menu seeks to program skips.
Title seeks: dvdnav_time_search() interpolates the target from cell
durations. On VBR content the landing can fall further short than the
seek step, so repeated relative seeks converge to a fixed point and
never advance. Use dvdnav_jump_to_sector_by_time(), which resolves
through the VTS time maps, with dvdnav_time_search() as the fallback for
titles without one. Accurate landings also let the hr-seek margin
shrink.
A menu change keeps the VM's selected-button register unless the link
command carried a button number or the new button set forces one via
fosl_btnn. Select the first button in that case.
Passing a disc image directly (e.g. `mpv disc.iso`) previously fell
through to FFmpeg. Route it to the matching disc backend instead,
like the VIDEO_TS.IFO/AUDIO_TS.IFO/BDMV redirectors already do.
When the disc VM jumps (menu activation, end of title), the demuxer
and player have to flush and reinitialize exactly at the boundary.
Hold an EOF at the boundary until the demuxer acks it, and resync
the player with a regular seek, which already orders flush, decoder
reset and restart. d_seek recognizes the held boundary and releases
it instead of repositioning the VM.
Also log the VM domain in nav event messages.
The menu/highlight state is filled by event processing on the demuxer
thread and read by nav commands and controls on the player thread. Add
a mutex around it.
BD_EVENT_POPUP was tracked into has_popup, which never grew a
consumer. BD_EVENT_MENU's menu_event_active only fed the menu_active
condition, where it was subsumed by the visible-overlay check. Remove
all three.
The highlight rectangle and palette were passed around as loose fields
in three places. Bundle them into a struct, pass the whole nav state to
the sd_lavc control.
Use dvdnav_open2() with a logger callback instead of letting libdvdnav
print to stderr. This bumps the libdvdnav requirement to 6.1.0. 6.1.0 is
from 2019, it's resonable to request it by now.
Store the duration in 90 kHz ticks instead of converting back and
forth. This also fixes STREAM_CTRL_GET_CURRENT_TIME's failure check,
which previously compared the already-converted value against -1 and
could never trigger.
Menu activations, HOP_CHANNEL and VTS changes jump the source position.
On this strictly forward stream the demuxer cannot tell where the old
content ends, so buffered pre-jump data would mix with post-jump data.
Return a single EOF at the boundary so the demuxer drains and resets
before any new content flows.
DVDNAV_STILL_FRAME means the VM is holding a frame indefinitely (menu
pages, some logos) or for a timed duration. Report the indefinite case
via nav state so the player holds playback at EOF instead of ending
the file, and skip timed stills, which would otherwise stall playback.
The disc VM advances when the stream is read, so in nav mode the cache
must not run ahead of what the user is seeing. Never read ahead (a
looping menu is endless). Never satisfy seeks from the cache either.
This applies to the whole disc session, not only while a menu is on
screen. The VM can jump at any time (BD-J timers, end of title), so
the cache must never run ahead of playback.
Activations still must be able to drive the VM while nothing is
consumed. demux_drive_nav() forces a single read for them.
The disc VM selects audio and subpicture streams itself (menu SPU
highlights, title-authored stream changes on jumps). Follow the VM's
selection on every hop, and turn subtitles on/off with the disc's
sub_visible flag.
The sync only applies while the corresponding track selection is on
auto. An explicitly chosen track (--aid/--sid or runtime cycling) is
never overridden.
Drive libdvdnav's menu state through the new disc-nav protocol so the
player can show and interact with VMGM and VTSM menus.
STREAM_CTRL_NAV_CMD maps the nav actions onto libdvdnav.
STREAM_CTRL_GET_NAV_STATE reports whether a menu with buttons is on
screen, the highlight rectangle and palette of the focused button, and
the ids of the disc-selected audio/SPU streams.
Menu mode is entered by opening with dvd://menu or --disc-menu, which
starts at the disc's root menu instead of a title.
While here, drop the message to MP_VERBOSE and fix its wording.
"switched to title" is misleading because this is a VTS-change event,
not a title change.
Since the option system now handles all the path expansion
automatically, these recent changes can be reverted for simplicity.
This reverts commit be15be3a83.
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 -\}`
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
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 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
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 warning seems to be designed well. It doesn't seem to warn on
fallthrough-only case statements, so it's compatible to well written
code.
stream_dvdnav.c had an obscure bug in inactive code, fix it.
stream_dvb.c is the only place where it intentionally falls through, I
guess I'll just leave it alone.
The dvdnav API reads in 2K blocks (dvdnav_get_next_block()). The mpv
wrapper (fill_buffer() in this file) expects that the read size done by
the mpv core is at least 2K for this reason. If not, it returns an
error.
This used to be OK, because there was a thing called section alignment
in the core code. This was removed because the core shouldn't suffer
from optical disc idiosyncrasies. Which means that ever since, it has
been working only by coincidence, or maybe not at all.
Fixing this would require keeping a buffer in the priv struct, and
returning it piece by piece if the core makes smaller reads. I have no
intention of writing such code, so add an error message asking for a
patch. If anyone actually cares about DVD, maybe it'll get fixed.
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.
The demuxer cache is the only cache now. Might need another change to
combat seeking failures in mp4 etc. The only bad thing is the loss of
cache-speed, which was sort of nice to have.
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.
Kacper Michajłow