logging: Add microsecond timer to log messages
videoplayer: adapt lateness detection and dropping to buffering
video player: present correct pts to user for a/v sync (after buffering in renderer)
[hifiberry] Hack: force it to be recognised as IEC958 capable to enable passthrough options
Move the reference-counting of Begin and End calls from DX and GL source files into GUIFontTTF.cpp.
Convert CGUIFontTTFBase::m_vertex to be managed as a std::vector.

Also retired CGUIFontTTFBase::m_vertex_count and
CGUIFontTTFBase::m_vertex_size because these can be derived from vector
member functions.
CGUIFontTTFBase::RenderCharacter can now append to arbitrary vectors of vertices rather than only CGUIFontTTFBase::m_vertex
Add a cache of font glyph bounding box vertices.

This is implemented as a template because ultimately we will key on different
parameters and store values of different types, depending upon whether we
have a GLES or non-GLES backend, and for GLES, whether or not the currently
applicable transformation matrices permit the use of hardware clipping.
Lay the groundwork for hardware clipping.

For glScissor() to replace CGraphicContext::ClipRect, a necessary condition
is that no shear or rotation is introduced between the coordinate systems
they use; this depends upon the settings of the GUI matrix m_finalTransform
as well as the OpenGL model-view and projection matrices. These all remain
unchanged between paired calls of CGUIShader::OnEnabled and
CGUIShader::OnDisabled, so we scan the matrices in CGUIShader::OnEnabled to
see whether hardware clipping is possible.

Then, in CGUIFontTTFBase::RenderCharacter, we don't apply software clipping
in such cases. However, because vertices arising from multiple
CGUIFontTTFBase::DrawTextInternal calls (each of which often uses a different
clip rectangle) get lumped into the same vector, which only at the end is
passed to OpenGL for rendering, we need to wait a few commits before we can
actually apply hardware clipping. In the meantime, expect to see rendering
errors.
Increase font cache hit rate by keying on the fractional part of m_originX and m_originY *after* they have been through the graphics context's transformation matrix, plus the scale/rotation elements of the matrix, rather than the origin in the original frame of reference plus the complete transformation matrix. All vertices of individual glyph bounding boxes are a constant offset from this position, and when the fractional part of the translation is a match, the rounding of each vertex will be in the same direction; this permits us to calculate the desired vertices from the cached ones simply by adding the integer parts of the translations with no additional rounding steps.

Note that this requires that software clipping is *not* performed.
Rewrite of scrolling text code.

No longer shuffles the string round to minimise the number of characters
before the clipping rectangle; this doesn't save much on rendering time but
does harm the effectiveness of the cache. Now uses a pixel offset into the
string rather than a character + pixel offset, and plots the entire string
every time (execpt when the wrap point is visible, in which case the entire
string is plotted twice).

It also makes motion smoother, because (possibly unintentionally) the
previous code preferred to align the scroll offset with character boundaries.
This would lead to uneven changes of position, especially when the width of
the character currently being scrolled off the edge was only slightly more
than an integral multiple of the scroll increment.
Move the application of the translation offsets into the GLES code.

Still all pure software at this stage. Main change is in the data types at
the interface between CGUIFontTTFBase and CGUIFontTTFGL. The old way
(array of vertices in m_vertex) are retained in addition, for the sake`of
cases that need to use software clipping on GLES, as well as for DX and GL
support where the new scheme is not (yet?) used.
Rather than applying the translation offsets to the vertices, now applies them to the model view matrix from the top of the matrix stack and pushes it over to OpenGL. The vertices themselves are still all held client-side.
Enable hardware clipping.
Move the vertex data across to a vertex buffer object just prior to drawing.
Move vertex data into an OpenGL VBO when the font cache entry is populated.

The font cache now stores the "name" (handle) of the VBO, rather than a vector
of vertices.
Switch from glDrawArrays() to glDrawElements().

This involves setting up a static VBO containing the indexes necessary to
convert from quads to triangles on the fly in the GPU.
Improved file buffering in CArchive

Even though memcpy is typically inlined by the compiler into byte/word loads
and stores (at least for release builds), the frequency with which 1, 2 and 4
byte loads/stores are encountered in cases where the size is *not*
determinable at compile time is still high enough that it's worth handling
these specially. On the ARM1176JZF-S in the Raspberry Pi, this improves the
total time to open a library (in the case where it's fetched from a CArchive)
by around 4%.

It should be noted that this code uses 16-bit and 32-bit word loads and
stores that are not necessarily aligned to their respective widths. It is
possible that there are some architectures out there which do not support
this, although all ARMs since ARMv6 have supported it (and ARMs earlier than
that are probably not powerful enough to be good targets for XBMC).
[mmal] Add MMAL decoder and MMAL renderer for Raspberry Pi

While omxplayer is the best performing player on the Pi (and the only option for raw Blu-Rays)
there are some reasons to use dvdplayer on a Pi:

DVDs with menus do not work well with omxplayer
support of software decode for SD codecs like divx3, msmpeg, sorenson spark etc
omxplayer doesn't support alsa, so can't be used with USB and I2S sound cards
dvdplayer may behave better with dodgy timestamps and packet loss, e.g. with live TV

So this PR adds hardware acceleration to dvdplayer using the MMAL api.

There is also a MMAL based video renderer. Compared to using GL, this:
saves the processing cost of YUV->RGB conversion
saves the memory cost of the RGB textures for video frames (1080p = 3MB for YUV and 8MB for RGB)
allows high quality (cubic) scaling
[mmal] Allow mmal codec for dvd stills