The functions are all private.

Fixes Ticket 5187

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

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

Silences: CID1351343

The header is calculated by the code above the changed hunk, it is
thus asserted that the header is always correct.
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Otherwise the 'lcov -q --remove' run fails with the following error:
lcov: ERROR: cannot write to coverage.info!
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

When out-of-tree builds now use a relative path, the '-b' option of lcov
is not needed, so just pass the current directory to it in this case.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Or when building in-tree.
Also don't try to remove src on distclean in these cases.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

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

Up to ~4 times faster on x86_64, ~8 times on x86_32 if compiling using x87 fp math.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

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

clang needs HAVE_MMX to be first in order to avoid an undefined
reference error.

Using rNm and x86inc's stack allocation with a negative value at the same
time isn't supported, and caused the original stack pointer to be clobbered
when using a compiler that doesn't support stack alignment.

This can provide a manual workaround for ticket #4230.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>

Checked compatiblity with VLC, Windows Media Player 12 and Windows Media ASF
Viewer 9 series.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>

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

2.6 times faster (366 vs. 142 cycles)

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

Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

The next frame time could slip, causing the frame rate to drop until
 frames were dropped. Now will capture at the next correct moment instead.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Fixes: CID1341581, CID1341582
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

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

Defined by the MP4 registration authority.
Fixes ticket #5217.

This fixes a null pointer dereferece
Fixes: CID1351346
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The parser only parses the core, and thus has a duration relative
to the core sample rate only, not the actual stream sample rate.

FATE references changed due to now correct timestamps.

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

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

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

Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

This was causing c99conv to crash.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

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