[vlc-devel] Re: Proposals and questions

Sigmund Augdal sigmunau at stud.ntnu.no
Mon Apr 4 16:11:25 CEST 2005

On Mon, Apr 04, 2005 at 01:53:39PM +0200, Clément Stenac wrote:
> --filter logo{file=one.png},logo{file=two.png} 
> --sub-filter marq{marquee="text1"},time,marq{marquee="text2"}

as for filters, these may create vouts, and it might be of interrest to
select which module to use for each vout that filter creates. This, I fear,
will further complicate stuff. I fear this might call for a merge of
--filter --sub-filter and --vout.

--vout clone{dst=distort{mode=ripple}:marq{marquee="ripples!"}:xvideo{xineramascreen=1},dst=distort{mode=wave,dst=wall{rows=3,cols=3,active=4,dst=gl{effect=cube}:marq{marquee="middle part of wave"}}}}

Now, that's nasty :)
> For this, we would need to unify all modules chains/lists parsing
> functions and add variable setting capabilities to them.
> This fits for initial setting of variables, but does not solve
> on-the-fly changing.
> There are currently several strategies :
> * either register callbacks in vlc or libvlc objects and set these
>   variables (marquee, equalizer, ...) : this is easy and fast, but it
>   can't work at all for instance-specific values.
> * register in the object and set the variable in the first object found
>   (used by vout, ...) : this works poorly too (if you have two vouts,
>   for example)
> For this, I don't have a great proposal, because none is perfect, and
> all are quite user-unfriendly. This is related to the RC interface, so I
> put proposals in the next section.
> II: RC/RTCI/Telnet interfaces
> -----------------------------
> Quite a mess here.
> This proposal is not new here : merge these interfaces.
> We should have only one interface, that would have the following
> features:
> - authentication
> - multi-connexion
> - optionally, advanced readline-type features : history,
>   auto-completion, yanking, ... (some example code can be found in
>   quagga, for example). But this is quite boring to make, as, if I
>   understand correctly, libreadline can't read over a socket, only with
>   stdin/stdout.
> I propose that commands are organized in a tree in which you can enter.
> play
> stop
> pause
> ....
> set an OTF variable
> get an OTF variable
> vlm
>   setup ...
>   control ...
> Each command would have an associated callback function. Lines are
> tokenized and passed to these callbacks.
> A series of "prefix" indicate where in the tree you are.
> Example: 
> Commands are "vlm" (VLMCallback), "play" (PlaybackCallback), "stop"
> (PlaybackCallback) and "exit" (ExitCallback).
> The goal is that you can use "vlm setup foo bar" or "vlm" to "enter vlm
> mode" and then "setup foo bar". To get out of vlm mode, you have to type
> exit (IOS-like syntax).
> So, if VLMCallback is called with only one token in the list, it will
> add the "vlm" prefix to the prefix stack. "exit" pops a prefix from the
> stack, and performs a logout if the stack is empty.
> Each command also features a right level. Users could be defined
> (login + hashed pwd + access level) in a configuration file.
> Another thing that would be appreciable is an option for
> machine-readable or human-readable output (for easy interaction with
> other programs, though things like XML-RPC or SOAP might be better for
> this).
> So, about OTF variables : 
> * Either we use the module id... not very intuitive ("set 117 logo-file
>   ...")
> * Either a number (1,2,3). We find all the modules of the right type
>   (to find the type, we need to build a list of OTF-variables), and set
>   the var in the 1st one, or 2nd one, .... If no number is specified,
>   set it in all modules. 
>   That might be a bit slow, though, but you generally don't set otf
>   variables thousands of times per second).
> * A more flexible solution would be to be able to give a name to the
>   module (ex logo{file=blabla.png,name=foo}) and you would "set foo
>   logo-type blabla2.png".
> In all cases, it would of course remain possible to set the var in all
> instances at once. We would need new helper functions to unify all this
> (at the moment, there is some code for this in several interfaces).
For rc-like interfaces we could have commands to browse the object tree.
ls could list child objects and variables of current objects.
cd could change current object, and set, could set the variable in the
current object.

usage example:
you want to change the marquee text saying "complecs" into "complex".
vlc:input> ls
aout  100
vout  101
vlc:input> cd vout
vlc:vout> ls
marq 102
marq 103
vlc:vout> cd 103
vlc:marq(103)> ls
+marquee="This is"
vlc:marq(103)> cd ..
vlc:vout> cd 104
vlc:marq(104)> ls
vlc:marq(104)> set marquee complex
vlc:marq(104)> exit
hurrah, screen now say "This is complex"

Sigmund Augdal
Edgar B. Schieldropsv 29-14
N-7033 Trondheim
tlf: 91809129

This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html

More information about the vlc-devel mailing list