core: minor cleanups

Enable printf format warnings for set_osd_[t]msg.
Remove the pointless assertion in mplayer.c (the assertion proved that
the following NULL check is probably pointless, but leave that check
anyway for robustness - it's not really clear whether it's needed).
gl_common: improve Mesa compatibility for GL3 context creation

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
cocoa_common: create window in the correct screen
cfg-config: avoid warning with -Wincompatible-pointer-types

This was throwing off a warning with clang. Add a cast to (void *) like many
other options do.
vo_xv: don't require frame stepping to remove OSD or subs

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.
vo_x11: add screenshot support

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_x11: don't require framestepping to update OSD

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.)
video: fix bogus uses of mp_image.w/width

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.
screenshot: add subs even with vf_screenshot

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.
subreader: do not skip the first char of ASS fields.

Without this change, fields that can be sometimes empty and
sometimes not, such as the Effect field, are counted in an
inconsistent way. Since the number of fields is used to find
where the text starts, it leads to internal field arriving
on the video.

Bug reported anonymously on the users mailing list.

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35426 b3059339-0415-0410-9bf9-f77b7e298cf2
stream_ftp: support longer filenames

This change was split into 8 patches. Squash them together, as they
affect stream_ftp.c only.

stream ftp: readline: Fix off-by-one error

Even if max bytes are available read at most max - 1 bytes.

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35427 b3059339-0415-0410-9bf9-f77b7e298cf2

Conflicts:
	stream/stream_ftp.c

stream ftp: readline: Always initialize output parameter buf

Only exception if passed parameter max is less than or equal
to zero. That cannot happen with the current code.

Additionally change readresp function to always copy the first
response line if the parameter rsp is non-NULL. This fixes some
error reporting that used uninitialized stack arrays.

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35428 b3059339-0415-0410-9bf9-f77b7e298cf2

stream ftp: readline: Always try to read complete lines

If there is not enough space in the provided line buffer just
skip the remaining bytes until reaching EOL.

Usually we are only interested in the first 5 characters and
for everything else the (on-stack) response buffer should still
be big enough.

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35429 b3059339-0415-0410-9bf9-f77b7e298cf2

stream ftp: Revise file descriptor usage

* Set unbound descriptor variables to -1
* Always test >= 0 to see if a variable refers to a valid descriptor

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35430 b3059339-0415-0410-9bf9-f77b7e298cf2

stream ftp: Only send QUIT command if connected

Do not attempt to send commands without control connections.

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35431 b3059339-0415-0410-9bf9-f77b7e298cf2

stream ftp: Create buffers before opening control connection

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35432 b3059339-0415-0410-9bf9-f77b7e298cf2

stream ftp: Allocate command buffer on-heap

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35433 b3059339-0415-0410-9bf9-f77b7e298cf2

stream ftp: Increase command buffer size

Allow for more longish file names (be it because of length or more
lengthy characters).

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@35434 b3059339-0415-0410-9bf9-f77b7e298cf2
stream_ftp: fix compilation with libav

Fixup commit for a04b35013a055926ab57f60137518a204ce9e753. That commit was
cherry-picked from mplayer(1) and thus assumes ffmpeg.
draw_bmp: add RGB rendering to fix image quality issues

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.)
osd: fix z-order of subtitle OSD elements

Subs should always be below OSD (meaning they have to be drawn first).
mp_image: make alloc_mpi() always allocate with aligned stride

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.
vo_xv: allocate Xv images with aligned stride

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.
configure: use pkg-config for detecting OpenAL

Pick 1.13 as minimal required version. (Arbitrary, but reasonable.)
manpage: remove --zoom remains

The --zoom option has been removed, and is always active.
sws_utils: remove unused helper

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.
ao_pulse: do not allow setting volume over 100%

PulseAudio allows applications to set volume over 100%. To make this
possible, the PulseAudio daemon raises the global system volume, and
tries to lower other applications volumes. Unfortunately, this doesn't
work out and doesn't manage to keep the effective volume level of these
other applications.

To make it short: this functionality invoked PulseAudio bugs. Disable
it.

This essentially reverts commit 85a64b.