[rpi] Include ntsc frequencies in list of supported resolutions
[omxplayer] Allow a framerate callback from GPU to trigger a hdmi mode change
[omxplayer] Add ability to log more timestamp info in extra debug settings
[omxplayer] Request to be notified about framerate changes
[omxplayer] Don't propagate 3d flags based on supported 3d modes
[omxplayer] Support stereo view modes with scaling

The Pi only supported a single view rectangle, which is sufficient for all mono view modes,
but only supports a subset of stereo modes.

To work around this, the scaling rectangles were ignored in 3D modes and 3D video was treated as unscaled.
While this worked or square pixel, 16:9 content on a 16:9 display, it went wrong is various other conditions.

@sraue reported that mono view of SBS/TAB content wasn't scaled correctly, and other forum reports
aspect ratio errors in widescreen 3D videos.

As it wasn't trivial to work around these bug reports, I've added a new stereo flags to the firmware
that allows a second display region to be created for the second eye, allowing scaling to work.

I've been through the video stereo modes (none, sbs, tab) and the display stereo modes (mono, sbs, tab)
and all the zoom modes, and compared the scaling to xbmc on windows and all seem to match

Requires udpated firmware.
Move the H.264 search code search functions into separate source files. This permits re-use with parsers for codecs which use similar start codes.
Add platform-specific start code search routine to VC1DSPContext. Initialise VC1DSPContext for parser as well as for decoder. Note, the VC-1 code doesn't actually use the function pointer yet.
vc-1: Optimise parser (with special attention to ARM)

The previous implementation of the parser made four passes over each input
buffer (reduced to two if the container format already guaranteed the input
buffer corresponded to frames, such as with MKV). But these buffers are
often 200K in size, certainly enough to flush the data out of L1 cache, and
for many CPUs, all the way out to main memory. The passes were:

1) locate frame boundaries (not needed for MKV etc)
2) copy the data into a contiguous block (not needed for MKV etc)
3) locate the start codes within each frame
4) unescape the data between start codes

After this, the unescaped data was parsed to extract certain header fields,
but because the unescape operation was so large, this was usually also
effectively operating on uncached memory. Most of the unescaped data was
simply thrown away and never processed further. Only step 2 - because it
used memcpy - was using prefetch, making things even worse.

This patch reorganises these steps so that, aside from the copying, the
operations are performed in parallel, maximising cache utilisation. No more
than the worst-case number of bytes needed for header parsing is unescaped.
Most of the data is, in practice, only read in order to search for a start
code, for which optimised implementations already existed in the H264 codec
(notably the ARM version uses prefetch, so we end up doing both remaining
passes at maximum speed). For MKV files, we know when we've found the last
start code of interest in a given frame, so we are able to avoid doing even
that one remaining pass for most of the buffer.

In some use-cases (such as the Raspberry Pi) video decode is handled by the
GPU, but the entire elementary stream is still fed through the parser to
pick out certain elements of the header which are necessary to manage the
decode process. As you might expect, in these cases, the performance of the
parser is significant.

To measure parser performance, I used the same VC-1 elementary stream in
either an MPEG-2 transport stream or a MKV file, and fed it through ffmpeg
with -c:v copy -c:a copy -f null. These are the gperftools counts for
those streams, both filtered to only include vc1_parse() and its callees,
and unfiltered (to include the whole binary). Lower numbers are better:

                Before          After
File  Filtered  Mean   StdDev   Mean   StdDev  Confidence  Change
M2TS  No        861.7  8.2      650.5  8.1     100.0%      +32.5%
MKV   No        868.9  7.4      731.7  9.0     100.0%      +18.8%
M2TS  Yes       250.0  11.2     27.2   3.4     100.0%      +817.9%
MKV   Yes       149.0  12.8     1.7    0.8     100.0%      +8526.3%

Yes, that last case shows vc1_parse() running 86 times faster! The M2TS
case does show a larger absolute improvement though, since it was worse
to begin with.

This patch has been tested with the FATE suite (albeit on x86 for speed).
[omxplayer] Make dvdplayer the default for dvd images
[graphics] Don't set stereo mode based on resolution

The resolution change should follow stereo mode
[graphics] Allow switching to a more suitable 3D resolution
[3D] Support switching to 3D resolutions

Include matching 3D flags (SBS/TAB) in the score of a resolution to switch to, to enable switching to 3d modes.
Also remove the old code that treated 3D modes differently when assigning a score.
[graphics] Make pixel ratio for 3d modes consistent

Note: Use the stored stereo flags from lists of resolutions.
Use current stereo mode for current resolution.