summaryrefslogtreecommitdiffstats
path: root/sub/draw_bmp.c
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* draw_bmp: always allocate cachewm42013-01-131-26/+25
| | | | | | 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.
* mp_image: add mp_image_crop()wm42013-01-131-12/+2
| | | | Actually stolen from draw_bmp.c.
* vo_xv, vo_x11: simplify OSD redrawingwm42013-01-131-123/+0
| | | | | | | | | | | | | 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.
* draw_bmp: better way to find 444 formatwm42013-01-131-43/+13
| | | | | | | | | | | | | 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.
* video: cleanup: replace old mp_image function nameswm42013-01-131-5/+5
| | | | | mp_image_alloc() also changes argument order compared to alloc_mpi(). The format now comes first, then width/height.
* mp_image: simplify image allocationwm42013-01-131-16/+15
| | | | | | | | | | | | | | | | | | | | | | | | mp_image_alloc_planes() allocated images with minimal stride, even if the resulting stride was unaligned. It was the responsibility of vf_get_image() to set an image's width to something larger than required to get an aligned stride, and then crop it. Always allocate with aligned strides instead. Get rid of IMGFMT_IF09 special handling. This format is not used anymore. (IF09 has 4x4 chroma sub-sampling, and that is what it was mainly used for - this is still supported.) Get rid of swapped chroma plane allocation. This is not used anywhere, and VOs like vo_xv, vo_direct3d and vo_sdl do their own swapping. Always round chroma width/height up instead of down. Consider 4:2:0 and an uneven image size. For luma, the size was left uneven, and the chroma size was rounded down. This doesn't make sense, because chroma would be missing for the bottom/right border. Remove mp_image_new_empty() and mp_image_alloc_planes(), they were not used anymore, except in draw_bmp.c. (It's still allowed to setup mp_images manually, you just can't allocate image data with them anymore - this is also done in draw_bmp.c.)
* mp_image: require using mp_image_set_size() for setting w/hwm42013-01-131-5/+1
| | | | | | | | | | | | | | 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.
* video: add support for 12 and 14 bit YUV pixel formatsStephen Hutchinson2012-12-031-0/+8
| | | | | | | | | | | | 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.
* draw_bmp: add RGB rendering to fix image quality issueswm42012-11-221-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* vo_xv: don't require frame stepping to remove OSD or subswm42012-11-211-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Rename directories, move files (step 2 of 2)wm42012-11-121-5/+5
| | | | | | | | | | | | 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.)
* draw_bmp: remove swscale bug workaroundwm42012-11-011-3/+1
| | | | | ffmpeg ticket #1852 is fixed with 425c30dda. This didn't actually happen in practice.
* screenshot, draw_bmp: use colorspace passed with mp_imagewm42012-11-011-25/+48
| | | | | Remove the explicit struct mp_csp_details parameters from all related functions, and use mp_image.colorspace/levels instead.
* csputils: better support for integer color valueswm42012-10-281-1/+3
|
* draw_bmp, csputils: use function instead of macrowm42012-10-281-21/+4
|
* draw_bmp: cosmetics, refactorwm42012-10-281-420/+318
| | | | | | | | | | | Mostly pedantic bikeshedding issues. Move some code around, so that the sub_bitmap_to_mp_images() function can be split into two parts. This is better than having a big function with many input and outputs, of which only half are used in each code path. Also, try to make code simpler by using a mp_rect type.
* draw_bmp: remove CONDITIONAL2 codewm42012-10-241-25/+0
| | | | This was sometimes slower, sometimes slightly faster. Remove it.
* options: remove subtitle related options that did nothingwm42012-10-241-0/+1
| | | | | | | Most of these cased working when the OSD was switched to libass, or didn't do anything even before that. Also don't recursively include subreader.h in sub.h.
* draw_bmp: fix IMGFMT_BGR32 useRudolf Polzer2012-10-241-9/+15
|
* draw_bmp: fix for yuy2 formatwm42012-10-241-1/+2
| | | | | | | mp_get_chroma_shift() modifies its argument even if it fails, so we have to restore that. mp_image didn't set chroma shifts for yuy2.
* draw_bmp: don't try to call swscale if image format not supportedwm42012-10-241-0/+3
| | | | If that happens, we silently fail.
* sub: add cache to mp_draw_sub_bitmaps()wm42012-10-241-9/+68
| | | | This caches scaled RGBA sub-bitmaps.
* draw_bmp: compensate for libswscale writing past image boundswm42012-10-241-1/+2
| | | | | | | | | | | | | | | | libswscale tends to overwrite the area between (w,y)-(0,y+1). It tries to process multiple pixels at once, and if the memory past the last x pixel is inside a SIMD operation, but still below the image stride, it overwrites that data with black. This happens with vo_x11 and 32 bit RGBA formats. The bug is visible as black bar right of the subtitle bounding box. Fix by giving libswscale more alignment. Then the "outside" pixels are inside, and are processed normally instead of overwritten with black. NOTE: we do not increase the alignment constant, because this is a separate issue from pointer alignment. libavutil's av_malloc() wouldn't actually satisfy the increased alignment either.
* sub: add helper to draw sub-bitmaps into an imageRudolf Polzer2012-10-241-0/+580
Merged by wm4 from commits 93978f17b76d..13211ef5fc20. Changed copyright header in draw_bmp.c to "mpv", and removed the one in draw_bmp.h.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-15 05:20:26 +0000