* commit '18f9308e':
  mpjpeg: Cope with multipart lacking the initial CRLF
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '22f4d9c3':
  img2enc: Make sure the images are atomically written
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '1ec72c6c':
  libx264: Make sure the extradata are padded
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit '5ea5a24e':
  movenc: Honor flush requests with delay_moov, when some tracks lack samples
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit 'e02dcdf6':
  rtsp: Allow $ as interleaved packet indicator before a complete response header
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

* commit 'dca23ffb':
  lavc: Deprecate AVPicture structure and related functions

Deprecation flag on AVPicture struct replaced by a comment, as it causes
excess deprecation warnings for every include of avcodec.h
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Reviewed-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: AppChecker <support.appc@cnpo.ru>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

HWAccels with frame threads are fundamentally flawed in avcodecs current
design, and there are several known problems ranging from image corruption
to driver crashes.

These problems come down to two design problems in the interaction of
threads and HWAccel decoding:

(1)
While avcodec prevents parallel decoding and as such simultaneous access
to the hardware accelerator from the decoding threads, it cannot account
for the user code and its access to the hardware surfaces and the hardware
itself.

This can result in image corruption or even driver crashes if the
user code locks image surfaces while they are being used by the decoder
threads as reference frames.

The current HWAccel API does not offer any way to ensure exclusive access
to the hardware or the surfaces if frame threading is used.

(2)
Initialization of the HWAccel with frame threads is non-trivial, and many
decoders had and still have issues that cause excess calls to the
get_format callback.

This will potentially cause duplicate HWAccel initialization, which in
extreme cases can even lead to driver crashes if the HWAccel is
re-initialized while the user code is actively accessing the hardware
surfaces associated with it, or lead to image corruption due to lost
reference frames.

While both of these issues are solvable, fixing (1) would at least require
a huge API redesign which would move a lot of complexity into the user
code.

The only reason the combination of frame threads and HWAccel was
considered useful is to allow a seamless fallback to multi-threaded
software decoding if the HWAccel is not available, however the issues
outlined above far outweigh this.

The proper solution for a fallback is to re-open the AVCodecContext with
threading enabled if the HWAccel failed, which is a practice commonly used
by various user applications using avcodec today already.
Reviewed-by: Gwenole Beauchesne <gb.devel@gmail.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>

Clang prerelease on Darwin is making the test fail.

Found-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

They barely fail on some systems by being off by 0.81.

Fixes crashes on fuzzed files
Fixes Ticket4969 part2
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes crash
Fixes Ticket4969 part 1
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Kyle Swanson <k@ylo.ph>

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

The Apple dev specification:
    https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/Metadata/Metadata.html

Basically the structure is like:
    |--meta
    |----hdlr
    |----keys
    |----ilst

1) The handler type in the metadata handler atom is ‘mdta’.
2) The key and value are stored separately for each key-value pair.
   The 'keys' atom stores the key table, while 'ilst' atom stores the
   values corresponding to the indices in the key table.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Instead just warn, and use the parse fps normally.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

This fixes a fate failure after bumping the minor version
Its unknown why this is not needed for the other aac tests,
more investigation needed but for now i dont want to leave
it broken while its investigated
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

filter_slice calls qsort, so qsort is in a performance critical
position. AV_QSORT is substantially faster due to the inlining of the
comparison callback. Thus, the increase in performance is worth the
increase in binary size.

Sample benchmark (x86-64, Haswell, GNU/Linux),
filter-removegrain-mode-02 (from FATE)
new:
  24060 decicycles in qsort,       1 runs,      0 skips
  15690 decicycles in qsort,       2 runs,      0 skips
   9307 decicycles in qsort,       4 runs,      0 skips
   5572 decicycles in qsort,       8 runs,      0 skips
   3485 decicycles in qsort,      16 runs,      0 skips
   2517 decicycles in qsort,      32 runs,      0 skips
   1979 decicycles in qsort,      64 runs,      0 skips
   1911 decicycles in qsort,     128 runs,      0 skips
   1568 decicycles in qsort,     256 runs,      0 skips
   1596 decicycles in qsort,     512 runs,      0 skips
   1614 decicycles in qsort,    1024 runs,      0 skips
   1874 decicycles in qsort,    2046 runs,      2 skips
   2186 decicycles in qsort,    4094 runs,      2 skips

old:
 246960 decicycles in qsort,       1 runs,      0 skips
 135765 decicycles in qsort,       2 runs,      0 skips
  70920 decicycles in qsort,       4 runs,      0 skips
  37710 decicycles in qsort,       8 runs,      0 skips
  20831 decicycles in qsort,      16 runs,      0 skips
  12225 decicycles in qsort,      32 runs,      0 skips
   8083 decicycles in qsort,      64 runs,      0 skips
   6270 decicycles in qsort,     128 runs,      0 skips
   5321 decicycles in qsort,     256 runs,      0 skips
   4860 decicycles in qsort,     512 runs,      0 skips
   4424 decicycles in qsort,    1024 runs,      0 skips
   4191 decicycles in qsort,    2046 runs,      2 skips
   4934 decicycles in qsort,    4094 runs,      2 skips
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

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

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

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Example:
% ./ffmpeg -h encoder=gif
[...]
GIF encoder AVOptions:
  -gifflags          <flags>      E..V.... set GIF flags (default offsetting+transdiff)
     offsetting                   E..V.... enable picture offsetting
     transdiff                    E..V.... enable transparency detection between frames

Commit 7c8fcbbd introduced some warnings
that get triggered on the test build. This should fix them.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Fixes ticket #4963.

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

ff_huff_build_tree uses qsort underneath. AV_QSORT is substantially
faster due to the inlining of the comparison callback. Furthermore, this
code is reasonably performance critical, since in e.g the fraps codec,
ff_huff_build_tree is called on every frame. This routine is also called
in vp6 on every frame in some circumstances.

Sample benchmark (x86-64, Haswell, GNU/Linux), vp6 from FATE:
vp6 (old):
  78930 decicycles in qsort,       1 runs,      0 skips
  45330 decicycles in qsort,       2 runs,      0 skips
  27825 decicycles in qsort,       4 runs,      0 skips
  17471 decicycles in qsort,       8 runs,      0 skips
  12296 decicycles in qsort,      16 runs,      0 skips
   9554 decicycles in qsort,      32 runs,      0 skips
   8404 decicycles in qsort,      64 runs,      0 skips
   7405 decicycles in qsort,     128 runs,      0 skips
   6740 decicycles in qsort,     256 runs,      0 skips
   7540 decicycles in qsort,     512 runs,      0 skips
   9498 decicycles in qsort,    1024 runs,      0 skips
   9938 decicycles in qsort,    2048 runs,      0 skips
   8043 decicycles in qsort,    4095 runs,      1 skips

vp6 (new):
  15880 decicycles in qsort,       1 runs,      0 skips
  10730 decicycles in qsort,       2 runs,      0 skips
  10155 decicycles in qsort,       4 runs,      0 skips
   7805 decicycles in qsort,       8 runs,      0 skips
   6883 decicycles in qsort,      16 runs,      0 skips
   6305 decicycles in qsort,      32 runs,      0 skips
   5854 decicycles in qsort,      64 runs,      0 skips
   5152 decicycles in qsort,     128 runs,      0 skips
   4452 decicycles in qsort,     256 runs,      0 skips
   4161 decicycles in qsort,     511 runs,      1 skips
   4081 decicycles in qsort,    1023 runs,      1 skips
   4072 decicycles in qsort,    2047 runs,      1 skips
   4004 decicycles in qsort,    4095 runs,      1 skips
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

This adds const-correctness when needed for the comparators.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>

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