[rbp/omxplayer] Avoid flushing fifos when audio/video fifos out of sync

This was intended to be a never happens event that could reset the state when something bad happens.
However it does trigger in some reasonable cases (like audio codec change) and makes things worse.
First implementation of the CRenderCapture interface

RenderCapture implementation for RPi using DispmanX

Minor changes that I reverted to the repo's version

Changed snapshot taking to use g_RBP.CaptureDisplay()

Removed unused fields, and changed implementation to use the width and height parameters
[rbp/omxplayer] Support frame advance with right arrow when paused

It seems this is desired behaviour for xbmc, and works okay on Pi, so enable it.
[rbp/omxplayer] Handle displaytime more like dvdplayer

We had various glitches when mixing seeking and trickplay with online streams or dvd content.
This tries to match more closely what dvdplayer does and fixes some seek/trickplay jumping issues
[rbp/omxplayer] Avoid loss of volume messages

There seems to be a race condition where the volume request arrives as the omx audio pipeline is being created.
Restructure the volume messages to apply the initial volume as pipeline is being created, and add missing locks.
This also reduces the differences between OMXPlayer and DVDPlayer
[rbp/omxplayer] Support both analogue and hdmi audio

Thanks to stupid-boy for original implementation.
[OverlayRenderGL] Fix corrupt pixels in graphical subs

On Pi you can see a corrupt line of pixels on bottom and right edges of subtitle bounding box.
This is due to using a subregion of a texture (due to the power of two rounding) and not ensuring
the texture coordinates are inside the valid pixels.

The easy solution is to use NPOT when available (always on GLES) and then the clamping works
(as well as saving memory).
[rbp/omxplayer] Cosmetics
[rbp/omxplayer] Improve the player diagnostics overlay
[rbp/omxplayer] Avoid too many calls to GPU

We currently read the media time once per packet received from demuxer to determine gpu underrun.
We've found that TrueHD audio in particular produces ~1000 packets per second (whether it is the active track or not).
The cost of reading media time (from gpu) is high enough that 1000 calls per second makes us fail to keep up.
So, cache the media time, and only read it at most 50 times per second.
h264_parser: Initialize the h264dsp context in the parser as well

Each AVStream struct for an H.264 elementary stream actually has two
copies of the H264DSPContext struct (and in fact all the other members
of H264Context as well):

((H264Context *) ((AVStream *)st)->codec->priv_data)->h264dsp
((H264Context *) ((AVStream *)st)->parser->priv_data)->h264dsp

but only the first of these was actually being initialised. This
prevented the addition of platform-specific implementations of
parser-related functions.

Signed-off-by: Martin Storsjö <martin@martin.st>
h264dsp: Factorize code into a new function, h264_find_start_code_candidate

This performs the start code search which was previously part of
h264_find_frame_end() - the most CPU intensive part of the function.

By itself, this results in a performance regression:
              Before          After
              Mean   StdDev   Mean   StdDev  Change
Overall time  2925.6 26.2     3068.5 31.7    -4.7%

but this can more than be made up for by platform-optimised
implementations of the function.

Signed-off-by: Martin Storsjö <martin@martin.st>
arm: Add assembly version of h264_find_start_code_candidate

               Before          After
               Mean   StdDev   Mean   StdDev  Change
This function   508.8 23.4      185.4  9.0    +174.4%
Overall        3068.5 31.7     2752.1 29.4     +11.5%

In combination with the preceding patch:
                Before          After
                Mean   StdDev   Mean   StdDev  Change
Overall         2925.6 26.2     2752.1 29.4     +6.3%

Signed-off-by: Martin Storsjö <martin@martin.st>