It is shared with svq3.

This will allow removing the H264Context dependency in the future.

This function depends on the h264 internals and is so tiny that just
copying the code out is the simplest replacement.

Stop using the H264Context ones, to allow removing the H264Context
dependency.

There is no need for them to be extern anymore.

The ~100 lines of shared code is not worth the pain of svq3 messing with
h264 internals.

This will allow decoupling the parser from the decoder.

This is required by h264.

This should make it more clear that it is not supposed to be used for
anything except logging.

This code will be shared with h264.

Previously, ff_h264_idct_add_neon (originally in the arm version) used
a non-regular transpose in order to be able to use more instructions
that deal with registers as 128 bit register pairs. The aarch64
translation doesn't do it to the same extent, but brought along the
same structure since it was a straight translation.

This reshuffles ff_h264_idct_add_neon, bringing it closer to
the C implementation, making the transpose_4x4H macro do a regular
transpose, usable for other algorithms as well.

Previously, the third and fourth output from transpose_4x4H were
swapped, and prior to cc29d96d5a, the same inputs as well. In
addition to just swapping the outputs, also renumber the intermediate
registers for better readability (making the register order match
transpose_4x8B).

This runs with the same number of cycles as before.

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

The problem is that the argument 'q' is of the type uint8_t.
According to the JPEG standard, if 1 <= q <= 50, the scale factor
'S' should be 5000 / Q. Because the create_default_qtables() reuses
the variable 'q' to store the result of this calculation, for small
values of q < 19, q wil subsequently overflow and give wrong results
in the calculated quantization tables.

Instead, use a new variable 'S' (same name as in RFC2435) with the
proper range to store the result of the division.

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

Helps in decoupling this code from mpegvideo.

It will be needed to initialize BlockDSP in the next commit.

Helps in decoupling this code from mpegvideo.

The size of the block is fixed (8x8 plus padding).

Helps in decoupling this code from mpegvideo.

Helps in decoupling this code from mpegvideo.

Use it instead of the embedded mpegvideo one. Update init function
signature to load it directly from the callers.

These buffers are just a way to store frame pointers and be able to
modify them without touching the original ones.

The two dependent decoders (WMV2 and VC1) do not need special care for
these fields: the former does not seem to use the dest buffers, while
the latter reinits them every time to the current frame data buffers.

So only keep a local copy rather than the one from mpegvideo.

The test uses printf.

CC: libav-stable@libav.org

This is already taken care of by CLEANSUFFIXES.

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

Apply the default value for timeout in code instead of via the
avoption, to allow distinguishing the default value from the user
not setting anything at all.

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

Since all URLContexts have the same AVOptions, such AVOptions
will be applied on the outermost context only and removed from the
dict, while they probably make sense on all contexts.

This makes sure that rw_timeout gets propagated to the innermost
URLContext (to make sure it gets passed to the tcp protocol, when
opening a http connection for instance).

Alternatively, such matching options would be kept in the dict
and only removed after the ffurl_connect call.

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

This includes documentation and other modifications by
Lukasz Marek and Martin Storsjö.

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

Also add const to pointers in static functions within opt.c where
possible/necessary.

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

Using this requires setting the rw_timeout option to make it
terminate, alternatively using the interrupt callback (if used via
the API).

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

If set non-zero, this limits duration of the retry_transfer_wrapper()
loop, thus affecting ffurl_read*(), ffurl_write(). As soon as
one single byte is successfully received/transmitted, the timer
restarts.

This has further changes by Michael Niedermayer and Martin Storsjö.

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

Currently the list of avoptions for URLContext is empty though,
but such options will be added.

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

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

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

The flushing case is a bit strange; not simplifying it so the change is
less noisy.

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

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

Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.

This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the packet and may produce output, the new API requires the user
to send input first, and then ask for output.

For now, there are no codecs supporting this API. The API can work with
codecs using the old API, and most code added here is to make them
interoperate. The reverse is not possible, although for audio it might.

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