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.

Even the latest android version (Nexus 10 5.1.1) have an undefined behavior
when playing a H264 Hi10P video

As there is no public API in NDK to get the MediaCodecList in order to list the
supported profiles, use the API from JNI.