summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_sdl: fix for rename of a function in SDL2's interfaceRudolf Polzer2013-01-121-2/+4
|
* vo_sdl: add a "sw" flag like in openglRudolf Polzer2013-01-101-36/+75
| | | | | | Also, rework the renderer creation for the flag being generally effective even if the "SW renderer" is detected only after creating a context.
* vo_xv: fix compilation when shared memory header files are not availablewm42013-01-061-5/+2
| | | | | This is an extremely obscure situation, but can actually happen on OpenBSD.
* cocoa_common: add support for `--no-border`Stefano Pigozzi2012-12-311-0/+1
| | | | Draw a window with style NSBorderlessWindow when the user uses `--no-border`.
* vo_sdl: support -geometry properlyRudolf Polzer2012-12-311-2/+7
| | | | Now the x and y origin options (-geometry WxH+X+Y) are supported too.
* vo_sdl: some OSD optimizationsRudolf Polzer2012-12-281-23/+41
| | | | | | | | | | | | | | | | 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.
* vf_scale: prefer 420P10 -> YV12 instead of 444Pwm42012-12-281-0/+1
| | | | | | Strictly speaking, 444P is higher quality than YV12, but doing this is not very useful when playing 10 bit video with -vo opengl-old on a GPU that doesn't support 16 bit textures.
* vo_opengl_old: reject 9-15 bit formats if textures have less than 16 bitwm42012-12-283-1/+22
| | | | | | | | | | | | | | | | | | | 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.)
* gl_common: properly reject old OpenGL versionswm42012-12-281-11/+20
| | | | | | | | | | | | | | | | | | | 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.)
* vo_opengl: use more precise gamma for BT.709 with color managementnand2012-12-282-5/+5
| | | | | | | | | | 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.
* sdl, encode_lavc: fix copyright headersRudolf Polzer2012-12-282-6/+5
| | | | | | Some of them had changes in 2012; extend their header. Fix project name.
* vdpau: silence a clang warningRudolf Polzer2012-12-281-1/+2
| | | | It's just some braces...
* vo/ao: SDL 1.2+ audio driver, SDL 2.0+ accelerated video driverRudolf Polzer2012-12-282-0/+1008
| | | | | | | | | | | 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.
* vf_scale: support more pixel formatsRudolf Polzer2012-12-281-0/+4
| | | | | The RGBA, ARGB, BGRA, ABGR were previously not always supported, depending on system endianness.
* core: make WAKEUP_PERIOD overridable by the voRudolf Polzer2012-12-192-0/+4
| | | | | | | | | | | | 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.
* video: silence warnings for missing libavutils pixel formatswm42012-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Using vf_screenshot on Libav printed useless/misleading error messages when playing 10 bit h264 with a VO that supports 8 bit yuv420p only: Unsupported format 444p14le Unsupported format 444p14be ... The cause of this is that vf_scale is inserted to handle the format conversion, and tries to find a pixel format with best quality. This includes the 14 bit and 12 bit formats, which don't exist on Libav. vf_screenshot tries to query whether Libav's libswscale supports it, resulting in these error messages. (In theory, vf_scale is missing this check, but it doesn't matter in practice.) Since this warning is rather useless anyway, because all input video comes from libavcodec, and only the conversion into the other could possibly fail. Silence the warning by raising it to verbose message level. Closes #7.
* options: move -ass-bottom-margin/-ass-top-margin options to vf_subwm42012-12-121-10/+15
| | | | | These options might be useful sometimes, but they are not that important, and work with vf_sub only. Make them vf_sub sub-options.
* vf_sub: fix aspect ratio when using marginswm42012-12-121-3/+3
|
* Fix compilation with Libavwm42012-12-041-12/+13
| | | | Libav doesn't have 12/14 bit planar formats.
* video: add support for 12 and 14 bit YUV pixel formatsStephen Hutchinson2012-12-035-3/+87
| | | | | | | | | | | | 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.
* vo_xv: try harder to get correctly aligned pointers/strideswm42012-12-031-4/+6
| | | | | | | | | | | | | | | | | | | | 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.
* osx_common: Avoid deprecated Gestalt callsStefano Pigozzi2012-12-021-16/+26
| | | | | | | | 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.
* sub: reimplement -spugauss as --sub-gausswm42012-11-252-7/+38
| | | | | | | | | | | | | | | | Apparently the -spugauss option was popular. The code originally implementing this is gone (scaler stuff in spudec.c). Reimplement it using libswscale to scale and blur image subtitles if the --sub-gauss option is set. The code does some rather lazy padding to allow the blur to spread pixels past the original image bounding box. (This problem exists with normal bilinear scaling too, but is barely noticable.) Technically, this doesn't just blur subtitles, but anything RGBA (or indexed) that enters the OSD rendering path. But only image subtitles produce these OSD formats currently, so no explicit check is done to prevent blurring in other cases.
* memcpy_pic: kill useless/dangerous optimizationwm42012-11-251-10/+6
| | | | | | | | | | | | | | | | | The memcpy_pic() function had a rather dangerous optimization: when the limit2width flag was not set, it was allowed to overwrite the data between the last pixel of a line and the first pixel of the next line (i.e. write over the stride padding). That was also the reason why there are so many whacky names for this function (memcpy_pic, my_memcpy_pic, memcpy_pic2). Kill this optimization, and never overwrite the stride padding. The code doing this can still be used if there's no stride padding at all, though. Also use the name memcpy_pic for the proper function. Now it should be rather clear that my_memcpy_pic and memcpy_pic2 are compatibility aliases. They should go away over the time.
* sws_utils: remove unused helperwm42012-11-243-33/+10
| | | | | | | | sws_getContextFromCmdLine_hq() was used by the screenshot code, which now uses mp_image_swscale(). Also move the mp_sws_set_colorspace() declaration from sws_utils.h to vf_scale.c.
* vo_xv: allocate Xv images with aligned stridewm42012-11-221-4/+5
| | | | | | | | | | | | | | | 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: make alloc_mpi() always allocate with aligned stridewm42012-11-222-17/+6
| | | | | | | | | | | | | | | | By "design", mplayer normally allocates aligned images only inside the filter chain, via the vf_get_image() function. This function pads the width of the requested image if a stride is allowed, sets that new width before calling mp_image_alloc_planes(). However, newer code wants aligned images as well (basically to satisfy libswscale). This affects all uses of alloc_mpi(). To get aligned strides, simply change alloc_mpi() to request an aligned width. Remove the old hack in mp_image_alloc_planes(), which special cases some image formats to be allocated with aligned strides. This is a temporary hack until mp_image_alloc_planes() is revised.
* draw_bmp: add RGB rendering to fix image quality issueswm42012-11-222-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* screenshot: add subs even with vf_screenshotwm42012-11-211-0/+1
| | | | | | | | | | | | | | Until now, screenshots with the video filter didn't add subs (unclear whether that was an oversight or feature). Fix this and make behavior when taking screenshots with vf_screenshot more consistent with VO screenshots. The change in vf_screenshot is needed, because add_subs() checks this flag to decide whether it's allowed to mutate the image. This commit has another user visible side effect. When taking a screenshot each frame (using the "each-frame" mode of the screenshot command), a normal screenshot command will stop the each-frame mode.
* video: fix bogus uses of mp_image.w/widthwm42012-11-213-14/+13
| | | | | | | | | | | | | | | | | 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.
* vo_x11: don't require framestepping to update OSDwm42012-11-211-1/+20
| | | | | | | | | | | | 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.)
* vo_x11: add screenshot supportwm42012-11-211-0/+16
| | | | | | 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.)
* vo_xv: don't require frame stepping to remove OSD or subswm42012-11-211-36/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* cocoa_common: create window in the correct screenStefano Pigozzi2012-11-211-1/+2
|
* gl_common: improve Mesa compatibility for GL3 context creationwm42012-11-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* vf_softpulldown: fix possible regressionwm42012-11-201-1/+2
| | | | | | | | | The lines added with this commit were accidentally removed in commit a0d759, which was a pure cleanup commit merged from mplayer-svn. The difference between mplayer-svn and the mplayer2 base is that this filter has been made PTS aware in mplayer2. Also remove the redundant initialization of vf->priv->state.
* options: remove --displaywm42012-11-162-11/+1
| | | | | Was used to set the X11 display. XDisplayName(NULL) does the same, using the DISPLAY environment variable instead.
* video/filter: rename vf_eq2 to vf_eqwm42012-11-162-4/+4
| | | | | vf_eq was deleted earlier, which makes the name vf_eq2 even more awkward.
* vo_opengl: remove osdcolor suboptionwm42012-11-161-16/+0
| | | | | | 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.
* options, vo_x11: remove -zoom option, make it defaultwm42012-11-1613-51/+13
| | | | | | | | | | | | | | 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.
* video: add IMGFMT_Y16/PIX_FMT_GRAY16wm42012-11-145-5/+26
| | | | | | | | | 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.
* Improve compatibility with Libav 0.8.4 and ffmpeg 0.11.2wm42012-11-141-0/+1
| | | | | | | | | | | 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.
* clang: fix all warnings except deprecationsStefano Pigozzi2012-11-133-2/+6
|
* vf_dlopen: fix a typo in zeroing memory (thanks, pigoz)Rudolf Polzer2012-11-131-1/+1
| | | | Accidentally had put the & inside the sizeof call too. Typing too fast.
* win32: remove pointless get/release DC wrapperswm42012-11-123-32/+8
|
* Add missing compat/libav.h includeswm42012-11-122-0/+4
| | | | For avcodec_free_frame().
* Rename directories, move files (step 2 of 2)wm42012-11-1267-352/+348
| | | | | | | | | | | | 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.)
* Rename directories, move files (step 1 of 2) (does not compile)wm42012-11-1294-0/+36526
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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-01 19:05:01 +0000