| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The OSD will now be rendered with libass. The old rendering code, which
used freetype/fontconfig and did text layout manually, is disabled. To
re-enable the old code, use the --disable-libass-osd configure switch.
Some switches do nothing with the new code enabled, such as -subalign,
-sub-bg-alpha, -sub-bg-color, and many more. (The reason is mostly that
the code for rendering unstyled subtitles with libass doesn't make any
attempts to support them. Some of them could be supported in theory.)
Teletext rendering is not implemented in the new OSD rendering code. I
don't have any teletext sources for testing, and since teletext is
being phased out world-wide, the need for this is questionable.
Note that rendering is extremely inefficient, mostly because the libass
output is blended with the extremely strange mplayer OSD format. This
could be improved at a later point.
Remove most OSD rendering from vo_aa.c, because that was extremely
hacky, can't be made work with osd_libass, and didn't work anyway in
my tests.
Internally, some cleanup is done. Subtitle and OSD related variable
declarations were literally all over the place. Move them to sub.h and
sub.c, which were hoarding most of these declarations already. Make the
player core in mplayer.c free of concerns like bitmap font loading.
The old OSD rendering code has been moved to osd_ft.c. The font_load.c
and font_load_ft.c are only needed and compiled if the old OSD
rendering code is configured.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.gitignore
bstr.c
cfg-mplayer.h
defaultopts.c
libvo/video_out.c
The conflict in bstr.c is due to uau adding a bstr_getline function in
commit 2ba8b91a97e7e8. This function already existed in this branch.
While uau's function is obviously derived from mine, it's incompatible.
His function preserves line breaks, while mine strips them. Add a
bstr_strip_linebreaks function, fix all other uses of bstr_getline, and
pick uau's implementation.
In .gitignore, change vo_gl3_shaders.h to use an absolute path
additional to resolving the merge conflict.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Under a compositing window manager the current VDPAU implementation
behaves differently than without it. Frame flip timing info becomes
incorrect (I guess it only reflects when the frame was sent to the
compositor, not when it was actually shown), and there is no
limitation to at most one frame switch per refresh like without
compositing. Detect whether a compositing window manager is active and
disable refresh-aware frame timing and dropping in this case,
similarly to what fps=-1 would do. This behavior can be controlled
with the new suboption "composite-detect".
Disabling the refresh-aware logic makes timing somewhat less accurate.
Because the video switch rate limit isn't there, the lack of frame
dropping on player side does not impose a hard limit on video FPS, but
does reduce performance somewhat as redundant frames are drawn in
memory.
The existence of a compositing window manager does not guarantee that
the current window is actually composited, so the current check is not
foolproof. In particular, some WMs have support for a "unredirect
fullscreen windows" option. Support for such things could be improved.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Preemption recovery code could change the vc->vdp pointer when
recreating the VDPAU device. However, some other code cached the value
of vc->vdp in local variables over calls to handle_preemption(), and
could then crash when using the stale value later. Make the device
creation code keep the same vc->vdp instead of freeing and
reallocating it, so that the old pointer value is never invalidated
now.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Add infrastructure that allows VOs to specify the suboptions they
take, and get the values directly parsed into their private struct.
The option functionality available with the new system is the same as
for top-level player options. Convert vo_vdpau to use the new system
instead of the old subopt_helper.
|
| |\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
command.c
mp_core.h
mplayer.c
screenshot.c
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Modify the YUV->RGB conversion matrix to take into account the
difference between the same color value being x/255 in a 8-bit texture
and x*256/65535 in a 16-bit texture (actually things are stored as
x*4/65535 for 10-bit color, but that can be ignored here). This 0.4 %
difference in the shader float value could make shades of gray in
10-bit (or generally more than 8 bit) YUV produce RGB values with
green slightly higher than red/blue.
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| | |
The code in eosd_packer.c/.h is taken from vo_vdpau.c and has been made
independent from vdpau API specifics. This allows other VOs, which need
to pack the small EOSD images into a large surface for efficiency, to use
this code.
|
| |/
|
|
|
|
|
| |
Recent commits for screenshot support and video redraw changes didn't
handle vdpau driver preemption state correctly, which could make the
player crash if preemption occurred. Fix this and improve preemption
handling a bit otherwise.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rewrite control of the colorspace and input/output level parameters
used in YUV-RGB conversions, replacing VO-specific suboptions with new
common options and adding configuration support to more cases.
Add new option --colormatrix which selects the colorspace the original
video is assumed to have in YUV->RGB conversions. The default
behavior changes from assuming BT.601 to colorspace autoselection
between BT.601 and BT.709 using a simple heuristic based on video
size. Add new options --colormatrix-input-range and
--colormatrix-output-range which select input YUV and output RGB range.
Disable the previously existing VO-specific colorspace and level
conversion suboptions in vo_gl and vo_vdpau. Remove the
"yuv_colorspace" property and replace it with one named "colormatrix"
and semantics matching the new option. Add new properties matching the
options for level conversion.
Colorspace selection is currently supported by vo_gl, vo_vdpau, vo_xv
and vf_scale, and all can change it at runtime (previously only
vo_vdpau and vo_xv could). vo_vdpau now uses the same conversion
matrix generation as vo_gl instead of libvdpau functionality; the main
functional difference is that the "contrast" equalizer control behaves
somewhat differently (it scales the Y component around 1/2 instead of
around 0, so that contrast 0 makes the image gray rather than black).
vo_xv does not support level conversion. vf_scale supports range
setting for input, but always outputs full-range RGB.
The value of the slave properties is the policy setting used for
conversions. This means they can be set to any value regardless of
whether the current VO supports that value or whether there currently
even is any video. Possibly separate properties could be added to
query the conversion actually used at the moment, if any.
Because the colorspace and level settings are now set with a single
VF/VO control call, the return value of that is no longer used to
signal whether all the settings are actually supported. Instead code
should set all the details it can support, and ignore the rest. The
core will use GET_YUV_COLORSPACE to check which colorspace details
have been set and which not. In other words, the return value for
SET_YUV_COLORSPACE only signals whether any kind of YUV colorspace
conversion handling exists at all, and VOs have to take care to return
the actual state with GET_YUV_COLORSPACE instead.
To be changed in later commits: add missing option documentation.
|
| |
|
|
|
|
|
|
| |
Commit decec7f2a3 ("vo_vdpau: skip resize code if not fully
initialized") broke preemption recovery because the resize code stayed
incorrectly disabled when it would have been used to reinitialize
things during recovery. Revert that commit and add different checks
to avoid running various code when not in a fully functional state.
|
| |
|
|
|
|
|
| |
Window events or user commands could trigger a call to resize() before
config() had been called. This caused at least error messages. Add a
check to make resize() exit without doing anything in this case. It
will be called again later when the output is configured.
|
| |
|
|
|
| |
Drop from frequent (per-frame) messages from DBG2 to DBG3. Drop VDPAU
clock adjustment messages from V to DBG2.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Allow negative values of the "deint" parameter and make them select
the same deinterlacing mode as the corresponding positive value, but
without enabling deinterlace on startup. This is useful for
configuration files. Also tweak the overall manpage description of
vo_vdpau a bit to make it sound less as if the VO would be for
hardware acceleration only.
|
| | |
|
| |
|
|
|
|
|
| |
The wrong variable was used as a function argument, and as a result
the code modified the usage_count field of non-refcounted mp_image
types. This error did not have any effect on visible behavior as no
code cares about the field value in the affected case.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Add a default case for unknown image format in create_vdp_decoder. I
think this condition shouldn't currently happen, but it's worth a
sanity check. Avoids a compiler warning about vdp_decoder_profile
being possibly used uninitialized.
Also remove an obsolete #ifdef (should always be true now).
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The loop initializing handles in the output surface table to
VDP_INVALID_HANDLE ran over indices from 0 to vc->num_output_surfaces.
However it is first called before that variable is initialized. As a
result later code could try to destroy the handles which still had the
"non-invalid" value 0. Most likely this caused no visible effects; at
least on my machine no valid surface gets handle 0, and libvdpau just
returns an error for the resulting invalid calls. Change the code to
loop over the whole table. Also add code to print visible warnings if
libvdpau rejects a surface destroy call (some other places already had
checks but not all).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Make the number of output surfaces allocated by vo_vdpau configurable
and allow queuing multiple future frames with the VDPAU frame timing
functionality. There are two known issues that could be polished in
the future for particularly long queue time cases. First, toplevel
code should possibly wait for the queued changes to finish displaying
in some situations like switching files. Second, the VO can block
waiting for a surface to become available, and in the worst case this
wait can be almost as long as the maximum queuing time (potentially
causing audio underruns). However those issues are not high priority.
|
| |
|
|
|
|
|
| |
Add -vo vdpau suboption "studio" to produce output in RGB range
16-235. Man page description mostly taken from a patch by Lauri
Mylläri (but not code). Also slightly tweak the description of two
other suboptions on the man page.
|
| |
|
|
|
|
|
|
| |
Since I dropped the hack to support older libvdpau versions (without
MPEG4 / hqscaling features) from the FFmpeg version used in the build
repo it's better to disable those libvdpau versions in MPlayer
too. Change the configure check to require a newer libvdpau version,
and drop compatibility code in vo_vdpau.c.
|
| |
|
|
|
| |
The macro is meant to simplify the handling of some code dealing with
circular buffers.
|
| |
|
|
|
|
|
|
|
|
| |
After a recent library update on my system MPlayer started crashing on
exit in XCloseDisplay() if -vo vdpau had been used. With normal
linking it works OK. Since there should be little need for the dynamic
loading functionality any more, I'll just drop it rather than try
investigating the exact problem with dynamic loading and whether it
would be fixable. VDPAU is now linked normally with -lvdpau if
available.
|
| |
|
|
|
|
|
|
| |
Remove the special case for fullscreen; the same variables should have
the correct values in windowed and fullscreen modes. This fixes libass
subtitle positioning in the (non-typical) case where you have black
bands inside a window. Behavior in fullscreen and in the typical
windowed case without borders should not be affected.
|
| |
|
|
|
|
|
|
|
|
| |
Add -vo vdpau suboptions "queuetime_windowed" and "queuetime_fs" to
specify the maximum number of milliseconds how far into the future a
frame flip can be queued using the VDPAU presentation queue
functionality. The intended main use of these options is to allow
disabling use of the queuing feature on systems where using it causes
choppiness in other graphics behavior (this is an NVIDIA driver issue;
the video itself isn't affected).
|
| |
|
|
|
|
|
| |
Misplaced #endif broke compilation with old libvdpau versions that
lack VDP_VIDEO_MIXER_FEATURE_HIGH_QUALITY_SCALING_L1 #define.
Also add missing space to the text in related mp_msg() call.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Check the return value when setting any video mixer attribute and
print an error message if the operation failed. Also simplify code by
changing update_csc_matrix() to use the utility function added for
this.
|
| |
|
|
| |
Original patch by NVIDIA.
|
| |
|
|
|
|
|
|
|
|
| |
Remove the help text explaining -vo vdpau suboptions that was printed
in case of parsing errors. It did perhaps have some value, but there
are also reasons to remove it: it was printed in an ugly manner in the
middle of output, most other MPlayer options do not have such internal
help texts either, and it was detailed enough that it required
maintaining documentation about the options in two separate places
(the man page and the help message).
|
| |
|
|
|
|
|
| |
Part of the code is currently under #ifdef to allow compilation with
older VDPAU library versions; that can be removed later.
Partially based on a patch by Carl Eugen Hoyos.
|
| |
|
|
| |
Patch by Carl Eugen Hoyos.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a property to select YUV colorspace. Currently implemented only in
vo_vdpau and vo_xv. Allows switching between BT.601, BT.709 and
SMPTE-240M (vdpau only).
The xv support uses the "XV_ITURBT_709" attribute. At least my NVIDIA
card supports that; I don't know whether other xv implementations do.
Bind the colorspace switch to the 'c' key by default. 'c' is currently
used by vo_sdl for some fullscreen mode change thing, but at the moment
that does not conflict and if it will in the future then vo_sdl can
change.
VDPAU part based on a patch from Lauri Mylläri <lauri.myllari@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Main things added are custom frame dropping for VDPAU to work around
the display FPS limi |
