Skip to content

Videolabs medialibrary meeting 25sept 2025

Videolabs medialibrary meeting 25sept 2025

Context

Updates and think tank on the ongoing works going on the medialibrary.

Participants

Discussions

Podcasts

VLC for android has implemented most of it's podcast interface and has already started testing it with medialibrary 0.13. Critical parts are still missing on our side to have a proper release:

  • Caching is lackluster, missing download progress infos and lacks asynchronous suppport. the libVLC downloader API from @deyayush6 will bring those features, it will likely be integrated in the ML before upstreaming to VLC.
  • the medialibrary won't support caching for the VLC 3.0 API, for now, it only means a runtime fail on API call rather than branching out of 3.0

This is top-priority work for the medialibrary as it blocks the release of the upcoming VLC 4 switch of the android spin.

Video previewer

Context

François and Gabriel are working on a POC of video previews in the seek bar of VLC 1. This discussion was to gather ideas and opinions on the way an user would expect this system to work best with its limitations in mind.

The preview is currently a single compressed image mosaic of frequent low resolution "screenshots" of the media2, this is the way most multimedia providers currently do (YouTube, Netflix...).

  • VLC 4 preparser API is used to generate those maps
  • Demuxers support attachments of already existing previews (only exposed by adaptive streams for now)

Limitations

  • Preview generation can be quite slow (10 to 45 seconds for a movie)
  • Even though it's a highly compressed image, with a large amount of preview items, mosaics can weigh multiple Mo.
  • The previews must have a small amount of metadata attached to it for VLC to display it correctly:
    • Number of images
    • Mosaic items size (width and height)

Discussion

Performance
  • To improve the generation speed, Pierre suggested using fast seeks to avoid stress on the decoder, Gabriel measured a 3 times speedup on his sample. Unfortunately, this makes the previews imprecise and could be hard to force on all cases, the acceptable margin of error needs to be evaluated in the common case to figure if we can use fast seeking in the general case.
  • Measures using hardware decoders implementations still need to be done as the POC uses x264, this is really important on small devices.
  • Overall, the performance impact seems to be too high on roaming devices for the feature to be enabled by default.
Sane defaults
  • The Android and IOS teams insist that we expose a lot of configuration options so they can tweak and find the proper image size/preview frequency ratio.
  • Most of the devs disagreed that we should enable the feature as a medialibrary scan running in the background like the thumbnailer, the load on existing Media libraries is too high.
  • File extension based automatic generation was suggested. To cover formats generally used by movies (Matroska) and exclude media where the demand for previews usually makes less sense (mp4, WebM).
  • The feature will likely be shipped first as a "generate preview" button on the playback, to test the feature and have user feedback.
  • The libvlc API needs to expose preview generation progress information for the UX, this requires some work on the sandboxed preparser.
Preview attachments

Since preview generation is costly and can hardly be done automatically, François suggested that VideoLAN promotes a new attachment norm for previews. A lot of discussion went on this, and we all mostly agree that it's a great idea if we can convince the community to ship previews files sided with their media.

To keep the format simple and trivial, it's likely that it will be an image detected in the same directory that matches a certain name. The image name should include the preview's metadata such as number of picture and width/height, which we all agreed is not really satisfying.

Overall, this is the direction we want to take rather than rely on automatic generation, this particular subject needs to be submitted to the VideoLAN community during a tech meeting at the next VDD in November 2025.

Database corruption troubles

Both Android and IOS have users reporting sudden data-loss that are very hard to reproduce. These issues are particularly catastrophic as they reset the database and loose the users playlists.
Playlists are the only side of the medialibrary (with custom thumbnails) that cannot be recovered with an automatic preparse on DB reset.

The issue was acknowledged by most medialibrary developers and the most likely answer to that issue is:

  • Calm down on the DB hard resets on corruption detection, research a less destructive approach to DB repair
  • Systematically export the users playlist sided with the database in a common playlist format (m3u, opml...)

  1. image ↩

  2. 1_preview ↩

Edited by Alaric Senat
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

VideoLAN code repository instance