The MSVCRT version of strftime calls the invalid parameter handler
if the struct values in struct tm are invalid. In case no invalid
parameter handler is set for the process, the process is aborted.

This fixes fate failures on MSVC builds since 570af382.

Based on a patch by Hendrik Leppkes.
Signed-off-by: Martin Storsjö <martin@martin.st>

'hvc1' requires that parameter set NAL units be
present only in the samples entry, but not in the
samples themselves, requiring that additional
parameter sets, if present, be filtered out of the
samples and placed in new, additional sample entries
if they override or otherwise conflict with the
parameter sets present in the first sample entry.
We do not have any way of doing this at present, so
the files we produce can only comply with the
restrictions set for the 'hev1' sample entry name in
ISO/IEC 14496-15.

Samples can be made from mencoder and jp2avi.dll codec.

The correct point that seperates ISO and MAC language codes is 0x400
according to the current QT spec. Old QT specs did not list where this
seperation is but apparently only defined the meaning of the first 137.

It is my understanding that "Unless otherwise stated, all data in a
QuickTime movie is stored in big-endian byte ordering" [1] in MOV files.

I have a couple of thousand files, which technically are invalid because
their sound sample description element 4CC is 'lpcm' but its version is
0 - and "Version 0 supports only uncompressed audio in raw ('raw ') or
twos-complement ('twos') format" [2]

Because isom.c only contains a mapping for 4CC 'lpcm' to
AV_CODEC_ID_PCM_S16LE, these files have their audio decoded as LE when
it is actually BE.

This commit adds AV_CODEC_ID_PCM_S16BE as the first match for 4CC 'lpcm'.

[1]
https://developer.apple.com/library/mac/documentation/quicktime/QTFF/qtff.pdf
page 21
[2]
https://developer.apple.com/library/mac/documentation/quicktime/QTFF/qtff.pdf
page 178
Reviewed-by: Yusuke Nakamura <muken.the.vfrmaniac@gmail.com>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Someone needs to binary search FCP for new isom...

Fixes integer overflow and out of array accesses.
Found-by: Mateusz j00ru Jurczyk and Gynvael Coldwind

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind

Fixes use of uninitialized memory and out of stack array read.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind

Fix assertion failure.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind

Not guaranteed to be in nanosecond resolution. On iOS 7 the duration
of one tick is 125/3 ns which is still more than an order of magnitude
better then microseconds.

Replace decicycles with the neutral UNITS. Decicycles is strange but
tenths of a nanosecond and unspecific "deci"-ticks for mach_absolute_time
is just silly.

Based on the aarch64 asm. CPU cycle counts on cortex-a9 compared to
gcc 4.8.2:
before: 475 decicycles in get_cabac_noinline, 67106035 runs, 2829 skips
after:  393 decicycles in get_cabac_noinline, 67106474 runs, 2390 skips

Overall speedup is above 2%. Code generated by clang 3.4 is slower on
the same hardware and the relative change is a little larger.

Based on the x86 branchless get_cabac asm. get_cabac_noinline() gets
approximately 20% faster (no cycle counts available) compared to clang
from Xcode 5.1 beta5. More than 6% faster overall. A part of the overall
speedup might be explained by additional inlining of get_cabac().

Was missed in aeaf268e when integrating
clear_blocks into the idct.

Bug-Id: 387
CC: libav-stable@libav.org

Signed-off-by: Tim Walker <tdskywalker@gmail.com>

CC: libav-stable@libav.org

Signed-off-by: Tim Walker <tdskywalker@gmail.com>

CC: libav-stable@libav.org

The overread avoidance fix in cbddee1c
broke the computation for the last row since it prevented the safe
reading from the height+1-th row.

CC: libav-stable@libav.org

Also sort #includes into canonical order.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Also sort #includes into canonical order.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Based on a suggestion by Martin Panter. This is more descriptive,
since it's the actual timestamp field from the RTMP packet,
which might or might not be a delta depending on context (in
some packets it's a delta, in some packets it's an absolute
timestamp, and in some packets it's 0xffffff to indicate that
the actual delta or absolute timestamp is transmitted separately).
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>