GitLab

The previous value was quite bogus.

This new implementation opportunistically tries to read data before
invoking poll(). This reduces latency when data is already waiting in
buffers, allows receiving pending data in non-blocking fashion even if
the object has been killed. This also gives GnuTLS a chance to dequeue
data from internal buffers.

Also the corner case of 0 read should now be handled correctly.

The corner case of an error after success read is no longer handled.
This was race-prone and useless.

Fix #6375 and may benefit to #8936

This is untested due to lack of compatible hardware.

It seems impossible to describe this chroma with
vlc_chroma_description_t. Thus picture allocation will fail.

Vittorio Giovara authored Jul 15, 2013 and Rémi Denis-Courmont committed Jul 16, 2013

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Vittorio Giovara authored Jul 15, 2013 and Rémi Denis-Courmont committed Jul 16, 2013

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Pictures without destroy callback are allocated on the stack and never
explicitly released.

gc.p_sys can now be NULL, if the picture has no planes.

psz_realhost is an alias to psz_socks when using socks.

This avoids loosing the picture context if there is one. If the
original picture has no context, it makes no difference whether the
original or the copy is kept since blending failed anyway.

If the picture copy fails or blending is unavailable(1), discard only
the subpicture and keep the original picture.

(1) In practice, this never happens as the blender object is kept
all the time even without a "blend" module.

This define several codec identifiers for each of the VDPAU video
surface types (YUV 4:2:0 and 4:2:2) and one for VDPAU output surfaces
regardless of their internal type. (At this point, it does not seem
that the output surface type affects VLC processes).
VDPAU bitmap surfaces are not included as they do not seem useful.

VDPAU pictures have zero pixel planes since they only carry picture
infos and handles to GPU resources, no actual pixel data. Nevertheless,
inclusion in chroma description is required for picture setup to work.

This reverts commit db8ff4e3.

Rémi Denis-Courmont authored Jul 02, 2013 and Rafaël Carré committed Jul 02, 2013

With the previous commit, the vout wrapper's display pool is no longer
used ever if direct rendering is not in use. Removing it saves one
picture buffer.
Signed-off-by: Rafaël Carré <funman@videolan.org>

Rémi Denis-Courmont authored Jul 02, 2013 and Rafaël Carré committed Jul 02, 2013

When the decoder output and the display video formats are different,
the picture copy comes for "free" during the conversion from the
earlier format to the latter one. So do not bother with copying the
picture before the conversion.

The straight copy is still required however in the case that the video
formats are identical but the display pool is inadequate (too few
pictures, slow memory bus...).
Signed-off-by: Rafaël Carré <funman@videolan.org>

Rémi Denis-Courmont authored Jul 02, 2013 and Rafaël Carré committed Jul 02, 2013

todisplay cannot be NULL there since its two possible values are
checked already.
Signed-off-by: Rafaël Carré <funman@videolan.org>