summaryrefslogtreecommitdiffstats
path: root/sub/draw_bmp.c
Commit message (Collapse)AuthorAgeFilesLines
* all: add missing repr assignmentsKacper Michajłow2024-01-261-0/+4
| | | | Fixes: 66e451f4
* csputils: replace mp_chroma_location with pl_chroma_locationKacper Michajłow2024-01-221-1/+1
|
* csputils: replace mp_alpha_type with pl_alpha_modeKacper Michajłow2024-01-221-6/+6
|
* csputils: replace mp_colorspace with pl_color_spaceKacper Michajłow2024-01-221-2/+2
|
* draw_bmp: fix overflowing coordinates in mark_rcsDudemanguy2023-07-301-1/+2
| | | | | | | | | | | | | | | | This is yet another unfortunate side effect of the width % SLICE_W == 0 special case. While looping through these rectangles, the rc->x1 value on the final loop can be greater than the actual total width. This will cause a buffer overflow if using the mp_draw_sub_overlay API. 2 of the current VOs that use that work around it by adjusting the values returned, but the better fix is to correct what's actually given in the rectangles so you can safely use the values. As for the fix, it's simply ensuring that rc->x1 doesn't extend beyond p->w with a MPCLAMP. Previously, the code would always naively add SLICE_W (256) to rc->x0 which would easily extend past the actual width in many cases. The adjustments in vo_vaapi and vo_dmabuf_wayland are dropped and in theory vo_direct3d should work now since we can just trust the values given to us in the rectangles. How nice.
* draw_bmp: ensure last slice is less than total width (again)Dudemanguy2023-07-121-0/+4
| | | | | | | | | | | | | | Essentially the same as d1d2370d073e9b70a181696e57075545b4802517 except for clear_rgba_overlay. From some empirical testing, the s->x1 value is either 0 or SLICE_W (256). In the case where it is 256 and s->x0 is 0, then it writes memory. For most slices, this is fine. However for the very last slice in the loop, it is possible for the width here to exceed the total width of the line (p->w). If that occurs, the memset triggers a buffer overflow. This last case needs to be guarded in the same way as the previously mentioned commit (total width - SLICE_W * x) and with MPMIN in case s->x1 is 0 here to preserve the old behavior. It's unknown if anything other than dmabuf-wayland can possibly hit this, but it's definitely a problem within mp_draw_sub_overlay itself.
* test: integrate unittests with mesonDudemanguy2023-03-021-0/+8
| | | | | | | | | | | | 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.
* draw_bmp: ensure last slice width is less than total widthDudemanguy2023-01-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | | e97819f88e451623a397b79d101497205fe849f9 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.
* draw_bmp: fix out of bounds access in mark_rectShreesh Adiga2022-10-111-3/+3
| | | | | | 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.
* sub: rename SUBBITMAP_RGBA to SUBBITMAP_BGRANiklas Haas2022-01-111-4/+4
| | | | | This was a misnomer, the actual channel order is IMGFMT_BGRA (as the comment explicitly point out). Rename the enum for consistency.
* video: clean up some imgfmt related stuffwm42020-05-181-4/+4
| | | | | | | | | | | | | | | | 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 00653a3eb052). With this I've decided to keep mp_imgfmt_desc, just removing the weird parts, and keeping the saner parts.
* draw_bmp: use command line options for any used scalerswm42020-05-131-9/+20
|
* draw_bmp: add integer blending for 8 bit formatswm42020-05-121-13/+51
| | | | | | | | 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.
* draw_bmp: don't make strange decisions on broken iknput csp paramswm42020-05-121-0/+2
| | | | | | | | | | | | 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.)
* draw_bmp: add a function to return a single-texture OSD overlaywm42020-05-111-46/+217
| | | | | | | | | | | | | | 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.
* video: remove RGB32/BGR32 aliaseswm42020-05-111-5/+5
| | | | | | | 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.
* draw_bmp: rewritewm42020-05-091-406/+649
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* video: make OSD/subtitle bitmaps refcounted (sort of)wm42020-04-261-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* draw_bmp: silence another ridiculous ubsan warningwm42020-04-181-4/+4
| | | | | | | | | | | | | | 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.)
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-311-4/+3
| | | | And remove libavutil includes where possible.
* draw_bmp: Fix for GBRP formats GBRP9 and upAnton Kindestam2019-09-221-5/+10
| | | | | | | | | | | | | | | | | | | 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.
* mp_image: split colorimetry metadata into its own structNiklas Haas2016-07-031-10/+7
| | | | | | | | | | | | | | | | | | 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.
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* sub: use macros to remove code duplicationwm42015-12-241-49/+31
| | | | Meh.
* sub: merge bitmap render functions into one for each kindwm42015-12-241-84/+45
| | | | | | | | | | 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.
* sub: remove "inaccurate" code pathwm42015-12-241-10/+0
| | | | | | 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.
* sub: find GBRP format automatically when rendering to RGBwm42015-12-241-12/+11
| | | | | | | | | | | | | | | | 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.
* sub: better alpha blending when rendering to alpha surfaceswm42015-12-241-1/+35
| | | | | | | | | | | 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.
* csputils: rename "yuv2rgb" functionswm42015-12-091-2/+2
| | | | | | They're not necessarily restricted to YUV aka YCbCr. vo_direct3d.c and demux_disc.c (DVD specific code) changes untested.
* csputils: remove obscure int_bits matrix scalingwm42015-12-091-4/+5
| | | | | | | 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).
* Update license headersMarcin Kurczewski2015-04-131-2/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* mp_image: remove redundant flags fieldwm42015-04-101-2/+2
| | | | | | | 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.
* mp_image: remove redundant chroma_x/y_shift fieldswm42015-04-101-3/+3
|
* mp_image: get rid of chroma_width/height fieldswm42015-04-091-5/+4
| | | | | | | 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).
* osd: simplify an aspect of change detection handlingwm42015-03-181-3/+3
| | | | | | | | | | | | | | | | | | 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.
* csputils: replace float[3][4] with a structwm42015-01-061-4/+4
| | | | | 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.
* csputils: move image_params -> csp_params into a functionwm42015-01-061-2/+1
| | | | | | | | | 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).
* csputils: get rid of mp_csp_detailswm42015-01-061-3/+3
| | | | It used to be central, but now it's just unneeded.
* draw_bmp: make code more obvious, remove assertionwm42014-11-211-3/+3
| | | | | | | 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.
* video: introduce failure path for image allocationswm42014-06-171-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* video: make mp_image use mp_image_params directlywm42014-04-211-10/+10
| | | | | Minor cleanup, so that we can stuff more information into mp_image_params later.
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-1/+1
|
* Rename sub.c/.h to osd.c/.hwm42013-11-241-3/+2
| | | | | This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-1/+1
| | | | Followup commit. Fixes all the files references.
* sws_utils: don't recursively include libswscale headerwm42013-07-181-0/+1
| | | | Add libswscale includes where they are actually needed instead.
* sub: don't crash on GBRP videowm42013-03-281-2/+4
| | | | | mp_get_yuv2rgb_coeffs() will crash if the colorspace is explicitly set to RGB.
* draw_bmp: use multiple bounding boxeswm42013-01-131-27/+20
| | | | | Seems to make it about up to 20% faster in some cases. Slightly slower in some others.
* img_convert: add sub_bitmap bounding box functionswm42013-01-131-1/+2
| | | | mp_sub_bitmaps_bb is just sub_bitmaps_bb renamed/moved.
* draw_bmp: don't copy Y plane on up/down-samplingwm42013-01-131-5/+46
| | | | | | | | | | | 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.
* draw_bmp: do not reallocate upsample temp image on each framewm42013-01-131-2/+14
| | | | Doesn't seem to help too much...
* draw_bmp: refactorwm42013-01-131-17/+31
|
*