movdec: handle 0x7fff langcode as macintosh per the specs

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.

(cherry picked from commit 9e71cc81f3655cacf0f91860fba3043f13b64059)
(cherry picked from commit 7940306a47df602be4f57a62175706265bbfd0aa)
isom: lpcm in mov default to big endian

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>
(cherry picked from commit 360022bd3b894cc01ea112b275fa4c8f53881808)
(cherry picked from commit d37fac6dbbdddb76225aa691b83ffd9a0c7dae6b)
apedec: do not buffer decoded samples over AVPackets

Only consume an AVPacket when all the samples have been read.

When the rate of samples output is limited (by the default value
of max_samples), consuming the first packet immediately will cause
timing problems:

- The first packet with PTS 0 will output 4608 samples and be
consumed entirely
- The second packet with PTS 64 will output the remaining samples
(typically, a lot, that's why max_samples exist) until the decoded
samples of the first packet have been exhausted, at which point the
samples of the second packet will be decoded and output when
av_decode_frame is called with the next packet).

That means there's a PTS jump since the first packet is 'decoded'
immediately, which can be seen with avplay or mplayer: the timing
jumps immediately to 6.2s (which is the size of a packet).

Sample: http://streams.videolan.org/issues/6348/Goldwave-MAClib.ape

Bug-Debian: http://bugs.debian.org/744901
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>
(cherry picked from commit 91d4cfb8127f1de6c4ad173a30fffe584700046d)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
oggdec: add support for Opus in Ogg demuxing

Fixes: https://bugzilla.libav.org/show_bug.cgi?id=603
Fixes: http://bugs.debian.org/720563

(cherry picked from commit ecab1c77410f023b437c6ed3a3281be8f039e574)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
mp3enc: Properly write bitrate value in XING header

Instead of using a fixed bitrate_idx, calculate a matching bitrate for
the XING header.

Using a fixed bitrate_idx causes tools such as file(1) and mediainfo(1)
to report wrong bitrate and bitrate mode when using CBR.

Bug-Id: https://bugs.debian.org/736088

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
(cherry picked from commit 617a1a98a6be3e59db6fbfc21afab2fb9a049c03)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit 0f6e309b97e3da83a0fa75fbf1c4b50cd72047eb)
matroska: add the Opus mapping

(cherry picked from commit 141fdc763c2841b572d29a2ad78513e8d5325870)
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
(cherry picked from commit 79041d92ee7421853ee8c57fc13891cb0c272e0e)
swscale: Fix an undefined behaviour

Prevent a division by zero down the codepath.

Sample-Id: 00001721-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
(cherry picked from commit 3a177a9cca924e097265b32f9282814f6b653e08)
(cherry picked from commit 0499f7809c1fcc33ed710cdf771a18b374702135)