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.

This line is not needed, the module is already linked against
IOKit.

This patch adds the option to smoothly turn off the keyboard backlight when
a video is playing in fullscreen, to the OSX user interface.
The option is off by default and it works better if the automatic
keyboard backlight adjustment is disabled in System Preferences.
Signed-off-by: David Fuhrmann <dfuhrmann@videolan.org>