| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
stream.url can never be NULL, although it probably used to be.
|
|
|
|
|
| |
And also fix the description. It didn't actually reflect what the code
did.
|
|
|
|
|
| |
There is some potential for breakage. If it happens, this might have to
be disabled by default.
|
|
|
|
|
|
|
| |
The options don't change, but they're now declared and used privately by
demux_mkv.c. This also brings with it a minor refactor of the subpreroll
seek handling - merge the code from playloop.c into demux_mkv.c. The
change in demux.c is pretty much equivalent as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows forward seeking even if there are no more video
keyframes in forward direction. This helps with files that e.g. encode
cover art as a single video frame (within a _real_ video stream - ffmpeg
seems to like to produce such files). Seeking backwards will still jump
to the nearest video frame, so this improvement has limited use.
The old code didn't do this because of the logic the min_diff variable
followed. Instead of somehow using the timestamp of the last packet read
for min_diff, use the first index entry for it. This actually makes it
fall back to the first/last index entry as the (removed) comment claims.
Note that last_pts is basically random at this point (because the
demuxer can be far ahead of playback position), so this didn't make
sense in the first place.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On EOF, this stopped reporting the actual cache duration, and just
signalled unknown duration. Fix this and keep reporting whatever is left
in the packet queue.
This reverts commit 5438a8b3. The commit doesn't give a good explanation
as to why it is needed, but I guess it was because the reporting was
imperfect (it switched between unknown or 0, and the correct duration).
This also removes a line added in commit 848546f2. The line is
ds->active = false;
The "active" flag basically says that data from this stream is actively
needed, and it's used to calculate the minimum data that can actually be
played (approximately). If this were ignored, a sparse subtitle stream
would set the cache duration to 0s. The commit message adding the line
says "actually does nothing, but in theory it's cleaner". Well, screw
it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the old implementation for these properties. It was never very
good, often returned very innaccurate values or just 0, and was static
even if the source was variable bitrate. Replace it with the
implementation of "packet-video-bitrate". Mark the "packet-..."
properties as deprecated. (The effective difference is different
formatting, and returning the raw value in bits instead of kilobits.)
Also extend the documentation a little.
It appears at least some decoders (sipr?) need the
AVCodecContext.bit_rate field set, so this one is still passed through.
|
|
|
|
|
|
|
|
|
|
|
| |
If a directory is encountered, replace it with its contents in the
internal playlist.
This is messed into demux_playlist.c, because why not. STREAMTYPE_DIR
could be avoided by unconditonally trying opendir() in demux_playlist.c,
but it seems nicer not to do weird things like calling it on real files.
This does not work on Windows, because msvcrt is retarded.
|
| |
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
| |
We handle picking out font attachments by mime type ourselves in a
higher level, so we really just want to use the mimetype. Also, Matroska
is currently the only code in libavformat which uses the fonts at all,
and we can drop use of the codec IDs completely.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With a recent cleanup, rar support was stuffed into demux_playlist.c
(because "opening" rar files pretty much just lists archive contents and
adds them to a playlist using a special rar:// protocol, which will
actually access the rar file contents).
Since demux_playlist.c is probed _after_ demux_lavf.c (and should/must
be), libavformat was given the chance to detect DTS streams embedded
within the rar file. This is not really what we want, and a regression
what happened before rar listing was moved to demux_playlist.c.
Fix it by moving the rar listing into its own pseudo-demuxer, and let ir
probe before demux_lavf.c.
(Yes, this feature still has users.)
|
|
|
|
|
| |
Don't bother with making these visible by default, because often they
are bogus and/or useless.
|
|
|
|
|
| |
Could theoretically dereference "d" later in the loop. It's on an error
codepath, so just give up.
|
|
|
|
|
| |
There are obscure methods to add timestamps to such streams, but assume
they're unused.
|
|
|
|
|
|
|
|
|
|
|
| |
Trying to handle such video is almost worthless, but it was requested by
at least 2 users.
If there are no timestamps, enable byte seeking by setting
ts_resets_possible. Use the video FPS (wherever it comes from) and the
audio samplerate for timing. The latter was already done by making the
first packet emit DTS=0; remove this again and do it "properly" in a
higher level.
|
|
|
|
|
|
| |
If this happens, the file is actually broken, but the assumption is
simply that the file was truncated, and printing a warning would be
strange.
|
|
|
|
|
|
|
|
|
| |
Check async abort notification. libavformat already do something
equivalent.
Before this commit, the demuxer could enter resync mode (and print silly
warning messages) when the stream stopped returning data because of an
abort.
|
|
|
|
|
| |
This is missing from the previous commit. Not that harmful, but also
slightly un-nice since even a failed seek will reset the cache.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A user reported a webm stream that couldn't be played. The issue was
that this stream 1. was on an unseekable HTTP connection, and 2. had a
SeekHead element (wtf?). The code reading the SeekHead marked the
element as unreadable too early: although you can't seek in the stream,
reading the header elements after the SeekHead read them anyway. Marking
them as unreadable only after the normal header reading fixes this.
(The way the failing stream was setup was pretty retarded: inserting
these SeekHead elements makes absolutely no sense for a stream that
cannot be seeked.)
Fixes #1656.
|
| |
|
|
|
|
|
|
|
| |
This reverts commit c8f49be919ffaf983bde77b63d75f96a593ec7a8.
Not needed anymore; fixed in all supported FFmpeg releases. Though I
could not test again, because all sample files are gone (oops).
|
|
|
|
|
|
| |
All of these are now in the supported FFmpeg and Libav versions.
The 3 remaining API checks are for FFmpeg-only things.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the (relatively new) libavformat image format probing functionality,
instead of letting demux_mf guess by file extension and MIME type.
The libavformat support is weird, though. Traditionally, it uses an
absolutely terrible hack to detect images by extension, _and_ (which is
the horrible part) will randomly interpret parts of the filename as
specifiers for matching by number. So something like '%03d' will be
interpreted as placeholder for a frame number. The worst part is that
such character sequences can be perfectly valid and common in http URLs.
This is known as "image2" demuxer. The newer support, which probes by
examining the file header, is split into several format-specific
demuxers with names ending in "_pipe". So we check for such a name
suffix. (At this point we're doing fine-grained hacking around ffmpeg
weirdness, so a clean solution is impossible anyway until upstream
changes.)
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was possible to make the player play local files by putting rar://
links into remote playlists, and some other potentially unsafe things.
Redo the handling of it. Now the rar-redirector (the thing in
demux_playlist.c) sets disable_safety, which makes the player open any
playlist entries returned. This is fine, because it redirects to the
same file anyway (just with different selection/interpretation of the
contents). On the other hand, rar:// itself is now considered fully
unsafe, which means that it is ignored if found in normal playlists.
|
|
|
|
|
|
|
|
|
| |
This warning wasn't overly helpful in the past, and warned against
perfectly fine code. But at least with recent gcc versions, this is the
warning that complains about assignments in if expressions (why???), so
we want to enable it.
Also change all the code this warning complains about for no reason.
|
|
|
|
| |
Unused since the previous commit. (Apparently it was a stupid idea.)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactors an older hack, which for some reason used a more complicated
way. This generates the playlist representing the contents of the rar
file in demux_playlist.c. The pseudo-demuxer could easily be separate
from the the playlist parsers (and in fact there's almost no shared
code), but I don't think this obscure feature deserves a separate file.
Sample files created with:
rar a -v20000k -m0 files.rar file1.mkv file1.mkv
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the cache is enabled, the demuxer is closed and opened again (because
currently, the cache can not be enabled atfer data was already read).
The call for opening a new demuxer uses the same params struct, which
references the ctx->uids array. But there is a MP_TARRAY_GROW()
invocation somewhere on the way, which can reallocate the ctx->uids
array, making params.uids a dangling pointer.
This issue probably existed for a longer time, probably since 5cd33853
(slightly more obvious since f50b105d).
|
|
|
|
|
|
|
| |
Again removes some indirections and extra arguments.
Also replace some memcpy/memmoves with assignments. (Assignments became
possible only later, when reference UIDs were turned into a struct.)
|
|
|
|
| |
Removes tripple pointer indirections and such.
|
|
|
|
|
|
| |
Should behave about the same, but reduces code some duplication with
seeking and reading a header element pointed to by a SeekHead. It also
makes behavior with incomplete files slightly better.
|
|
|
|
|
| |
Limit it to a single message. It often printed more than that, and in
some cases (old files with "cluster" index), spammed a lot.
|
|
|
|
|
|
|
| |
Remove coded_width and coded_height. This was originally added in commit
fd7dde40, when BITMAPINFOHEADER was killed. The separate fields became
redundant in commit e68f4be1. Remove them (nothing passed to the
decoders actually changes with _this_ commit).
|
| |
|
|
|
|
|
| |
Often stream and a demuxer are opened at the same time. Provide a
function for this and replace most of its uses.
|
|
|
|
| |
Fold the relatively obscure force_format parameter into demuxer_params.
|
|
|
|
|
| |
Although their lifetimes are conceptually different, it happens often
that a demuxer is destroyed together with its stream.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the hacks were not applied if the file format was forced. Commit
37a0c914 moved them to a table, which is checked with normal probing
only.
Fixes #1612 (DVD forces mpeg, which in turn has to export native stream
IDs specifically).
Do some code restructuring on the way. For example, the probescore can
simply be set to the correct initial value, instead of checking whether
it was set at all.
|
|
|
|
|
|
| |
Whatever the hell that is. FFmpeg tries to open any files with .bin file
extension with this demuxer (unless it finds a better demuxer), and then
reads the whole damn file, along with spamming dumb crap.
|
|
|
|
|
|
|
|
|
| |
Includes some logic for not starting the demuxer thread for fully read
subtitles. (Well, the cache will still waste _lots_ of resources, and
the cache always has to be created, because we don't know whether it'll
be needed _before_ opening the file.)
See #1597.
|
|
|
|
|
|
|
|
|
|
|
| |
An attempt to make format-specifics more declarative. (In my opinion,
all of this should be either provided by libavformat, or should not be
needed.)
I'm still leaving many checks with matches_avinputformat_name(), because
they're so specific.
Also useful for the following commit.
|
|
|
|
|
|
| |
Helps with terminating the stream if e.g. HLS streams are stuck. (For
other demuxers, the stream's interrupt callback already takes care of
this.)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Matroska timeline code was the only thing which still used the
demuxer.type field. This field explicitly identifies a demuxer
implementation. The purpose of the Matroska timeline code was to reject
files that are not Matroska. But it already forces the Matroska format,
meaning loading will explicitly only use the Matroska demuxer. If the
demuxer can't open the file, no other demuxer will be tried, and thus
checking the field is redundant.
The change in demux_mkv_timeline.c removes the if condition, and
unindents the if body.
|
|
|
|
|
|
|
| |
Only demux_cue and demux_edl used it. It's a weird field and doesn't
help with anything anymore - by now, it only saves a priv context in the
mentioned demuxers. Reducing the number of confusing things the demuxer
struct has is more important than minimizing the code.
|
| |
|
|
|
|
| |
Same deal as with demux_cue, and a separate commit for the same reasons.
|
|
|
|
| |
Also see previous commit(s).
|
|
|
|
|
|
|
|
| |
Move the implementation, of which most was in tl_cue.c, to demux_cue.c.
Currently, this is illogical, because tl_cue.c still accesses MPContext.
This is going to change, and then it will be better if everything is in
demux_cue.c. This is only a separate commit to distinguish code movement
and actual work; the next commit will do the actual work.
|
|
|
|
|
| |
Weird, but helps with the case a demuxer gets handed its own instance
from outside.
|
|
|
|
|
| |
Separate from previous commit, because git is bad at tracking file
renames when the file contents are also changed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of accessing MPContext in player/timeline/*, create a separate
context struct, which the timeline loaders fill out. It turns out that
there's not much in the way too big MPContext that these need to access.
One major PITA is managing (and closing) the set of open demuxers. The
problem is that we need a list of all demuxers to make sure no unneeded
streams are enabled.
This adds a callback to the demuxer_desc struct, with the intention of
leaving to to the demuxer to call the right loader, instead of
explicitly checking the demuxer type and dispatching manually in common
code. I also considered making the timeline part of the demuxer state,
but decided against: it's too much of a mess wrt. memory management and
threading, and also doesn't make it clear who owns the child demuxers.
With the struct timeline decoupled from the demuxer state, it's at least
somewhat clear that the child demuxers are independent from the "main"
demuxer.
The actual changes to player/timeline/* are separated in the following
commits, because they're quite verbose. Some artifacts will be removed
later as soon as there's only 1 timeline loading mechanism.
|
|
|
|
| |
Makes some of the following commits slightly simpler. Also fix a typo.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The HLs protocol consists of a "playlist" main file, which mpv downloads
and passes to the HLS demuxer. The HLS demuxer actually requests segment
files containing media data on its own. The packets read from the
demuxer have a source file position set, but it's not from the main
file. This leads to a strange effect: as a last fallback, the player
will calculate the approximate playback position from the file
position/size ratio, and since the main file is tiny, this will always
show 100%. Fix this by resetting the packet file position.
This doesn't affect the case when HLS actually reports a duration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the previous subtitle packet is too far back, and the refresh seek
won't pick it up, and the packet never comes again. As a consequence,
the refresh mode was never stopped on the subtitle stream, which caused
all packets to be discarded.
Fix by assuming the file position is monotonically increasing; then it
will resume even if a packet _after_ the intended resume point is
returned. This introduces a new requirement on how the demuxer behaves.
(I'm not sure if mp4 actually satisfies this requirement in all cases.)
Fixes a regression introduced by commit f9f2e1cc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 pr |