The png file added to etc/ are taken from the link mentioned in commit
303096b, except that they have been converted to 16 bit, sRGB (with
color profile info dropped, if there was one), and transparent pixels
reset for better compression.
The file x11_icon.bin is generated by gen-x11-icon.sh. I'm adding it to
the git repo directly, because the script requires ImageMagick, and we
don't want to make building even more complicated.
The way how this is done is basically a compromise between effort
required in x11_common.c and in gen-x11-icon.sh. Ideally, x11_icon.bin
would be directly in the format as required by _NET_WM_ICON, but trying
to write the binary width/height values from shell would probably be a
nightmare, so here we go.
The zlib code in x11_common.c is lifted from demux_mkv.c, with some
modifications (like accepting a gzip header, because I don't know how to
make gzip write raw compressed data).
This allows other threads to use mp_input_put_key without blocking if the
playloop is doing the 500ms select call (i.e.: during pause).
Makes Cocoa GUI responsive again (regression since 2d363c3).
If the input section is enabled with MP_INPUT_ALLOW_VO_DRAGGING, then
the VO will be allowed to drag the window with mouse button down +
mouse move even if the mouse is inside the section's mouse area.
If the mpv window is unfocus, clicking on the OSC should focus the
window (done by the window manager) and allow interaction with the OSC.
But somehow X sends a spurious LeaveNotify event, immediately followed
by an EnterNotify event. This happens at least with IceWM. The result is
that the OSC will disappear (due to receiving MOUSE_LEAVE). The OSC will
stay invisible, because EnterNotify isn't handled, and there's nothing
that could make the OSC appear again.
Solve this by handling EnterNotify. We cause a redundant MOUSE_MOVE
event to be sent, which triggers the code to make the OSC visible. We
have to remove the code from input.c, which ignores redundant mouse move
events.
Since the code ignoring redundant mouse move events is still needed on
Windows, move that code to w32_common.c. The need for this is documented
in the code, also see commit 03fd2fe. (The original idea was to save
some code by having this code in the core, but now it turns out that
this didn't quite work out.)
Normally, moving the mouse outside of the mouse area of an input section
will send mouse events somewhere else (because input section mouse areas
are similar to windows/widgets in real GUI toolkits). This was done even
if a mouse button was held down. This is quite different from how GUI
toolkits behave.
Change the code so that if a mouse button is down, the mouse area of the
current input section can't be left. Releasing the mouse button (while
the mouse pointer is outside of the mouse area) will actually leave the
mouse area.
As a side-effect, this commit also tests more often whether the current
mouse input section is valid. This is needed to make releasing a mouse
button trigger the mouse input section change.
These keys can be found on various "multimedia" and "internet" keyboard.
X defines many keycodes, so I'm not adding all, just what I found on my
own keyboard.
Other key codes can be added on request.
This is basically a libavcodec API oddity: it can happen that
avcodec_decode_audio4() returns 0 (meaning 0 bytes were consumed). It
requires you to feed the complete packet again to decode the full
packet, and to successfully decode the following packets.
We ignored this case with the argument that there's the danger of an
endless decode loop (because nothing of that packet is apparently
decoded, so it would retry forever), but change it in order to decode
mpc8 files correctly.
Also add some comments to explain the mess.
I suspect most users will just copy etc/input.conf when they want to
remap some default bindings. But usually this means the user even copies
bindings he doesn't care about, and it's better if the user maps only
the bindings in his input.conf the user intends to remap.
Comment all bindings in etc/input.conf. Since this file also defines the
builtin defaults and is baked into the mpv binary, we have to do
something to get them anyway, even though they are commented. Do this by
having input.c "uncomment" the bindings in the baked in input.conf. (Of
course this is done only for the builtin config, not configs loaded from
disk.)
The previous code was locking only the input queue. That was too weak since it
didn't protect the input_ctx data structure. So remove the locking on the queue
and lock all the public functions that interact with the input_ctx.
The private functions and public functions that do not act on the input_ctx
(there are quite some functions doing mp_cmd manipulations for instance) are
not locked.
Some changes by wm4. Use a recursive mutex, and restructure some code to be
less annoying with locks, such as converting code to single return, or
making use of the recursive mutex.
Generate a mouse down event on the first click so that one can interact
with the OSC directly as opposed to wasting the first click in order to focus
the window.
I would like to thank Chris Ward (@tenzerothree, http://tenzerothree.com/) for
working on the art for these icons and bringing some eye candy to the project.
The PSDs made by Chris are available on our Dropbox [1], along with the exports
I made to create OSX and Windows icons. The PSDs are almost completly vector
and all the resolutions look really similar, except the 16px favicon which was
handcrafted to look better and more recognizeable on the smaller pixel budget.
For Mac OS X the icons were created using iconutils on the PNGs iconsets
exported from the PSDs. These even support retina resolutions (except 512@2x).
For Windows the .ico file was created with imagemagick. The included images
are 16px, 24px, 32px, 48px 64px, 256px. These are the resolutions listed on
MSDN for supporting Windows XP [2] and Windows versions based on Aero [3].
Only 32bit PNGs were used since it is 2013.
For Linux nothing changed yet, even though @wm4 talked about using the PNGs
directly there. This will probably be dealt with in a later commit.
[1]: https://www.dropbox.com/sh/yelfoj9tbft7o06/A8vOT6JKaG
[2]: http://msdn.microsoft.com/en-us/library/ms997636.aspx
[3]: http://msdn.microsoft.com/en-us/library/aa511280.aspx
This probably has been broken since bbc865a: a test was added that uses
a FBO, but it's always run, even if FBOs were not detected. On the other
hand, fbotex_init() just runs into an assert. Fix the test that
triggered this condition, and make fbotex_init() "nicer" by just failing
if FBOs are not available.
Port it from playlist_parser.c to demux_playlist.c. Also, change the m3u
parser to drop whitespace from the trailing part of the line (will make
it work properly with windows line endings).
(I hoped that this would make MMS URIs with http instead of mmsh
prefixes work, but it doesn't. Instead, it leads to a playlist loop. So
solving this issue would require a change in ffmpeg, probably.)
Until now, stream_peek() read only the bare minimum it had to read from
the stream. But this could cause problems, such as being very
inefficient when peeking a lot, or conflicting with ability to seek
back. (The latter issue can be caused by peeking a few bytes, and then
doing a stream_read() with a size that is 1 byte longer: this would read
the peeked data, then call stream_fill_buffer(), which throws away the
previously peeked bytes - so you can't seek back anymore. This is
mitigated by a hack in demux_open(): it peeks a full buffer, to avoid
that peeking/reading during demuxer probing [or before that, in a stream
filter] can cause the buffer to be dropped.)
The original condition was too weak, requiring only the header. The header is
installed is FFmpeg regardless of the presence of VDA on the system, so just
perform a check on the `ff_vda_create_decoder` function.
Make use of opaque regions on non-alpha formats. This allows the compositor to
improve the drawing of the surface, because he can discard everything behind
the window when drawing.
Odd video sizes if pixel formats with chroma subsampling and PBOs were
used, garbage was rendered. This was because the PBO path created
buffers with an unpadded size, and then tried to upload a padded
image to it. Fix it by explicitly setting the padded size. (As with
the non-PBO path, we rely that image allocations are somehow padded,
which is normally the case.)
Apparently, it is popular to store large files in uncompressed rar
archives. Extracting files is not practical, and some media players
suport playing directly from uncompressed rar (at least VLC and some
DirectShow components).
Storing or accessing files this way is completely idiotic, but it is
a common practice, and the ones subjected to this practice can't do
much to change this (at least that's what I assume/hope). Also, it's
a feature request, so we say yes.
This code is mostly taken from VLC (commit f6e7240 from their git tree).
We also copy the way this is done: opening a rar file by itself yields
a playlist, which contains URLs to the actual entries in the rar file.
Compressed entries are simply skipped.
Add a stream filter concept, in which streams can be opened on top of
an underlying "source" stream. Change the open code to make this
easier, and also to account for some mechanisms that will be needed
for this.
The following commit will add stream_rar, which contains such a stream
filter.
This is really not needed. While we really can't take a loaded buffer
over to the cache, there's no reason why the cache couldn't read this
buffer normally.
On the other hand, this code could cause trouble when probing from a
stream before the cache has been enabled.
The way the url_options field was handled was not entirely sane: it's
actually a flexible array member, so it points to garbage for streams
which do not initialize this member (it just points to the data right
after the struct, which is garbage in theory and practice). This was
not actually a problem, since the field is only used if priv_size is
set (due to how this stuff is used). But it doesn't allow setting
priv_size only, which might be useful in some cases.
Also, make the protocols array not a fixed size array. Most stream
implementations have only 1 protocol prefix, but stream_lavf.c has
over 10 (whitelists ffmpeg protocols). The high size of the fixed
size protocol array wastes space, and it is _still_ annoying to
add new prefixes to stream_lavf (have to bump the maximum length),
so make it arbitrary length.
The two changes (plus some more cosmetic changes) arte conflated into
one, because it was annoying going over all the stream implementations.
Modeled after the old playlist_parser.c, but actually new code, and it
works a bit differently.
Demuxers (and sometimes streams) are the component that should be used
to open files and to determine the file format. This was already done
for subtitles, but playlists still use a separate code path.
af_str2fmt_short(), which is used by the command line option parser,
allowed passing a hex number. The user could set arbitrary integers as
internal audio formats, even formats which don't exist or make no sense.
This is not very useful, so get rid of it.
Having to use -1 for that is generally quite annoying.
Audio formats are created from bitmasks, and it can't be excluded that
0 is not a valid format. Fix this by adjusting AF_FORMAT_I so that it
is never 0. Along with AF_FORMAT_F and the special formats, all valid
formats are covered and guaranteed to be non-0.
It's possible that this commit will cause some regressions, as the
check for invalid audio formats changes a bit.
A wayland output based on shared memory. This video output is useful for x11
free systems, because the current libGL in mesa provides GLX symbols. It is also
useful for embedded systems where the wayland backend for EGL is not
implemented like the raspberry pi.
At the moment only rgb formats are supported, because there is still no
compositor which supports planar formats like yuv420p. The most used compositor
at the moment, weston, supports only BGR0, BGRA and BGR16 (565).
The BGR16 format is the fastest to convert and render without any noticeable
differences to the BGR32 formats. For this reason the current (very basic)
auto-detection code will prefer the BGR16 format. Also the weston source code
indicates that the preferred format is BGR16 (RGB565).
There are 2 options:
* default-format (yes|no) Which uses the BGR32 format
* alpha (yes|no) For outputting images and videos with transparencies
The obtained information from the shm listener isn't used by anything and is
also wrong now in wayland git master branch because of new shm formats which
need a different way of saving the supported formats.
Moves a good chunk of the resizing code to wayland_common.c. This makes it
possible to share it with future video drivers.
It doesn't resizit it immediatly, it calcutlates the new position and size and
then shedules a resizing event. This removes the ugly callback and void pointer
from the wayland data structure.
Regression since 18b6c01d92. That commit changed the colorspace handling to
always reinit the video output. Since the CVPixelBuffers are lazily created,
VOCTRL_SET_YUV_COLORSPACE was always called when the CVPixelBufferRef was NULL.
Since CoreVideo functions do not complain when called on NULL, no one noticed
that CVBufferSetAttachment, which stored the color matrix meta data was called
on NULL.
