| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the delay when switching audio tracks in mkv or mp4 files.
Other formats are not enabled, because it's not clear whether the
demuxers fulfill the requirements listed in demux.h. (Many formats
definitely do not with libavformat.)
Background:
The demuxer packet cache buffers a certain amount of packets. This
includes only packets from selected streams. We discard packets from
other streams for various reasons. This introduces a problem: switching
to a different audio track introduces a delay. The delay is as big as
the demuxer packet cache buffer, because while the file was read ahead
to fill the packet buffer, the process of reading packets also discarded
all packets from the previously not selected audio stream. Once the
remaining packet buffer has been played, new audio packets are available
and you hear audio again.
We could probably just not discard packets from unselected streams. But
this would require additional memory and CPU resources, and also it's
hard to tell when packets from unused streams should be discarded (we
don't want to keep them forever; it'd be a memory leak).
We could also issue a player hr-seek to the current playback position,
which would solve the problem in 1 line of code or so. But this can be
rather slow.
So what we do in this commit instead is: we just seek back to the
position where our current packet buffer starts, and start demuxing from
this position again. This way we can get the "past" packets for the
newly selected stream. For streams which were already selected the
packets are simply discarded until the previous position is reached
again.
That latter part is the hard part. We really want to skip packets
exactly until the position where we left off previously, or we will skip
packets or feed packets to the decoder twice. If we assume that the
demuxer is deterministic (returns exactly the same packets after a seek
to a previous position), then we can try to check whether it's the same
packet as the one at the end of the packet buffer. If it is, we know
that the packet after it is where we left off last time.
Unfortunately, this is not very robust, and maybe it can't be made
robust. Currently we use the demux_packet.pos field as unique packet
ID - which works fine in some scenarios, but will break in arbitrary
ways if the basic requirement to the demuxer (as listed in the demux.h
additions) are broken. Thus, this is enabled only for the internal mkv
demuxer and the libavformat mp4 demuxer.
(libavformat mkv does not work, because the packet positions are not
unique. Probably could be fixed upstream, but it's not clear whether
it's a bug or a feature.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, some packets could return the same file position if they were
split off from a Matroska-level packet. This was perfectly fine, because
the file position isn't used for anything overly important (it uses it
to estimate playback position if no other information is available). The
following commit will use the demux_packet.pos field as unique ID (as a
simplification), so make the demuxer export more finegrained
information.
Also, the last_filepos field didn't have to be global, at least not
anymore.
|
| |
|
|
|
|
| |
Granted, this doesn't help much with anything, other than the hate-
driven desire to remove or at least reduce anything that has to do with
RealMedia.
|
| |
|
|
|
|
|
|
|
|
| |
Reindent the whole handle_realaudio() function, and make the surrouding
if block return early instead.
Also contains some cosmetics to the sipr swapping, which hopefully does
not change the semantics, but is untested (the kind of cosmetic changes
everyone loves so much). May the person responsible for sipr rot in
hell. (It was probably done to obfuscate the codec?)
|
| |
|
|
|
|
|
| |
Staring at the code, it doesn't look like the extra code for "normal"
audio is needed. Most of it looks like artifacts from the previous code
structure (much of it was added in the initial commit). I couldn't find
a sample that uses this code path to fully confirm this, though.
|
| |
|
|
|
|
|
|
| |
I suppose it could lead to subtle changes in behavior in presence of
realvideo files that change aspect radio. With the only sample I had
available, the behavior actually improved (azumi.mkv from the MPlayer
samples FTP; when starting playback in the middle it used the wrong
aspect ratio).
|
| |
|
|
|
|
| |
Appears to work, so we can drop some code. For some really odd reason,
the descrambling done on the timestamp requires millisecond units (due
to the "algorithm", not the libavcodec API).
|
| |
|
|
|
|
|
|
|
| |
Fixes vp9 missing timestamps. This requires a brand new libavcodec (the
patch for this was just applied to FFmpeg git master).
The timestamp mangling is applied to VP9 only. It'd probably work with
other codecs, but it's not needed. It could break in various ways, so
it has to be explicitly checked for every enabled codec.
|
| |
|
|
|
|
|
|
| |
Makes it somewhat more uniform, and breaks up the awfully deep nesting.
This implicitly changes multiple small details, rather than only moving
code around. In particular, this computes the packet fields first and
parses them afterwards, which is needed for the next commit.
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently, audio packets are always filtered as a whole. Since demux_raw
output a 1 second long packet, this could lead to large delays when
applying softvol volume. It could be fixed by splitting the frames the
decoder outputs before filtering them (like the old filter code used
to), but since this didn't cause any other problems yet, I'm going with
the simpler fix.
Fixes #1558.
|
| |
|
|
|
|
|
|
| |
The only reason why cdda:// goes through this wrapper-demuxer is so that
we add chapters to it. Most things related to seeking apply only to
DVD/BD, and in fact broke CDDA sekkability.
Fixes #1555.
|
| |
|
|
|
|
|
| |
Might fix behavior with mkv files that use ordered chapters and have
cover art tags. In my opinion, this should actually have worked (because
cover art pseudo-tracks are strictly appended), but I don't have a
sample file to test at hand.
|
| |
|
|
|
| |
Causes a lot of terminal spam on large folders and is not actually
useful except maybe for debugging.
|
| |
|
|
|
|
|
|
|
|
| |
If a file is unseekable (consider e.g. a http server without resume
functionality), but the stream cache is active, the player will enable
seeking anyway. Until know, client API user couldn't know that this
happens, and it has implications on how well seeking will work. So add a
property which exports whether this situation applies.
Fixes #1522.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Repurpose demuxer->filetype for this. It used to be used to print a
human readable format description; change it to a symbolic format name
and export it as property.
Unfortunately, libavformat has its own weird conventions, which are
reflected through the new property, e.g. the .mp4 case mentioned in the
manpage.
Fixes #1504.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pass through the seek flags to the stream layer. The STREAM_CTRL
semantics become a bit awkward, but that's still the least awkward
part about optical disc media.
Make demux_disc.c request relative seeks. Now the player will use
relative seeks if the user sends relative seek commands, and the
demuxer announces it wants these by setting rel_seeks to true. This
change probably changes seek behavior for dvd, dvdnav, bluray, cdda,
and possibly makes seeking useless if the demuxer-cache is set to
a high value.
Will be used in the next commit. (Split to make reverting the next
commit easier.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally the player doesn't read from unselected streams, so this should
be a no-op. But unfortunately, some broken files can severely confuse
the player, and assign the same demuxer stream to multiple front-end
tracks. Then selecting one of the tracks would deselect the other track,
with the end result that the demuxer stream for the selected track is
deselected. This could happen with mkv files that use the same track
number (which is of course broken). timeline_set_part() sets the tracks
using demuxer_stream_by_demuxer_id(), using the broken non-unique IDs.
The observable effect was that the player never quit, because
demux_read_packet_async() told the caller to wait some longer for new
packets. Fix by returning EOF instead.
Fixes #1481.
|
| |
|
|
|
|
|
|
| |
Reading IDs must be checked too. This was basically forgotten in commit
f3a978cd. Also set the *length parameter for ebml_parse_length() in some
error cases, which _really_ should happen.
Fixes #1461.
|
| |
|
|
|
|
|
|
|
|
| |
Apparently, originally this code was meant to be able to read past the
buffer somewhat, which is why the buffer allocation was padded by 8
byte. This is unclean and confuses valgrind. This probably could have
crashed with certain invalid files too.
Also revert the change added with 10a2f69; it should be not needed
anymore.
|
| |
|
|
| |
Fixes #1457.
|
| |
|
|
|
|
|
|
|
| |
The VP9 codec parser has a bug: it doesn't set the data/size pointers
passed to it. As I understand, it must always do this, and in fact, if
it doesn't some libavcodec generic code would be in trouble too.
This helps with #1448, but is not the full fix for it. The codec parser
must be fixed in libavcodec itself.
|
| |
|
|
|
| |
Not being able to use the 3x3 part of the matrix was annoying, so split
it into a float[3][3] matrix and a separate float[3] constant vector.
|
| |
|
|
|
|
|
| |
Removes an annoying "No video PTS! Making something up." warning.
Mark it as keyframe, which is needed to prevent strange behavior with
PNG. Also, don't leak the picture data.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For some codecs, we need to invoke a codec parser (because libavcodec
will run into trouble otherwise). This was done based on the Matroska
codec field.
But this ignores handling of vfw-muxed files, which use a pseudo-codec
to signal presence of vfw structures, which we must unmangle to get the
real codec. Handle this by rearranging the code.
This fixes at least mp3-in-mkv for vfw-muxed files; typically old files.
|
| |
|
|
| |
I guess these parsers still have a way to go...
|
| |
|
|
|
|
|
| |
This message can happen a lot for mkv files which index clusters in the
seekhead (which is also broken non-sense, but that's a different story).
Also remove a duplicate define from matroska.h.
|
| |
|
|
|
|
|
|
|
| |
There's no reason why parts of this demuxer would be in a separate
source file. The existence of this code is already somewhat questionable
anyway, so it may as well be dumped into a single file.
Even stranger that demux.c included mf.h for no reason (it was an
artifact from 2002 when the architecture was uncleaner).
|
| | |
|
| |
|
|
| |
Reuses the mime type table introduced in the previous commit.
|
| |
|
|
|
|
|
|
|
|
|
| |
The code could as well be in demux.c, but it's better to avoid
accidental clashes with demux_lavf.c.
FFmpeg provides no way yet to map a mime type to a codec, so do it
manually. (It _can_ map a mime type to an "input format", but not a
codec.)
Fixes #1374.
|
| |
|
|
| |
Fixes #1337.
|
| |
|
|
| |
Fixes #1192.
|
| |
|
|
| |
It's confusing. Whether the new behavior is less confusing... whatever.
|
| |
|
|
|
|
|
|
|
|
| |
These actually are harmless. Even if the data the reader is working on
is essentially random, it's treated like untrusted input data, so there
should be no harm.
But it upsets tools like valgrind.
Probably fixes #1329.
|
| |
|
|
|
|
|
|
|
|
| |
The most awesome codec, not.
The actual code for svq3 is actually just the part that checks for
MKV_V_QUICKTIME (no other QT-muxed codecs are supported). The rest is
minor refactoring, that actually improves the code in general.
This is just enough to support the 2 svq3-in-mkv sample files I have.
|
| |
|
|
|
|
|
| |
Also reject anything over INT_MAX; no particular reason for this upper
bound.
Fixes #1317.
|
| |
|
|
| |
Fuck.
|
| |
|
|
|
|
|
| |
This message was added in commit a0acb6ea. But it showed up in all sorts
of inappropriate contexts, such as when opening m3u from an unseekable
http URL, or playing DVDs. So I guess this didn't work out. Disabling it
again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
m3u files are normally just text files with a list of filenames. Nothing
actually mandates that there is a header. Until now, we've rejected such
files, because there's absolutely no way to detect them.
If nothing else claims the file, the extension is ".m3u", and if the
contents of the file look like text, then load it as m3u playlist. The
text heuristic is pretty cheap, but at least it should prevent trying
to load binary data as playlist. (Which would "work", but result in a
catastrophic user experience.)
Due to the text heuristic, UTF-16/32 files will be rejected (unless they
have a header), but I don't care.
|
| |
|
|
| |
Probably doesn't matter much in practice.
|
| |
|
|
| |
Even thouhg it was printed in verbose mode only, it was annoying.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was completely breaking any low-level caching. Change it so that at
least demuxer caching will work.
Do this by using the metadata cache mechanism to funnel through the menu
commands.
For some incomprehensible reason, I had to reorder the events (which
affects their delivery priority), or they would be ignored. Probably
some crap about the event state being cleared before it could be
delivered. I don't give a shit.
All this code sucks. It would probably be better to let discnav.c access
the menu event "queue" directly, and to synchronize access with a mutex,
instead of going through all the caching layers, making things
complicated and slow.
|
| |
|
|
|
|
|
|
| |
If EOF is reached after reading a line, the EOF flag is set. This was a
problem for the m3u code, which checked for EOF _after_ reading a line,
which will discard the last line read.
Also fix a typo in an unrelated part of the file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All of this is basically due to how MPlayer's codecs.conf worked. It
had a demuxer-interface based an AVI, using FourCCs and data structures
found in AVI. FourCCs were used to map streams to decoders. For codecs
not supported by AVI, "MPlayer internal" FourCCs were made up.
codec_tags.c is there to bridge demuxers written against the old API to
the mpv one. By now, only demux_mkv.c needs this (because demux_mkv is
the only serious demuxer left - preferably, we should use libavformat
for mkv too, but I can't see this happening any time soon, because
libavformat _still_ doesn't support segment linking). But the codec
tables are full of weird stuff automatically extracted from the old
codecs.conf tables. Most of it isn't needed for mkv.
Remove all custom tags, readd those used by demux_mkv.c internally
(see vinfo and mkv_audio_tag tables). The rest is handled by the
tables provided by libavformat, which includes AVI and QT tags.
|
| |
|
|
|
|
|
|
|
| |
It was more complicated than necessary.
The behavior changes slightly. Now it might pass through extradata when
it didn't before (hopefully harmless), and doesn't fail with an error if
extradata is not available, even though it's needed (harmless, will fail
either way).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The if branch has a weak check to test whether the codec_id is the short
ID, and handles the long IDs in the else branch. The long IDs are all
longer than 12 bytes long, so hardcoding the string offset to get the
trailing part of the name makes sense. But the if condition checks for
another thing, which could get the else branch run even if the codec_id
is short.
Fix the bogus control flow and check if the codec_id is long enough. One
of these checks could be considered redundant, but include them both for
defensive coding.
|
| |
|
|
| |
Makes time display work for some raw audio formats (*.shn).
|
| |
|
|
|
|
|
| |
Expressions involving uint16_t are promoted to int, which then can
overflow if the uint16_t values are large enough.
Found by Coverity.
|
| |
|
|
|
|
|
| |
Could index static arrays from arbitrary input data without checking for
bounds.
Found by Coverity.
|
wm4
Diogo Franco (Kovensky)