| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
It really doesn’t want to pagebreak that box, so I removed a
useless example.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The glFlush() call was made optional recently
since it's not needed in most cases. On OSX though
this is needed since we removed kCGLPFADoubleBuffer
from the context creation, so the glFlush() call
was added to the cocoa backend only.
The CGLFlushDrawable() call can be safely removed
since it only does something when a double
buffered context is used. Also fixes a small typo.
Fixes #3627.
|
|
|
|
|
| |
Also, not setting pen=None seems to draw horizontal lines for the dots,
which is fine too.
|
|
|
|
|
|
|
|
| |
In "dumb mode" (where most features are disabled and which only performs
some basic rendering) we explicitly copy a set of whitelisted options,
and leave all the other options at their default values. Add the new
--opengl-early-flush option to this whitelist. Also remove an option
field accidentally added in the commit adding --opengl-early-flush.
|
|
|
|
|
|
| |
Don't require special property code for handling updates, and simply use
the UPDATE_AUDIO flag instead. Also make runtime changes to
--audio-client-name take effect.
|
|
|
|
|
|
|
|
|
| |
Now a reload requested by an AO behaves in exactly the same way as
changing an AO-related options (like --audio-channels or
--audio-exclusive). This is good for testing and uniform behavior. (You
could go as far as saying it's a necessity, because the spotty and
obscure AO reload behavior is hard to reproduce and thus hard to test at
all.)
|
|
|
|
|
|
|
|
|
|
|
|
| |
This affects changing audio configuration options. Explicitly flush and
uninitialize the audio output first before doing the rest. This should
ensure all state attached to the audio output is discarded and not used
during the reconfiguration.
Also add a comment to the reinit_audio_filters() call. It doesn't
necessarily restore the audio chain fully, but makes sure a seek is
issued if the amnount of buffered audio discarded was huge enough to
cause "problems".
|
|
|
|
|
|
|
| |
This also removes some extra waiting if no video is active, at least in
theory.
Also clarify the vo_frame flag comments for redraw/repeat.
|
|
|
|
|
|
|
|
|
|
|
| |
It seems this can cause issues with certain platforms, so better to
disable it by default. The original reason for this isn't overly
justified, and display-sync mode should get rid of the need for it
anyway.
The new option is meant for testing, and will probably be removed if
nobody comes up and reports that enabling the option actually improves
anything.
|
|
|
|
|
| |
This is required since exclusive mode requires entirely different
initializaiton.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The player tries to avoid splitting frames with spdif (sample alignment
stuff). This can in certain corner cases with certain drivers lead to
the situation that ao_get_space() returns a number higher than 0 and
lower than the audio frame size. The playloop will round this down to 0
bytes and do nothing, leading to a missed wakeup. This can lead to
underruns or playback completely getting stuck.
It can be reproduced by playing AC3 passthrough with no video and:
--ao=null --ao-null-buffer=0.256 --ao-null-outburst=6100
This commit attempts to fix it by allowing the playloop to write some
additional data (to get a complete frame), that will be buffered within
the AO ringbuffer even if the audio device doesn't want it.
|
| |
|
|
|
|
|
| |
If a client API user provides the MPGetNativeDisplay callback, but
returns NULL for "MPV_RPI_WINDOW", this would crash.
|
|
|
|
|
|
|
|
| |
If we really want client API users to use mpv_set_property() instead of
mpv_set_option(), then compatibility handling of deprecated options
should be included. Otherwise, there's the danger that client API users
either break too early (and without a warning), or mpv_set_option() will
continue to have a reason to exist.
|
| |
|
|
|
|
|
|
|
|
| |
Reduces code duplication between OpenGL backend and DRM VO.
(The control() for OpenGL backend isn't sufficiently similar to the
VO's control() to consider merging it as a whole - I extracted only the
FPS code.)
|
|
|
|
| |
...
|
|
|
|
|
|
|
|
|
|
|
| |
Rename the text subtitle options from --sub-text- to --sub-
and --ass- options to --sub-ass-.
The intention is to common sub options to prefixed --sub-
and special ASS option be seen as a special version of sub options.
The OSD options that work like the --sub- options are still named
--osd-.
Man page updated including a short note about renamed --sub-text-*
and --ass-* options to --sub-* and --sub-ass-*.
|
|
|
|
|
|
| |
This is potentially incompatible if a program used negative timestamps
to deal with timestamp resets, which would potentially lead to mpv
producing and using negative timestamps.
|
|
|
|
|
|
| |
"seek -10 absolute" will seek to 10 seconds before the end. This more or less
matches the --start option and negative seeks were otherwise useless (they just
clipped to 0).
|
|
|
|
|
|
|
|
|
| |
Regression since commit bbcd0b6a. This code is just cursed, because it's
a fragile state machine with no proper tests, and which could be done in
a much simpler way. Without doubt this change will cause a regression in
some ridiculous corner case as well.
Fixes #3610 (the cause of it, not the behavior it resulted in).
|
|
|
|
|
| |
Can help to analyze timestamp jitter or seeing completely bogus
timestamps.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the vaapi decoder is used in copy mode, it creates a dummy
display to render to. In theory, this should support hardware
decoding on on a separate GPU that is not actually connected to
any output (like an iGPU which supports more formats than the
external GPU to which the monitor is connected).
However, before this change, only X11 displays were supported as
dummy displays. This caused some graphics drivers (namely
intel-driver) to core dump when they were not actually used as X11
module.
This change introduces support for drm libav displays, which
allows vaapi-copy to run on such cards which are not actually
rendering the X11 output.
|
|
|
|
|
|
|
|
|
|
| |
Move the screensaver enable/disable determination to a central place,
and call it if the stop-screensaver property is changed.
Also, do not stop the screensaver when in idle mode (i.e. no file is
loaded).
Fixes #3615.
|
| |
|
|
|
|
| |
The extra gl_transform_trans() has no apparent use.
|
|
|
|
|
|
| |
Other than being overly convoluted, this seems to make sense to me.
Except that to get the "rot" transform I have to set flip=true, which
makes no sense at all to me.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Combining rotation and cropping didn't work. It was just completely
broken.
I'm still not sure if this is correct. Chroma positioning seems to be
broken on rotation. There might also be a problem with non-mod-2 frame
sizes. Still, strictly an improvement for both rotated and non-rotated
rendering modes.
Also, this could probably be written in a more elegant way.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit aa1047a3 originally added this as:
+ // this is from the DarkPlaces engine, reduces to 3x3. Original code
+ // released under GPL2 or any later version.
According to Rudolf Polzer, the original author (a certain LH) was
actually asked whether it would be ok to put this code under LGPL, and
the author gave his agreement. This code is not from id Software either
(on which large parts of DarkPlaces is based on), which is the main
reason why DarkPlaces is under GPL.
So this note is just confusing, and always has been LGPL. Fix it.
|
|
|
|
|
|
| |
We'd like to get log messages on the output as soon as possible in the
output. I also feel like using fflush() is nicer than using setvbuf().
Who knows how the latter behaves on win32.
|
| |
|
|
|
|
| |
It's not even true anymore.
|
|
|
|
|
| |
This was in previously inactive code (uploading yuv420p), so it did not
matter.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The video code can deal fine with feeding software image formats to
hwdec interop drivers. In RPI's case, this is preferable for
performance, working around OpenGL bugs (see RPI firmware issue #666),
and because OpenGL rendering doesn't bring too many advantages due to
RPI supporting GLES 2.0 only.
Maybe a way to force the normal video path is needed later. But
currently, this can be tested by just not loading the hwdec interop
driver.
If you run command-line mpv and set --hwdec to something that does
not load the RPI interop layer, you'll even have to use --hwdec-preload
manually to get it enabled.
|
| |
|
|
|
|
|
| |
Avoids printing an error when trying to create a GLES 3.x context on a
device which can do GLES 2.0 only.
|
|
|
|
|
|
| |
Was intended to put the GL layer above the standard console. (But
actually that was done already, and the oddness I'm seeing seems to
be an unrelated bug.)
|
|
|
|
|
| |
Less confusing to see what's going on. I think there were more than one
users who got tricked by this, including myself.
|
|
|
|
|
|
| |
This means it can be used with normal video filters.
Might help out with #3604.
|
|
|
|
| |
Fixes #3598.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code for expanding the ~~ prefix used mp_find_config_file(), which
strictly looks for _existing_ files in any config path (e.g. not just
the user-local one, but also system-wide config). If no such file
exists, it simply returns NULL, which makes the code below just return
the literal, unexpanded path.
Change this so that it'll resolve the path to the user-local config
directory instead.
Requested in #3591.
|
|
|
|
| |
Someone requested this.
|
|
|
|
|
| |
Using vf_expand (which uses mp_image_clear()) with p010 cleared chroma
to green instead.
|
|
|
|
|
|
|
|
| |
This should make display-names usable on Windows. It returns a list of
GDI monitor names like "\\.\DISPLAY1". Since it may be useful to get the
monitor that Windows considers associated with the window (with
MonitorFromWindow,) this will always be returned as the first argument.
This monitor is the one used for display-fps and icc-profile-auto.
|
| |
|
|
|
|
|
| |
In retrospect, this seems obvious, but ffmpeg didn't complain until
a recent update.
|
|
|
|
|
| |
So it doesn't have to be in the list of options that can be set before
mpv_initialize() only.
|
|
|
|
|
|
|
|
|
| |
Seems like a valid use-case. Not sure if I like it calling back into the
config code. Care has to be taken for not letting the config path
resolving code dead-lock (which is why locking details in the msg.c code
are changed).
Fixes #3591.
|
|
|
|
| |
They're still supported, just that they have no IMGFMT_ alias.
|
|
|
|
|
|
|
|
|
|
| |
I'm not sure if this option affects anything or if it's a placebo,
especially since the VO thread is now registered with MMCSS. Still, I
think --priority=high may have helped back when I used mplayer2 on a
netbook. It's also possible that encoding-mode users would want to set
--priority=idle.
Anyway, it was one of the last M_OPT_FIXED options, so fix that.
|
|
|
|
|
|
|
|
|
|
|
|
| |
We always want to use __declspec(selectany) to declare GUIDs, but
manually including <initguid.h> in every file that used GUIDs was
error-prone. Since all <initguid.h> does is define INITGUID and include
<guiddef.h>, we can remove all references to <initguid.h> and just
compile with -DINITGUID to get the same effect.
Also, this partially reverts 622bcb0 by re-adding libuuid.a to the
build, since apparently some GUIDs (such as GUID_NULL) are not declared
in the source file, even when INITGUID is set.
|
|
|
|
| |
Just a name change. Requested.
|
|
|
|
|
|
| |
AVIOContext.seekable is actually a bitfield. Currently, it has only
AVIO_SEEKABLE_NORMAL defined, but it might be extended with a hint for
non-byte seekability. Thus we should check it correctly.
|
|
|
|
| |
Fixes #3586 (probably). Untested.
|
| |
|
|
|
|
| |
Fixes #3364.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should still allow user-set default options to override built-in
pseudo-gui while respecting user-set pseudo-gui options.
Pros:
- user option in default profile overrides built-in pseudo-gui's options
Ex: screenshot-directory overrides built-in pseudo-gui's
- user can "fix" pseudo-gui if some option like "force-window=no" is set
in default by setting "force-window=yes" in [pseudo-gui]
- `mpv --profile=pseudo-gui` will work as before
Cons:
- --show-profile=pseudo-gui won't display the built-in's options
Original idea from wm4.
Documentation edits mostly by wm4.
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
|
|
|
|
|
| |
If the PTS goes backwards (whether it's a timestamp reset or some other
problem) would just use 0 as frame duration. (At least until the logic
for detecting divergence with the timestamps gets active.)
Trust the demuxer framerate in these cases instead, if it's available. I
think this improves behavior slightly with some broken files.
|
|
|
|
| |
(Why the heck is the C++ helper not in a separate repository?)
|
|
|
|
|
|
|
|
|
| |
During init it will first call mp_load_builtin_scripts(), and then again
via mp_load_scripts().
This was harmless (a second attempt won't load it again if the first one
was successful), but it's unnecessary, and also looks confusing if the
scripts failed to load the first time.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
demux_lavf.c forces seek to being determined as supported if
STREAM_CTRL_HAS_AVSEEK is returned as success. But it always succeeds
with current FFmpeg versions. (Seems like Libav commit cae448cf broke
this in early 2016.)
Now we can't determine via private API whether the underlying protocol
supports read_seek anymore. The affected protocols (mostly rtmp) also
set seekable=0, meaning they signal they're not seekable, even though
read_seek would work. (My guess is that this can't be fixed because even
though seekable is in theory a combination of elaborate flags [of which
only 1 is defined, AVIO_SEEKABLE_NORMAL], a seekable!=0 always means
it's byte-seekable in some way.)
So the FFmpeg API is being garbage _again_, and all what we can do is
determining this via protocol name and a whitelist.
Should fix the behavior reported in #1701.
|
|
|
|
| |
they keep changing things. . .
|
|
|
|
| |
Fixes #3429
|
|
|
|
|
|
|
|
|
|
|
| |
Secondary subtitle streams (to be shown on the top of the screen along
main subtitle stream) were shown with normal alignment. This is because
we tell libass to override the alignment style (a relatively recent
change, see commit 2f1eb49e). This would behave differently with old
libass versions too.
To escape the mess, just set the alignment explicitly with an override
tag instead of modifying the style.
|