demux_lavf: use lavf for RealMedia (.rm) files by default

RealMedia was listed as a format for which the internal demuxer
(demux_real) was preferred over lavf. The original reason for this
(lavf failing to give any timing information for some video frames)
has been fixed in libavformat since. Make demux_lavf the preferred
demuxer for RealMedia.

The libavformat demuxer does still have issues. COOK audio initially
misbehaves after a seek (inconsistent timestamps, audio remaining from
the before-seek position). However, the internal demuxer seemed to be
_consistently_ out of sync with a test file. I haven't done thorough
testing, but the internal demuxer does not seem less buggy.
options: support "no-foo" syntax for flag suboptions

Allow using "no-foo" as an alternative to "foo=no" for flag
suboptions, similarly to what top-level flag options already support.
This means things like "--lavdopts=no-fast" or
"--vo=vdpau:no-chroma-deint" are now supported.
vo_vdpau: disable refresh-aware frame timing when composited

Under a compositing window manager the current VDPAU implementation
behaves differently than without it. Frame flip timing info becomes
incorrect (I guess it only reflects when the frame was sent to the
compositor, not when it was actually shown), and there is no
limitation to at most one frame switch per refresh like without
compositing. Detect whether a compositing window manager is active and
disable refresh-aware frame timing and dropping in this case,
similarly to what fps=-1 would do. This behavior can be controlled
with the new suboption "composite-detect".

Disabling the refresh-aware logic makes timing somewhat less accurate.
Because the video switch rate limit isn't there, the lack of frame
dropping on player side does not impose a hard limit on video FPS, but
does reduce performance somewhat as redundant frames are drawn in
memory.

The existence of a compositing window manager does not guarantee that
the current window is actually composited, so the current check is not
foolproof. In particular, some WMs have support for a "unredirect
fullscreen windows" option. Support for such things could be improved.
demux_rawdv.c: fix change missing from recent 8079f4ff821

Like vd_vfw.c fixed earlier, demux_rawdv.c was also missing a change
needed for the "flags"->"keyframe" demux packet field rename. This
broke compilation with libdv enabled.

Hopefully there aren't more cases. It's hard to reliably check for
references in files that aren't compiled in the local tree if they use
different base variable names, as the "flags" name itself is used for
many unrelated things.
vo_corevideo, vo_sharedbuffer: put private state in vo->priv

These VOs were already using a struct for all private data but the
struct variable itself was static. Change them to store the address in
vo->priv. Also change them to use the new automatic private data
allocation and option parsing mechanism.
vo_sharedbuffer: remove from autoprobe list

This video output is headless and only intended to work with GUIs
explicitly asking for it. This makes it useless to have it in the
autoprobe list.
ao_pulse: work around PulseAudio timing bugs

Work around PulseAudio bugs more effectively. In particular, this
should avoid two issues: playback never finishing at end of file /
segment due to PulseAudio always claiming there's still time before
audio playback reaches the end, and jerky playback especially after
seeking due to bogus output from PulseAudio's timing interpolation
code.

This time, I looked into the PulseAudio code itself and analyzed the
bugs causing problems. Fortunately, two of the serious ones can be
worked around in client code. Write a new get_delay() implementation
doing that, and remove some of the previous workarounds which are now
unnecessary. Also add a pa_stream_trigger() call to ensure playback of
files shorter than prebuf value starts (btw doing that by setting a
low prebuf hits yet another PulseAudio bug, even if you then write the
whole file in one call).

There are still a couple of known PulseAudio bugs that can not be
worked around in client code. Especially, bug 4 below can cause issues
when pausing.

Below is a copy of a message I sent to the pulseaudio-discuss mailing
list, describing some of the PulseAudio bugs:

==================================================

A lot of mplayer2 users with PulseAudio have experienced problems. I
investigated some of those and confirmed that they are caused by
PulseAudio. There are quite a few distinct PulseAudio bugs; some are
analyzed below. Overall, however, I wonder why there are so many fairly
obvious bugs in a widely used piece of software. Is there no
maintenance? Or do people not test it? Some of the bugs are probably
less obvious if you request low latency (though they're not specific to
higher-latency case); do people test the low-latency case only?

1. The timing interpolation functionality can return completely bogus
values for playback position and latency, especially after seeking
(mplayer2 does cork / flush / uncork, as flushing alone does not seem to
remove data already in sink). I've seen quickly repeated seeks report
over 10 second latency, when there aren't any buffers anywhere that big.
I have not investigated the exact cause. Instead I disabled
interpolation and added code to always call
pa_stream_update_timing_info(). (I assume that always waiting for this
to complete, instead of doing custom interpolation, may give bad
performance if it queries a remote server. But at least it works better
locally.)

2. Position/latency reporting is wrong at the end of a stream (after the
lack of more data triggers underflow status). As a result mplayer2 never
ends the playback of a file, as it's waiting forever for audio to finish
playing. The reason for this is that the calculations in PulseAudio add
the whole length of data in the sink to the current latency (subtract
from position), even if the sink does not contain that much data *from
this stream* in underflow conditions. I was able to work around this bug
by calculating latency from pa_timing_info data myself as follows
(ti=pa_timing_info):

    int64_t latency = pa_bytes_to_usec(ti->write_index - ti->read_index, ss);
    latency -= ti->transport_usec;
    int64_t sink_latency = ti->sink_usec;
    if (!ti->playing)
        // this part is missing from PulseAudio itself
        sink_latency -= pa_bytes_to_usec(ti->since_underrun, ss);
    if (sink_latency > 0)
        latency += sink_latency;
    if (latency < 0)
        latency = 0;

However, this still doesn't always work due to the next bug.

3. The since_underrun field in pa_timing_info is wrong if PulseAudio is
resampling the stream. As a result, the above code indicated that the
playback of a 0.1 second 8-bit mono file would take about 0.5 seconds.
This bug is in pa_sink_input_peek(). The problematic parts are:

ilength = pa_resampler_request(i->thread_info.resampler, slength);
...
if (ilength > block_size_max_sink_input)
    ilength = block_size_max_sink_input;
...
pa_memblockq_seek(i->thread_info.render_memblockq, (int64_t) slength, PA_SEEK_RELATIVE, TRUE);
...
i->thread_info.underrun_for += ilength;

This is measuring audio in two different units, bytes for
resampled-to-sink (slength) and original stream (ilength). However, the
block_size_max_sink_input test only adjusts ilength; after that the
values may be out of sync. Thus underrun_for is incremented by less than
it should be to match the slength value used in pa_memblockq_seek.

4. Stream rewind functionality breaks if the sink is suspended (while
the stream is corked). Thus, if you pause for more than 5 seconds
without other audio playing, things are broken after that. The most
obvious symptom is that playback can continue for a significant time
after corking. This is caused by sink_input and sink getting out of
sync. First, after uncorking a stream on a suspended sink,
pa_sink_input_request_rewind() is called while the sink is still in
suspended state. This sets sink_input->thread_info.rewrite_nbytes to -1
and calls pa_sink_request_rewind(). However, the sink ignores rewind
requests while suspended. Thus this particular rewind does nothing. The
problem is that rewrite_nbytes is left at -1. Further calls to
pa_sink_input_request_rewind() do nothing because "nbytes =
PA_MAX(i->thread_info.rewrite_nbytes, nbytes);" sets nbytes to -1, and
the call to pa_sink_request_rewind() is under "if (nbytes != (size_t)
-1) {". Usually, after a sink responds to a rewind request,
rewrite_bytes is reset in pa_sink_input_process_rewind(), but this
doesn't happen if the sink ever ignores one request. This broken state
can be resolved if pa_sink_input_process_rewind() is called due to a
rewind triggered by _another_ stream.

There were more bugs, but I'll leave those for later.
demux_lavf: fix initial video stream selection

One bug in initial video stream selection when opening the demuxer was
fixed earlier by cb4394aea32 ("demux_lavf: fix initial "-vid"-based
video selection"). However, this still doesn't always work right due
to the nonsensical way demuxer->video->id is initialized. Before
demuxer-specific code runs, demuxer.c initializes it to the value of
the --vid option, or -2 for disabled or -1 for autoselect. However, in
a running demuxer, the value of the field is demuxer->v_streams[]
index which does not need to match --vid value for the stream. The
demux_lavf video selection code considered each stream one by one as
they were being added. As a result, the code could first select one
stream based on the demuxer->video->id value from demuxer.c, set
demuxer->video->id to the corresponding v_streams index value, and
then later reinterpret that as --vid specifying a _different_ stream.

Move video stream selection to the end of demuxer initialization. This
ensures there is no ambiguity whether demuxer->video->id is still the
--vid value or after-stream-selection v_streams index. It also ensures
the code will not try to autoselect a stream that is added later after
demuxer initialization (which, while perhaps desirable in some cases,
would not work correctly without extra code). Also, remove some code
which set demuxer->audio->sh and demuxer->video->sh in fill_buffer();
this should not be needed if other code is working correctly, as
anything selecting the stream should have already initialized those
fields.
stream_file: print strerror() when failing to open a file

stream_file always printed "File not found" if it could not open a
file, even though this could be due to other reasons such as
permission problems. Print strerror() information instead. This
changes the output for "mplayer /etc/shadow" from
File not found: '/etc/shadow'
to
Cannot open file '/etc/shadow': Permission denied
stream_file: refuse to open directories

It's pointless.
demux_lmlm4: avoid printing error from check_file()

lmlm4_check_file() did a seek back before returning failure. This
triggered a "Invalid seek to negative position" error when trying to
play very short files (mainly ones too short to actually contain
anything playable). As there's no need to change stream position
before returning demuxer detection failure, fix the spurious message
by simply removing the seek.
input/lirc: don't show errors even if LIRC init fails

LIRC support is enabled by default if the machine has liblircclient
development headers installed, and it's also enabled in at least some
distro packages. However, most machines will not have the LIRC daemon
running. In this case the LIRC input initialization code printed three
lines of errors: two from the liblircclient lirc_init() function
called with verbose mode enabled, and one from the player input code.
The first two lines also ignored message level settings as they were
output directly by the library. Disable these messages: call
lirc_init() without verbose mode, and move the player message from
MSGL_ERR to MSGL_V. The first change unfortunately means that there
are no details about the error available in case you expected LIRC
support to work.
gl_common: fix compilation on OS X 10.8

As of OS X 10.8 Apple completely removed X11 from the system.
gl_common.h was including gl.h using the path <GL/gl.h>. This path
comes from the X11 headers, which are missing in 10.8.

Change gl_common.h to include gl.h from Apple's OpenGL implementation
as <OpenGL/gl.h> if X11/XQuartz is not detected.
cocoa_common: make fullscreen menubar/dock hiding conditional

cocoa_common was hiding the dock and menubar unconditionally when
going fullscreen. This means they were hidden even if they weren't on
the screen mplayer2 was going fullscreen on, resulting in poor user
experience.

Change the fullscreen function in the cocoa backend to check that
mplayer2 is on the same screen as the menubar/dock before hiding them.
ad_ffmpeg: add sanity check against decoder overreads

The libavcodec Musepack SV8 decoder returned 2 bytes consumed for 1
byte input, which triggered a crash due to negative input packet size
later. Add a sanity check to prevent crashes with this type of minor
decoder overreads. Also add a check to parser consumed data.
demux_lavf: assume audio codec_tag 0 means unset

Libavformat does not distinguish between "no codec_tag given" and
"codec_tag given, value is 0". 0 can be a valid value. Change
demux_lavf to assume that 0 always means unset for audio. This
prevents incorrect selection of the PCM decoder, which includes
"format 0x0" in its codecs.conf entry. The video case accepts 0 iff
codec_id is RAWVIDEO, but there's no obvious similar check possible
for audio. Thus this could possibly cause issues if a file really uses
0 to mean uncompressed audio.
cocoa_common: refactor menu generation

This commit is supposed to make the menu generation a little more
readable. It also fixes menu generation for the `cmd+q` entry.
cleanup: osx_common: remove unused functions

Remove functions that aren't called anymore:

 *  `osx_foreground_hack` was replaced by the NSApplication's
    activateIgnoringOtherApps: in cocoa_common.
 *  Aspect ratio functions were not called by the "new" cocoa backend,
    since the corresponding menu item was deleted.
cocoa_common.m: add missing config.h include

This is needed for the check on CONFIG_SDL in this file.
macosx_finder_args: add SDL specific code path

SDL bootstrap code (include SDL.h in mplayer.c) creates its own minimal
Cocoa Application and creates a new argv to abstract away OSX specific
stuff (like -psn). For this reason the original code was not entering the
correct code path. This resulted in mplayer2 spamming to system.log.

Add a different code path to handle the case where SDL boostrap code ran.

Also, sort the files by filename for both SDL and no-SDL code paths: when
files are double clicked or drag and dropped to the mplayer2 icon they can
be in random order. Opening them with command + down arrow already
worked correctly.