[FOSDEM 2023] Technical Discussions summary

FOSDEM 2023 VLC Technical Discussions

The discussions were mainly targeted at determining the remaining tense topics blocking the 4.0 release.

Stabilization

Given the amount of changes between 3.0 and 4.0, the stabilization/regression hunt will probably need a proper organization, and possibly a dedicated workshop.

Clock

Clock sources

• stable master clock input is not implemented yet, but we are still struggling to find out "real life" tests where this triggers a regression
• input slave should be fixed, but this is not a regression from 3.0. TODO: create a ticket to track this.

Clock synchronization

A few subjects are related to clock synchronization:

• netsync still has to be fixed based on the new clock system
• implementing syncplay/timingObject new standards could also be a good idea

Note: this could be a good subject for a GSoC/internship.

Audio

• pipewire: we could add the pipewire support and raise the priority, but the API does not seem to be 100% functional (for example, device selection in pipewire is not working properly). @tguillem suggests the following strategy to end it merged and with a higher priority:
  • Merge it with a lower priority than Pulse
  • Implement new timing_report callback (TODO either @Courmisch or @tguillem)
  • @tguillem will implement and test passthrough with all the available devices
  • then the priority can be raised higher than Pulseaudio.
• iOS audio stack has been reworked a lot, but we are still waiting for Apple answer to get 100% clean. TODO: @tguillem needs to create an issue on c.v.o to track the status.

Vout

• update_format: the MR !1021 (merged) has been stale, it should probably be resumed. The previous discussion tends to split the problematic in two (resolution change VS format change) to simplify the resolution.

• subtitles in black bars: this is the same subject as subtitle crop on android when ratio is modified. This does not seem complex, but long (refactor/modify every vout that support SPUs).

SPU

Android subtitles issue

Activation of subtitles display on android suffers performance issues. There can be a lot of causes to that:

• API used to upload is really old, due to really old benchmark at the time of the first implementation. OpenGL should probably be prefered now.
• freetype rendering can be slow (still ?)
• if we use opengl, we should upload in premultiply
• swscale is triggered by the core, usually for aspect ratio reasons (but possibly not good ones).

TODO: @fcartegnie , @tguillem and @alexandre-janniaux will look at it.

Core Misc

next/prev frame

The feature needs to be "fixed" for 4.0, even in an ugly way, as:

• this is a regression from 3.0
• this is probably going to be fixed properly only with the input rework in 5.0

The goal is not to find a solution that works on every scenario, but to find a good compromise for the existing 4.0 architecture.

"Previous frame" can be possible but very ugly (seek back).

Right now, "Next frame" is broken because it is buffering too much (it is buffering at every call of next frame function).

Possible workarounds are:

• play paused style (@robUx4)
• play and paused (hotkeys) (@jbk )
• polling vout state until the next frame is out (@tguillem )
• don't call pf_demux if the es_out fifo is less than a certain threshold (@typx)

MRs should be sent ss soon as one of these cludge is "functional" for most cases.

sout

• display is broken on master, but @asenat is working on it
• cycle filter: the feature is 100% legit (similar to A/B loop but for sout), but it seems very few people use it, as it should be broken most of the time:
  • PCR is not handle properly
  • no discontinuities triggered
  • no GoP management
  • it could be wise to drop its support (could be very time consuming to reimplement it properly)
• udp aout is still broken. @asenat is also on it.
• gather: TODO: @typx is taking a look at it.

libVLC

Get Window Callback

It might be a good idea to add the "player->get_window_callback" before 4.0 (add a way to override the window providing through an external context).

The proper signature still needs to be defined.

Thumbnailer/parser

Some flaws have been discovered in the Thumbnailer implementation in 4.0.

Thumbnailer should not be linked to media, it should be directly linked to libvlc.

The callback should be set directly through the Thumbnailer executor, and not use the libvlc events.

@tguillem, @asenat and @alexandre-janniaux should propose a MR according to these statements.

libVLC Event management rework

This rework would be nice, but not mandatory for 4.0.

It can be proposed only if everything works before.

Download API

The main issue revolves around the activation/deactivation of the stream filters.

Consensus: an acceptable solution is to add a "raw" boolean flag to the download API to be able to deactivate the automatic stream filter injection.

This flag will be considered and documented as "potentially dangerous/use it only if you know what you are doing".

Other

VLC 4.0 OS support

On the 4.0 target OSes (especially for Windows): even if the previous compatibility matrix has been set a long time ago, the targets remains the same (Windows 7 for Windows).

Update server

Some prototype of a new update server has been initiated by a GSoC a few years ago and reworked by @Garf (https://code.videolan.org/Garf/UpdateServer).

The idea is to provide VLC media players the "proper" update file for their OS and OS version (as well as A/B testing, etc.).

The UpdateServer is somewhat functional right now, but some discussion with security@c.v.o needs to be started (trust management between client and server is not 100% trivial as TLS cannot be used on old systems, like Windows XP).

Rust

Should we add Rust support for 4.0 ?

Right now, there are still some discussions on how to manage the Rust <-> C bindings properly.

The strategy agreed on this subject is: Rust support should be added to 4.0 if and only if some "pragmatic" Rust integration strategy is found until RC.

Modules loading list state

It could be convenient to replace the modules tree that is not a tree diagram that has been removed in 4.0.

For example, using some accurate tracing/logging during loading/using the module could be a good idea (some info are missing right now).

Solution: trace the module probe, and use the tracing information to graph/display the current status.

Note: this could also be applied to ability to trace the video format (@typx would like it).

Wayland & Qt

The opengl refcount context issue persists.

[EDIT] It might be "solved" using some "higher level" api. For example, using GBM would avoid the use of EGL/Wayland and then would dodge the refcount management, but this could take a significant amount of time to make it work...