Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Fixes Ticket5618
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Fixes failures with yasm 1.1.0 and older
Signed-off-by: James Almer <jamrial@gmail.com>

Old yasm/nasm versions don't support some of these
Signed-off-by: James Almer <jamrial@gmail.com>

All HE-AAC samples with an LFE channel make this warning get spammed on
every frame. Turning off SBR for LFE channels makes sense (since it has
much less coefficients than normal channels do), so this error print is
of no value in this case.
It makes sense to keep the error in other cases, hence why it's still
around, degraded to warning severity since the decoder will still
attempt to decode without SBR.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

fix error 'Channel layout change is not supported' when
opening wav file
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

see Ticket #5618
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes assertion failure
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

on x86_64:
        time    PSNR
plain   3.303   inf
SSE     1.649   107.087535
SSE3    1.632   107.087535
AVX     1.409   106.986771
FMA3    1.265   107.108437

on x86_32 (PSNR compared to x86_64 plain):
        time    PSNR
plain   7.225   103.951979
SSE     1.827   105.859282
SSE3    1.819   105.859282
AVX     1.533   105.997661
FMA3    1.384   105.885377

FMA4 test is not available
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Mkvtoolnix stores the sample rate of the original stream as reported by the
"OpusHead" stream header instead of 48kHz, the actual sample rate of the Opus
stream.
Ignoring the stored sample rate and forcing 48kHz preserves the correct initial
padding when remuxing such files.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes fate-h264-xavc-4389 with slice threads

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

No testcase known
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Use "colors" option instead.
Signed-off-by: Lou Logan <lou@lrcd.com>

Fixes Ticket5566
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The framerate is 25 which is a fixed default and is wrong undo the 1 line
change which caused this regression
Only the avg_frame rate setting is removed
The timebase update is not done as there was a objection (see ML)
Fixes Ticket 5444
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Codec width/height restrictions seem hardcoded at the OMX level and
seem arbitrary. Bypassing those restrictions allows a device to decode
streams at higher resolutions.

For example it allows a Nexus 5 to decode h264 streams with a resolution
higher than 1920x1080.

Fixes Ticket5528
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

simply by substracting pts to compensate delay
also handle AV_NOPTS_VALUE
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Fixes: Ticket5526

Tested-by: kgp700
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>