The internal call definitions using vout_thread_private_t are moved to
vout_private.h as well.

The object and storage structure are now separated for these calls.

This way only video_output.c needs to know about the original format.

So that only video_output.c needs to know about its internal control.

It's a VLC_API defined in vlc_vout.h

refs #24949
Was wired as SUBT for ease, but that only works
as long as cue parameters are not used.

Remove hardocded --jobs and use the value from the build script by
default, which is machdep.cpu.core_count + 1.

We don't add useless rules.

vorbisenc is built with libvorbis, so we just build that when needed.

and removes unused flag from cfea200c

They don't actually need some special treatment. They extract properly in the
expected folder given their tarball name.

It doesn't have any depedency with x264 nor anything shared.

It doesn't build but at least we get the sources to build properly.

The official tarballs (with a proper extraction folder name) are in .tar.gz

The tarballs we used so far are git snapshots.

This is cleaner than using a loop of vlc_tick_sleep(VOUT_OUTMEM_SLEEP);

We don't potentially wait 19.9999ms before giving a surface to the decoder.

If there's no surface available the decoder should wait for one to be available,
not get an error and not try to decode anymore. When pictures (and thus
surfaces) were coming from the display a picture_pool_Wait() was used, so in
the normal case we should do something similar.

The infinite looping shouldn't be an issue as on Flush or Close the decoder
will release all the past pictures/surfaces. So there will be new surfaces
available for past calls.

We could improve the code by using a conditional variable or semaphore to
unlock the pending requests rather than using vlc_tick_sleep().

avcodec_flush_buffers() is already not "protected" on close or drain.

The comment mentions some deadlock but when it was introduced there was a
semaphore around the call (3532e72e). There's
no such thread protection anymore. libavcodec must handle its threads flushing
internally (see ff_thread_flush() in pthread_frame.c)

With canceled pictures/surfaces, before the flush is received it may still
try to get a picture after the previous call returned NULL and so on.

Without canceled pictures/surfaces, the threads waiting for a picture/surface
will keep waiting but their "context" is reset. Either they will receive a
picture from the pending call for a previous frame but the flush should discard
it. Either the picture will be used for a fresh picture to decode and we don't
need to care at all.

Non-regression test for 12fa8556:

    lib: media_player: keep player libvlc instance

The media_player instance retains and releases the libvlc instance it's
created from. When using a different libvlc instance for media_player
and media, it was using the libvlc instance from the media_t object,
leading to the release of the wrong libvlc instance, and thus potential
use-after-free of one instance and leaks of the other.

It has been spotted since VLCKit creates a shared libvlc instance and
then can create a new libvlc instance in case the VLCMediaPlayer is
created with different options, which means that the VLCMediaPlayer and
the VLCMedia will be bound to different libvlc instances, triggering the
issue described in first paragraph and crashing.

/!\ This commit changes libvlc behaviour in the following case:

 - There's at least two libvlc instance, one being the parent of a media
   and the other being the parent of a media_player.

 - The media is set on the media_player.

 - A new media is played by the underlying vlc_player_t, in which case
   the new libvlc_media_t instance is now created with the player
   libvlc instance instead of the media libvlc instance.

 - The user call libvlc_media_player_get_media() on the player.

 - The user call preparse functions on the media.

Since this very case was leading to crash anyway, and is quite
intricate, it's probably not a very important change though.

Refs videolan/VLCKit#189, videolan/VLCKit#116

Avoid leaks in freetype when not testing it.

Avoid leaks in pulse and freetype when not testing those.

Test compilation for apple tvOS, which has the particularity to need
apple bitcode when compiling in order to ship it.

Since the iphonesimulator build has been broken multiple time because of
cross-compilation miss-detection, add a job with same architecture as
the CI. It builds with iphonesimulator, which could also be useful for
running tests in the future.

Generalize iOS jobs by supplying the SDK name as variable.

It is mainly designed so as to have other SDK than iphoneos one, like
iPhone simulator or Apple TV.