Commit Graph

9 Commits

Author SHA1 Message Date
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 65a0b5fdc6 mp_image: refcounting helpers 2013-01-13 17:39:32 +01:00
Stephen Hutchinson c082240c62 video: add support for 12 and 14 bit YUV pixel formats
Based on a patch by qyot27. Add the missing parts in mp_get_chroma_shift(),
which allow allocation of such images, and which make vo_opengl
automatically accept the new formats. Change the IMGFMT_IS_YUVP16_LE/BE
macros to properly report IMGFMT_444P14 as supported: this pixel format
has the highest numerical bit width identifier (0x55), which is not
covered by the mask ~0xfc. Remove 1 bit from the mask (makes it 0xf8) so
that IMGFMT_IS_YUVP16(IMGFMT_444P14) is 1. This is slightly risky, as
the organization of the image format IDs (actually FourCCs + mplayer
internal IDs) is messy at best, but it should be ok.
2012-12-03 21:08:51 +01:00
wm4 1d3179a5f1 mp_image: make alloc_mpi() always allocate with aligned stride
By "design", mplayer normally allocates aligned images only inside the
filter chain, via the vf_get_image() function. This function pads the
width of the requested image if a stride is allowed, sets that new width
before calling mp_image_alloc_planes().

However, newer code wants aligned images as well (basically to satisfy
libswscale). This affects all uses of alloc_mpi(). To get aligned
strides, simply change alloc_mpi() to request an aligned width.

Remove the old hack in mp_image_alloc_planes(), which special cases some
image formats to be allocated with aligned strides.

This is a temporary hack until mp_image_alloc_planes() is revised.
2012-11-22 19:22:38 +01:00
wm4 86ad77d0db draw_bmp: add RGB rendering to fix image quality issues
As pointed out in commit ed01df, the quality loss due to frequent
conversion between RGB and YUV is too much when drawing OSD and
subtitles.

Fix this by staying in the same colorspace when drawing subtitles.
Render directly to RGB, without converting to YUV first.

The bad thing about packed RGB is that there are many pixel formats,
which would all require special code for blending. It's also completely
incompatible to planar YUV. Use planar RGB instead, which allows us to
reuse all code originally written for planar YUV. The only thing that
needs to be changed is the color conversion in the libass case. (In
exchange for simpler code, the image has to be copied, but this is
still much better than converting to YUV.)

Unfortunately, libswscale doesn't support planar RGB output. Add a hack
to sws_utils.c to handle conversion to planar RGB. In the common case,
when converting 32 bit per pixel RGB, calling swscale can be avoided
entirely.

The change in mp_image.c is needed to allocate GBRP images correctly.

(The issue with vo_x11 could be easily solved by always backing up the
same bounding box as the bitmap drawing RGB<->YUV conversion does, but
this commit is probably the better fix.)
2012-11-22 15:26:38 +01:00
wm4 e5f7976000 video: add IMGFMT_Y16/PIX_FMT_GRAY16
This pixel format is sometimes used with yuv4mpeg.

vo_direct3d used its own IMGFMT_Y16 internally for some reason.

vo_opengl, vo_opengl_old, and vo_direct3d should be able to display
this pixel format natively.
2012-11-14 11:50:02 +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