Also make sure that no new controls are pushed after input_Stop().

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

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

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

And also with dxgidebug.h to show leaks
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

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

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

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

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

The input is already stopped if it has reached end or error.

After each and every MainLoop() call is a call to End(), which
inconditionally sets the input state to END_S.

```--
  CC       access_output/file.lo
access_output/file.c: In function 'Open':
access_output/file.c:288:9: error: implicit declaration of function 'setmode' [-Werror=implicit-function-declaration]
         setmode (STDOUT_FILENO, O_BINARY);
         ^
cc1.exe: some warnings being treated as errors
make.exe[4]: *** [access_output/file.lo] Error 1
```

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

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

Use signed variables for calculating the buffers to be sent to the component
as negative values may occur.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Save some memory by allocating fewer buffers. This is still not optimal, but
close to where we can get with the current implementation.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

As we use packetized input we normally don't need more than a handful of input
buffers. Using the default of mmal, which is 20, seems absolutely sufficient.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

To be able to handle seeking properly we need to do a full decoder flush on a
discontinuity. As flushing the in- and output ports alone would not cause the
codecs internal state to be reset we have to disable the ports, reconfigure
and reenable. To ensure the flushing is synchronous the input buffers in
transit are now tracked as well.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

When running in opaque mode the mmal codec, deinterlace and vout must be used
together, so it is known that all pictures in use are allocated by the mmal
vout and contain an associated mmal_buffer_header. This allows us to enable
the zerocopy feature of mmal, which allocates shared memory between GPU and
CPU for holding the buffer payloads. Albeit the payloads are just small opaque
handles that reference the GPU side pictures it saves a little bit of
performance, because less VCHIQ transfers are required.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Using mmal_port_pool_allocate/destroy adds some extra safety on maintaining
the pool lifecycle in relation to the component lifecycle. Furthermore it is a
prerequisite to use zerocopy mode for ports.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

If the input port returns a buffer which has no picture attached to it it
would be leaked. While this in fact should not happen it seems sane to at
least release the buffer and spit a warning in case it does happen.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

If the same picture, containing the same buffer header without being
re-acquired in the meantime, is sent to image_fx twice it will portentially
cause a double free within the mmal core as it destroys the internal
refcounting. Use the same guarding mechanism which is already in place in
mmal/vout to ensure this is not happening at any point.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The mmal deinterlace filter does currently support the mmal opaque encoding
only and thus must be used together with mmal vout and mmal codec. This
ensures that pictures being used contain valid mmal buffer headers in the
picture_sys. Using them instead of locally allocated buffer headers simplifies
the code and avoids error-prone dangling with the data attached to the buffer
headers. Furthermore it is a prerequisite to enable zerocopy on the buffer
ports, which can even be a good thing when using opaque buffers.
If at some point in time the image_fx component in mmal will be fixed to also
support I420 input we may reintroduce them for operating this filter
independently from mmal codec and vout.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

When running in opaque mode the codec must be used together with the mmal
vout. In this case each picture contains a mmal_buffer_header within the
picture_sys_t. That buffer header can be used instead of locally allocated
headers with the advantage of reducing complexity and avoiding possibly
error-prone mangling of buffer headers. Furthermore it is a prerequisite to
enable zero_copy mode on the ports.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>