At least on some keyboards, the key between '0' and 'Enter' on the
key pad is mapped to KP_Separator. Since X11 VOs accept unicode
input, the mplayer keycode this key generates depended on the numlock
state, and with numlock enabled this mapped to an ASCII character.
This is probably not what the user wanted, since two physical keys
will always map to the same key code.
Map it to KP_DEC.
This assumes the terminal uses UTF-8. If invalid UTF-8 is encountered (for
example because the terminal uses a legacy encoding), the code falls back
to the old method and feeds each byte as key code to the input code.
In theory, UTF-8 input could randomly fail, because the code in getch2.c
doesn't try to fill the input buffer correctly with input sequences
longer than a byte. This is a problem with the design of the existing
code.
This change allows using non-ASCII keys with X11. These keys were ingored
before.
Technically, this creates an invisible, non-interactive input method
context. If creation fails, the code falls back to the old method, which
allows a subset of ASCII only.
This moves all key codes above the highest valid unicode code point (which
is 0x10FFFF). All key codes below MP_KEY_BASE now directly map to unicode.
Configuration files (input.conf) can contain unicode characters in UTF-8
to map non-ASCII characters/keys.
This shouldn't change anything user visible, except that "direct key codes"
(as used in input.conf) will change their meaning.
Using the "expand" filter makes the image area larger by adding
borders to the video frame. These borders are supposed to be always
black. The filter relied on the borders in its output buffer staying
black without redrawing them for each frame. However, when using
direct rendering, a video filter inserted after vf_expand can draw
into these borders, for example the "unsharp" and "ass" filters. These
changes incorrectly stayed visible in the the following video frames.
Fix this by always clearing the borders in vf_expand. In some cases,
this might be more work than necessary, but vf_expand has no way of
detecting whether a subsequent filter draws into the borders or not,
and this avoids fragile assumptions about the existing contents of the
output buffer(s).
This also deals with frame size changes when config() is called again.
Before this commit, remains of the old video were visible if the new
video frame size was smaller than before.
Since we now always clear the borders, there's no more need for the
complicated code that cleared only the regions that were covered by the
OSD. Delete that.
When config() is called multiple times (e.g. aspect ratio changes
while the same file is playing), the user settings are not honoured,
because config() overwrites them. Don't do that.
This fixes a crash with vo_gl when the switch_ratio slave command is used
while a displaying an animated subtitle. switch_ratio will cause a config()
call to vo_gl, which will reset all state, including the EOSD state. Next
time the EOSD is rendered, its change detection will indicate that only
subtitle positions have changed. The render code will attempt to access
the EOSD data structures which have been deleted with config().
Fix this by forcing the change detection to indicate a full change if
config() has been called.
This only happens when doing switch_ratio with vo_gl, and the current
subtitle is only changing positions, i.e. mp_eosd_images_t.changed == 1.
With current typical video sizes, font sizes are large enough that
they don't really need hinting (and particularly so for font sizes in
display-resolution rendered subtitles in fullscreen mode), and hinting
apparently causes problems with some fonts.
Currently there is no way to set the swap interval with a function
that has a signature compatible with other platforms' gl extensions.
Make a wrapper function around the gui toolkit method of setting the
swap interval property, and point gl->SwapInterval to it.
Remove the useless dependency on MPGLContext from cocoa_common, since
it was used just to access the vo struct. Change gl_common to pass the
vo struct directly to all the cocoa_common functions.
Always set the X11 window title properties as UTF-8. This is a bit tricky
for X11 window properties which are not specified to use UTF-8, such as
WM_NAME.
We also properly set WM_ICON_NAME, which means the window caption and the
text used in the task bar (of the WM has one) will be the same on most
window managers. Before this commit, WM_ICON_NAME was always hardcoded to
"MPlayer", even if --title or --use-filename-title was used.
Also update the window title only on reconfigure, like it is done in
mplayer-svn commit 34380.
This affects only the "new" VO API. The config() title argument was barely
used, and it's hardcoded to "MPlayer" in vf_vo.c. The X11 and the Cocoa
GUI backends, which are the only ones properly supporting window titles,
ignored this argument. Remove the title argument.
Add the vo_get_window_title function. All GUI VOs are supposed to use it
for the window title.
Avoid calling avcodec_close() in uninit() if avcodec_open() failed.
Calling avcodec_close() on a non-open codec context causes a crash
with recent Libav versions.
Remove no longer necessary tests from hrseek code. As a result each
field of vo_vdpau framerate-doubling deinterlace modes is now
considered as a possible seek target.
Adjust the scheduled time until next frame when changing playback
speed (only affects behavior without audio). The main case where this
makes a difference is when it would take a noticeably long time to
switch frames with the previous speed and you switch to a faster
speed.
Remove code refreshing window contents after events such as resize
from vo_vdpau, vo_gl and vo_xv. Instead have them simply set a flag
indicating that a refresh is needed, and have the player core perform
that refresh by doing an OSD redraw. Also add support for updating the
OSD contents over existing frames during slow-but-not-paused playback.
The VOs now also request a refresh if parameters affecting the picture
change (equalizer settings, colormatrix, VDPAU deinterlacing setting).
Even previously the picture was typically redrawn with the new
settings while paused because new OSD messages associated with setting
changes triggered a redraw, but this did not happen if OSD was turned
off.
A minor imperfection is that now window system events can trigger a
single one-frame step forward when using vo_xv after pausing so that
vo_xv does not yet have a copy of the current image. This could be
fixed but I think it's not important enough to bother.
Previously the core sent VFCTRL_REDRAW_OSD to change OSD contents over
the current frame. Change this to VFCTRL_REDRAW_FRAME followed by
normal EOSD and OSD drawing calls, then vo_flip_page(). The new
version supports changing EOSD contents for libass-rendered subtitles
and simplifies the redraw support code needed per VO. vo_xv doesn't
support EOSD changes because it relies on vf_ass to render EOSD
contents earlier in the filter chain.
vo_xv logic is additionally simplified because the previous commit
removed the need to track the status of current and next images
separately (now each frame is guaranteed to become "visible" soon
after we receive it as "next", with no VO code running in the interval
between).
Separate passing a new frame to VOs using the new API into two steps.
The first, vo_draw_image(), happens after a new frame is available
from the filter chain. In constrast to old behavior, now the frame is
not actually rendered yet at this point (though possible slice draw
calls can already reach the VO before). The second step,
vo_new_frame_imminent(), happens when we're close enough to the
display time of the new frame that we'll commit to flipping it as the
next action and will not change the OSD over the previous frame any
more.
This new behavior fixes a previous problem with vo_vdpau and vo_gl in
the situation where the player is paused after decoding a new frame
but before flipping it; previously changing OSD in that state would
switch to the new frame as a side effect. It would also allow an easy
way to fix extra output files produced with something like "--vo=png
--frames=1" with precise seeking, but this is not done yet.
The code now relies on a new mp_image from the filter chain staying
valid even after the vf_vo put_image() call providing it returns. In
other words decoders/filters must not deallocate or otherwise
invalidate their output frame between passing it forward and returning
from the decode/filter call.
Add native Cocoa code to display an OpenGL window. Some of the code is
based on the OpenGL parts of vo_corevideo but I took the time to remove
old code based on Carbon.
There is autodetection in the configure script but you can use
--enable[disable]-cocoa to enable[disable] this.
When interpreting a key event, use the "charactersIgnoringModifiers"
method of the event in order to extract Alt+key combinations while
keeping the normal meaning of "key". When the right alt modifier is
pressed use the "characters" method to allow AltGr behavior to be used
to generate different characters.
The ARB shader code generated at the end of the shaders for scaling mode 4
and 5 was something like:
MAD yuv.g, b.r, {0.5}, a.r;
This appears to be semantically equivalent with:
MAD yuv.g, b.rrrr, {0.5, 0, 0, 0}, a.rrrr;
This has the consequence that the result register, yuv.g, will not contain
the value computed by the scale filter, but a.r. a.r is the unchanged
value sampled from the normal texture coordinates, so the filter did
effectively nothing and behaved as if cscale=0 was specified. The basic
mistake here is that yuv.g does not specify a single register, but it
specifies the full vector register yuv, with writing enabled on the g
channel. This means yuv.g will assigned the g channel of the the result
vector computed by the MAD instruction.
The GL_LUMINANCE16 texture format had only 8 bit precision on Mesa
based drivers. This caused heavy degradation of the image when playing
formats with more than 8 bits per pixel, such as 10 bit h264. Use
GL_R16 instead, which at least Mesa and Nvidia drivers actually
implement as 16 bit textures. Since sampling from this texture format
doesn't return anything meaningful in the other color components
(unlike luminance textures), the shader code has to be slightly
changed.
GL_R16 requires the GL_ARB_texture_rg extension. Check for it, and fall
back to the old texture format if it's not available.
The low precision of the GL_LUMINANCE16 format has just been fixed in
upstream Mesa, but it'll take a while before that fix is available in
distros.
The shader code was generated from very long strings with lots of
format specifiers with snprintf calls. It was almost impossible to
quickly tell what variables were inserted where in the shader. Make
this more readable by implementing a kind of simple variable
substitution, which allows replacing the format specifiers in the code
templates with with variable names.
Caveat: the OSD will be included in the screenshots when the screenshot is
taken during normal playback. This doesn't happen when a screenshot is
taken while playback is paused.
Fixing this would introduce a small performance reduction during normal
playback, which is unacceptable for a possibly rarely used optional
feature.
Due to the nature of the Xv API, taking a screenshot of the scaled video
isn't possible either.
The screenshot command normally converts the currently displayed video
frame to an image. Add support for an alternative screenshot mode
that is supposed to capture the real window contents. Such a
screenshot contains a possibly scaled version of the frame, the OSD,
and subtitles.
Add a default key binding Alt+s for taking screenshots in this mode.
This needs special VO support, and might not work with all VOs (this
commit does not yet contain an implementation for any VO, only the
infrastructure).
Add a VO command (VOCTRL_SCREENSHOT) which requests a screenshot
directly from the VO. If VO support is available, screenshots will be
taken instantly (no more 1 or 2 frames delay). Taking screenshots when
hardware decoding is in use will also work (vdpau). Additionally, the
screenshots will now use the same colorspace as the video display.
Change the central MPContext to be allocated with talloc so that it
can be used as a talloc parent context.
This commit does not yet implement the functionality for any VO (added
in subsequent commits).
The old screenshot video filter is not needed anymore if VO support is
present, and in that case will not be used even if it is present in
the filter chain. If VO support is not available then the filter is
used like before. Note that the filter still has some of the old
problems, such as delaying the screenshot by at least 1 frame.
RenderCallbackSPDIF might call read_buffer with NULL data. The purpose
is to drain data from the buffer when the output is muted. Add a check
to call av_fifo_drain() in this case.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34241 b3059339-0415-0410-9bf9-f77b7e298cf2
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@34242 b3059339-0415-0410-9bf9-f77b7e298cf2
The implementation of the switch_ratio command was hacky and called
mpcodecs_config_vo() to reconfigure the filter/VO chain from under an
existing decoder. This call no longer worked properly with vd_ffmpeg
after that started using mpcodec_config_vo2(). Add new video decoder
control command VDCTRL_RESET_ASPECT and use this to tell vd_ffmpeg to
reinitialize the output chain properly.
Some demuxers do not accurately seek to a keyframe before a given
time but instead start too late. This means that precise seeks cannot
work either. Most notably the libavformat mpeg demuxer exhibits this
behavior depending on the file being played (with the internal mpeg
demuxer precise seeks don't work at all). Add new option
--hr-seek-demuxer-offset which can be used as a workaround with such
demuxers. The value of the option is subtracted from the seek target
position given to the demuxer when doing a precise seek.
Before, precise seeking only worked if there was a video stream; in
the audio-only case playback always started from the demuxer seek
position. Add code to cut away samples from the demuxer seek position
to the seek target position.
Support "no-" prefix to negate boolean suboptions in the subopt helper
(used to parse VO etc suboptions). Previously only "no" was supported,
unlike toplevel options which gained "no-" support earlier.
When not using direct rendering, vd_ffmpeg created an mp_image struct
before calling libavcodec decoder, so that possible slice support
could be checked from the mpi_image and output would be ready for
slice-drawing calls. However, this behavior is unsound with decoders
that can change output size, as the parameters can change after the
mp_image was created. Disable the code creating the mp_image at that
point, which also disables use of slices in this case. Slices are
disabled with threading anyway, so I think trying to add workarounds
to support them is not a high priority.
I think this code has always been buggy, but before common thread use
it was rarely executed because the direct-rendering case was used
instead.
Information about individual chapters was printed during demuxer
opening phase, and total chapter count (ID_CHAPTERS) was printed
according to mpctx->demuxer->num_chapters. When playing a file with
ordered chapters, this meant that chapter information about every
source file was printed individually (even though only the chapters
from the first file would be used for playback) and the total chapter
count could be wrong. Remove the printing of chapter information from
the demuxer layer and print the chapter information and count actually
used for playback in core print_file_properties().
Also somewhat simplify the internal chapters API and remove possible
inconsistencies.
wm4
Uoti Urpala
Stefano Pigozzi
reimar
Zongyao Qu