The outer streams live for as long as the disc does, but each program
brings its own set. Playing a BD playlist without the Dolby Vision
enhancement layer left the outer EL stream selected with no slave
stream mapped to it.
Normally when there is no EL there is no track either, but since it was
exposed in PMT we still have the track, while VM may decide to unmap it.
This is bit of workaround, but harmless one.
Media can stop providing a stream mid-playback, for example a disc
program that does not carry the Dolby Vision enhancement layer the
previous one had. Since mpv always try to keep at least 1 packet
buffered in all tracks, it can keep reading it till EOF.
mp_pin_connect() clears manual_connection on the pins it links, so a
filter that stops being the first or the last one leaves the chain
unable to drive its own ends. Nothing has changed the ends at runtime
so far, so this went unnoticed.
The BD-J VM progresses only on reads. With playback at EOF or on a
held still nothing reads anymore, applet playlist switches never
surface and menus freeze, libbluray documents this polling requirement
for idle states. Drive one nav read per tick and keep the core awake.
The slave demuxer latches its EOF and stops touching the stream, so
the read path peeks the stream itself to run its event loop. Poll the
same way while paused in a menu, highlight redraws would otherwise
wait for the next core wakeup. dvdnav stills release on user input,
not reads, and the pump bypasses the cache limits, so no pumping
outside these states.
A seek repositions the disc under the live slave demuxer, and mpegts
spliced its buffered PES state together with data of the new position
into broken packets, an AU worth of decode errors per seek. mpegts
already flushes all per-PID packet state when it sees the avio
position jump, so restart the byte position counters on the seek and
resync the avio position to the stream in drop_buffers.
BD-J applets seek their player and restart playlists without any event
reaching the read loop, menu loop points do this constantly. Compare
bd_tell against the end of the previous read and treat a mismatch as a
jump. Checking before the read keeps the new position's head out of
the old slave demuxer, the forward-only stream cannot re-read it. A
read delivered together with a jump event can already carry data of
the new position, the same check drops it.
While the disc is between positions the open only probes an EOF and
fails, and retrying at the read rate logged a warning every attempt.
Peek before opening, this pumps the stream's event loop and the peeked
bytes stay buffered for the probe.
The release of a still can already sit in the event queue behind the
event that announced it. Holding at first sight would miss it and
freeze the menu until user input. STILL_TIME is re-emitted on every
read while the still holds and does not count as progress.
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.
The resync seek that follows a disc-initiated jump must not reposition
the VM. On BD the jump is handled out-of-band by reopening the slave
demuxer on the packet-read path, and the VM already sits at the jump
destination. Repositioning it with the (stale) seek target time would
hop to the wrong place. Adopting the discontinuity counter here would
leave the old slave demuxer parsing the new playlist's data with the
wrong codec context. Flush our side only, and keep the counter stale so
the read path still performs the reopen.
Discs restart the in-stream timestamps at cell/segment boundaries. The
single global base_dts/last_dts pair rebased on any |diff| >= 5s between
consecutive packets of any stream, which broke down in several ways:
- Backward resets smaller than the threshold (e.g. a 1.5s menu
transition cell followed by the looping button cell) were not detected
at all, producing non-monotonic playback timestamps.
- The global last_dts ping-ponged between streams that cross a boundary
at different packet positions (interleave skew), rebasing on nearly
every packet and spamming the log.
- Menu subpictures timestamped for the next cell were mapped with the
previous cell's offset and displayed at the wrong time.
Map each segment as a timeline "generation" with its own raw->playback
offset instead. Boundaries are detected per stream, as a backward step
beyond muxing jitter or a forward gap that would stall playback (sparse
still-image streams exempt). The previous generation stays valid until
every stream has moved past the boundary, and the new generation is
placed so the triggering stream continues seamlessly.
DVD subpictures are muxed around cell boundaries and their raw
timestamps alone cannot tell whether they continue the current segment
or belong to the next one. Defer each by one a/v packet (or EOF) and
let the packet that follows settle which generation it belongs to.
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.
Audio DVDs commonly author each song as a chapter whose video is a
single (or more) still frame, with only the audio really interleaved.
Detect this at runtime and mark the video still_image. The player then
treats it as sparse, and the starved stream stops forcing eager reads
that would scan through the source hunting for the next still.
The player's default track selection picks the first probed audio
track, but the substream the disc's current PGC actually plays is
decided by the DVD VM and may be a different one. On discs whose menu
domain plays LPCM while the mux also carries an (unreferenced) AC3
substream, mpv selected the AC3 track, which has no data. We have to
keep track of what VM wants to output and what LAVF expects.
BoatingCloud