[ffmpeg] - backport - mpegts: Remove one 64-bit integer modulus operation per packet

The common case of the pointer having increased by one packet (which results
in no change to the modulus) can be detected with a 64-bit subtraction,
which is far cheaper than a division on many platforms.

           Before          After
           Mean   StdDev   Mean   StdDev  Change
Divisions   248.3  8.8      51.5   7.4    +381.7%
Overall    2773.2 25.6     2372.5 43.1     +16.9%

Signed-off-by: Martin Storsjö <martin@martin.st>
Speed improvement for opening the movies library

On all but the first time of opening the movies library, the CFileItemList
is built using CArchive. A large proportion of the time taken to do this is
actually spent in CVideoInfoTag::Archive() where it calls
CScraperUrl::Parse() and CFanart::Unpack(). Unless I've overlooked something,
these calls are unnecessary - the XML parsing they do is not performed the
first time the movies library is opened (when instead the virtual directory
videodb://movies/titles/ is enumerated using a database query). Also, the
Parse() method is called again when you do something like open the Movie
Information window, irrespective of whether it was called when the library
was opened.

Also note, it is unusual for any implementation of IArchivable::Archive() to
do anything other than read or write a data member from/to a CArchive, so
these calls to Parse() and Unpack() feel like an anomaly.

Additionally, inserted a call to std::vector::reserve() before reading the
cast list, because it was an obvious speed win.

Here are some benchmarks for the function CGUIMediaWindow::GetDirectory()
on a library of 600 movies, running on a Raspberry Pi:
* First call (before or after):    3.4 seconds
* Subsequent calls (before patch): 7.3 seconds
* Subsequent calls (after patch):  2.9 seconds
Speedup for opening music song library

Previously, this repeatedly parsed the same URL string over and over again
for every song, each time the list of songs was opened.

Benchmarks for CMusicDatabase::GetSongsByWhere() on a Raspberry Pi with a
library of 4115 songs:

Before patch: 14.5 seconds
After patch:   4.0 seconds
Faster sorting of CFileItemLists, step 1

CFileItemLists are sorted by first construcing a SortItems object that refers
back to each CFileItem by index, sorting the SortItems object, then rebuilding
CSortItemList::m_items (a vector of pointers to CFileItems) by examination of
the sorted version of the SortItems object.

It might be more sensible, long-term, to sort m_items directly, but in the
meantime, there are a couple of simple ways to make sorting with SortItems
sufficiently efficient that it's not a problem any more.

Previously, SortItems was a vector of SortItem objects, held by value; each
SortItem was a std::map (implemented as a red-black tree) which ended up
being constructed and destructed as each element of SortItems was moved.
This patch changes SortItems to be a vector of pointers to SortItems instead.

Benchmarks for CFileItemList::Sort() on a Raspberry Pi with a library of
600 movies:
Before patch: 4.6 seconds
After patch:  1.1 seconds
Faster sorting of CFileItemLists, step 2

Each time a CFileItemList is sorted, multiple SortItem objects are
constructed and destructed. Each object is a std::map ,implemented as a
red-black tree with one node for each attribute (Field) upon which the
CFileItemList could conceivably have been sorted, even though for any given
SortBy, very few attributes are actually examined by SortUtils::Sort(). Worse
still, many of those nodes involve creating an associated fresh copy of a
string, with all the associated heap thrashing that entails.

This patch changes the various ToSortable methods to limit the number of
items in each SortItem's std::map to those actually required for performing
the chosen sort.

Benchmarks for CFileItemList::Sort() on a Raspberry Pi with a library of
600 movies:
Before patch: 1.1 seconds
After patch:  0.36 seconds
Two extra fields now always inserted when SortItems are initialised

These are FieldSortSpecial (used to force certain items like ".." to the
top or the bottom of the list) and FieldFolder (used to ensure folders are
separated from files). These are required in addition to whatever the
primary sort variable is.

Obviously this will impact the speedup of the rest of the patch, but since
neither are string fields, this should be minimal.
SortUtils: fix possible crash when sorting by season
[rbp] Avoid overflow in version string

gedit complains about invalid characters when opening xbmc.log file produced by pi
Since the change from perforce revision number to git hash, the version string has increased in size.

Fortunately we don't overrun the "response" buffer.
Unfortunately when buffer doesn't fit, it is not null terminated, so logging message pulls in garbage.

Version string looks like:
Jun 17 2013 20:49:11
Copyright (c) 2012 Broadcom
version d380dde43fe729f043befb5cf775f99e54586cde (clean) (release)

So, 80 characters is not enough (it is about 115 plus newlines).
160 seems more than enough, but truncate the string just in case.
[players] Don't bump volume to maximum after trickplay
[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] Check total memory, and if plenty use full size buffers

Part 1: Support
omxplayer has used a quarter sized video buffer and a half sized audio buffer for the file reading message queue, compared to dvdplayer.
This is required on 256M boards, but is unneccessary on 512M board. So we query the memory size and use full size buffers if possible.
[rbp] Add screenshot implementation that includes video layer

As Pi doesn't use GL for video, a screenshot only contains UI.
Need to use Pi specific function for screenshot.
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] Fix for hang following seek after eos

If you seek after the demuxer eof, the eof state is cleared, but we are not clearing the flags relating to sending eos stream to audio/video players
[rbp/omxplayer] Make m_omx_render an object rather than pointer

Seems no reason for it not to be like other components, as it makes merging with command line omxplayer more difficult
[rbp/omxplayer] Make sure swr resampler gets reinited when channel count changes

Just like #2795.
[rbp/omxplayer] Remove commented out code
[rbp/omxplayer] Move openmax pipeline creation into portsettingschanged code

OpenMAX setup becomes more straightforward when components and tunnels are initialised after the first portsettingschanged message.
You get one of these after the first frame is decoded (and also when settings change, like resolution).
Doing the setup here means you know useful information about the stream, like the resolution and you avoid having to disable/enable multiple ports.

It will also make creating a pipline with the deinterlace component possible *after* the decoder has identified if stream is interlaced
[rbp/omxplayer] Support automatic deinterlace correctly.

Previously there was no distinction between deinterlace being automatic and force on.
Both did a hack parse that only worked (sometimes) for h264. Other codecs would always force on.

This change now handles the three modes correctly. Off and force on do as expected.
Automatic now queries the openmax video codec, which can reliably determine if a stream is interlaced
[rbp/omxplayer] Remove unused variable m_pTempOverlayPicture