[vlc-devel] Re: Proposals and questions
Moriarty, Mark F
mark.f.moriarty at lmco.com
Mon Apr 4 16:23:15 CEST 2005
A difficulty with treelist kinds of things is that you really blow away the ability to do things using external applications.
I had only stubbed in rtci, now gone, because of fears that the existing interfaces would go in a direction that did not permit automation of control, that would make their use as an API horrendously complex by a controlling application. Once you start to talk about trees, where you type in one command and it poops out a list, you then pick an option, it poops out another list,..., remote control by anything other than another person has gone out the window.
I absolutely agree that there is overlap of functionality, and that at present there is no clean way to do some things (like on-the-fly, control multiple marquees). Including a "tag" for the filters, so that you would instantiate --marq-create "my_marq_name", then attach my_marq_name as a filter to a given vout, would likely be a really nice thing. Just please remember that there are people trying to use VLC for production work, make sure that anything done to remote control capabilities leaves at least some way for sane automation.
-----Original Message-----
From: vlc-devel-bounce at videolan.org [mailto:vlc-devel-bounce at videolan.org] On Behalf Of Sigmund Augdal
Sent: Monday, April 04, 2005 10:11 AM
To: vlc-devel at videolan.org
Subject: [vlc-devel] Re: Proposals and questions
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.
Example:
--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
+marquee="complecs"
vlc:marq(104)> set marquee complex
+marquee="complex"
vlc:marq(104)> exit
----
hurrah, screen now say "This is complex"
--
Sigmund Augdal
Edgar B. Schieldropsv 29-14
N-7033 Trondheim
Norway
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
--
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