summaryrefslogtreecommitdiffstats
path: root/sub/draw_bmp.c
Commit message (Collapse)AuthorAgeFilesLines
* 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-01 00:05:22 +0000