Some OpenGL implementations on some platforms require that a context
is current only on one thread. For this reason, mpgl_lock() and
mpgl_unlock() take care of this as well for convenience.
Each backend that needs thread safety should provide it's own locking strategy
inside of `set_current`.
This is done because statically linked SDL libraries are incompatible
with direct X11 function use (e.g. vo_x11, vo_gl etc.) because of
clashing symbol names.
http://bugzilla.libsdl.org/show_bug.cgi?id=1828
Uses the same mechanisms as stream_dvd to report the virtual playback
time as known by libdvdread/libbluray, instead of the raw demuxer
output.
This should solve many problems with BD playback, like correct display
of playback time and duration.
On the other hand, this causes some new problems. For example, the
reported stream time has a rather low resolution (1-2 seconds), so
doing precise seeking on it is near impossible.
Makes it easier to understand... maybe. It's still pretty strange how
this function may either queue the seek or seek immediately. The way
it actually works doesn't change, queuing the seek is just moved into
the function.
Also add a execute_queued_seek() function, which resets the queue state
correctly.
This fixes 2 bugs:
* Resizing very fast breaks the aspect of the window and the width and height
don't match with the video anymore
* Pressing 'f' for fullscreen very fast can overwrite the backup variables for
the previous width and height.
Also includes a better aspect calculation with fluid resizing.
Allow the stream layer to report chapter times. Extend stream_dvd to do
this. I'm not 100% sure whether the re-used code is bug-free (because it
was used for slave-mode and/or debugging only).
MAke the frontend do time-based seeks when switching DVD chapters. I'm
not sure if there's a real reason STREAM_CTRL_SEEK_TO_CHAPTER exists
(maybe/hopefully not), but we will see.
Note that querying chapter times in demuxer_chapter_time() with the new
STREAM_CTRL_GET_CHAPTER_TIME could be excessively slow, especially with
the cache enabled. The frontend likes to query chapter times very often.
Additionally, stream_dvd uses some sort of quadratic algorithm to list
times for all chapters. For this reason, we try to query all chapters on
start (after the demuxer is opened), and add the chapters to the demuxer
chapter list. demuxer_chapter_time() will get the time from that list,
instead of asking the stream layer over and over again.
This assumes stream_dvd knows the list of chapters at the start, and
also that the list of chapters never changes during playback. This
seems to be true, and the only exception, switching DVD titles, is not
supported at runtime (and doesn't need to be supported).
The frontend doesn't use this.
Also use double for returning the chapter times. Everything uses double
for times, and there's no reason to use float here.
These were found by the cppcheck and scan-build static analyzers. Most
of these aren't interesting (the 2 previous commits fix some interesting
cases found by these analyzers), and they don't nearly fix all warnings.
(Most of the unfixed warnings are spam, things MPlayer never cared
about, or false positives.)
This caused all formats with fewer than 8 bits per component marked as
little endian. (Normally, only some messed up packed RGB formats are
endian-specific in this case.)
"%[,.:]" conversion was used with a buffer that could be shorter than
the matched string. Suppress assignment of the conversion since the
value wasn't used anyway, and also limit match length to 1 as it
doesn't look like the intent was to match longer runs of the
characters.
Merged from mplayer2 commit 5cb9aac. Note that the other half of the
mplayer2 commit is already part of the mpv commit d98e61e. (I'm not
sure why. The mplayer2 commit date precedes mpv's, but was pushed long
after the mpv change was pushed; either one of the dates is wrong, or
we did the same work twice - in that case, thanks a lot...)
Commit 4d14a42, a seemingly harmless change, introduced very bad cache
behavior when the cache isn't forked, such as on Windows, where it uses
threads. Apparently the cache code was designed for forking, and an
unknown obscure condition causes severe performance degradation if a
STREAM_CTRL is sent to the cache on every frame.
Since the cache code is literally insane (uses shared memory + fork(),
and has hacks to make it work with threads, is messed into the stream
code in extra-hacky ways), we just fix it by caching the STREAM_CTRL in
question.
This is also done for some other STREAM_CTRLs that are called on each
frame, such as playback duration. This indicates that the cache code has
some inherent problem with answering such requests in a timely matter,
and that there's no easy way around this.
(Even if the cache is eventually rewritten, these things will probably
have to be cached, otherwise you'd have to forcibly block until the
stream implementation is done with a blocking read. The real question
is why it worked fine with the forked cache, though.)
A "watch later" command is now mapped to Shift+Q. This quits the player
and stores the playback state in a config file in ~/.mpv/watch_later/.
When calling the player with the same file again, playback is resumed
at that time position.
It's also possible to make mpv save playback state always on quit with
the --save-position-on-quit option. Likewise, resuming can be disabled
with the --no-resume-playback option.
This also attempts to save some playback parameters, like fullscreen
state or track selection. This will unconditionally override config
settings and command line options (which is probably not what you would
expect, but in general nobody will really care about this). Some things
are not backed up, because that would cause various problems. Additional
subtitle files, video filters, etc. are not stored because that would be
too hard and fragile. Volume/mute state are not stored because it would
mess up if the system mixer is used, or if the system mixer was
readjusted in the meantime.
Basically, the tradeoff between perfect state restoration and
complexity/fragility makes it not worth to attempt to implement
it perfectly, even if the result is a little bit inconsistent.
Now vid/aid/sid can be used as properties. video/audio/sub still work,
but they are aliases for the "real" properties.
This guarantees that options/properties use the same value range. One
consequence is that the video/audio/sub properties return "no" as value
if no track is selected instead of -1.
Also, mark demuxer as not capable if DVD playback is done. The problem
with DVD is that playback time (stream_pts) is not reported frame-exact,
and the time is a "guess" at best.
With the commit "demux_lavf: fix DEMUXER_CTRL_RESYNC", DVD playback
seems to work nicely with demux_lavf, and maybe works even better than
with demux_mpg.
The old demuxer can be forced with: --demuxer=mpegps
If no regressions surface, demux_mpg.c will be deleted later.
This used the libavformat current position, instead of the mp stream
(which reflects current DVD/Bluray read position). This was broken,
because libavformat won't update its position by calling the user's
stream callbacks, negating the whole point of DEMUXER_CTRL_RESYNC.
Now DVD playback with libavformat seems to work relatively well.
demux_mpg did the same, and doing this in demux_lavf fixes DVD playback
when using this demuxer.
Additionally this might make bluray work better in the future (but for
now, bluray playback doesn't change as it doesn't report stream PTS yet).
Will be needed to override the demuxer's start time reporting. We could
be lazy and special-case it since the result is always 0 for the streams
that care, but doing it properly is better.
DVD playback uses a demuxer that signals to the frontend that timestamp
resets are possible. This made the frontend calculate the OSD playback
position based on the byte position and the total size of the stream.
This actually broke DVD playback position display. Since DVD reports a
a linear playback position, we don't have to rely on the demuxer
reported position, so disable this functionality in case of DVD
playback. This reverts the OSD behavior with DVD to the old behavior.
This allows using the vdpau decoders with -vd without having to use
the -hwdec switch (basically like in mplayer).
Note that this way of selecting the hardware decoder is still
deprecated. libavcodec went away from adding special decoder entries
for hardware decoding, and instead makes use of the "hwaccel"
architecture, where hardware decoders use the same decoder names as
the software decoders. The old vdpau special decoders will probably
be deprecated and removed in the future.
YCgCo can be manually selected, but will also be used if the decoder
reports YCgCo. To make things more fun, files are sometimes marked
incorrectly, which will display such broken files incorrectly starting
with this commit.
Useful for the j2k decoder.
Matrix taken from http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
(XYZ to sRGB, whitepoint D65)
Gamma conversion follows what libswscale does (2.6 in, 2.2 out).
If linear RGB is used internally for scaling, the gamma conversion
will be undone by setting the exponent to 1. Unfortunately, the two
gamma values don't compensate each others exactly (2.2 vs. 1/0.45=2.22...),
so output is a little bit incorrect in sRGB or color-managed mode. But
for now try hard to match libswscale output, which may or may not be
correct.
We only print an error message when POLLERR or POLLHUP occurrs, as the
something did go horribly wrong and the server will either deal with it or
crash.
Also add POLLOUT to the events.
Bump xkbcommon version and use the new xkb_keymap_from_buffer. This is more
secure, because the from_string expects a 0 terminated string, but this cannot
be guaranteed with mmap.
wm4
Rudolf Polzer
Alexander Preisinger
Uoti Urpala