[vlc-devel] LIBVLC API : feedbacks

[brezhoneg1]

VLC is great! LIBVLC API is well designed (instance, media,
media_player). Yet, to improve it, a few things still need to be
addressed such as:

            - Hotkeys (several issues)
		- Enabling dynamic changes of filter parameters

Please, find here below the full list of all
feedbacks/comments/questions I came across. I hope this can help enhance
vlc and libvlc api.


Q1: key/mouse events are managed by the X11 vout plugin module.
What about making this optional?
Something like a --vout-x11-events=none|fullscreen-only|fullsupport
This would let liblvc api developers decide what key/mouse interaction
would be best for their own need.


Q2: Launching the hotkeys interface is hardcoded when starting a new
instance. What about making it optional the way it is with any other
interface/control?
Benefit: let libvlc api developers decide whether they want to let vlc
manage hotkeys or not.


Q3: vlc has got two entities: keys and actions. Yet, actions are always
used together with keys.
Why not differentiate them further? Actions implementation could be
moved into the already existing src/misc/action.c. Actions could be made
available throughout the vlc architecture (not just associated with
keys). Why not even create a libvlc_trigger_action(media_player,
actionid) as part of the libvlc api ?
Benefit: let libvlc api developers only trigger the actions they find
relevant for their need through keys, pushbuttons or anything else.


Q4: multiple keys for one action.
As of today, add_key() function is based on an integer and yet, it is
stored in config file or read from the command line as a string
(StringToKey and KeyToString functions used internally).
Why not change add_key() to become string-based ? Why not then accept
multiples strings like "key-record=Shift-R:Alt-R:r" (this would be
consistent with how sub-filters and others are already managed) ?


Q5: libvlc API allows for multiple media_players playing multiple
videos. Yet, one single hotkeys thread is responsible for monitoring key
pressed for all windows, leading to a real mess.
Why not create one hotkeys thread per window to ensure that keys are
managed independently (see
http://mailman.videolan.org/pipermail/vlc-devel/2008-October/052361.html
)?


Q6: inputs threads created by media_players (libvlc api) are attached to
the libvlc object. This prevents them from benefiting from a whole range
of features where inputs are supposed to be attached to a playlist.
(str_format_meta function, hotkeys module, ...). Any plans to treat
these libvlc api inputs on a par with the playlist-attached inputs?


Q7: livlc_media_add_option allows setting up filters and their parameter
(:sub-filter=marq at marq1, :marq-marquee="Something"). Yet, once a
media_player is running, no function is available to allow dynamic
changes. I proposed two generic functions
libvlc_media_player_get(set)_param_named_entity (media_player, "marq1",
"marq-marquee", new_val) which were thought too close to internals.
(http://mailman.videolan.org/pipermail/vlc-devel/2008-October/052420.htm
l)
Dynamically changing filter parameters is often requested in the vlc
forum.
This may be the one thing libvlc api developers feel most frustrated
about.
Are there any plans to work out this issue?


I hope some of you have reached the end of this email. Of course, any
comments will be much appreciated .... 

Erwan10