Passing a cutoff value < sample_rate/256 will cause a crash.
Also, values >20000 will have no effect and 20000 will be used anyway.
Signed-off-by: Mohammad Alsaleh <msal@tormail.org>
Signed-off-by: Martin Storsjö <martin@martin.st>
Even if linking directly to getaddrinfo, use our version of
gai_strerror instead of the system's version. Microsoft explicitly
documents that their version of gai_strerror is thread-unsafe.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids warnings if there already exists a definition.
This is the case on windows, where the getaddrinfo isn't available
and linked to (and we use our fallbacks instead, which actually
try to use the proper getaddrinfo version if found at runtime),
but gai_strerror still exists as a define.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is useful if a proper getaddrinfo is loaded dynamically on
windows, while using the fallback implementation of gai_strerror.
Signed-off-by: Martin Storsjö <martin@martin.st>
The actual result of the check isn't used anywhere (since we
use this function unconditionally within #ifdef _WIN32), but it
makes sure we explicitly link to shell32 (which is linked in
implictly on mingw).
Signed-off-by: Martin Storsjö <martin@martin.st>
This was unnoticed on linux, since stdlib.h apparently includes
files declaring the pthread_mutex_t and pthread_cond_t types.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This function is only available in the headers if unconditionally
targeting a version >= XP. It is not strictly necessary, since we
try loading these functions dynamically at runtime on windows in
the fallback, but this makes things a bit faster and more
straightforward.
On mingw32, this function isn't visible by default, while it is
on mingw64 (on both 32 and 64 bit).
Signed-off-by: Martin Storsjö <martin@martin.st>
Testing gives 25-30% gain on HD clips with two threads and
up to 50% gain with eight threads.
Sliced threading uses more memory than single or frame threading.
Frame threading and single threading keep the previous memory
layout.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The number of pixel formats outgrew the number of available bits in
the bitmask used in avcodec_find_best_pix_fmt().
avcodec_find_best_pix_fmt2() uses a PIX_FMT_NONE terminated list
of pixel formats instead.
This allows compiling and running these tests on systems lacking a built-
in version of getopt(), such as MSVC.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
We cannot do this in general since we could be reading
a file with B-frames while lacking an index.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This allows future assumptions to be made without affecting non-intra files.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The "ECs != 1 -> OP1a" assumption was wrong. Luckily, the file
that triggered that behavior had two ECs, not zero. Hence
distinguishing between them is simple in this case.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This fixes rare cases where OPAtom may be treated
as OP1a, causing all essence to be read into RAM.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The properties of the CDCI Descriptor are insufficient to specify
the pixel format for uncompressed picture data. SMPTE 377-1 and
RP224v10 have defined a set of picture coding labels to indicate what
formatting was used.
This patch uses 2 labels to detect UYVY422 or YUYV422 pixel formats.
It defaults to UYVY422 for 8-bit 4:2:2 pictures to support files
that were created before the coding labels were introduced ~2008
The codec pix_fmt default was changed from 0 (PIX_FMT_YUV420P) to
-1 (PIX_FMT_NONE)
Reviewed-by: Baptiste Coudurier <baptiste.coudurier@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This supports detection of uncompressed picture in files that
didn't include a Picture Coding Label. The lables weren't
available until SMPTE 377-1 and RP224v10
Reviewed-by: Baptiste Coudurier <baptiste.coudurier@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
