| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
Because that might be a bad idea.
Note that remote playlists still can use any protocol marked with
is_safe and is_network, because the case of http-hosted playlists
containing URLs using other streaming protocols is not unusual.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Loading a playlist with --playlist from a sub-directory added the
playlist's base path twice: one time in the playlist demuxer, and then
again in playlist_parse_file(). The latter function is used only for
--playlist, so it worked when loading the playlist directly.
(This is probably a mess-up when the MPlayer playlist parsers were
replaced with newer code.)
CC: @mpv-player/stable
|
| |
|
|
|
|
|
|
| |
The event was copied early, and wasn't released if it was rejected
instead of being added to the event queue. Fix by copying the event at a
point when it's certainly added to the event queue.
The dup_event_data() function is merely moved.
|
| |
|
|
|
|
|
|
|
| |
Until now, you had to use --load-unsafe-playlists or --playlist to get
playlists loaded. Change this and always load playlists by default.
This still attempts to reject unsafe URLs. For example, trying to invoke
libavdevice pseudo-demuxer is explicitly prevented. Local paths and any
http links (and some more) are always allowed.
|
| |
|
|
|
|
| |
Probably no observable effect, but it's more correct. Setting audio to
EOF could have bad effects otherwise (anywhere the player logic for
example decides whether EOF was reached, and such).
|
| |
|
|
|
|
|
| |
There is no proper and exact spec (Matroska tradition), so we probably
have to rely on guessing for this.
Also see issue #1045.
|
| |
|
|
|
|
|
|
|
| |
The audio/video sync code in player/audio.c calls ao_reset() each time
audio decoding is entered, but the player is paused, and there would be
more than 1 sample to skip to make audio start match with video start.
This caused a wakeup feedback loop with push.c.
CC: @mpv-player/stable
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When embedding a X window, it's hard to control whether it receives
mouse/keyboard input or not. It seems the X protocol itself makes this
hard (basically due to the outdated design mismatching with modern
toolkits), and we have to take care of these things explicitly.
Simply do this by manually querying and using the parent window event
flags.
This restores some MPlayer behavior (it doesn't add back exactly the
same code, but it's very similar).
This probably has some potential to interfere with libmpv embedding, so
bump the client API minor.
CC: @mpv-player/stable (if applied, client-api-changes.rst has to be
adjusted to include the 0.5.2 release)
|
| | |
|
| |
|
|
|
|
| |
In particular, use the note markup. The issue about rounded timestamps
is mostly with respect to Matroska (which usually rounds them to
milliseconds), which somewhat adds to the reliability issue.
|
| |
|
|
|
| |
Make it clear that the value is linked to the StereoMode element. You
can't change this without adjusting demux_mkv.c.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This inserts an automatic conversion filter if a Matroska file is marked
as 3D (StereoMode element). The basic idea is similar to video rotation
and colorspace handling: the 3D mode is added as a property to the video
params. Depending on this property, a video filter can be inserted.
As of this commit, extending mp_image_params is actually completely
unnecessary - but the idea is that it will make it easier to integrate
with VOs supporting stereo 3D mogrification. Although vo_opengl does
support some stereo rendering, it didn't support the mode my sample file
used, so I'll leave that part for later.
Not that most mappings from Matroska mode to vf_stereo3d mode are
probably wrong, and some are missing.
Assuming that Matroska modes, and vf_stereo3d in modes, and out modes
are all the same might be an oversimplification - we'll see.
See issue #1045.
|
| |
|
|
|
|
|
| |
Since we have to be portable, our options for creating temporary files
are somewhat limited. tmpfile() happens to be available everywhere, so
use that. This function doesn't allow having a "visible" filename or
location, so we use the magic string "TMP" for this.
|
| |
|
|
|
|
|
| |
A (hopefully) temporary hack to make stream switching delays tolerable.
It's not clear how this should be handled (either executing a precise
seek on track switching, or always enabling all streams), so get this
issue out of the way for now by picking a rather low value.
|
| | |
|
| |
|
|
|
| |
Double-quote everything, eliminate unneeded evals and deprecated
`backtits` substitution syntax.
|
| |
|
|
|
| |
Don't prepend each variable with __midentify__, just make them local
to the function.
|
| | |
|
| |
|
|
|
| |
$video_url can contain a question mark, which can be expanded to a
character in an existing file name if globbing is enabled.
|
| | |
|
| |
|
|
|
| |
This makes the ordered chapter code not think that a stream from the
local filesystem is not a local file (it checks uncached_type).
|
| |
|
|
| |
Because why not.
|
| |
|
|
| |
Check if mpi is NULL before accessing mpi->fields.
|
| |
|
|
|
| |
ar_rate is set to -1 when autorepeat is disabled; there is no reason
for ar_delay to stay unsigned.
|
| |
|
|
| |
Don't dereference fd and increment ictx->num_fds on fail.
|
| |
|
|
|
|
| |
In the else branch pict_type is always 3, so pict_type != 3 is always
false. (Note that I have no idea of what it was supposed to do and it is
just an equivalent of the old behaviour.)
|
| |
|
|
|
| |
pkt can't be NULL since it's initialized from ds->head, which is checked
at the beginning.
|
| |
|
|
|
| |
Break the cycle on fail. Old code was checking if sh is NULL after
accessing it's fields.
|
| |
|
|
|
| |
Only execute most of the opengl termination procedure if we actually have an
egl context.
|
| | |
|
| |
|
|
| |
Removes '##' operator from OpenGL shader code.
|
| |
|
|
|
| |
Unfortunately this also means you can't pass extra mpv options after the
URL anymore. You can prefix the script with MPV='mpv --options' though.
|
| |
|
|
|
|
|
|
|
|
| |
The player didn't quit when seeking past EOF in audio-only mode while
paused. The only case when we don't want to quit is when the last video
frame is displayed while paused.
This logic was probably broken a while ago, but I'm not exactly sure.
CC: @mpv-player/stable
|
| |
|
|
|
|
|
|
|
| |
bstr.c doesn't really deserve its own directory, and compat had just
a few files, most of which may as well be in osdep. There isn't really
any justification for these extra directories, so get rid of them.
The compat/libav.h was empty - just delete it. We changed our approach
to API compatibility, and will likely not need it anymore.
|
| |
|
|
|
|
|
|
| |
Just so I can move this file without modifying its contents in the next
commit.
compat/compiler.h is to be moved to osdep/ with the next commit, so add
a dummy header.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't reconnect to the cache (since the cached stream already handles
reconnection). This is necessary, because since commit 0b428e44 the
"streaming" field (which also controls whether attempting to reconnect
makes sense at all) is inherited to the cache stream wrapper.
Also, let the stream reset its own position on reconnect. This removes
some assumptions and messy handling from the reconnect function.
Make sure the cache is dropped on reconnect. This takes care of
readjusting the stream position if necessary. (Also drop the cache on
DVB channel switching commands.)
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Add a mechanism to the client API code, which allows the player core to
query whether a client API event is needed at all. Use it for the cache
update.
In this case, this is probably a pure microoptimization; but the
mechanism will be useful for other things too.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't attempt to resync after speed changes. Note that most other cases
of audio reinit (like switching tracks etc.) still resync, but other
code paths take care of setting the audio_status accordingly.
This restores the old behavior of not trying to fix audio desync, which
was probably changed with commit 261506e3.
Note that the code as of now wasn't even entirely correct, since the A/V
sync values are slightly shifted. The dsync depends on the audio buffer
size, so a larger buffer size will show more extreme desync. Also see
mplayer2 commit 213a224e, which should fixed this - it was not merged
into mpv, because it disabled audio for too long, resulting in a worse
user experience. This is similar to the issue this commit attempts to
fix.
Fixes: #1042 (probably)
CC: @mpv-player-stable
|
| |
|
|
|
| |
Rather than "magic" numbers, use meaningful constant names provided by
unistd.h.
|
| | |
|
| |
|
|
|
| |
The display name is always recomputed, so we can always toss the input
name.
|
| |
|
|
|
| |
This can occur if the directory does not have any files in it which
causes files to never be non-NULL for qsort.
|
| |
|
|
|
|
| |
glGetString(GL_SHADING_LANGUAGE_VERSION) can return NULL; I suppose this
happens on legacy OpenGL, while all the other fields are guaranteed to
exist.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Regression since commit f14722a4. For some reason, this worked on
nvidia, but rightfully failed on mesa.
At least in C, the ## operator indeed needs two macro arguments, and
you can't just concatenate with non-arguments.
This change will most likely fix it.
CC: @bjin
|
| |
|
|
|
|
|
|
|
|
|
| |
Remove the hardcoded wait time of 2 seconds. Instead, adjust the wait
time each time we unpause: if downloading the data took longer than its
estimated playback time, increase the amount of data we wait for. If
it's shorter, decrease it.
The +/- is supposed to avoid oscillating between two values if the
elapsed time and the wait time are similar. It's not sure if this
actually helps with anything, but it can't harm.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the "native" underrun detection, instead of guessing by a low cache
duration. The new underrun detection (which was added with the original
commit) might have the problem that it's easy for the playloop to miss
the underrun event. The underrun is actually not stored as state, so if
the demuxer thread adds a new packet before the playloop happens to see
the state, it's as if it never happened. On the other hand, this means
that network was fast enough, so it should be just fine.
Also, should it happen that we don't know the cached range (the
ts_duration < 0 case), just wait until the demuxer goes idle (i.e.
read_packet() decides to stop). This pretty much should affect broken or
unusual files only, and there might be various things that could go
wrong. But it's more robust in the normal case: this situation also
happens when no packets have been read yet, and we don't want to
consider this as reason to resume playback.
|
| |
|
|
|
| |
Enabling the cache doesn't make much in this situation, but there's also
no reason not to reject it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The cache percentage was useless. It showed how much of the total stream
cache was in use, but since the cache size is something huge and
unrelated to the bitrate or network speed, the information content of
the percentage was rather low.
Replace this with printing the duration of the demuxer-cached data, and
the size of the stream cache in KB.
I'm not completely sure about the formatting; suggestions are welcome.
Note that it's not easy to know how much playback time the stream cache
covers, so it's always in bytes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The "buffering" logic was active even if the stream cache was disabled.
This is contrary to what the manpage says. It also breaks playback
because of another bug: the demuxer cache is smaller than 2 seconds,
and thus the resume condition never becomes true.
Explicitly run this code only if the stream cache is enabled. Also, fix
the underlying problem of the breakage, and resume when the demuxer
thread stops reading in any case, not just on EOF.
Broken by previous commit. Unbreaks playback of local files.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the --cache-secs option, which literally overrides the value of
--demuxer-readahead-secs if the stream cache is active. The default
value is very high (10 seconds), which means it can act as network
cache.
Remove the old behavior of trying to pause once the byte cache runs
low. Instead, do something similar wit the demuxer cache. The nice
thing is that we can guess how many seconds of video it has cached,
and we can make better decisions. But for now, apply a relatively
naive heuristic: if the cache is below 0.5 secs, pause, and wait
until at least 2 secs are available.
Note that due to timestamp reordering, the estimated cached duration
of video might be inaccurate, depending on the file format. If the
file format has DTS, it's easy, otherwise the duration will seemingly
jump back and forth.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The purpose of the unconditional pthread_cond_signal() when reading
cached DEMUXER_CTRLs and STREAM_CTRLs was apparently to update the
stream cache state. Otherwise, the cached fields would never be updated
when the stream is e.g. paused.
The same could be said about other CTRLs, but these aren't as important,
since they are normally updated while reading packet data.
In order to reduce wakeups, make this logic explicit.
|
| |
|
|
|
|
|
|
|
|
| |
Add a new parameter 'p' to gaussian filter. The new formula used
a different base taken from fmtconv plugin, so that the
new parameter is exactly same as the one used in Avisynth and
Vapoursynth.
The new default value is 2 / log(2) * 10, with the default value it
conforms to the original kernel taken from vector-agg.
|
| |
|
|
|
|
|
| |
Add two new options, make it possible for user to set the radius
for some of the filters with no fixed radius.
Also add three new filters with the new radius parameter supported.
|
| |
|
|
|
|
| |
Although cscale is rarely used, it's possible that params of cscale
are accidentally set to lparam1 and lparam2, which might cause
unexpected results.
|
| |
|
|
|
|
|
|
| |
The coefficients are taken from fmtconv plugin for vapoursynth:
https://github.com/vapoursynth/fmtconv/blob/master/src/fmtc/ContFirSpline64.cpp
The package is licensed under WTFPL, and it's from the same author
of Dither plugin for avisynth.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
When video format changes, the frame before the frame with the new
format sets video_status briefly to STATUS_DRAINING. This caused the
code to handle the EOF case to kick in, which just pauses the player
when trying to step past the last frame. As a result, trying to
framestep over format changes resulted in pausing the player.
Fix by testing against the correct status.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Shift+X" didn't actually map any key, as opposed to "Shift+x". This is
because shift usually changes the case of a character, so a plain
printable character like "X" simply can never be combined with shift.
But this is not very intuitive. Always remove the shift code from
printable characters. Also, for ASCII, actually apply the case mapping
to uppercase characters if combined with shift. Doing this for unicode
in general would be nice, but that would require lookup tables. In
general, we don't know anyway what character a key produces when
combined with shift - it could be anything, and depends on the keyboard
layout.
|
| | |
|
| |
|
|
|
|
|
|
| |
The little lua snippet at #488 as well as the actual implementation
seems to indicate that not expanding properties is indeed the correct
behavior. Document that.
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
| |
Oops. I can never remember this righ |
