[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
[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.
[rbp/omxplayer] Multichannel audio: add missing files
[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?