* commit '360022bd3b894cc01ea112b275fa4c8f53881808':
isom: lpcm in mov default to big endian
See: 8b3964ecd1bfc7ac65ae91013b404beb7d2c875a
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '073cd30fb4dc1c2a885c62540e3cfaac1f17c21b':
isom: Support MPEG-2 video mov files from FPC5
See: 0aded6bf028ff188e3bbd7eb023bd854b474b794
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'eeae858596a5ce5a84797283f590a16add5704f4':
isom: Support Sony XAVC in mov
See: 5b9f39860d83380c4af3039710b4fcf3ea1f4c99
See: 6e65e3483706d969d176909fae9e216919f59277
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ed06e5d92b4c67b49068d538461fbbe0a53a8c5e':
hevc: Do not turn 32bit timebases into negative numbers
Conflicts:
libavcodec/hevc.c
See: bf2ce19e51fde57727a4ee33a4b3c2622f37a5c4
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6cc94e971933cd38c452172bb048bf760e65cc3e':
hevc: use av_mallocz() for allocating tab_ipm
See: 0999f1613bc48ed9d6578a3ad7bcd17610e07fbf
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '920c01adce6c273fc043513ff237a6266e612152':
hevc: Use get_bits_long() in decode_vui()
See: b818637b84948e917d11c987f2270cea5b3fcfea
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
* commit 'c708b5403346255ea5adc776645616cc7c61f078':
timer: use mach_absolute_time as high resolution clock on darwin
Conflicts:
configure
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* cus/stable:
libzvbi-teletextdec: split dvb packet to slices
libzvbi-teletextdec: use av_dlog where possible
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
build: Use pkg-config for openjpeg
Conflicts:
configure
Not merged / merge just for metadata at request of carl
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '565e0c6d866ce08d4b06427456d3d1f4fd856e9c':
movenc: allow override of "writing application" tag
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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().
Instead of using the demux function of libzvbi to split the packet to slices
(vbi lines), lets do it ourselves.
- eliminates the 1 frame delay between page input and output
- handles non-ascending line numbers more gracefully
- enables us to return error codes on some invalid packets instead of silently
ignoring them
Signed-off-by: Marton Balint <cus@passwd.hu>
The overread avoidance fix in cbddee1cca0ebd01e8c5aa694d31228eb4de4b41
broke the computation for the last row since it prevented the safe
reading from the height+1-th row.
CC: libav-stable@libav.org
