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>

The option named mmal-zerocopy until now is used to configure the codec to
generate pictures with MMAL_ENCODING_OPAQUE which in fact is a fake payload
format that just contains handles for pictures allocated on the GPU side.
While this in effect causes a zerocopy mode of pixel data the naming is
potentially misleading because mmal supports another mode called zero_copy. In
this mode the GPU and CPU use shared buffers via the vc_sm kernel module, so
that the buffer data is actually accessible from userspace but no copies are
required when transferring from or to mmal components.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The reason for having a local picture pool within the deinterlace filter has
been that the mmal core did not allow to initialise the image_fx filter with
less than 20 output buffers. This limitation was removed from the mmal core,
so that it is possible to operate with as less as 2 output buffers, which
makes it possible to use pictures acquired from the core video output pool.
Besides being much more conformant to VLC core design this also avoids some
possible issues with buffer ownership and component lifecycle of the mmal
components.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

When an input picture can not be handled due to lack of resources we need to
free it to avoid a picture leak.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The data attached to the output port headers is not owned by the deinterlace
filter but by the vout and only temporarily attached to the codecs buffers. To
avoid refcount issues within the mmal core clear the data field before
releasing the buffers.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

It is safe to flush enabled ports, so avoid unnecessary delays by disabling
and enabling the ports.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The data attached to the output port headers is not owned by the codec but by
the vout and only temporarily attached to the codecs buffers. To avoid
refcount issues within the mmal core clear the data field before releasing the
buffers.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Depending on what parts of the format have changed it can be possible to apply
the changes without resetting the whole port. As this saves some time try to
make use of it.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Instead of dynamically allocating a mmal buffer from the mmal buffer pool use
a fixed binding, where the same mmal buffer is used for the whole pictures
lifecycle. This avoids some overhead on picture allocation and simplifies the
code. As the mmal buffer pool is allocated in exactly the same size as the vlc
picture pool there is no drawback doing it this way.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

When not running in opaque mode the buffer headed over for rendering is only
returned when the following buffer isrendered or the component is disabled. So
in this case waiting for the buffer to be returned immediately deadlocks the
rendering. As all buffers get immediately flushed on stop it is safe to skip
this wait for non-opaque usecase.
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>

If the port is disabled it would refuse buffers with an error anyway. Avoid
this by not sending them when the port is disabled.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The locking was incomplete and partly just wrong.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

It is not required to disable mmal ports before flushing them.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Only lock when really needed. To do this feeding the mmal port with buffers is
done from one place only now.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

If a port is not enabled sending any buffers to it will cause an error, so
just don't try it.
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>

Close #14820

Those values are writable by the input thread, and thus inaccessible
to other threads. Any remaining use of those (in VLM, podcast and
interfaces notably) is an undefined memory access, a bug.

The input thread sends events. There is no point in checking manually
since the input thread functions aresafe to "use" so long as the caller
has a reference to the input thread (regardless of the input thread
being dead or at EOF). Also the value of those flags can change
asynchronously (outside the input thread) so the checks were racy.

This avoids undefined access to input_thread_t.b_dead.

The caller (i.e. the buffer stream_t) will call the function again if
NULL is returned (assuming !b_error and !b_eof).

The net_* and vlc_tls_* functions will return errors.

If the input thread is killed, the net_* functions will return an
error. It gets propagated all the way up to where vlc_object_alive()
was checked.

The NetFillBuffer() functions already waits (somewhat more correctly)
for events. If the error is due to parsing error, waiting longer will
not fix it. If the error is due to network timeout, then
NetFillBuffer() is already fine.

In case of spurious wake-up, the function will return NULL. This is OK.

We would rather not terminate the whole VLC process in case of a
broken pipe or remotely closed TCP connection.

As for other parameters in this case.

As per both usage and documentation ACCESS_CAN_SEEK,
ACCESS_CAN_FASTSEEK, ACCESS_CAN_PAUSE, ACCESS_CAN_CONTROL_PACE and
ACCESS_GET_PTS_DELAY are mandatory. Thus the pf_control callback is
mandatory.

(Note that STREAM_* maps directly to ACCESS_* here.