json-rpc: don't try to set playcount/lastplayed for tvshows
json-rpc: fix resetting a datetime property through VideoLibrary.SetFooDetails
[omxplayer] When setting fullscreen flag we don't want noaspect

We set the fullscreen on 3d videos to avoid scaling breaking the 3d affect.
However we also set the noaspect flag which means widescreen videos (e.g. 1920x800) will get stretched vertically which is unwanted.
[thumbs] don't use a separate class instance in CProgramThumbLoader::FillThumb
[thumbs] don't set an empty thumb in C(Video|Music)ThumbLoader::FillThumb. Fixes #15007.
Merge pull request #4404 from popcornmix/3daspect

[omxplayer] When setting fullscreen flag we don't want noaspect
[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] Add fixed latency mode for live streams
[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] When opening a stream don't try to update gui so often

The 1ms sleep allows for up to 1000 fps gui overlay update, which when busy when opening a file is a bad idea.
Increase the sleep so it only tries to update at up to 10 times per second
More efficient infobool expression evaluator

Expession infobools are evaluated at runtime from one or more single infobools
and a combination of boolean NOT, AND and OR operators. Previously, parsing
produced a vector of operands (leaf nodes) and operators in postfix
(reverse-Polish) form, and evaluated all leaf nodes every time the expression
was evaluated. But this ignores the fact that in many cases, once one operand
of an AND or OR operation has been evaluated, there is no need to evaluate the
other operand because its value can have no effect on the ultimate result. It
is also worth noting that AND and OR operations are associative, meaning they
can be rearranged at runtime to better suit the selected skin.

This patch rewrites the expression parsing and evaluation code. Now the
internal repreentation is in the form of a tree where leaf nodes represent a
single infobool, and branch nodes represent either an AND or an OR operation
on two or more child nodes.

Expressions are rewritten at parse time into a form which favours the
formation of groups of associative nodes. These groups are then reordered at
evaluation time such that nodes whose value renders the evaluation of the
remainder of the group unnecessary tend to be evaluated first (these are
true nodes for OR subexpressions, or false nodes for AND subexpressions).
The end effect is to minimise the number of leaf nodes that need to be
evaluated in order to determine the value of the expression. The runtime
adaptability has the advantage of not being customised for any particular skin.

The modifications to the expression at parse time fall into two groups:
1) Moving logical NOTs so that they are only applied to leaf nodes.
   For example, rewriting ![A+B]|C as !A|!B|C allows reordering such that
   any of the three leaves can be evaluated first.
2) Combining adjacent AND or OR operations such that each path from the root
   to a leaf encounters a strictly alternating pattern of AND and OR
   operations. So [A|B]|[C|D+[[E|F]|G] becomes A|B|C|[D+[E|F|G]].

I measured the effect while the Videos window of the default skin was open
(but idle) on a Raspberry Pi, and this reduced the CPU usage by 2.8% from
41.9% to 39.1%:

          Before          After
          Mean   StdDev   Mean   StdDev  Confidence  Change
IdleCPU%  41.9   0.5      39.1   0.9     100.0%      +7.0%
Add caching of infolabels

The functions CGUIInfoLabel::GetLabel and CGUIInfoLabel::GetItemLabel take
a number of strings returned from CGUIInfoManager::GetImage or
CGUIInfoManager::GetLabel, and combine them with various constant strings
which were determined during CGUIInfoLabel::Parse.

Rather than perform all the string operations on every call, this patch
changes to use a two-pass process: first it queries all the GetImage/GetLabel
strings, and then only if at least one of them has changed does it bother
rebuilding the resultant string - otherwise it re-uses the copy built on a
preceding call.

CGUIInfoLabel::GetLabel/GetItemLabel are also changed to return string
references, rather than forcing an additional string copy.

I have measured the effect while the Videos window of the default skin was
open (but idle) on a Raspberry Pi, and this reduced the CPU usage by 0.8%
from 36.2% to 35.4%:

          Before          After
          Mean   StdDev   Mean   StdDev  Confidence  Change
IdleCPU%  36.2   0.5      35.4   0.5     99.9%       +2.2%
De-duplication of string cache for non-item and item labels
Faster and simpler portable implementation of MathUtils::round_int().

Much as I like a bit of inline assembler, I have also removed the ARM versions
of MathUtils::truncate_int() and MathUtils::round_int(). The former was just
how any sane compiler should have assembled a cast from double to signed int
anyway. The latter was a much too complicated way to achieve the desired
effect, and was switched out in most ARM builds anyway in favour of the old
portable implementation that used floor().

Verified that MathUtils::test() still passes, and that GCC is now able to
inline MathUtils::round_int(), where it didn't previously.

I tested on a Raspberry Pi with the default theme, displaying the front page
with the RSS ticker enabled. This saturates the CPU, so I'm measuring the
improvement using the debug window's FPS figure. This patch improves this from
~50.8 FPS to ~52.6 FPS.