Matroska segment linking allows abusing Matroska files as playlists
without any actual video/audio/sub data, making files without any
clusters still useful for the frontend.
Relative seeks backwards didn't work too well with incomplete files, or
other files that are missing the seek index. The problem was that the
on-the-fly seek index generation simply added cluster positions as seek
entries. While this is perfectly fine, the seek code had no information
about the location of video key frames. For example, a 5 second long
cluster can have only 1 video key frame, which is located 4 seconds into
the cluster. Seeking backwards by one second while still located in the
same cluster would select this cluster as seek target again. Decoding
would resume with the key frame, giving the impression that seeking is
"stuck" at this frame.
Make the generated index aware of key frame and track information, so
that video can always be seeked in an idea way. This also uses the
normal block parsing code for indexing the clusters, instead of the
suspicious looking special code. (This code didn't parse the Matroska
elements correctly, but was fine for files with normal structure. Files
with corrupted clusters or clusters formatted for streaming were not
handled properly.)
Skipping is now quite a bit slower (takes about twice as long as
before), but it removes the special cased skipping code, and it's still
much faster (at least twice as fast) than libavformat. It needs to do
more I/O (no more skipping entire clusters, all data is read), and has
more CPU usage (more data needs to be parsed).
Move most code from demux_mkv_fill_buffer() to read_next_block(). The
former is supposed to read raw blocks, while ..fill_buffer() reads
blocks and turns them into packets.
Somehow this was setup such that a BlockGroup can be incrementally
read (at least in theory). This makes no sense, as BlockGroup can
contain only one Block (despite its name). There's no need to read
this incrementally, and makes the code confusing for no gain.
Read all the BlockGroup sub-elements with a single function call,
without keeping global state for BlockGroup parsing.
The code for reading block data was duplicated. Move it into a function.
Instead of returning on error (possibly due to corrupt data) and
signalling EOF, continue by trying to find the next block. This makes
error handling slightly simpler too, because you don't have to care
about freeing the current block. We could still signal EOF in this case,
but trying to resync sounds better for dealing with corrupted files.
Matroska files prepared for streaming have clusters with unknown size.
These files are pretty rare, see e.g. test4.mkv from the official
Matroska test file collection.
The end positions of the current cluster and block were managed by
tracking their size and how much of them were read, instead of just
using the absolute end positions.
I'm not sure about the reasons why this code was originally written
this way. One obvious concern is reading from pipes and such, but the
stream layers hides this. stream_tell(s) works even when reading from
pipes. It's also a fast call, and doesn't involve the stream
implementation or syscalls. Keeping track of the cluster/block end is
simpler and there's no reason why this wouldn't work.
Incomplete files don't have a valid index, because the index is usually
located near the end of a file. In this case, an index is created on the
fly during demuxing, or when seeks are done.
This used a completely different code path, which leads to unnecessary
complications and code duplication. Use the normal index data structure
instead. The seeking code at the end of seek_creating_index() (in this
commit renamed to create_index_until()) is removed. The normal seek code
does the same thing instead.
The condition that checked whether the chapters are out of order and
should be sorted was inverted. This likely wasn't noticed in testing,
because even if the chapters are unsorted, if the last two chapters
were sorted, the rest got sorted too.
Instead of doing this silly check, always sort the chapters after
demuxer initialization. Also make sure the sort order is stable in case
chapter start times are the same (original_index check).
CC demux/demux.o
demux/demux.c: In function 'demuxer_switch_track':
demux/demux.c:1241:29: warning: array subscript is above array bounds [-Warray-bounds]
int new_id = demuxer->ds[type]->id;
^
No subtitle selected was supposed to disable the preroll logic
completely. However, the packet skipping logic was not properly enabled,
so the demuxer would still return subtitle packets from before the seek
target timecode. This shouldn't matter at all in practice, but fixing
this makes the code clearer.
Makes sure that seeking to a given time position shows the subtitle at
that position. This can fail if the subtitle packet is not close enough
to the seek target. Always enabled for hr-seeks, and can be manually
enabled for normal seeks with --mkv-subtitle-preroll.
This helps displaying subtitles correctly with ordered chapters. When
switching ordered chapter segments, a seek is performed. If the subtitle
is timed slightly before the start of the segment, it normally won't be
demuxed. This is a problem with all seeks, but in this case normal
playback is affected. Since switching segments always uses hr-seeks,
the code added by this commit is always active in this situation.
If no subtitles are selected or the subtitles come from an external
file, the demuxer should behave exactly as before this commit.
Commit 546ae23 fixed aspect ratio if the DisplayWidth or DisplayHeight
elements were missing. However, some bogus files [1] can have these
elements present in the file, but set to 0. Use 1:1 pixel aspect for
such files.
[1] https://ffmpeg.org/trac/ffmpeg/ticket/2424
Commit ac1c5e6 (demux_mkv: improve robustness against broken files)
added code to skip to the next cluster on error conditions. However,
reaching normal EOF triggers this code as well, so explicitly check
for EOF before this happens. Note that the EOF flag is only set _after_
reading the last byte, so EOF needs to be checked after the fact. (Or
in other words, we must check for EOF after the ebml_read_id() call.)
(To answer the question why reading packets actually reaches EOF, even
if there's the seek index between the last packet and the end of the
file: the cluster reading code skips the seeking related EBML elements
as normal part of operation, so it hits EOF gracefully when trying to
find the next cluster.)
Fixes test7.mkv from the Matroska test file collection, as well as some
real broken files I've found in the wild. (Unfortunately, true recovery
requires resetting the decoders and playback state with a manual seek,
but it's still better than just exiting.)
If there are broken EBML elements, try harder to skip them correctly.
Do this by searching for the next cluster element. The cluster element
intentionally has a long ID, so it's a suitable element for
resynchronizing (mkvmerge does something similar).
We know that data is corrupt if the ID or length fields of an element
are malformed. Additionally, if skipping an unknown element goes past
the end of the file, we assume it's corrupt and undo the seek. Do this
because it often happens that corrupt data is interpreted as correct
EBML elements. Since these elements will have a ridiculous values in
their length fields due to the large value range that is possible
(0-2^56-2), they will go past the end of the file. So instead of
skipping them (which would result in playback termination), try to
find the next cluster instead. (We still skip unknown elements that
are within the file, as this is needed for correct operation. Also, we
first execute the seek, because we don't really know where the file
ends. Doing it this way is better for unseekable streams too, because
it will still work in the non-error case.)
This is done as special case in the packet reading function only. On
the other hand, that's the only part of the file that's read after
initialization is done.
Fixes test4.mkv from the Matroska test file collection.
demux_mkv_open() contains a loop that reads header elements. It starts
by reading the EBML element ID with ebml_read_id(). If there is broken
data in the header, ebml_read_id() might return EBML_ID_INVALID.
However, that is not handled specially, and the code for handling
unknown tags is invoked. This reads the EBML element length in order to
skip data, which, if the EBML ID is broken, is entirely random. This
caused a seek beyond the end of the file, making the demuxer fail.
So don't skip any data if the EBML ID was invalid, and simply try to
read the next element. ebml_read_id() reads at least one byte, so the
parsing loop won't get stuck.
All in all this is rather questionable, but since this affects error
situations only, makes behavior a bit more robust (no random seeks), and
actually fixes at least one sample, it's ok.
libavformat's demuxer handled this.
The code modified by this commit is supposed to prevent demuxing the
whole file when cover art is present. (The problem with cover art is
that the ffmpeg libavformat API doesn't signal video EOF correctly - so
we try to read more packets to find the next video frame, which results
in demuxing and queuing the whole audio stream.)
This caused regressions for files with extremely high audio offset (see
github issue #46). MY conclusion is that this cover art crap doesn't
work, and this is just another case of completely insane ffmpeg/libav
API.
Disable the hack in all cases, unless a cover art video track is
selected. Maybe I'll handle cover art directly in the frontend later, so
that we don't have to rely on whatever libavformat does.
Unfortunately, this also makes behavior with equally insane mp4 files
with sparse video tracks worse, but this issue takes priority.
Doing 'mpv mf://*' in a file with directories would crash, because even
though directories are skipped, the corresponding file entry is just
left at NULL, leading to a segfault on access. So explicitly skip NULL
entries.
FFmpeg recently changed how it writes Opus-in-Matroska to match
the A_OPUS/EXPERIMENTAL name that mkvmerge uses, with the caveat
that things will change and compatibility with old files can get
worked out when the spec is finalized.
This adds both A_OPUS and A_OPUS/EXPERIMENTAL so that *hopefully*
it can play both the newer files that use A_OPUS/EXPERIMENTAL, and
older ones muxed by FFmpeg that were simply A_OPUS, since this is
also what FFmpeg seems to be doing to handle the situation.
r_frame_rate was deprecated and was finally removed from Libav and
FFmpeg git.
Not sure what's the correct replacement. avg_frame_rate may or may not
be worse than the fallback of using the time_base as guess. The
framerate is mostly unused, but needed for frame-based subtitles and for
encoding. (It appears encoding guesses a timebase based on the FPS, and
I'm not sure why we don't just use the source timebase.)
The old names have been deprecated a while ago, but were needed for
supporting older ffmpeg/libav versions. The deprecated identifiers
have been removed from recent Libav and FFmpeg git.
This change breaks compatibility with Libav 0.8.x and equivalent
FFmpeg releases.
Emulate percentage-seeks (SEEK_FACTOR) as normal time-seeks if possible.
This fixes some issues with (let's call it) low quality implementations
of SEEK_FACTOR (e.g. demux_mkv basically interprets this as byte-seek,
and also seeking to 99.9% makes it seek back to the start).
For weird MPEG formats the demuxer level SEEK_FACTOR is still used.
These formats, which can have timestamp resets, are identified by
setting demuxer->ts_resets_possible to true.
Also, have get_current_pos_ratio() follow the same rules, and calculate
the percentage position with the file position if timestamp resets are
possible.
This actually fixes percentage-seeks in .ts files with demux_lavf.c.
This kind of seek is not really used now, but it will be more important
when we add a progress bar.
Note: seeking in chained ogg files is still completely broken. The main
issue is that ffmpeg doesn't provide a sane API for dealing with
timestamp resets, and trying to do byte seeks with ogg confuses demuxer
and decoder (or something like this) and just does random things.
(Tested with two concatenated flac-in-ogg files).
AVFormatContext.start_time is sometimes AV_NOPTS_VALUE, such as when
playing FLAC files. (For most other file formats it's set to 0, even if
the format doesn't support arbitrary start times.)
OPT_BASE_STRUCT defines which struct the OPT_ macros (like OPT_INT etc.)
reference implicitly, since these macros take struct member names but no
struct type. Normally, only cfg-mplayer.h should need this, and other
places shouldn't be bothered with having to #undef it.
(Some files, like demux_lavf.c, still store their options in MPOpts. In
the long term, this should be removed, and handled like e.g. with VO
suboptions instead.)
The percent position is used for the OSD, the status line, and for the
OSD bar (shown on seeks). By default, the PTS of the last demuxed packet
was used to calculate it. This led to a "jumpy" display when the
percentage value (casted to int) was changing. The reasons for this were
the presence of video frame reordering (packet PTS is not monotonic), or
getting PTS values from different streams (like audio/subs).
Since these rely on PTS values and correct file durations anyway,
simplify it by calculating it with the current playback position in
mplayer.c instead.
And support the PIX_FMT_MONOWHITE pixel format. (This is really weird:
unlike PIX_FMT_MONOBLACK, it uses white pixels. I have no idea why
libavcodec doesn't just convert the pixel format on the fly, instead of
bothering everyone with really special pixel formats.)
Seeking before the start of a .flac file (such as seeking backwards when
the file just started) generates a bunch of decoding errors and audible
artifacts. Also, the audio output doesn't match the reported playback
position. The errors printed to the terminal are:
[flac @ 0x8aca1c0]invalid sync code
[flac @ 0x8aca1c0]invalid frame header
[flac @ 0x8aca1c0]decode_frame() failed
This is most likely a problem with the libavformat API. When seeking
with av_seek_frame() fails, the demuxer can be left in an inconsistent
state. ffplay has the same issue [1].
Older versions of mpv somehow handled this fine. Bisection shows that
commit b3fb7c2 caused this regression by removing code that retried
failed seeks with an inverted AVSEEK_FLAG_BACKWARD flag. This code was
removed because it made it harder to stop playback of a file by seeking
past the end of the file (expecting this is rather natural when skipping
through multiple files by seeking, and the internal mplayer demuxers
also did this).
As a workaround, re-add the original code, but only for the backwards
seeking case.
Also note that the original intention of the code removed in b3fb7c2 was
not dealing with this case, but something else. It also had to do with
working around weird libavformat situations, though. It's not perfectly
clear what exactly. See commit 1ad332f.
[1] https://ffmpeg.org/trac/ffmpeg/ticket/2282
Apparently this cuases trouble for legacy demuxers. demux_mpg stopped
doing PCM audio. (The problem was probably that it read a bunch of
video packets on detection, and then the sparse video hack prevented
audio packets from being read, because it looked like there were no
more audio packets. With sparse video, this normally helps not reading
too many audio packets.)
Since the legacy demuxers do not need this hack, enable it for
demux_lavf and demux_mkv only.
Some additional hacks that were needed to handle legacy demuxers can be
removed, making the code simpler.
Also see commit 4a40eed.
There should be no functional changes, except that way how avoiding
spamming the terminal with the overflow warning is handled changes a
bit.
The removed check for ds->eof looks suspicious, but it should be
redundant now.
Commit 4d016a9 changed how demuxers report the codec of each stream.
Some of that was missed in video.c, which is important for legacy
demuxers (demux_mpg was broken by this, which is needed for DVD
playback).
Not sure about the ASF/AVI related change, but this is also a legacy
demuxers only codepath.
Instead of putting codec header data into WAVEFORMATEX and
BITMAPINFOHEADER, pass it directly via AVCodecContext. To do this, we
add mp_copy_lav_codec_headers(), which copies the codec header data
from one AVCodecContext to another (originally, the plan was to use
avcodec_copy_context() for this, but it looks like this would turn
decoder initialization into an even worse mess).
Get rid of the silly CodecID <-> codec_tag mapping. This was originally
needed for codecs.conf: codec tags were used to identify codecs, but
libavformat didn't always return useful codec tags (different file
formats can have different, overlapping tag numbers). Since we don't
go through WAVEFORMATEX etc. and pass all header data directly via
AVCodecContext, we can be absolutely sure that the codec tag mapping is
not needed anymore.
Note that this also destroys the "standard" MPlayer method of exporting
codec header data. WAVEFORMATEX and BITMAPINFOHEADER made sure that
other non-libavcodec decoders could be initialized. However, all these
decoders have been removed, so this is just cruft full of old hacks that
are not needed anymore. There's still ad_spdif and ad_mpg123, bu neither
of these need codec header data. Should we ever add non-libavcodec
decoders, better data structures without the past hacks could be added
to export the headers.
