summaryrefslogtreecommitdiffstats
path: root/video/out/vo_xv.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* 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.
* 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.
* options, vo_x11: remove -zoom option, make it defaultwm42012-11-161-1/+1
| | | | | | | | | | | | | | 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.
* Rename directories, move files (step 2 of 2)wm42012-11-121-8/+8
| | | | | | | | | | | | 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-121-0/+716
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.