[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.

I've also added a small weight to higher multiples of the desired framerate, so if display supports 30, 60 and 120Hz
and the video is 30fps then 30 will now be chosen rather than 120. This reduces the overhead of rendering the gui.
[confluence] Use animated gif as a cheaper working spinner
[rbp/omxplayer] Do we need discontinuity handling?

So far I've not seen what this is needed for and it does cause problems for some files.
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>
[ffmpeg] Backport of h264_find_start_code_candidate optimisation
[rbp/omxplayer] First attempt at a jpeg thumbnail pipeline
[rbp/omxplayer] Use an omx decode to texture pipeline git push -f This PR uses an openmax pipeline to handle jpeg
decode/resize/convert to texture without the decoded pixels being returned to the arm.

The jpeg is decoded in stripes which saves memory. There is no need for the RGBA32 pixel buffer to ever exist on the arm.
It is straightforward to choose whether the textures are 16bpp or 32bpp which could be a useful option on 256M Pi.

This scheme is *much* faster, and is the main factor in the recent raspberry-pi "speed" video.
It is well tested and openelec and raspbmc builds have been made with this patch in.
[rbp/gui] Add switch between higher and lower quality textures

To save memory we default to 16bpp textures,
but provide a GUI option to increase that to 32bpp.
[rbp/gui] Add switch to remove GUI 720p limit
[rbp/omxplayer] Add caching of states to reduce number of round trip delays to GPU
Revert "[rbp/omxplayer] Add caching of states to reduce number of round trip delays to GPU"

This reverts commit 691cfc567895b6645d7052b292f44f557004059b.
[rbp/omxplayer] Avoid clipping with amplification

The amplification algorithm introduced in #3185 relies on a fixed duration between
submitting samples (where max output values are computed) and samples being output,
so volume can be adjusted in time.

When this is too low, such as at start of stream when buffering is low we can apply
attenuation too late and so produce a loud distorted/clipped sound.

When too high, the attenuation can start to decay before the max sample is output,
again causing clipping.

This PR keeps a queue of max sample values for the current buffered audio duration,
and avoids clipping if any sample in queue will clip.
[rbp/omxplayer] Add fixed latency mode for live streams
[rbp/omxplayer] Support multichannel PCM audio output over hdmi

Requires updated firmware (from next branch)
[rbp/omxplayer] Avoid marking non-monotonic timestamps as unknown

Following a single spurious timestamp that is in the future,
all subsequent timestamps will be marked unknown causing out of sync.
[Players] Avoid jumping volume to maximum after trickplay
For players that control volume, if the speed changes (e.g. with ff/rew) the volume gets reset to maximum.
This change sets it back to current value, although I question why it is being changed at all.
Do any players require muting during trickplay?