Rar multiple volume parsing still gets tricked by filenames matching
new naming prefixes, and using the old naming.

We need to decide according to the number of volumes found if our
new naming scheme has found only 1 volume.

part01.rar,part02.rar
part1.rar,part2.rar
part1.rar,part1.r00 (tricked here)
foobar.rar,foobar.r00

refs #9835

Close #11481

Signed-off-by: David Fuhrmann <dfuhrmann@videolan.org>

Allows decompression and access through rar, lha, tar, ...
Mostly unseekable.

Also remove the filter chain buffer functions update hack, keep constant
callbacks for video filters in the filter chain, remove now useless
parameters from filter_chain_New(), and inline
filter_chain_AppendFilterInternal().

(rather than recursive)

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

This fixes direct rendering playback on one tested honeycomb
device.
Signed-off-by: Martin Storsjö <martin@martin.st>

This would allow building libiomx-hc.so with -DANDROID_API=13
instead of =11 as right now - using 13 would probably be more
correct as the headers match 3.2.
Signed-off-by: Martin Storsjö <martin@martin.st>

This simplifies doing device/version specific overrides for the
hal format, which seems to be more necessary on older platform versions.
Signed-off-by: Martin Storsjö <martin@martin.st>

The website uses HTTPS by default so that was confusing

A level of indirection is added now that descrambling rules are in a
separate helper. This is not necessarily worse.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

As soon as either the input packet has been written, or an output
buffer is available, we return from the function, allowing passing
the output frames down the pipeline as soon as possible. (For
direct rendering, a new output buffer only become available for
the codec to use once the picture is rendered or discarded.)

This fixes playback with IOMX direct rendering on Nexus S, which
only uses 2 output buffers in this mode (min_undequeued = 1,
nBufferCountMin = 1), and probably also for other devices with
a small number of output buffers.

(On the Nexus S, the number of output buffers can't be increased,
since this leads to blinking.)

This is similar to how available input/output buffers are checked
in the MediaCodec plugin.

This still isn't completely foolproof with respect to the case when
an input packet needs to be split up over multiple input buffers
though, but it wasn't completely correct previously either.

Also make sure we don't return from the function without consuming
the input packet or returning an output frame, which earlier would
lead to a skipped input packet and leaked memory. (This could
previously happen on reconfiguration, or on timeout while waiting for
an input buffer.)

Finally, make sure we don't block indefinitely in case the playback
is paused (causing the decoder to block while waiting for a free
output buffer). The same solution as in the android mediacodec
decoder is used here.
Signed-off-by: Martin Storsjö <martin@martin.st>

In HwBuffer, split Setup into Setup, GetMinUndequeued and SetBufferCount since
we want to control the buffer count logic from omxil.c.

Some OMX components (like OMX.TI.*.Decoder) may have nBufferCountActual that is
greater than nBufferCountMin + min_undequeued. In that case we decreased the
number of buffer wanted by the component and had an undefined behavior.

In order to fix it, we need to increase nBufferCountActual value from the
component only when it's smaller than nBufferCountMin + min_undequeued.
Signed-off-by: Martin Storsjö <martin@martin.st>

According to OMXCodec.cpp, we shouldn't call lockBuffer when we first allocate
all buffers, since we may cancel some of them (the min_undequeued ones).

We should call lockBuffer only before giving a buffer to OMX.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

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