Pierre Lamot authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

those variables are usually changed simultaneously, qml would trigger an update
request for each variable updated and require detecting that the second call is
idempotent or making assumption regarding the call order to avoid the second
call.

this allows getting a single update point for the view.

Pierre Lamot authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

This allows to set conditions that should be met before being allowed to load
a page

Pierre Lamot authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

previous implementation was only restoring subview by overriding the
defaultPage of the subview. this caused some issues:

- default was overridden, this is not desirable as the default was no logner
  reliable from the POV of the subview

- the substate of the view wasn't restored, for instance if you opened the page
  of a particular artist, it would restore on the home page of the artists.

Allow server to compress manifests and text subtitles

If there's a pts, just respect it. Otherwise set the PTS to vlc_tick_now().

The documentation says it should be used like

> vlc -vv http://127.0.0.1:8081 --demux=stats --codec=stats --vout=stats

There's no reason force the "display" (logging) to render right away.

We may not want some of those logs to be dropped because they arrive late. But
we may also want to stat how frames are dropped, which is not possible with
this flag.
To show stats for all frames, even late ones use `--no-drop-late-frames`.

We don't have any system specific calls in our code. It seems the decklink_str_t
only needs special handling on macOS. It's a char* on Linux and Windows.

This image contains a prebuilt protobuf-compiler.
We don't need it yet, but when we do it will be included

Benjamin Arnaud authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

And patch the qml files accordingly.

Alexandre Janniaux authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

The decoder device was setup for offscreen surface but not for usual
surfaces, and was hold but never released.

Alexandre Janniaux authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

The bitcode flag was already added to CFLAGS, but was only used when
creating a static build of libvlc, which doesn't involve linkage. When
creating shared plugins, the dylibs must be linked with the
-fembed-bitcode flag to gather the bitcode from the different objects.

In particular, bitcode is mandatory on tvOS, so this is mandatory when
building dynamic plugins and/or libvlc for tvOS.

Alexandre Janniaux authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

When building with bitcode enabled (*FLAGS+=-fembed-bitcode), the
following happens:

 - with LDFLAGS += -fembed-bitcode, the vanilla libtool version will
   remove the -fembed-bitcode flag, being an unknown flag, so bitcode
   won't actually be enabled, and final link steps might complain that
   the dylibs (libvlccore.dylib for instance) doesn't actually have
   bitcode embedded.

 - once fixed (either by this patch or by using -Wl,-fembed-bitcode),
   the plugins will be compiled with -module, which default to using
   MH_BUNDLE on iOS/tvOS/MacOSX instead of MH_DYLIB. Indeed, dylibs can
   be dlopened only since MacOSX 10.3/10.4, and can be dlclosed only
   since MacOSX 10.5, so MH_BUNDLE was the primary target for libtool
   module support. However, MH_BUNDLE is not compatible with the bitcode
   support from Clang.

Since we support MacOSX 10.11 as minimum, we can default to using
MH_DYLIB for plugins to have the bitcode support.

This new libtool patch add the explicit support for -fembed-bitcode in
libtool --mode=link flags, and change the flags used when using -module
in libtool to switch to dylibs.

Alexandre Janniaux authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

Check that the linker features from Darwin ld64 for marking a symbol as
undefined (in the context of two-level namespace, it means that it can
be looked up in other namespaces) are usable. If they are not, the
static module bank is disabled since it depends on either static linkage
(which is obviously not affected by this option) or more generally the
ability to look up the static module bank symbol in a different linkage
unit/namespace.

In particular, they are currently not usable when enabling bitcode
through LDFLAGS+=" -fembed-bitcode" and compiling dynamically. On tvOS,
bitcode is mandatory, so supporting compiling with bitcode but without
the static module bank seems a rather good compromise given that it was
disabled anyway previously.

In static builds (the current shipping target for iOS and tvOS), the
static module bank stays enabled by the !HAVE_DYNAMIC_PLUGINS check.

Alexandre Janniaux authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

Those frameworks only exist for MacOSX, so it was invalid to set them up
in the general case. Fortunately, it wasn't really used on iOS and tvOS
for the executables so it didn't have consequences.

On MacOSX, the targets needing this framework already link it so it is
not needed.

Alexandre Janniaux authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

 - use a single location for adding every defines
 - use a single vout_LTLIBRARIES += line
 - deduplicate -framework,IOSurface

Alexandre Janniaux authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

Otherwise, the OpenGL interop doesn't link on tvOS when creating dynamic
plugins (--enable-shared option from build.sh).

Alexandre Janniaux authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

Those flags are not supported with bitcode and are not needed now that
the code has migrated to using availability targeting.

Alexandre Janniaux authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

The SSL*ALPNProtocols were introduced in recent OS version, and dynamic
lookup (using ld64 option -Wl,-U) was used to make it work during
link-time and potentially not have the function available.

However, -Wl,-U is not compatible with bitcode support, whereas
availability targeting is, and availability targeting provides more
information about when it's not supported.

MacOSX 10.13.4 is the minimal version target in cURL too. The
SSL*ALPNProtocols functions are documented as supported since 10.13 but
they were not included in the initial 10.13 releases.

Alexandre Janniaux authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

This is not supported with -bundle_bitcode, and was only supposed to be
used on 32bit anyway. It seems to be only a legacy flag now.

From ld64 man:

     -read_only_relocs treatment
                 Enables the use of relocations which will cause dyld to
                 modify (copy-on-write) read-only pages.  The compiler
                 will normally never generate such code.

HTTP realm is provided by reply headers. Sending it proactively
can then only be done by matching the url. (RFC 7617)

This image contains a prebuilt protobuf-compiler

Steve Lhomme authored 3 years ago and Hugo Beauzée-Luyssen committed 3 years ago

We no longer use/support it in 4.0