iod being only for initial object

descriptors can then be updated and we'll
be able to do delayed es fmt setup (OD stream parsing)

Pointed-out-by: Zoran Turalija <zoran.turalija@gmail.com>

They are not mapped yet
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

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

(fixes #8562)

This more closely matches the usual open/read/seek/close pattern.

Pointers cannot be inherited as normal configuration item for somewhat
obvious reasons. For output parameters, this is not much of an issue as
LibVLC sets the pointer values directly on its media player object. But
for input-related parameters, LibVLC would need to store pointer values
in the media item. Thus this change to input items.

Note that pointers are considered intrinsically unsafe, so there are no
flags for the time being.

Call timestamp_FifoGet before releasing Output Buffers.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

it uses its own system, so we must give it the proper value with --disable-option
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

This issue is easily reproducible with VDPAU activated, with a 60fps ts file,
see #14199.

With this sample, The video_output Thread is looping in ThreadDisplayPicture
way more often than with other videos. Consequently, vout_ManageWrapper and
ThreadControl are not called enough. As a result, subtitles are processed too
late, the mouse isn't able to hide/unhide, we can be stuck in fullscreen mode,
or second click on video to pop up the menu doesn't work.

To fix this issue: don't loop in ThreadDisplayPicture and don't wait in
vout_control_Pop if a picture was previously displayed.

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

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

this time it's working properly with a SMPTE color pattern
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Differentiate between BT.601 (SD) and BT.709 (HD) for YUV pixel conversion
use the same precision values as the openGL vout
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Some muxes, e.g. MP4, will send multiple header blocks. These are
merged by the HTTP server to a single header which is sent out to
the beginning of each client. However, they are _also_ sent out
directly on the wire to any client that connected before the first
block. In this case, we would send two separate Metacube header
blocks, which would have Cubemap (correctly) discard the first and
set only the second as header.

This would make us send only part of the MP4 header when sending
through Cubemap, if Cubemap connected before the first non-header
block, which would in turn confuse Chrome on Android (although not
Chrome on e.g. Linux). As Cubemap is pretty aggressive about
reconnecting (trying every 200 ms), this could easily happen in practice.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Hugo Beauzée-Luyssen <hugo@beauzee.fr>

Fixes read overflows.