It is now possible to show images and videos with alpha information correctly.
This was disalbed before, because there was a bug that made black parts of
videos also transparent.
The OSX part of the Apple Remote was unmaintained for a long time and was not
working anymore. I tried to update the cookies to what the current versions of
OS X expect without much luck. I decided to remove it since Apple is not
including the IR receiver anymore in new hardware and it's clear that wifi
based remotes are the way to go.
A third party iOS app should be used in it's place. In the future we could look
into having a dedicated iOS Remote Control app like VLC and XBMC do.
The Linux side (`appleir.c`) was relatively tidy but it looks like LIRC can be
configured to work with any version of Apple Remote [1] and is more maintained.
[1] LIRC Apple Remote configs: http://lirc.sourceforge.net/remotes/apple/
Commit ac1c5e6 (demux_mkv: improve robustness against broken files)
added code to skip to the next cluster on error conditions. However,
reaching normal EOF triggers this code as well, so explicitly check
for EOF before this happens. Note that the EOF flag is only set _after_
reading the last byte, so EOF needs to be checked after the fact. (Or
in other words, we must check for EOF after the ebml_read_id() call.)
(To answer the question why reading packets actually reaches EOF, even
if there's the seek index between the last packet and the end of the
file: the cluster reading code skips the seeking related EBML elements
as normal part of operation, so it hits EOF gracefully when trying to
find the next cluster.)
Drawing the bar with vector drawings (instead with characters from the
OSD font) offers more flexibility and looks better. This also adds
chapter marks to the OSD bar, which are visible as small triangles on
the top and bottom inner border of the bar.
Change the default position of the OSD bar below the center of the
screen. This is less annoying than putting the bar directly into the
center of the view, where it obscures the video. The new position is
not quite on the bottom of the screen to avoid collisions with
subtitles.
The old centered position can be forced with ``--osd-bar-align-y=0``.
Also make it possible to change the OSD bar width/height with the new
--osd-bar-w and --osd-bar-h options.
It's possible that the new OSD bar renders much slower than the old
one. There are two reasons for this: 1. the character based bar
allowed libass to cache each character, while the vector drawing forces
it to redraw every time the bar position changes. 2., the bar position
is updated at a much higher granularity (the bar position is passed
along as float instead of as integer in the range 0-100, so the bar
will be updated on every single video frame).
The previous attempt was missing some code paths, so there were still
shaders generated that triggered the shader compilation error. Fix it
instead by special handling USE_CONV in the shader.
By the way, the shader compiler did not accept:
#if defined(USE_CONV) && (USE_CONV == ...)
In my opinion this should be perfectly fine, but it gives the same
error as before. So test USE_CONV separately with #ifndef.
The OSX shader compiler was giving this error:
ERROR: 0:235: '' : syntax error incorrect preprocessor directive
on this line:
[235] #if USE_CONV == CONV_PLANAR
USE_CONV was undefined in some cases. The expected behavior is that the
shader preprocessor interprets this as branch not taken (AFAIK exactly
as in C), which is probably what the standard would dictate. This is
possible an OSX bug. But admittedly, I'm not sure whether this is really
standard behavior (in C or GLSL), and doing this is extremely weird at
best, so make sure that USE_CONV is always defined.
Should fix behavior on OSX.
Allows playing video with alpha information on X11, as long as the video
contains alpha and the window manager does compositing. See vo.rst.
Whether a window can be transparent is decided by the choice of the X
Visual used for window creation. Unfortunately, there's no direct way to
request such a Visual through the GLX or the X API, and use of the
XRender extension is required to find out whether a Visual implies a
framebuffer with alpha used by XRender (see for example [1]). Instead of
depending on the XRender wrapper library (which would require annoying
configure checks, even though XRender is virtually always supported),
use a simple heuristics to find out whether a Visual has alpha. Since
getting it wrong just means an optional feature will not work as
expected, we consider this ok.
[1] http://stackoverflow.com/questions/4052940/how-to-make-an-opengl-rendering-context-with-transparent-background/9215724#9215724
When displaying YUV with alpha plane (an extremely rare special case),
we didn't upload the alpha plane, because we don't do anything with it.
This actually created some annoying special cases, so upload the alpha
planes as well, even if they're unused.
This is a bit cleaner. Also don't repeat the chroma shift calculations
over and over, but store the image size instead, which is simpler and
will give us a chance to fix display of non-mod-2 image sizes.
gl_video.c contains all rendering code, gl_lcms.c the .icc loader and
creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is
reduced to interfacing between the various parts.
Do this instead of stuffing all x11/cocoa/win32/wayland specific code
into gl_common.c. The cocoa specific parts could probably go directly
into cocoa_common.m, possibly same with wayland.
Also redo how the list of backends is managed. Get rid of the GLTYPE_
constants. Instead of having a big switch() on GLTYPE_, each backend
entry has a function pointer to setup the MPGLContext callback (e.g.
mpgl_set_backend_x11()).
Makes the code a bit simpler to follow, at least in the "modern"
decoding path (update_video_nocorrect_pts() is used with old demuxers,
which don't return proper packets and need further parsing, so this code
looks less simple now).
Fixes test7.mkv from the Matroska test file collection, as well as some
real broken files I've found in the wild. (Unfortunately, true recovery
requires resetting the decoders and playback state with a manual seek,
but it's still better than just exiting.)
If there are broken EBML elements, try harder to skip them correctly.
Do this by searching for the next cluster element. The cluster element
intentionally has a long ID, so it's a suitable element for
resynchronizing (mkvmerge does something similar).
We know that data is corrupt if the ID or length fields of an element
are malformed. Additionally, if skipping an unknown element goes past
the end of the file, we assume it's corrupt and undo the seek. Do this
because it often happens that corrupt data is interpreted as correct
EBML elements. Since these elements will have a ridiculous values in
their length fields due to the large value range that is possible
(0-2^56-2), they will go past the end of the file. So instead of
skipping them (which would result in playback termination), try to
find the next cluster instead. (We still skip unknown elements that
are within the file, as this is needed for correct operation. Also, we
first execute the seek, because we don't really know where the file
ends. Doing it this way is better for unseekable streams too, because
it will still work in the non-error case.)
This is done as special case in the packet reading function only. On
the other hand, that's the only part of the file that's read after
initialization is done.
Fixes test4.mkv from the Matroska test file collection.
demux_mkv_open() contains a loop that reads header elements. It starts
by reading the EBML element ID with ebml_read_id(). If there is broken
data in the header, ebml_read_id() might return EBML_ID_INVALID.
However, that is not handled specially, and the code for handling
unknown tags is invoked. This reads the EBML element length in order to
skip data, which, if the EBML ID is broken, is entirely random. This
caused a seek beyond the end of the file, making the demuxer fail.
So don't skip any data if the EBML ID was invalid, and simply try to
read the next element. ebml_read_id() reads at least one byte, so the
parsing loop won't get stuck.
All in all this is rather questionable, but since this affects error
situations only, makes behavior a bit more robust (no random seeks), and
actually fixes at least one sample, it's ok.
libavformat's demuxer handled this.
There were complaints that ${fps} was printed as e.g. "23.98" instead of
"23.976". Since there's no way to format floats exactly _and_ in a user-
friendly way, just change the default precision for printing floats.
Prevents the status line from being printed. Otherwise, the status line
is always printed due to --frames=1, and it's visible on the terminal
because it's printed to stderr.
This way it's possible to retrieve correct information about video, like
actual width/height, which in general are available only after at least
one frame has been sent to the video output, such as dwidth/dheight.
mpv_identify.sh becomes a bit slower, because we let it decode enough
audio and video to fill the audio buffers and to send one frame to the
video output. Also, --playing-msg isn't shown anymore with --frames=0
(could be fixed by special-casing it, should this break any use cases).
Note that in some corner cases, like when the demuxer for some reason
returns lots of audio packets but no video packets at the start, but
video actually starts later, the --playing-msg will still be output
before video starts.
This has the same (useless) definition as frame stepping in audio-only
mode: one frame means one playloop iteration. (It's relatively useless,
because one playloop iteration has a random duration. But it makes
--frames=1 work, which is useful again.)
Add new properties "dwidth" and "dheight", which contain the video
size as known by the VO (not necessarily what the VO makes out of them,
i.e. without window scaling and panscan).
Some time ago, all old special-cased commands (like "volume 1" to change
volume by one) have been removed. These commands are still emulated
using simple text replacement. This emulation is done to not break
everyone's input.conf, especially because the input.conf provided by
standard mplayer* still uses the old commands.
Every use of a deprecated command prints a replacement warning, which
was visible only with -v. Make these warnings visible by default.
There's actually not much reason to do this, but since commands like
"volume 5 1" don't work anymore, it's better to be verbose about this.
Also simplify the replacement for "vo_fullscreen".
Normal text was set to gray foreground color. This didn't work for
terminals with white background.
Instead of setting a color for normal text, reset the color attributes.
This way, only errors and warnings are formatted differently.
Also change the default color for MSGL_HINT from bold white to yellow.
Good news: MPV worked fine even without the fixes, but pointer size
mismatch warnings aren't the nicest things to leave lying around.
Fix macro that assumed HWND is uint32_t-sized.
Win64 is also a special butterfly and is an LLP64 platform on amd64
CPUs, while all the other amd64 platforms are LP64. Cygwin decided to go
with the other platforms, and thus sizeof(long) != sizeof(int), and in
cygwin's windows headers LONG is int-sized. Fix an mp_msg that assumed
LONG is long.
In some cases (when using tune=animation as an additional option), the
N900 profile caused use of 6 reference frames, where Level 3.0 only
allows 5 reference frames. This prevented playback on the Nokia N900.
This has been fixed by always specifying refs=5.
Alexander Preisinger
wm4
Rudolf Polzer
Stefano Pigozzi
Kovensky