All wayland only specific routines are placed in wayland_common.
This makes it easier to write other video outputs.
The EGL specific parts, as well as opengl context creation, are in gl_common.
This backend works for:
* opengl-old
* opengl
* opengl-hq
To use it just specify the opengl backend
--vo=opengl:backend=wayland
or disable the x11 build.
Don't forget to set EGL_PLATFORM to wayland.
Co-Author: Scott Moreau
(Sorry I lost the old commit history due to the file structure changes)
Use floats instead of integers in the range 0-100. Currently, the OSD
is currently made up of 46 elements so no change should be visible, but
rendering of the bar will be changed later to use vector drawings (using
pixel coordinates) instead of glyphs. This commit is for preparation.
The percent position is used for the OSD, the status line, and for the
OSD bar (shown on seeks). By default, the PTS of the last demuxed packet
was used to calculate it. This led to a "jumpy" display when the
percentage value (casted to int) was changing. The reasons for this were
the presence of video frame reordering (packet PTS is not monotonic), or
getting PTS values from different streams (like audio/subs).
Since these rely on PTS values and correct file durations anyway,
simplify it by calculating it with the current playback position in
mplayer.c instead.
This allowed making the player switch the monitor video mode when
creating the video window. This was a questionable feature, and with
today's LCD screens certainly not useful anymore. Switching to a random
video mode (going by video width/height) doesn't sound too useful
either.
I'm not sure about the win32 implementation, but the X part had several
bugs. Even in mplayer-svn (where x11_common.c hasn't been receiving any
larger changes for a long time), this code is buggy and doesn't do the
right thing anyway. (And what the hell _did_ it do when using multiple
physical monitors?)
If you really want this, write a shell script that calls xrandr before
and after calling mpv.
vo_sdl still can do mode switching, because SDL has native support for
it, and using it is trivial. Add a new sub-option for this.
The --wid switch (for embedding the player into other applications)
didn't create a new window, and instead tried to use the window that
was passed via --wid directly. This made the code more complex, caused
strange X errors (mpv and host application fighting for exclusive X
resources), and actually could cause issues if the --wid window wasn't
created with the X Visual needed for OpenGL.
Always create a window instead. This makes it always possible to embed
the player into foreign windows. --geometry doesn't work anymore - the
controlling application should always create a new window to place the
player inside it, and can control the video window by moving and
resizing this window.
w32_common.c actually did this right, and always creates a new window.
create_window is really bad naming, because this function can be called
multiple times, while the name implies that it always creates a new
window. At least the name config_window is not actively misleading.
Allow the backend code to create a GL context on best effort basis,
instead of having to implement separate functions for each variation.
This means there's only a single create_window callback now. Also,
getFunctions() doesn't have the gl3 parameter anymore, which was
confusing and hard to explain.
create_window() tries to create a GL context of any version. The field
MPGLContext.requested_gl_version is taken as a hint whether a GL3 or a
legacy context is preferred. (This should be easy on all platforms.)
The cocoa part always assumes that GL 3 is always available on
OSX 10.7.0 and higher, and miserably fails if it's not. One could try
to put more effort into probing the context, but apparently this
situation never happens, so don't bother. (And even if, mpv should be
able to fall back to vo_corevideo.)
The X11 part doesn't change much, but moving these functions around
makes the diff bigger.
Note about some corner cases:
This doesn't handle CONTEXT_FORWARD_COMPATIBLE_BIT_ARB on OpenGL 3.0
correctly. This was the one thing getFunctions() actually needed the
gl3 parameter, and we just make sure we never use forward compatible
contexts on 3.0. It should work with any version above (e.g. 3.1, 3.2
and 3.3 should be fine). This is because the GL_ARB_compatibility
extension is specified for 3.1 and up only. There doesn't seem to be
any way to detect presence of legacy GL on 3.0 with a forward
compatible context. As a counter measure, remove the FORWARD_COMPATIBLE
flags from the win32 code. Maybe this will go wrong. (Should this
happen, the flag has the be added back, and the win32 will have to
explicitly check for GL 3.0 and add "GL_ARB_compatibility" to the extra
extension string.)
Note about GLX:
Probing GL versions by trying to create a context on an existing window
was (probably) not always possible. Old code used GLX 1.2 to create
legacy contexts, and it required code different from GLX 1.3 even before
creation of the X window (the problem was selections of the X Visual).
That's why there were two functions for window creation (create_window_old
and create_window_gl3). However, the legacy context creation code was
updated to GLX 1.3 in commit b3b20cc, so having different functions for
window creation is not needed anymore.
The message reads: "Screenshot: filename", where the filename is what
mpv passes to fopen(). It will also show error messages when saving the
screenshot fails.
SHOUTcast bans "Mozilla" in the user-agent, Vimeo bans "Lavf" (part of
the libavformat normal user-agent). "MPlayer 1.1-..." seems to work
everywhere, and is close to the intented use (mpv is based on MPlayer,
after all).
This means a commands like "seek 13:00 absolute" actually behaves like
"--start=13:00", instead of interpreting the argument as fraction as
with normal float options. This is probably slightly closer to what
you'd expect.
As a consequence, the seek argument's type changes from float to double
internally.
Apparently the intention was parsing numbers reliably in presence of
non-C locales. mpv is always in C locale, and not being in C locale
would probably break even more things, so remove this code.
The backend sub-option for vo_opengl and vo_opengl-old accepted numeric
values (like -1, 0, ...) for compatibility with MPlayer. This was added
in mplayer2 times, and is not important anymore.
You can just use --wid=0 if you really want this.
This only worked/works for X11, and even then it might interact badly
with most desktop environments. All the option did was setting --wid to
0, and the property did nothing.
And support the PIX_FMT_MONOWHITE pixel format. (This is really weird:
unlike PIX_FMT_MONOBLACK, it uses white pixels. I have no idea why
libavcodec doesn't just convert the pixel format on the fly, instead of
bothering everyone with really special pixel formats.)
Recent changes to the OSD code made vo_caca crash when showing OSD.
Since this is a joke VO (== I'd rather not waste my time with it),
remove the OSD support. It wasn't that great anyway.
"End of file" was printed to the terminal instead of "Quit" when exiting
with the "quit" slave command (closing the window and such). Note that
it will still print EOF when it exists because the end of the playlist
is reached.
Do some other (not strictly related) simplifications.
This fixes the issue that black borders (e.g. on fullscreen) are not
redrawn, even if OSD rendering changes these areas.
In theory, the code could try some clever things to determine whether
clearing the window is really necessary, but that's probably not worth
the trouble and won't bring any significant performance gain, or might
even make things slower (because the GPU can't discard the old
contents).
Also fix redrawing when changing panscan with OSD disabled.
Use the option parser instead of sscanf. Remove the parameter changing
the field dominance (it has been marked deprecated for ages). Add a new
suboption "enabled", which can be used to disable the filter by default,
until it's enabled at runtime:
mpv -vf yadif=enabled=no
Was very complicated to use, and its uses have been removed in the
previous commits.
(While this feature sounded kind of useful, it could be rewritten in
a much simpler way, like storing presets as strings, and then using
the option parser to apply a preset. The removed code did some major
pointer juggling to handle raw values, which made it hard to use.)
For all suboptions, "flat" options were available by separating the
parent option and the sub option with ":", e.g. "--rawvideo:w=123". Drop
this syntax and use "-" as separator. This means even suboptions are
available as normal options now, e.g. "--rawvideo-w=123". The old syntax
doesn't work anymore.
Note that this is completely separate from actual suboptions. For
example, "-rawvideo w=123:h=123" still works. (Not that this syntax is
worth supporting, but it's needed anyway, for for other things like vf
and vo suboptions.)
As a consequence of this change, we also have to add new "no-" prefixed
options for flag suboptions, so that "--no-input-default-bindings"
works. ("--input-no-default-bindings" also works as a consequence of
allowing "-input no-default-bindings" - they are handled by the same
underlying option.)
For --input, always use the full syntax in the manpage. There exist
suboptions other than --input (like --tv, --rawvideo, etc.), but since
they might be handled differently in the future, don't touch these yet.
M_OPT_PREFIXED becomes the default, so remove it. As a minor unrelated
cleanup, get rid of M_OPT_MERGE too and use the OPT_SUBSTRUCT() macro in
some places.
Unrelated: remove the duplicated --tv:buffersize option, fix a typo in
changes.rst.
`--fs-screen` allows to decide what display to go fullscreen into. The
semantics of `--screen` changed and now it is only used to select the windowed
display when starting the application.
This is useful for people using mpv with an external TV. They will start
windowed on their laptop's screen and switch to fullscreen on the TV.
@wm4 worked on the x11 and w32 parts of the code. All is squashed in one
commit for history clarity.
Also some other cosmetic changes. And reformat the two remaining doxygen
comments.
Removing MSGLEN in x11_errorhandler() is technically not just a cosmetic
change, but the result is the same anyway.
The string is deallocated by the callee after initialization, so
fallback at runtime passes a deallocated string to libavcodec, which
results in random crashes. Regression introduced by commit 4d016a9.
Being able to insert newline characters ("\n") is useful for
--osd-status-msg, and possibly also for anything that prints to the
terminal. Espcially --term-osd-esc looks relatively useless without
being able to specify escapes.
Maybe parsing escapes should happen during command line / config parsing
instead (for all options).
This was supposed to be fixed in f897138, but there's another corner
case. Basically, set_osd_function() reset the OSD time, which is not
nice at all and breaks the logic of letting OSD elements disappear when
they're not wanted anymore. Fix this by adding a separate timer for
this.
Additionally, make sure the OSD bar is _really_ always updated when
visible. Also, redraw the OSD only if the OSD bar actually changes to
prevent redrawing too often (every vo_osd_changed() will flag that the
OSD should be redrawn, even if nothing changes).
Increase robustness against out of bound chapter numbers. Normally
these functions expect that the callers sanitize the chapter number.
This went wrong at least in add_seek_osd_messages() (which displayed
a chapter "-1" when chapters were not available). Make these functions
a bit friendler and add some reasonable checks and fallbacks, which
fixes the mentioned chapter seeking case as well.
Fixes#29. When a user used dead input keys (like the accent key), `mpv`
crashed because the code tried to access the 0 element of a characters array
(which was empty).
While I was closing this bug, I refactored some related conditionals to
make the code more readable.
Seeking before the start of a .flac file (such as seeking backwards when
the file just started) generates a bunch of decoding errors and audible
artifacts. Also, the audio output doesn't match the reported playback
position. The errors printed to the terminal are:
[flac @ 0x8aca1c0]invalid sync code
[flac @ 0x8aca1c0]invalid frame header
[flac @ 0x8aca1c0]decode_frame() failed
This is most likely a problem with the libavformat API. When seeking
with av_seek_frame() fails, the demuxer can be left in an inconsistent
state. ffplay has the same issue [1].
Older versions of mpv somehow handled this fine. Bisection shows that
commit b3fb7c2 caused this regression by removing code that retried
failed seeks with an inverted AVSEEK_FLAG_BACKWARD flag. This code was
removed because it made it harder to stop playback of a file by seeking
past the end of the file (expecting this is rather natural when skipping
through multiple files by seeking, and the internal mplayer demuxers
also did this).
As a workaround, re-add the original code, but only for the backwards
seeking case.
Also note that the original intention of the code removed in b3fb7c2 was
not dealing with this case, but something else. It also had to do with
working around weird libavformat situations, though. It's not perfectly
clear what exactly. See commit 1ad332f.
[1] https://ffmpeg.org/trac/ffmpeg/ticket/2282
Printed "error parsing option profile-desc=..." when using that inside
of profile sections. This happened because we now check the presence of
an option before setting it, and profile-desc is not an option, but
special cased in the config parser.
This affects the "show_progress" command, by defualt on the 'P' key.
If there are complaints, I'll probably remove it again. (It looks
relatively annoying, but it also valueable information... sort of.)
wm4
Alexander Preisinger
Stefano Pigozzi