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.
VFCAP_TIMER disables any additional waiting done by mpv in the
playloop. Remove VFCAP_TIMER, but re-use the idea for vo_image and
vo_lavc.
This means --untimed doesn't have to be passed when using --vo=image.
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.
Change the entire filter API to use reference counted images instead
of vf_get_image().
Remove filter "direct rendering". This was useful for vf_expand and (in
rare cases) vf_sub: DR allowed these filters to pass a cropped image to
the filters before them. Then, on filtering, the image was "uncropped",
so that black bars could be added around the image without copying. This
means that in some cases, vf_expand will be slower (-vf gradfun,expand
for example).
Note that another form of DR used for in-place filters has been replaced
by simpler logic. Instead of trying to do DR, filters can check if the
image is writeable (with mp_image_is_writeable()), and do true in-place
if that's the case. This affects filters like vf_gradfun and vf_sub.
Everything has to support strides now. If something doesn't, making a
copy of the image data is required.
The code was entirely correct, as the VO doesn't report VFCAP_ACCEPT_STRIDE
in query_format. Add stride capability in preparation for changing the
video chain: soon all VOs will have to support arbitrary strides.
The code assumed mp_image_alloc() would allocate an image large enough
for corevideo's stride, which doesn't have to be the case. If
corevideo's stride was larger than the stride of mp_image, the memcpy()
would write beyond the mp_image allocation.
This probably didn't actually happen, but fix the code to be more
correct anyway.
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.
vdpau hardware decoding used the DR (direct rendering) path to let the
decoder query a surface from the VO. Special-case the HW decoding path
instead, to make it separate from DR.
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.
For some reason, libavcodec abuses the slices rendering code path for
hardware decoding: in that case, the only purpose of the draw callback
is to pass a vdpau video surface object to video output. (It is unclear
to me why this had to use the slices code, instead of just returning an
AVFrame with the required vdpau state.)
Make this code separate within mpv, so that the internal slices code
path is not used for hardware decoding. Pass the vdpau state with
VOCTRL_HWDEC_DECODER_RENDER instead.
Remove the mencoder specific VOCTRLs.
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.
The premultiplied-alpha hack is changed:
- The first stage now uses a colormod of black with an unmodified
texture. This saves on applying the AND mask of 0xFF000000 to keep
alpha only.
- The second stage no longer uses an AND mask, but only an OR mask of
0xFF000000 to cancel out alpha.
- The texture uploads are no longer done using SDL_LockTexture,
SDL_ConvertPixels, SDL_UnlockTexture when the mpv pixel format matches
the OSD's pixel format. Instead, SDL_UploadTexture is used, which
saves a copy when using the "opengl" renderer.
For 9-15 bit material, cutting off the lower bits leads to significant
quality reduction, because these formats leave the most significant bits
unused (e.g. 10 bit padded to 16 bit, transferred as 8 bit -> only
2 bits left). 16 bit formats still can be played like this, as cutting
the lower bits merely reduces quality in this case.
This problem was encountered with the following GPU/driver combination:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 915GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 9.0.1
It appears 16 bit support is rather common on GPUs, so testing the
actual texture depth wasn't needed until now. (There are some other Mesa
GPU/driver combinations which support 16 bit only when using RG textures
instead of LUMINANCE_ALPHA. This is due to OpenGL driver bugs.)
The extension checking logic was broken, which reported OpenGL 3 if the
OpenGL .so exported OpenGL 3-only symbols, even if the reported OpenGL
version is below 3.0. Fix it and simplify the code a bit. Also never
fail hard if required functions are not found. The caller should check
the capability flags instead. Give up on the idea that we should print
a warning if essential functions are not found (makes loading of ancient
legacy-only extensions easier).
This was experienced with the following version strings:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 915GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 9.0.1
(Possibly reports a very old version because it has no GLSL support,
and thus isn't even GL 2.0 compliant.)
Change from gamma 2.2 to the slightly more precise 1/0.45 as per BT.709.
https://www.itu.int/rec/R-REC-BT.709-5-200204-I/en mentions a value of
γ=0.45 for the conceptual non-linear precorrection of video signals.
This is approximately the inverse of 2.22, and not 2.20 as the code had
been using until now.
This mainly serves as a fallback for platforms where nothing better is
available; also as a debugging help. Both the audio and video driver are
not first class - the audio driver lacks delay detection, and the video
driver only supports a single YUV color space.
Configure options: --disable-sdl2 to disable SDL 2.0+ detection,
--disable-sdl to disable SDL 1.2+ detection. Both options need to be
specified to turn off SDL support entirely.
This is better than having just the operating system type decide the
wakeup period, as e.g. when compiling for Win32/cygwin, a wakeup period
of 0.5 would work perfectly fine.
Instead, the default wakeup period is now only decided by availability
of a working select() system call (which is the case on cygwin but not
mingw and MSVC) AND a vo that can provide an event file descriptor or a
similar hack (vo_corevideo). vos that cannot do either need polling for
event handling and now can set the wakeup period to 0.02 in the vo code.
To get guaranteed alignment for the chroma planes with typical YV12
playback, we have to double the alignment on the image width, as the
chroma planes have half the image width.
Clear the image with black instead of green to hide scaling artifacts
on the right border of the screen.
(It might be possible to create the image layout ourselves by not
calling XvShmCreateImage(), and filling in our own image width and exact
strides, but that's probably too risky: the Xv client library sends an
X protocol request to query the real image dimension and strides. It is
unknown to me whether X servers or drivers would generally accept an
image with mismatching parameters, even if the image is conceptually
valid.)
Allocate the image with av_malloc() in the non-SHM case. I suspect the
non-SHM case doesn't matter much, though.
Gestalt is deprecated since 10.8. Change the code to read the OS version from
a system plist file.
As mentioned http://stackoverflow.com/a/11072974/499456 Apple engineers are
suggesting this plist reading approach.
This is required, as the Xv image is directly used for rendering OSD and
taking screenshots. These involve libswscale, which wants aligned
strides.
There doesn't seem to be an easy way to request aligned strides from Xv.
Simply request an image with an aligned width, which usually results in
an aligned stride. The padding border remains invisible.
One caveat is that if padding is added, there might be scaling artifacts
on the right pixel border of the screen. This is at least the case with
nvidia binary drivers. Since we consider vo_xv a sensible choice only on
crappy/slow hardware, performance is more important than quality.
mp_image has this confusing distinction between the w/h and width/height
fields. w/h are the actual width and height, while width/height have a
very special meaning inside the video filter code: it's the actually
allocated width, which is also used for stride padding.
Screenshot related code abused the w/h fields to store the aspect
corrected size. Some code confused the role of w/h and width/height.
Fix these issues. For aspect corrected size, display_w/h are used, while
width/height should never be used outside vf.c internals and related
code.
This also fixes an actual bug when taking screenshots of anamorphic
video with vf_screenshot, as well as using vo_image with such videos.
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.)
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.)
In order to improve performance, vo_xv didn't create a backup of the
video frame before drawing OSD and subtitles during normal playback. It
required the frontend to do frame stepping if it wanted to redraw the
OSD, but no backup of the video frame was available. (Consider the
following use case: enable the OSD permanently with --osd-level=3, then
pause during playback and do something that shows an OSD message. The
player will advance the video by one frame at the time the new OSD
message is first drawn.)
This also meant that taking a screenshot during playback with vo_xv
would include OSD and subtitles in the resulting image.
Fix this by always creating a backup before drawing OSD or subtitles.
In order to avoid having to create a full copy of the whole image frame,
introduce a complex scheme that tries to backup only the changed
regions.
It's unclear whether the additional complexity in draw_bmp.c for
backing up only the changed areas of the frame is worth it. Possibly
a simpler implementation would suffice, such as tracking only Y ranges
of changed image data, or even just copying the full frame.
vo_xv's get_screenshot() now always creates a copy in order not to
modify the currently displayed frame.
Don't request CONTEXT_FORWARD_COMPATIBLE when creating a GL3 context on
X11. This improves compatibility with some Mesa drivers.
Setting this bit was originally intended to make the code compatible
to newer (future, possibly not yet existing) OpenGL implementations.
These implementations wouldn't have to support deprecated legacy GL
features, which we know that we don't use, and could return a context
with a higher OpenGL version than requested.
In practice, this didn't work out. CONTEXT_FORWARD_COMPATIBLE requires
the driver to explicitly disable deprecated functionality. If it doesn't
do that, it has to reject context creation with that flag set. And it
turns out there are Mesa drivers which suffer from this caveat. See [1].
This probably also means that a GL application with a fixed set of
required GL features (such as a subset of GL 3.2 core, like vo_opengl.c)
may need to probe several GL versions if drivers really start dropping
legacy GL.
On Windows, CONTEXT_FORWARD_COMPATIBLE is still set. It is not known
if this is ideal, but fortunately there is no Mesa on Windows.
CONTEXT_CORE_PROFILE is still always set. For requested GL versions
lower than 3.2, this flag is ignored. Should we requires higher versions
later, we want it to be set, so don't remove it.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=57241
This wasn't actually used since the old gray-alpha OSD rendering has
been removed. Removing the documentation for the vo_opengl_old osdcolor
suboption was forgotten as well.
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.
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.
Libav 0.8.4 is ridiculously old (in relative terms), so I don't know
how many things are broken silently.
Encoding is disabled, because the required API hasn't been added yet.
(On the other hand, the old API can't be used in newer versions.)
This should improve compatibility with ffmpeg 0.11.2 as well, which
didn't define AV_CODEC_ID_SUBRIP yet.
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.)
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.
