GetCurrentProcess() is deprecated on 10.9. Make a universal solution by
checking OS version number.
get_system_version() function is the recommended Apple way of getting the
OS version, since Gestalt is also deprecated (and does pretty much the same
thing anyway)
Updating HIDRemote.m to use a similar function would allow to get rid of the
2 other warnings.
This is supposed to reduce the amount of useless error messages shown
during initialization of vo_opengl. If multiple backends are compiled,
usually only one of them will work. For example, on Linux both X and
Wayland backends can be compiled, but usually either Wayland or X is
running. Then, if Wayland is not running, but X is, trying to initialize
the Wayland backend should not spam the terminal with error messages.
Signed-off-by: Andreas Sinz <andreas.sinz@aon.at>
Call update_subtitles() on every iteration of the playloop, so that
subtitle packets are read as soon as possible, instead of every time a
video frame is displayed. This helps in case the packet queue is swamped
with subtitle packets, which can happen with certain insane mkv files.
The change will simply cause the subtitle queue to be emptied on each
playloop iteration.
The timestamps update_subtitles() uses for display are the same before
and after this commit. (Important for files which have subtitle packets
with timestamps or duration not set.)
In insane files with a very huge number of subtitle events, and if the
--demuxer-mkv-subtitle-preroll option is given, seeking can still
overflow the packet queue. Normally, the subtitle_preroll variable
specifies the maximum number of packets that can be added. But once this
number is reached, the normal seeking behavior is enabled, which will
add all subtitle packets with the right timestamps to the packet queue.
At this point the next video keyframe can still be quite far away, with
enough subtitle packets on the way to overflow the packet queue.
Fix this by always setting an upper limit of subtitle packets read
during seeking. This should provide additional robustness even if the
preroll option is not used.
This means that even with normal seeking, at most 500 subtitle packets
are demuxed. Packets after that are discarded.
One slightly questionable aspect of this commit is that subtitle_preroll
is never reset in audio-only mode, but that is probably ok.
The mpv.desktop file is taken from the Arch package [1]. It appears to
be based on the mplayer2 git mplayer.desktop file (e.g. very similar
MimeType field), with minor modifications applied by Arch package
maintainers.
Note that for now, this doesn't show a terminal (Terminal=false), which
might not always be ideal. For example, if the file is audio only, or
if VO initialization fails for some reason, mpv will run in the
background and play audio without showing a window. But users prefer
running it without terminal, and don't want to play audio files with
it.
Maybe a --force-window option will be added in the future, which would
always create a VO window, and compensate for these issues.
[1] https://aur.archlinux.org/packages/mpv-git/
These would have to be updated manually all the time. Replacing them
automatically would be possible, but additional work, and would force
regeneration of the manpage way too often.
We decided that we don't need these fields.
Instead of containing a format string within %w{...}, simply allow %w
to specify one item of a time format string. This is simpler, more like
other format specifiers (%t), and probably easier to use too.
This is for situations when repeated attempts at playing a playlist
entry failed, and playlist navigation becomes impossible due to that.
For example, it wasn't possible to skip backwards past an unplayable
playlist entry:
mpv file1.mkv doesntexist.mkv file3.mkv
You couldn't skip back to file1.mkv from file3.mkv. When running a
single "playlist_prev" command, doesntexist.mkv would be played, which
would fail to load. As reaction to the failure to load it, the next file
would be played, which is file3.mkv.
To make this even worse, the file could successfully load, but run only
for a split second. So just loading successfully isn't good enough.
Attempt to solve this by marking problematic playlist entries as failed,
and by having playlist_prev skip past such playlist entries. We define
failure as not being able to play more than 3 seconds (or failing to
initialize to begin with). (The 3 seconds are in real time, not file
duration.)
"playlist_prev force" still exhibits the old behavior.
Additionally, use the same mechanism to prevent pointless infinite
reloading if none of the files on the playlist exist. (See github issue
All in all, this is a heuristic, and later adjustments might be
necessary.
Note: forward skips (playlist_next) are not affected at all. (Except for
the interaction with --loop.)
This is commonly used to disable the screensaver with broken/non-
standard X screensavers. During pause, the screensaver should not be
disabled, so not calling this command while paused seems sensible.
See github issue #236.
They are rarely useful in my opinion.
This commit was mainly motivated by this message:
Video uses a non-standard and wasteful way to store B-frames ('packed B-frames'). Consider using a tool like VirtualDub or avidemux to fix it.
It's what's left over from the "Invalid and inefficient vfw-avi..."
warning that used to be printed when playing avi/divx files. Although
the new message is much better, it's still rather useless and poses
more questions than it answers. Besides, nobody wants to remux a file
when playing it, especially not if playback appears to be completely
fine. (There are some claims that these files raise CPU usage, but even
my old crappy CPU can decode low res avi/divx files at real time at
about x35 playback speed.)
I have a sample where some final chapters are missing. This was causing a
segmentation fault when trying to fetch chapter times for them.
This makes the code ignore those chapters.
The quicktime html scripting guide suggests to wrap urls not
necesarly associated with quicktime in a .mov file.
(so that when <embed>ing videos quicktime would be forced.)
These mov files may contain several "Text Hacks".
One of these is RTSPtext.
The suggested/allowed format (as regex) is like:
RTSPtext[ \r]RTSP://url
See also p.51 of:
https://developer.apple.com/library/mac/documentation/QuickTime/Conceptual/QTScripting_HTML/QTScripting_HTML.pdf
In reality there are also files like (e.g. zdfmediathek.de):
RTSPtext\nrtsp://url\n\n
Lets handle these files as a playlist with one element.
In init_vo(), if sh->aspect is 0 or last_sample_aspect_ratio is set,
sh->aspect is overwritten. With software decoding fallback behaviour,
this makes the aspect ratio from container ignored since
last_sample_aspect_ratio is already set in first try with hardware
decoding.
The --deinterlace option does on playback start what the "deinterlace"
property normally does at runtime. You could do this before by using the
--vf option or by messing with the vo_vdpau default options, but this
new option is supposed to be a "foolproof" way.
The main motivation for adding this is so that the deinterlace property
can be restored when using the video resume functionality
(quit_watch_later command).
Implementation-wise, this is a bit messy. The video chain is rebuilt in
mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the
usual mechanism for enabling deinterlacing can't be used. Further,
mpcodecs_reconfig_vo() is called by the video decoder, which doesn't
have access to MPContext either. Moving this call to mplayer.c isn't
currently possible either (see below). So we just do this before frames
are filtered, which potentially means setting the deinterlacing every
frame. Fortunately, setting deinterlacing is stable and idempotent, so
this is hopefully not a problem. We also add a counter that is
incremented on each reconfig to reduce the amount of additional work per
frame to nearly zero.
The reason we can't move mpcodecs_reconfig_vo() to mplayer.c is because
of hardware decoding: we need to check whether the video chain works
before we decide that we can use hardware decoding. Changing it so that
this can be decided in advance without building a filter chain sounds
like a good idea and should be done, but we aren't there yet.
I did commit 86c05655d by thinking `mpv` already removed the `mpv` from
argc/argv. It actually is still there, so the argc must be 1 to check for no
arguments.
Thanks to @Nyx0uf for pointing out the bug and for testing on 10.9!
File opening through Finder, apparently drops `--psn` arguments on Mavericks
and just uses no args. Modify the code to account for that case.
This wasn't tested on 10.9 itself (I don't have a paid dev account), but it
*should* work if I understood the problem correctly.
Problem: I own the buffer and I destroyed while still being displayed.
Solution: Add a temporary buffer and destroy it when the next buffer is
attached.
Previously, mpv incorrectly used the %HOME% environment variable on
MinGW to determine the current user’s home directory. This is wrong;
the correct variable to use would be %HOMEPATH%, which would however
still be wrong since application data goes into the application data
directory, not the user’s home. This patch makes it use the local
AppData path instead of reading an environment variable.
This however exposed another problem (which also affected users who
actually had the %HOME% variable set):
b2c2fe7a37 (discussed in issue #95) introduced some changes that
make mpv load user config files from the executable path on Windows.
The problem with this change is that config_dir was still declared
static, so once a config file had been found in the executable path,
it would set config_dir to an empty string, so mpv would dump e.g.
watch_later data straight into the user’s home. This commit also
fixes that.
One side effect of this is that mpv no longer considers the “mpv”
subdirectory in the executable path (that behavior resulted from
the homedir variable always being empty), unless it is somehow
unable to determine the local AppData path.
This is mostly related to the fullscreen behaviour. cecbd8864 introduces an
option to make mpv behave like a OSX user would expect. This commit changes
the Cocoa parts of the code to be consistent with the behaviour on X11. Old
behaviour is still available through the option mentioned in cecbd8864.
There is still custom logic in the cocoa backend and it can probably be moved
to core:
* Don't perform autohide if the mouse is down
* Don't perform autohide outside of the video window
Fixes#218 (by accident)
wm4
Nyx0uf
Andreas Sinz
Stefano Pigozzi
Bilal Syed Hussain
Benjamin Franzke
xylosper
Martin Herkt
Alexander Preisinger