Fixes out of array read
Fixes: test_case-mdc.264 (b47be15a120979f5a1a945c938cbef33)
Found-by: Tyson Smith <twsmith@mozilla.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

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

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

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

It serves absolutely no purpose other than to confuse potentional
Android developers about how to use hardware acceleration properly
on the the platform. The stagefright "API" is not public, and the
MediaCodec API is the proper way to do this.

Furthermore, stagefright support in avcodec needs a series of
magic incantations and version-specific stuff, such that
using it actually provides downsides compared just using the actual
Android frameworks properly, in that it is a lot more work and confusion
to get it even running. It also leads to a lot of misinformation, like
these sorts of comments (in [1]) that are absolutely incorrect.

[1] http://stackoverflow.com/a/29362353/3115956Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

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

This corrects the codec_tag for some SVQ3 files
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

sqrt is faster, and is sometimes more accurate depending on the libm.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

avio_closep is not guaranteed to succeed, and its return value can
contain information regarding failure of preceding writes and silent
loss of data (man 2 close, man fclose). Users should know when the
progress was not successfully logged, and so a diagnostic is printed
here.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

The previous check only caught sizes from -AV_INPUT_BUFFER_PADDING_SIZE
to -1.

This fixes ubsan runtime error: signed integer overflow: 2147483647 + 32
cannot be represented in type 'int'
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Otherwise this can have some surprising effects (crashes), so let's
better not allow it.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Analyzed by Timothy B. Terriberry in Mozilla bug 1227153.
Fixes ticket #5121.

Fixes out of array read
Found-by: Tyson Smith <twsmith@mozilla.com>
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>

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

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

Fixes potential out of array read

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

Fixes out of array read

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

This gets rid of some branches to speed up table generation slightly
(impact higher on mulaw than alaw). Tables are identical to before,
tested with FATE.

Sample benchmark (Haswell, GNU/Linux+gcc):
old:
 313494 decicycles in build_alaw_table,    4094 runs,      2 skips
 315959 decicycles in build_alaw_table,    8190 runs,      2 skips

 323599 decicycles in build_ulaw_table,    4095 runs,      1 skips
 318849 decicycles in build_ulaw_table,    8188 runs,      4 skips

new:
 261902 decicycles in build_alaw_table,    4096 runs,      0 skips
 266519 decicycles in build_alaw_table,    8192 runs,      0 skips

 209657 decicycles in build_ulaw_table,    4096 runs,      0 skips
 232656 decicycles in build_ulaw_table,    8192 runs,      0 skips
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Fixes mozilla bug 1230423
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

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

Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

This fixes NULL pointer dereferencing if the codec is forced to
adpcm_thp even though a different one was detected.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

This fixes NULL pointer dereferencing.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

This causes non-unique elements in floor_setup->data.t1.list, which
makes the stream undecodable according to the specification.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

* commit '2080bea4':
  h264_refs: Remove broken trace debug code
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '58170b02':
  lavc: Add missing #includes for ff_dlog()
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '3b6473b4':
  qsvdec: properly handle the warning from MFXVideoCORE_SyncOperation
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit 'a43905f4':
  qsvenc_hevc: improve the default settings
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '9d740127':
  h264: improve behaviour with invalid reference lists

Not merged, as we have a different solution.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

The QuickTime File Format Specification states the following:

"Depth: A 16-bit integer that indicates the pixel depth of the
compressed image. Values of 1, 2, 4, 8 ,16, 24, and 32 indicate the
depth of color images. The value 32 should be used only if the image
contains an alpha channel. Values of 34, 36, and 40 indicate 2-, 4-, and
8-bit grayscale, respectively, for grayscale images."

There is no mention of value 33, i.e. 1-bit video (0x01) with the
greyscale bit (0x20) set. I therefore suggest that we ignore the
greyscale bit when processing 1-bit video. Another reason to do this is
that the first 1-bit sample file below will be displayed properly with
blue colors in QuickTime in Windows or Mac *in spite of* the greyscale
bit being set.

Also, QuickTime in Windows or Mac ignores the greyscale bit if the
video sample description contains a palette, regardless of bit depth.
This is undocumented behaviour, but I think we should do the same, and
it seems pretty logical after all, since one wouldn't really bother
putting a customized palette into a grayscale file anyway. See the
second 8-bit sample file below, which has the greyscale bit set, and
which contains a palette in the video sample description. In Windows or
Mac, it will be displayed with the palette in the sample description, in
spite of the greyscale bit being set.

Sample file 1 (1-bit QuickTime Animation):
https://drive.google.com/open?id=0B3_pEBoLs0faTThSek1EeXQ0ZHM
Earth Spin 1-bit qtrle orig.mov

Sample file 2 (8-bit QuickTime Animation):
https://drive.google.com/open?id=0B3_pEBoLs0fad2s0V1YzUWo5aDA
quiz-palette+gs.mov
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This commit fixes the lack of palettized display of 1-bit video
in the qtrle decoder. It is related to my commit of
lavf/qtpalette, which added 1-bit video to the "palettized video"
category. As far as I can see, everything works fine, but comments are
of course welcome.

Below are links to sample files, which should now be displayed properly
with bluish colors, but which were previously displayed in black &
white.

Matroska:
https://drive.google.com/open?id=0B3_pEBoLs0faNjI0cHBMWDhYY2c
Earth Spin 1-bit qtrle.mkv

QuickTime (mov):
https://drive.google.com/open?id=0B3_pEBoLs0faUlItWm9KaGJSTEE
Earth Spin 1-bit qtrle.mov
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This fixes a regression of the sample from Ticket 2371
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>