| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
These were found by the cppcheck and scan-build static analyzers. Most
of these aren't interesting (the 2 previous commits fix some interesting
cases found by these analyzers), and they don't nearly fix all warnings.
(Most of the unfixed warnings are spam, things MPlayer never cared
about, or false positives.)
|
|
|
|
| |
No functional change.
|
|
|
|
|
|
| |
Also, mark demuxer as not capable if DVD playback is done. The problem
with DVD is that playback time (stream_pts) is not reported frame-exact,
and the time is a "guess" at best.
|
|
|
|
|
| |
Might help mapping tracks correctly to stream_bluray, fixing the
issue with the track language not being reported.
|
|
|
|
|
|
|
|
|
|
| |
With the commit "demux_lavf: fix DEMUXER_CTRL_RESYNC", DVD playback
seems to work nicely with demux_lavf, and maybe works even better than
with demux_mpg.
The old demuxer can be forced with: --demuxer=mpegps
If no regressions surface, demux_mpg.c will be deleted later.
|
|
|
|
|
|
|
|
|
| |
This used the libavformat current position, instead of the mp stream
(which reflects current DVD/Bluray read position). This was broken,
because libavformat won't update its position by calling the user's
stream callbacks, negating the whole point of DEMUXER_CTRL_RESYNC.
Now DVD playback with libavformat seems to work relatively well.
|
|
|
|
|
|
|
|
| |
demux_mpg did the same, and doing this in demux_lavf fixes DVD playback
when using this demuxer.
Additionally this might make bluray work better in the future (but for
now, bluray playback doesn't change as it doesn't report stream PTS yet).
|
|
|
|
|
| |
Needed for bluray and dvd. demux_mpg (used for dvd playback) did this
manually for the time length.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
DVD playback uses a demuxer that signals to the frontend that timestamp
resets are possible. This made the frontend calculate the OSD playback
position based on the byte position and the total size of the stream.
This actually broke DVD playback position display. Since DVD reports a
a linear playback position, we don't have to rely on the demuxer
reported position, so disable this functionality in case of DVD
playback. This reverts the OSD behavior with DVD to the old behavior.
|
|
|
|
|
|
|
|
|
|
|
| |
The stream ID handling as it was changed in commit 654c34f was still
a little bit insane, and caused a regression with the cover art hack
(the stream set in demux->video->sh was incorrect for demux_lavf).
Simplify by always using stream_index for demux_stream->id, and getting
rid of that tid thing. It turns out that the id for subtitles isn't
special either (maybe demux_ts.c was the only thing left that required
this).
|
|
|
|
| |
This bug was introduced in commit 06eee1b.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This check was always false:
if (num == EBML_UINT_INVALID)
Fix it by using the proper type for the num variable.
This case actually doesn't really matter, and this is just for hiding
the warning and for being 100% correct.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When trying to seek before the start of the file, which usually happens
when using the arrow keys to seek to the start of the file, external
libavformat demuxed subtitles will be invisible. This is because seeking
in the external subtitle file fails, so the subtitle demuxer is left in
a random state.
This is actually similar to the normal seeking path, which has some
fallback code to handle this situation. Add such code to the subtitle
seeking path too.
(Normally, all demuxer support av_seek_frame(), except subtitles, which
support avformat_seek_file() only. The latter was meant to be the "new"
seeking API, but this never really took off, and using it normally seems
to cause worse seeking behavior. Or maybe we just use it incorrectly,
nobody really knows.)
|
|
|
|
|
| |
Otherwise audio/video/sub track handling code would dereference the NULL
pointer.
|
|
|
|
| |
Even if the codec is unknown.
|
|
|
|
| |
Completely mysterious, and its values were never actually used.
|
|
|
|
|
|
| |
The only reason this existed was the parsing code. Even though it
could have been used for video, it's audio-only, so just move this
to sh_audio_t.
|
|
|
|
|
|
|
|
|
| |
Get rid of the 1-char subtitle type field. Use sh_stream->codec instead
just like audio and video do. Use codec names as defined by libavcodec
for simplicity, even if they're somewhat verbose and annoying.
Note that ffmpeg might switch to "ass" as codec name for ASS, so we
don't bother with the current silly "ssa" name.
|
|
|
|
|
| |
Only demux_ts.c used sid in one case, replace that by reading the same
value from another location.
|
|
|
|
|
|
| |
MP_INPUT_BUFFER_PADDING_SIZE and FF_INPUT_BUFFER_PADDING_SIZE are both
16. The doxygen for FF_INPUT_BUFFER_PADDING_SIZE says only the first 23
bits must to be 0, but this is probably a lie.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the stream handling mess by using a single list for all
stream types.
One consequence is that new streams are always set to AVDISCARD_ALL,
which could be an issue if packets are read before initializing other
streams. However, this doesn't seem to an issue for various reasons,
so we don't do anything about it.
The new code strictly assumes that libavformat never removes or
reorders streams once added to AVFormatContext->streams. Undefined
behavior will result if it does.
|
|
|
|
|
|
|
| |
mkv_track_t now references sh_stream directly, instead of using an ID.
Also remove all accesses to demux_stream (demuxer->video etc.).
Remove some slave-mode things on the way, like "ID_SID_..." messages.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some preparations to simplify demux_mkv and demux_lavf.
struct demux_stream manages state for each stream type that is being
demuxed (audio/video/sub). demux_stream is rather annoying, especially
the id and sh members, which are often used by the demuxers to determine
current stream and so on. Demuxers don't really have to access this,
except for testing whether a stream is selected and to add packets.
Add a new_sh_stream(), which allows creating streams without having the
caller specify any kind of stream ID. Demuxers should just use sh_stream
pointers, instead of multiple kinds of IDs and indexes.
|
|
|
|
|
|
| |
Cleanup based on results from cppcheck-1.59
Reduce the scope of several variables
Replace 2 calloc/realloc calls with a single malloc
|
|
|
|
|
|
| |
Since demux_mkv queries the demuxer state when reading packets, track
switching is completely passive. Cycling etc. is done by the frontend.
As result, all track switching code can be removed.
|
|
|
|
| |
This interfaces assumes track switching is always successful.
|
|
|
|
| |
Possibly once needed, now it's just redundant code.
|
| |
|
|
|
|
| |
Note that ffmpeg doesn't provide a decoder by default yet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Matroska files can contain multiple segments, which are literally
further Matroska files appended to the main file. They can be referenced
by segment linking.
While this is an extraordinarily useless and dumb feature, we support it
for the hell of it.
This is implemented by adding a further demuxer parameter for skipping
segments. When scanning for linked segments, each file is opened
multiple times, until there are no further segments found. Each segment
will have a separate demuxer instance (with a separate file handle
etc.).
It appears the Matroska spec. has an even worse feature for segments:
live streaming can completely reconfigure the stream by starting a new
segment. We won't add support for it, because there are 0 people on this
earth who think Matroska life streaming is a good idea. (As opposed to
serving Matroska/WebM files via HTTP.)
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
Also change the extracting of the lace type bitfield from flags to
make it more apparent that the value range is 0-3.
|
|
|
|
|
| |
The lace number is stored with an offset of 1, so the maximum number
of laces is 255+1=256.
|
| |
|
|
|
|
| |
Should help avoiding out-of-bounds reads.
|
|
|
|
|
|
|
|
| |
Avoid messy memory management and error handling.
remove tmp_lace_buffer non-sense
Not sure how my mind got 8k, or how this made sense at all.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 parts of the Block element parsing to read_block(). This way
read_block() can return block time and track information in
struct block_info.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This pre-allocation looked tricky and awkward. Use MP_TARRAY_APPEND(),
which makes the code simpler. This even keeps the pre-allocation.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|