On the current code, armcc will fail with:
"libavutil/atomic_gcc.h", line 52: Error:  #2771: first argument must be
a pointer to integer or enumeration type

Fixes valgrind uninitialized memory errors when decoding png.

CC:libav-stable@libav.org

CC:libav-stable@libav.org

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

Print an error and abort when the option is of the wrong type (decoding
for output file or vice versa), since this could never be correct for
any input or output configuration.

Print a warning and continue when the option is of the correct type,
just unused, so same commandlines can be reused for different kinds of
input or output files.

The -{vas}<option> syntax is now obsolete and deprecated, and has never
been documented or encouraged.

It is an encoding option, it has no effect when applied to decoding.

This is shorter and more readable.

This is shorter and more readable.

I.e. input options to output files or vice versa.

Not all gcc configurations have an implementation of all the atomic
operations, and some gcc configurations have some atomic builtins
implemented but not all.

Thus check for the most essential function, whose presence should
indicate that all others are present as well, since it can be used
to implement all the other ones.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

This makes them pass standalone compilation tests. Previously,
they included atomic.h which included themselves again, leading to
double definitions.
Signed-off-by: Martin Storsjö <martin@martin.st>

Fixes build without threads after
759001c5.

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

CC:libav-stable@libav.org

Returning 0 may result in an infinite loop in valid calling programs. A
decoder should never return 0 without producing any output.

CC:libav-stable@libav.org

Avoids an infinite loop in the calling programs with decoder not
consuming any input and not returning output.

CC:libav-stable@libav.org

Avoids an infinite loop in the calling programs with decoder not
consuming any input and not returning output.

CC:libav-stable@libav.org

CC:libav-stable@libav.org

When there is just 1 byte remanining in the buffer, nothing will be read
and the loop will continue forever. Check that there are at least 8
bytes, which are always read at the beginning.

CC:libav-stable@libav.org

The loop a few lines below the xan_unpack() call accesses up to
dec_size * 2 bytes into y_buffer, so dec_size must be limited to
buffer_size / 2.

CC:libav-stable@libav.org

The container does not store any timestamps and is CFR-only.

This allows us to test the slice threading code.

It got broken in 0f13cd31.

CC:libav-stable@libav.org

CC:libav-stable@libav.org

Its replacement is still not ready.

It is not used inside lavc anywhere and now it makes no sense to export
it.