[vlc-devel] [PATCH v2 0/9] Implement libvlc player using vlc_player
Felix Paul Kühne
fkuehne at videolan.org
Mon May 20 21:34:18 CEST 2019
> On 20. May 2019, at 10:14, Romain Vimont <rom1v at videolabs.io> wrote:
> On Mon, May 20, 2019 at 09:34:04AM +0300, Rémi Denis-Courmont wrote:
>> Does that mean the new LibVLC player handles playlist files internally? AFAIU, that is not the case in 3.0 and earlier'
> No, like the old one, it just manages 1 media at a time.
> The client may or may not used the provided libvlc_media_list_player.
> For example, Android only uses the player and implements its own
> In the future, we could implement a libvlc API for the new playlist.
Sorry, but I refuse removing the list media player without an appropriate replacement API in place.
The iOS port and multiple third party libraries depend on a playlist implemented by the media list player. You might argue that you could implement a player in the VLCKit layer which is partially correct. However, the main scenario is to open playlist files (as in m3u or xspf) with large number of (live) stream URLs and switch between those. This is easily possible with the list player as it uses libvlc’s internal playlist parsers. Removing the list player would require re-implementing a playlist parser in the client app, which is a waste of resources and time.
Additionally, in previous tests, the channel switch times between multiple libvlc players and the list player were noticeably different. For reasons I never investigated, the list player was a lot faster at switching channels than stoping, setting a different media and starting a player instance.
Ideally, the internals of the media list player should be re-written based on the new playlist API which should address all the aforementioned issues and would also allow us to use more for its feature such as shuffle (so the randomizer in the Android port could be removed as it is simply duplicated code).
More information about the vlc-devel