[release] bump version to 12.3
fix crash loading JPEGs where m_cinfo.scale_num was set to 9 due to not finding a suitably sized scale factor. Thanks to tscheck
[osx/sdl] - fix possible NPE - fixes #14676
- fix crashing with libnfs 1.6 by bumping to 1.6.1 (which is 1.6.0 + a compile fix - 32bit time_t define was missing in the release target of vs project for libnfs)
[darwin] - move isMavericks helper to DarwinUtils
[osx/mavericks] - on mavericks don't use pbo rendering with intel gpus as it might result in distorted rendering (ripple)
Merge pull request #3820 from Memphiz/Frodo

[osx/mavericks] fix rippled rendering with intel gpu
Merge pull request #3821 from MartijnKaijser/12.3

[release] bump version to 12.3
[rbp/buildsystem] changed set USE_TEXTUREPACKER_NATIVE_ROOT in the build environment
Add VFP-accelerated version of synth_filter_float(), used by DTS Coherent Acoustics decoder
1st version of ff_int32_to_float_fmul_scalar_vfp
2nd version of fmul_scalar
Add VFP-accelerated version of imdct_half
Add VFP_accelerated version of dca_lfe_fir
Add VFP-accelerated version of fft16
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 - 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