The chunksize internal variable has two different uses - for
reading, it's the amount of data left of the current chunk
(or -1 if the server doesn't send data in chunked mode), where
it's only an internal state variable. For writing, it's used
to decide whether to enable chunked encoding (by default), by
using the value 0, or disable chunked encoding (value -1).

This, while consistent, doesn't make much sense to expose
as an AVOption. This splits the usage of the internal variable
into two variables, chunksize which is used for reading (as
before), and chunked_post which is the user-settable option,
with the values 0 and 1, where 1 is default.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

The problem they are supposed to fix is handled in riff.c, so those
hacks are pointless.

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>

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

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

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

It is found in some 8svx files (e.g. ones created by SoX).
Currently the decoder reuses the 8svx functions because we already have
handling of a single large planar packet for the compressed 8svx codecs.

This enables the user (i.e. avconv) to automatically convert to the supported
sample format if needed.

This matches the output sample format and the range of the output values.

the user is not required to set bit_rate

This is useful if sending multicast data on a host with
multiple interfaces.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

There are no reason for "if (c_valid) { ... }" to appear before
"if (b_valid) { ... }".
Signed-off-by: Anton Khirnov <anton@khirnov.net>

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

The current code is a generalization of the earlier progressive MV
prediction code. This was supposed to predict MVs for both interlaced
and progressive pictures. But the interlaced MV prediction is buggy
and works mostly by luck.

This partially fixes interlaced MV prediction.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

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

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

The return value ret isn't an error code that can be passed
to ERR_error_string().

This makes the error messages printed actually contain useful
information.
Signed-off-by: Martin Storsjö <martin@martin.st>

Found with asan and the venerable 1-dog.avi sample.

'size' is populated by functions returning int64_t and int that return
negative error codes.

Bug introduced in 84ad31ff.
Thanks to Uoti Urpala for finding it.

Filenames are brittle across renames and add no useful information.