Commit Graph

30 Commits

Author SHA1 Message Date
wm4 d5de75b340 x11: use vo_x11_control() for all VOs 2013-05-26 16:44:19 +02:00
wm4 ea03cc6712 x11_common: remove assumption that video is always centered
The vo_x11_clearwindow_part() function assumed that the video is always
centered. Replace it with a new vo_x11_clear_background() function
instead, which essentially does the same as the old function. It takes
the video rectangle instead of just the video size, and doesn't have to
make the assumption that the video rectangle is centered.

Also make vo_x11 use it (seems advantageous).
2013-03-17 23:01:33 +01:00
wm4 1ae1939742 video: remove aspect.h includes from files which don't need it 2013-03-17 22:07:13 +01:00
wm4 36f5d800d5 vo_x11: accept all swscale formats
There's no reason why there should be a separate vf_scale stage.
2013-03-17 19:07:29 +01:00
wm4 b1b982941d vo_x11: use generic aspect ratio code, refactor
Instead of manually calculating aspect ratio etc., use
vo_get_src_dst_rects(). This has the advantage that we can drop some
special cases in aspect.c later.

Simplify the code, and move resizing the X images from draw_image() to a
new resize() function.

Do some other simplifications. The gXErrorFlag check was actually dead
code, even in mplayer-svn. Special-casing on WinID is not needed
anymore (we created an embedded window, and its size is updated by
x11_common.c).
2013-03-17 18:46:03 +01:00
Alexander Preisinger 1198c031e4 vo: Separate vo options from MPOpts
Separate the video output options from the big MPOpts structure and also only
pass the new mp_vo_opts structure to the vo backend.

Move video_driver_list into mp_vo_opts
2013-03-04 23:32:47 +01:00
Alexander Preisinger 7686cd7f04 vo: remove and cleanup globals
Removes almost every global variabel in vo.h and puts them in a special struct
in MPOpts for video output related options.

Also we completly remove the options/globals pts and refresh rate because
they were unused.
2013-03-04 17:40:21 +01:00
wm4 d511ef79a0 core: simplify OSD capability handling, remove VFCAP_OSD
VFCAP_OSD was used to determine at runtime whether the VO supports OSD
rendering. This was mostly unused. vo_direct3d had an option to disable
OSD (was supposed to allow to force auto-insertion of vf_ass, but we
removed that anyway). vo_opengl_old could disable OSD rendering when a
very old OpenGL version was detected, and had an option to explicitly
disable it as well.

Remove VFCAP_OSD from everything (and some associated logic). Now the
vo_driver.draw_osd callback can be set to NULL to indicate missing OSD
support (important so that vo_null etc. don't single-step on OSD
redraw), and if OSD support depends on runtime support, the VO's
draw_osd should just do nothing if OSD is not available.

Also, do not access vo->want_redraw directly. Change the want_redraw
reset logic for this purpose, too. (Probably unneeded, vo_flip_page
resets it already.)
2013-03-01 11:16:01 +01:00
wm4 423c0b13c4 video/out: rename create_window to config_window
create_window is really bad naming, because this function can be called
multiple times, while the name implies that it always creates a new
window. At least the name config_window is not actively misleading.
2013-02-26 02:01:48 +01:00
wm4 fddba2d529 vo_x11: fix redrawing on expose events
This part wasn't converted when changing to the new OSD redrawing way.
2013-01-27 13:32:39 +01:00
wm4 df80cd379a x11: simplify handling of X Visuals and Colormaps in VOs
Don't force VOs to pick an arbitrary default Visual and Colormap. They
still can override them if needed. This simplifies the X11 VO interface.

Always create a Colormap for simplicity. Using CopyFromParent fails if
the selected visual is not the same of that of the parent window, which
happens for me with vo_opengl.

vo_vdpau and vo_xv explicitly set CWBorderPixel, do that in x11_common
instead (it was already done for native windows, but not for slave mode
windows).

What gl_common did was incorrect in theory: freeing a colormap while a
window uses it will change the colormap of the window to "None", and
the color mapping for such windows is "undefined".
2013-01-27 13:32:27 +01:00
wm4 0535a14505 x11: reduce VO mode switching code duplication
Some parts for initiating mode switches were duplicated in every VO
supporting X11 (except vo_opengl/gl_common, which didn't support mode
switching). Move this to x11_common.c.

Note that this might be slightly risky: is it really guaranteed that no
VO needed to do "special" setup that depends on X parameters changing
after a mode switch, such as bit depth, visuals etc.? From what I can
see, this shouldn't be the case (X probably can't even change depth on
the fly). Even if this should be a one-way road, VM switching is in
general very useless, and its implementation buggy, so it can just be
removed should unfixable problems arise.
2013-01-27 13:30:54 +01:00
wm4 a243acb1de x11: cleanup, refactor
Move things that are used by vo_xv only into vo_xv, same for vo_x11.

Rename some functions exported by x11_common, like vo_init to
vo_x11_common. Make functions not used outsode of x11_common.c private
to that file. Eliminate all global variables defined by x11_common
(except error handler and colormap stuff).

There shouldn't be any functional changes, and only code is moved
around. There are some minor simplifications in the X11 init code, as
we completely remove the ability to initialize X11 and X11+VO
separately (see commit b4d9647 "mplayer: do not create X11 state in player frontend"),
and the respective functions are conflated into vo_x11_init() and
vo_x11_uninit().
2013-01-27 13:30:53 +01:00
Rudolf Polzer aaa27ead86 vo_x11: use two buffers like Xv 2013-01-13 22:36:42 +01:00
Rudolf Polzer 4044754d24 vo_x11, vo_xv: XShmCompletion event support
This fixes OSD flicker with vo_xv at high frame rates.
2013-01-13 22:36:42 +01:00
wm4 3d6d549dac vo_xv, vo_x11: simplify OSD redrawing
In order to support OSD redrawing for vo_xv and vo_x11, draw_bmp.c
included an awkward "backup" mechanism to copy and restore image
regions that have been changed by OSD/subtitles.

Replace this by a much simpler mechanism: keep a reference to the
original image, and use that to restore the Xv/X framebuffers.

In the worst case, this may increase cache pressure and memory usage,
even if no OSD or subtitles are rendered. In practice, it seems to be
always faster.
2013-01-13 20:04:12 +01:00
wm4 5830d639b8 video: remove img_format compat hacks
Remove the strange things the old mp_image_setfmt() code did to the
image format parameters. This includes setting chroma shift to 31 for
gray (Y8) formats and more.

Y8 + vo_opengl_old didn't actually work for unknown reasons (regression
in this branch). Fix this. The difference is that Y8 is now interpreted
as gray RGB (LUMINANCE texture) instead of involving YUV (and levels)
conversion.

Get rid of distinguishing RGB and BGR. There wasn't really any good
reason for this.

Remove mp_get_chroma_shift() and IMGFMT_IS_YUVP16*(). mp_imgfmt_desc
gives the same information and more.
2013-01-13 20:04:11 +01:00
wm4 8751a0e261 video: decouple internal pixel formats from FourCCs
mplayer's video chain traditionally used FourCCs for pixel formats. For
example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the
string 'YV12' interpreted as unsigned int. Additionally, it used to
encode information into the numeric values of some formats. The RGB
formats had their bit depth and endian encoded into the least
significant byte. Extended planar formats (420P10 etc.) had chroma
shift, endian, and component bit depth encoded. (This has been removed
in recent commits.)

Replace the FourCC mess with a simple enum. Remove all the redundant
formats like YV12/I420/IYUV. Replace some image format names by
something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P.

Add img_fourcc.h, which contains the old IDs for code that actually uses
FourCCs. Change the way demuxers, that output raw video, identify the
video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to
request the rawvideo decoder, and sh_video->imgfmt specifies the pixel
format. Like the previous hack, this is supposed to avoid the need for
a complete codecs.cfg entry per format, or other lookup tables. (Note
that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT
raw video, but this is still considered better than adding a raw video
decoder - even if trivial, it would be full of annoying lookup tables.)

The TV code has not been tested.

Some corrective changes regarding endian and other image format flags
creep in.
2013-01-13 20:04:11 +01:00
wm4 0c5311f17c video: cleanup: replace old mp_image function names
mp_image_alloc() also changes argument order compared to alloc_mpi().
The format now comes first, then width/height.
2013-01-13 20:04:11 +01:00
wm4 aa6ba6372c mp_image: change how palette is handled
According to DOCS/OUTDATED-tech/colorspaces.txt, the following formats
are supposed to be palettized:

    IMGFMT_BGR8
    IMGFMT_RGB8,
    IMGFMT_BGR4_CHAR
    IMGFMT_RGB4_CHAR
    IMGFMT_BGR4
    IMGFMT_RGB4

Of these, only BGR8 and RGB8 are actually treated as palettized in some
way. ffmpeg has only one palettized format (AV_PIX_FMT_PAL8), and
IMGFMT_BGR8 was inconsistently mapped to packed non-palettized RGB
formats too (AV_PIX_FMT_BGR8). Moreover, vf_scale.c contained messy
hacks to generate a palette when AV_PIX_FMT_BGR8 is output. (libswscale
does not support AV_PIX_FMT_PAL8 output in the first place.)

Get rid of all of this, and introduce IMGFMT_PAL8, which directly maps
to AV_PIX_FMT_PAL8. Remove the palette creation code from vf_scale.c.
IMGFMT_BGR8 maps to AV_PIX_FMT_RGB8 (don't ask me why it's swapped),
without any palette use. Enabling it in vo_x11 or using it as vf_scale
input seems to give correct results.
2013-01-13 20:04:11 +01:00
wm4 1b9d4a771a video: remove things related to old DR code
Remove mp_image.width/height. The w/h members are the ones to use.
width/height were used internally by vf_get_image(), and sometimes for
other purposes.

Remove some image flags, most of which are now useless or completely
unused. This includes VFCAP_ACCEPT_STRIDE: the vf_expand insertion in
vf.c does nothing.

Remove some other unused mp_image fields.

Some rather messy changes in vo_opengl[_old] to get rid of legacy
mp_image flags and fields. This is left from when vo_gl supported DR.
2013-01-13 20:04:10 +01:00
wm4 d77d9fb933 mp_image: require using mp_image_set_size() for setting w/h
Setting the size of a mp_image must be done with mp_image_set_size()
now. Do this to guarantee that the redundant fields (like chroma_width)
are updated consistently. Replacing the redundant fields by function
calls would probably be better, but there are too many uses of them,
and is a bit less convenient.

Most code actually called mp_image_setfmt(), which did this as well.
This commit just makes things a bit more explicit.

Warning: the video filter chain still sets up mp_images manually,
and vf_get_image() is not updated.
2013-01-13 17:39:32 +01:00
wm4 23ab098969 video: remove slice based filtering and video output
Slices allowed filtering or drawing video in horizontal bands or
blocks. This allowed working on the video in smaller units. In theory,
this could bring a performance win by lowering cache pressure, as you
didn't have to keep the whole video frame in cache while filtering,
only the slice.

In practice, the slice code path was barely used for the following
reasons:
- Multithreaded decoding with ffmpeg didn't use slices. The ffmpeg
  slice callback was disabled, because it can be called from another
  thread, and the mplayer video chain is not thread-safe.
- There was nothing that would turn "full" images into appropriate
  slices, so slices were rarely used.
- Most filters didn't actually support slices.

On the other hand, supporting slices lead to code duplication and more
complex code in general. I made some experiments and didn't find any
actual measurable performance improvements when using slices. Even
ffmpeg removed slices based filtering from libavfilter in favor of
simpler code.

The most broken thing about the slices code path is that slices can't
be queued, like it is done for images in vo.c.
2013-01-13 17:39:31 +01:00
wm4 58d3469fd6 video/out: replace VOCTRL_QUERY_FORMAT with vo_driver.query_format 2013-01-13 17:39:31 +01:00
wm4 191bcbd1f2 video/out: make draw_image mandatory, remove VOCTRL_DRAW_IMAGE
Remove VOCTRL_DRAW_IMAGE and always set vo_driver.draw_image in VOs.
Make draw_image mandatory: change some VOs (like vo_x11) to support it,
and remove the image-to-slices fallback in vf_vo.

Remove vo_driver.is_new. This member indicated whether draw_image is
supported unconditionally, which is now always the case.

draw_image_pts is a hack until the video filter chain is changed to
include the PTS as field in mp_image. Then vo_vdpau and vo_lavc will
be changed to use draw_image.
2013-01-13 17:39:31 +01:00
wm4 ed01dfeff3 vo_x11: don't require framestepping to update OSD
The OSD couldn't be updated at all without frame stepping. This made the
VO unusable (In fact, vo_x11 should never be used, but it's provided as
fail-safe fallback). Implement VOCTRL_REDRAW_FRAME to deal with this.

Unfortunately, this exposes issues with draw_bmp's subtitle rendering:
areas that are not covered by subtitles at all are changed as well. The
"backup" mechanism provided by draw_bmp doesn't copy these areas, which
turns up as quite visible artifacts. (These are included when taking
screenshots too.)
2012-11-21 19:58:16 +01:00
wm4 4757f9d0ce vo_x11: add screenshot support
Although vo_x11 shouldn't be used, it's a good thing to have screenshot
support in absolutely all interactive VOs. (Except vo_caca, but that is
literally a joke.)
2012-11-21 19:56:59 +01:00
wm4 53ee9aa6ae options, vo_x11: remove -zoom option, make it default
The -zoom option enabled scaling with vo_x11. Remove the -zoom option,
and make its behavior default. Since vo_x11 has to use libswscale for
colorspace conversion anyway, which doesn't do actual extra scaling when
vo_x11 is run in windowed mode, there should be no speed difference with
this change.

The code removed from vf_scale attempted to scale the video to d_width/
d_height, which matters for anamorphic video and the --xy option only.
vo_x11 can handle these natively. The only case for which the removed
vf_scale code could matter is encoding with vo_lavc, but since that
didn't set VOFLAG_SWSCALE, nothing actually changes.
2012-11-16 21:21:14 +01:00
wm4 4873b32c59 Rename directories, move files (step 2 of 2)
Finish renaming directories and moving files. Adjust all include
statements to make the previous commit compile.

The two commits are separate, because git is bad at tracking renames
and content changes at the same time.

Also take this as an opportunity to remove the separation between
"common" and "mplayer" sources in the Makefile. ("common" used to be
shared between mplayer and mencoder.)
2012-11-12 20:08:18 +01:00
wm4 d4bdd0473d Rename directories, move files (step 1 of 2) (does not compile)
Tis drops the silly lib prefixes, and attempts to organize the tree in
a more logical way. Make the top-level directory less cluttered as
well.

Renames the following directories:
    libaf -> audio/filter
    libao2 -> audio/out
    libvo -> video/out
    libmpdemux -> demux

Split libmpcodecs:
    vf* -> video/filter
    vd*, dec_video.* -> video/decode
    mp_image*, img_format*, ... -> video/
    ad*, dec_audio.* -> audio/decode

libaf/format.* is moved to audio/ - this is similar to how mp_image.*
is located in video/.

Move most top-level .c/.h files to core. (talloc.c/.h is left on top-
level, because it's external.) Park some of the more annoying files
in compat/. Some of these are relicts from the time mplayer used
ffmpeg internals.

sub/ is not split, because it's too much of a mess (subtitle code is
mixed with OSD display and rendering).

Maybe the organization of core is not ideal: it mixes playback core
(like mplayer.c) and utility helpers (like bstr.c/h). Should the need
arise, the playback core will be moved somewhere else, while core
contains all helper and common code.
2012-11-12 20:06:14 +01:00