Commit Graph

69 Commits

Author SHA1 Message Date
Dudemanguy 9db818279a test: integrate unittests with meson
This reworks all of mpv's unit tests so they are compiled as separate
executables (optional) and run via meson test. Because most of the tests
are dependant on mpv's internals, existing compiled objects are
leveraged to create static libs and used when necessary. As an aside, a
function was moved into video/out/gpu/utils for sanity's sake (otherwise
most of vo would have been needed). As a plus, meson multithreads
running tests automatically and also the output no longer pollutes the
source directory. There are tests that can break due to ffmpeg changes,
so they require a specific minimum libavutil version to be built.
2023-03-02 15:45:27 +00:00
Dudemanguy d1d2370d07 draw_bmp: ensure last slice width is less than total width
e97819f88e corrected a special case
condition that lead to an out of bounds access if the total width
happened to be an integer multiple of SLICE_W (256) which could cause a
crash in software VOs. However, it turns out that the functions in this
file evaluate quite differently when using encoding mode (and presumably
libmpv as well according to reports although I could not independently
verify it).

The logic here gets complicated but what ends up happening is that, in
blend_overlay_with_video, the value of x + w can be greater than p->w in
certain cases in encoding mode. The x is the positional value of the
slice which remained unchanged from before, but w can take the full
value of SLICE_W (256) which is not necessarily correct. The width of
the final slice here should be the total remaining width. We can handle
this in mark_rect by simply always adjusting x1 of the last slice to be
equal to total width - SLICE_W * x so it can never extend beyond where
it should be. In practice, this value should be the maximum allowed
here. I'm not sure if the existing x1 value can possibly already be
lower than SLICE_W, but just MPMIN it to be on the safe side.
Fixes #10908.
2023-01-03 01:08:46 +00:00
Shreesh Adiga e97819f88e draw_bmp: fix out of bounds access in mark_rect
When the width is exactly a multiple of SLICE_W (currently 256),
heap buffer overflow is reported by Address Sanitizer. So adjust
the maximum index for the line array accordingly.
2022-10-11 17:11:07 +00:00
Niklas Haas 9e2c0b8baa sub: rename SUBBITMAP_RGBA to SUBBITMAP_BGRA
This was a misnomer, the actual channel order is IMGFMT_BGRA (as the
comment explicitly point out). Rename the enum for consistency.
2022-01-11 23:45:08 +02:00
wm4 caee8748da video: clean up some imgfmt related stuff
Remove the vaguely defined plane_bits and component_bits fields from
struct mp_imgfmt_desc. Add weird replacements for existing uses. Remove
the bytes[] field, replace uses with bpp[].

Fix some potential alignment issues in existing code. As a compromise,
split mp_image_pixel_ptr() into 2 functions, because I think it's a bad
idea to implicitly round, but for some callers being slightly less
strict is convenient.

This shouldn't really change anything. In fact, it's a 100% useless
change. I'm just cleaning up what I started almost 8 years ago (see
commit 00653a3eb0). With this I've decided to keep mp_imgfmt_desc,
just removing the weird parts, and keeping the saner parts.
2020-05-18 01:54:59 +02:00
wm4 baabd5fce3 draw_bmp: use command line options for any used scalers 2020-05-13 20:07:59 +02:00
wm4 0ff839d467 draw_bmp: add integer blending for 8 bit formats
Whatever it's worth. Instead of doing a pretty stupid conversion to
float, just blend it directly. This works for most RGB formats that are
8 bits per component or below (the latter because we expand packed
fringe RGB formats for simplicity). For higher bit depth RGB this would
need extra code.
2020-05-12 23:10:14 +02:00
wm4 c4b2ca83d6 draw_bmp: don't make strange decisions on broken iknput csp params
This checked params->color.space for being RGB. If the colorspace is
unset, this did dumb things because even if the imgfmt was a RGB one,
the colorspace was not set to RGB. This actually also happened to the
tests.

(Short-cutting RGB like this is actually wrong, since RGB could still
have strange gamma or primaries, which would warrant a full conversion.
So you'd need to check for these other parameters as well. To be fixed
later.)
2020-05-12 22:43:29 +02:00
wm4 55e1f15cdb draw_bmp: add a function to return a single-texture OSD overlay
Maybe this is useful for some of the lesser VOs. It's preferable over
bad ad-hoc solutions based on the more complex sub_bitmap data
structures (as observed e.g. in vo_vaapi.c), and does not use that much
more code since draw_bmp already created such an overlay internally.

But I still wanted something that avoids having to upload/render a full
screen-sized overlay if for example there's only a tiny subtitle line on
the bottom of the screen. So the new API can return a list of modified
pixels (for upload) and non-transparent pixels (for display). The way
these pixel rectangles are computed is a bit dumb and returns dumb
results, but it should be usable, and the implementation can change.
2020-05-11 19:57:34 +02:00
wm4 6db890ebab video: remove RGB32/BGR32 aliases
They are sort of confusing, and they hide the fact that they have an
alpha component. Using the actual formats directly is no problem, sicne
these were useful only for big endian systems, something we can't test
anyway.
2020-05-11 19:57:34 +02:00
wm4 c1a961ad78 draw_bmp: rewrite
draw_bmp.c is the software blender for subtitles and OSD. It's used by
encoding mode (burning subtitles), and some VOs, like vo_drm, vo_x11,
vo_xv, and possibly more.

This changes the algorithm from upsampling the video to 4:4:4 and then
blending to downsampling the OSD and then blending directly to video.
This has far-reaching consequences for its internals, and results in an
effective rewrite.

Since I wanted to avoid un-premultiplying, all blending is done with
premultiplied alpha. That's actually the sane thing to do. The old code
just didn't do it, because it's very weird in YUV fixed point.
Essentially, you'd have to compensate for the chroma centering constant
by subtracting src_alpha/255*128. This seemed so hairy (especially with
correct rounding and high bit depths involved) that I went for using
float.

I think it turned out mostly OK, although it's more complex and less
maintainable than before. reinit() is certainly a bit too long. While it
should be possible to optimize the RGB path more (for example by
blending directly instead of doing the stupid float conversion), this is
probably slower. vo_xv users probably lose in this, because it takes the
slowest path (due to subsampling requirements and using YUV).

Why this rewrite? Nobody knows. I simply forgot the reason. But you'll
have it anyway. Whether or not this would have required a full rewrite,
at least it supports target alpha now (you can for example hard sub
transparent PNGs, if you ever wanted to use mpv for this).

Remove the check in vf_sub. The new draw_bmp.c is not as reliant on
libswscale anymore (mostly uses repack.c now), and osd.c shows an
error message on missing support instead now.

Formats with chroma subsampling of 4 are not supported, because FFmpeg
doesn't provide pixfmt definitions for alpha variants. We could provide
those ourselves (relatively trivial), but why bother.
2020-05-09 18:02:57 +02:00
wm4 e9e883e3b2 video: make OSD/subtitle bitmaps refcounted (sort of)
Making OSD/subtitle bitmaps refcounted was planend a longer time ago,
e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap
data) was added in 2016. But nothing benefited much from it, because
struct sub_bitmaps was usually stack allocated, and there was this weird
callback stuff through osd_draw().

Make it possible to get actually refcounted subtitle bitmaps on the OSD
API level. For this, we just copy all subtitle data other than the
bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy
refcount shit, but when that was a big mess and hard to debug and just
boiled to emulating malloc(), I made it a full allocation+copy. This
affects mostly the parts array. With crazy ASS subtitles, this parts
array can get pretty big (thousands of elements or more), in which case
the extra alloc/copy could become performance relevant. But then again
this is just pure bullshit, and I see no need to care. In practice, this
extra work most likely gets drowned out by libass murdering a single
core (while mpv is waiting for it) anyway. So fuck it.

I just wanted this so draw_bmp.c requires only a single call to render
everything. VOs also can benefit from this, because the weird callback
shit isn't necessary anymore (simpler code), but I haven't done anything
about it yet. In general I'd hope this will work towards simplifying the
OSD layer, which is prerequisite for making actual further improvements.

I haven't tested some cases such as the "overlay-add" command. Maybe it
crashes now? Who knows, who cares.

In addition, it might be worthwhile to reduce the code duplication
between all the things that output subtitle bitmaps (with repacking,
image allocation, etc.), but that's orthogonal.
2020-04-26 23:34:32 +02:00
wm4 a09c7691d7 draw_bmp: silence another ridiculous ubsan warning
UB sanitizer complains that aval<<24 (if >=128) cannot be represented as
int. Indeed, we would shift a bit into the sign of an int, which is
probably UB or implementation defined (I can't even remember, but the
stupidity of it burns). So technically, ubsan might be right.

Change aval to uint32_t, which I don't think has a chance of getting
promoted to int. Change the other *val to uint32_t too for cosmetic
symmetry.

So we have to obscure the intention of the code (*val can take only 8
bits) out of language stupidity. How nice. (What a shitty language.)
2020-04-18 00:16:52 +02:00
wm4 6d92e55502 Replace uses of FFMIN/MAX with MPMIN/MAX
And remove libavutil includes where possible.
2019-10-31 11:24:20 +01:00
Anton Kindestam d00f9b19c7 draw_bmp: Fix for GBRP formats GBRP9 and up
First we shift the values up to the actual amount of bits in draw_ass,
so that they will be drawn correctly when using formats with more than
8 bpc. (draw_rgba is already correct w.r.t. RGB formats with 9 or more
bpc)

Then, in scale_sb_rgba, by setting the amount of bits per channel used
for planar RGB formats (formats are always planar at this point in
draw_bmp) to be the same as the source from 9 to 16 bpc (in effect all
the various GBRP formats) we manage to fit the special case that does
not require any conversion in chroma_up and chroma_down when handling
these formats (as long as the source itself is a planar format),
instead writing directly to the combined dst/src buffer. This in turn
works around a bug (incorrect colors) in libswscale when scaling
between GBRP formats with 9 or more bpc. Additionally this should be
more efficient, since we skip up- and down-conversion and temporary
buffers.
2019-09-22 15:59:24 +02:00
Niklas Haas d81fb97f45 mp_image: split colorimetry metadata into its own struct
This has two reasons:

1. I tend to add new fields to this metadata, and every time I've done
so I've consistently forgotten to update all of the dozens of places in
which this colorimetry metadata might end up getting used. While most
usages don't really care about most of the metadata, sometimes the
intend was simply to “copy” the colorimetry metadata from one struct to
another. With this being inside a substruct, those lines of code can now
simply read a.color = b.color without having to care about added or
removed fields.

2. It makes the type definitions nicer for upcoming refactors.

In going through all of the usages, I also expanded a few where I felt
that omitting the “young” fields was a bug.
2016-07-03 19:42:52 +02:00
wm4 8a9b64329c Relicense some non-MPlayer source files to LGPL 2.1 or later
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.

There are probably more files to which this applies, but I'm being
conservative here.

A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).

common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.

codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.

From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).

misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.

screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
2016-01-19 18:36:06 +01:00
wm4 bbb65ed84b sub: use macros to remove code duplication
Meh.
2015-12-24 17:32:10 +01:00
wm4 30074f8440 sub: merge bitmap render functions into one for each kind
Merge blend_src8_alpha and blend_src16_alpha into blend_src_alpha, and
the same for blend_const_alpha.

One thing that changes is that the vertical loop is now shared for both
code paths.

I think this is slightly easier to read, and it's a bit shorter as well.
2015-12-24 17:24:55 +01:00
wm4 a042dcc700 sub: remove "inaccurate" code path
The "accurate" one always has been enabled, and I can't find much
evidence that the "inaccurate" one is much faster on my particular
machine anyway.
2015-12-24 17:08:02 +01:00
wm4 3973a953df sub: find GBRP format automatically when rendering to RGB
This removes the need to define IMGFMT_GBRAP, which fixes compilation
with the current Libav release.

This also makes it automatically pick up a GBRP format with the same bit
width. (Unfortunately, it seems libswscale does not support conversion
to AV_PIX_FMT_GBRAP16, so our code falls back to 8 bit, removing
precision for video covered by subtitles in cases this code is used.)

Also, when the source video is e.g. 10 bit YUV, upsample to 16 bit.
Whether this is good or bad, it fixes behavior with alpha. Although I'm
not sure if the alpha range is really correct ([0,2^16-1] vs.
[0,255*256]). Keep in mind that libswscale doesn't even agree with the
way we do it.
2015-12-24 16:42:21 +01:00
wm4 6bec6ac558 sub: better alpha blending when rendering to alpha surfaces
This actually treats destination alpha correctly, and gives much better
results than before. I don't know if this is perfectly correct yet,
though. Slight difference with vo_opengl behavior suggests it might not
be.

Note that this does not affect VOs with true alpha support. vo_opengl
does not use this code at all, and does the alpha calculations in OpenGL
instead.
2015-12-24 14:43:23 +01:00
wm4 45ae0716be csputils: rename "yuv2rgb" functions
They're not necessarily restricted to YUV aka YCbCr.

vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
2015-12-09 00:23:36 +01:00
wm4 c2d0d7818f csputils: remove obscure int_bits matrix scaling
This has no reason to be there. Put the functionality into another
function instead. While we're at it, also adjust for possible accuracy
issues with high bit depth YUV (matters for rendering subtitles into
screenshots only).
2015-12-09 00:08:00 +01:00
Marcin Kurczewski f43017bfe9 Update license headers
Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 12:10:01 +02:00
wm4 37a71e57d4 mp_image: remove redundant flags field
Because gcc (and clang) is a goddamn PITA and unnecessarily warns if
the universal initializer for structs is used (like mp_image x = {})
and the first member of the struct is also a struct, move the w/h
fields to the top.
2015-04-10 21:06:25 +02:00
wm4 41151122e7 mp_image: remove redundant chroma_x/y_shift fields 2015-04-10 21:02:16 +02:00
wm4 be259be15c mp_image: get rid of chroma_width/height fields
They are redundant. They were used by draw_bmp.c only, and only in a
special code path that 1. used fixed image formats, and 2. had image
sized perfectly aligned to chroma boundaries (so computing the chroma
width/height is trivial).
2015-04-09 21:11:20 +02:00
wm4 51befc9deb osd: simplify an aspect of change detection handling
There was a somewhat obscure optimization in the OSD and subtitle
rendering path: if only the position of the sub-images changed, and not
the actual image data, uploading of the image data could be skipped. In
theory, this could speed up things like scrolling subtitles.

But it turns out that even in the rare cases subtitles have such scrolls
or axis-aligned movement, modern libass rarely signals this kind of
change. Possibly this is because of sub-pixel handling and such, which
break this.

As such, it's a worthless optimization and just introduces additional
complexity and subtle bugs (especially in cases libass does the
opposite: incorrectly signaling a position change only, which happened
before). Remove this optimization, and rename bitmap_pos_id to
change_id.
2015-03-18 13:15:20 +01:00
wm4 d42d60bc1e csputils: replace float[3][4] with a struct
Not being able to use the 3x3 part of the matrix was annoying, so split
it into a float[3][3] matrix and a separate float[3] constant vector.
2015-01-06 16:51:06 +01:00
wm4 5410a5b2c5 csputils: move image_params -> csp_params into a function
Although the line count increases, this is better for making sure
everything is handled consistently for all users of the mp_csp_params
stuff.

This also makes sure mp_csp_params is always initialized with
MP_CSP_PARAMS_DEFAULTS (for consistency).
2015-01-06 16:51:02 +01:00
wm4 a52ca8a2b0 csputils: get rid of mp_csp_details
It used to be central, but now it's just unneeded.
2015-01-06 16:50:58 +01:00
wm4 9a724f62ce draw_bmp: make code more obvious, remove assertion
Silences a Coverity warning.

Also, drop the assert(); although it should be pretty much guaranteed
that things happen this way, it's still a bit fuzzy.
2014-11-21 05:56:55 +01:00
wm4 72aac9ae8a video: introduce failure path for image allocations
Until now, failure to allocate image data resulted in a crash (i.e.
abort() was called). This was intentional, because it's pretty silly to
degrade playback, and in almost all situations, the OOM will probably
kill you anyway. (And then there's the standard Linux overcommit
behavior, which also will kill you at some point.)

But I changed my opinion, so here we go. This change does not affect
_all_ memory allocations, just image data. Now in most failure cases,
the output will just be skipped. For video filters, this coincidentally
means that failure is treated as EOF (because the playback core assumes
EOF if nothing comes out of the video filter chain). In other
situations, output might be in some way degraded, like skipping frames,
not scaling OSD, and such.

Functions whose return values changed semantics:

  mp_image_alloc
  mp_image_new_copy
  mp_image_new_ref
  mp_image_make_writeable
  mp_image_setrefp
  mp_image_to_av_frame_and_unref
  mp_image_from_av_frame
  mp_image_new_external_ref
  mp_image_new_custom_ref
  mp_image_pool_make_writeable
  mp_image_pool_get
  mp_image_pool_new_copy
  mp_vdpau_mixed_frame_create
  vf_alloc_out_image
  vf_make_out_image_writeable
  glGetWindowScreenshot
2014-06-17 22:43:43 +02:00
wm4 5e4e248dc2 video: make mp_image use mp_image_params directly
Minor cleanup, so that we can stuff more information into
mp_image_params later.
2014-04-21 02:57:16 +02:00
wm4 0112143fda Split mpvcore/ into common/, misc/, bstr/ 2013-12-17 02:39:45 +01:00
wm4 e5311586ab Rename sub.c/.h to osd.c/.h
This was way too misleading. osd.c merely calls the subtitle renderers,
instead of actually dealing with subtitles.
2013-11-24 14:44:58 +01:00
Stefano Pigozzi 406241005e core: move contents to mpvcore (2/2)
Followup commit. Fixes all the files references.
2013-08-06 22:52:31 +02:00
wm4 7f88e36911 sws_utils: don't recursively include libswscale header
Add libswscale includes where they are actually needed instead.
2013-07-18 13:46:05 +02:00
wm4 f6a68063ba sub: don't crash on GBRP video
mp_get_yuv2rgb_coeffs() will crash if the colorspace is explicitly set
to RGB.
2013-03-28 21:46:17 +01:00
wm4 6b91ba0192 draw_bmp: use multiple bounding boxes
Seems to make it about up to 20% faster in some cases.
Slightly slower in some others.
2013-01-13 20:04:16 +01:00
wm4 03730e73dc img_convert: add sub_bitmap bounding box functions
mp_sub_bitmaps_bb is just sub_bitmaps_bb renamed/moved.
2013-01-13 20:04:16 +01:00
wm4 fb23c3a8ee draw_bmp: don't copy Y plane on up/down-sampling
Image areas with subtitles are upsampled to 4:4:4 in order to render
the subtitles (makes blending easier). Try not to copy the Y plane on
upsampling. The libswscale API requires this, but this commit works it
around by scaling the chroma planes separately as AV_PIX_FMT_GRAY8. The
Y plane is not touched at all. This is done for 420p8 only, which is the
most commonly needed case. For other formats, the old way is used.

Seems to make ASS rendering faster about 15% in the setup I tested.
2013-01-13 20:04:14 +01:00
wm4 7d15bd1488 draw_bmp: do not reallocate upsample temp image on each frame
Doesn't seem to help too much...
2013-01-13 20:04:14 +01:00
wm4 5c049bf577 draw_bmp: refactor 2013-01-13 20:04:14 +01:00
wm4 c652e3f6b1 draw_bmp: always allocate cache
Allocate it even if it's needed. The actually done work is almost the
same, except that the code is a bit simpler. May need more memory at
once for RGB subs that use more than one part, which is rare.
2013-01-13 20:04:14 +01:00
wm4 717d904bbc mp_image: add mp_image_crop()
Actually stolen from draw_bmp.c.
2013-01-13 20:04:12 +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 3791c226b7 draw_bmp: better way to find 444 format
Even though #ifdef ACCURATE is removed, the result should be about the
same. The fallback is only used by packed YUV formats (YUYV, NV12), and
doing 16 bit for them instead of 8 bit is not useful.

A side effect is that Y8 (gray) is not converted drawing subs, and for
alpha formats, the alpha plane is not removed. This means the number of
planes after upsampling can be 1-4 (1: gray, 2: gray+alpha, 3: planar,
4: planar+alpha). The code has to be adjusted accordingly to work on the
color planes only. Also remove the workaround for the chroma shift 31
hack.
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