[vlc-devel] [PATCH v2 0/9] Implement libvlc player using vlc_player
rom1v at videolabs.io
Mon May 20 21:59:07 CEST 2019
On Mon, May 20, 2019 at 09:37:59PM +0200, Felix Paul Kühne wrote:
> > 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:
> >> Hi,
> >> 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
> > playlist.
> > 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.
That's why it is not removed and left as is.
> The iOS port and multiple third party apps depend on a playlist implemented by the media list player as exposed through VLCKit. You might argue that you could implement a playlist 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 single 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).
The plan is to write a new libvlc playlist API matching the core
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel