By default libav sets it to 3/4 while x264 sets it to 9/10.

CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

rc_buffer_size is not set before.

Solve the initial the rate control underflow issue reported in
bug 222.

CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

The function is a callback that is called by ff_gen_search with
a constant stream index.

Avoid a false positive on older gcc version.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

These warnings have no false positives and point to serious bugs.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

It's been returning an error value since
bad446e2

Also check for the errors it returns.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

The floating point version of av_clip has to be used when
converting the quality level.
Signed-off-by: Maximilian Seesslen <mes@seesslen.net>
Signed-off-by: Martin Storsjö <martin@martin.st>

Pass the correct header size to ff_vorbis_comment()
Signed-off-by: Martin Storsjö <martin@martin.st>

Clobbering these tables will temporarily clobber the template used
as a basis for other threads to start decoding from. If the other
decoding thread updates from the template right at that moment,
subsequent threads will get invalid (or, usually, none at all) mmco
tables. This leads to invalid reference lists and subsequent decode
failures.

Therefore, instead, decode the mmco tables only for the first slice in
a field or frame. For other slices, decode the bits and ensure they
are identical to the mmco tables in the first slice, but don't ever
clobber the context state. This prevents other threads from using a
clobbered/invalid template as starting point for decoding, and thus
fixes decoding in these cases.

This fixes occasional (~1%) failures of h264-conformance-mr1_bt_a with
frame-multithreading enabled.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Support older libvpx versions.

This feature is experimental use at your risk

This makes the behaviour defined when they wrap around. The value
assigned to expected_prior was a uint32_t already.
Signed-off-by: Martin Storsjö <martin@martin.st>

Without this, we'd signal a huge loss rate (due to unsigned
wraparound) if we had received one packet more than expected (that
is, one seq number sent twice). The code has a check for lost_interval
<= 0, but that doesn't do what was intended as long as the variable is
unsigned.
Signed-off-by: Martin Storsjö <martin@martin.st>

By using a pointer-to-pointer, we avoid having to keep track
of the previous packet separately.
Signed-off-by: Martin Storsjö <martin@martin.st>

The code below the comment does not at all relate to statistics,
and even if moved to the right place, the comment adds little
value.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Fixes null pointer dereference later, since if this function failed,
a positive return value was returned to the caller.

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Martin Storsjö <martin@martin.st>