[vlc-devel] [PATCH] [RFC] input: set "input-current" early so control interfaces can control earlier

[Steve Lhomme]

On Mon, Nov 23, 2015 at 3:06 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2015-11-23 16:42, Steve Lhomme a écrit :
>>
>> Also the way the input thread is currently done, it initializes its
>> "chain" (sout or vout/aout) right at the beginning.
>
>
> That is _not_ going to change. Too many features depend on this.

This is not what this patch is about, no worries.

>> It may be done
>> before input_Start() finishes, and thus PlayItem is done. So we need
>> at least to have this sout decision done at the beginning of the input
>> thread. It could be some kind of "input modifier" plugin, if we don't
>> want to abuse the control interface too much.
>
>
> That is also not going to change: the whole point of the (otherwise crappy)
> VLC playlist is multiple interfaces/views. If you want full control over an

What do you mean ? That the playlist allows multiple interfaces/UIs to
have access to it ?

> input thread, create your own input thread (or VLM media or LibVLC player)
> and leave the playlist and its input alone.

What the Playlist, libvlc.mediaplayer and VLM have in common is that
they create their own input thread via input_Create(). We surely want
to have the Chromecast "output" working with VLC desktop and players
using liblvc. It turns out "input-current" is specific to the playlist
so it not a good solution when using libvlc.

We need a way to add a module that does the following:

- remain in memory when playing multiple files, so we don't reconnect
with the Chromecast each time. So likely held by the libvlc object.

- can add a custom sout depending on the input being played. For now
it may be forcing the sout, rather than adding one more.

- define this sout before or during the Init call of the
input_thread_t. After that the "sout" variable won't be used. That
leaves room between input_Create() and Init() to do it (both
included). That's compatible with libvlc and the playlist based
playback.


We could have some "input modifier/handler" module that tweaks the
input_thread_t at the end of input_Create(). Defined as a command-line
plugin chain, so the order can be deterministic. It could be passed as
an extra argument to input_Create() or even in the input_item_t used
to create the input_thread_t, via an extra parameter to
input_item_NewExt(). That module could be free to add parameters to
the input_thread_t environement, maybe rewrite URLs and so on.

Just thinking out loud.

>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel