[vls-devel] Re: [RFC] VideoLAN Server Architecture For the Future

[Bill Eldridge]

Jean-Paul Saman wrote:
> With the proposed module interface each module has certain capabilities 
> one of them is "seek" capability in a stream. If the input file is a 
> fifo then the stream control could set the seek capability to false for 
> that input file. This create the same effect as you need in this case.

Yes, the issue isn't very complicated.


>  > THis might be replaced
>  > with a URL for ffmpeg, with a UDP socket input
>  > for vls (& UDP output for ffmpeg and/or ffserver),
>  > etc.
>  >
> Could you elaborate on this?

Well, the problem with the fifo is the blocking,
especially if you have a server handling several
things at once. Additionally, since the vls/vlc
interaction is already UDP and ideally multicast,
you could have a vls server act as a UDP/multicast
client for another vls server, which makes it
simply a repeater. If the other "vls server"
happens to an ffserver instead, no problem.
Either provide a URL that will specify the connection
or a UDP port to start listening on.

>> I have a bit of a hacked http.cpp interface
>> for vls on http://techweb.rfa.org/staff/bill
>> that only failed because of page buffering
>> issues (it was cutting off after 512 bytes
>> on the POST with some browsers but not with
>> others) that can provide a different kind
>> of control interface than the telnet.cpp
>> one.
>>
> My idea was that a HTTP control interface (it should act like a little 
> webserver) would present a web page from which (after authentication):
> - a user could start/stop a stream.
> - a admin could alter/view current dynamic configuration
> 
> Tell if I'm wrong but it seems that your solution partly solves the 
> admin case. In the next VLS version we should try to integrate and 
> improve your HTTP control interface. I see it is written like the telnet 
> interface (looked into http.c and http.h on your website).
> 

Yes, my solution provides a small Web server interface
that can be expanded to do whatever. I have several
versions - one was a direct replacement for telnet.cpp,
one created a new file http.cpp using STL classes and the
last (buggiest) attempted to use the videolan STL replacements.
(I'm not sure the latter is extrememely necessary, but
having both STL & videolan classes is a bit chaotic).
It implemented both the POST & GET methods and I think
cookies. It basically just passed in the same commands
as telnet.cpp used, so you could browse, start, stop, etc.

I also wrote a quick Python cgi interface that just
calls up the telnet socket and does the same stuff.

-- 
Bill Eldridge
Radio Free Asia
bill at rfa.org


-- 
This is the vls-devel mailing-list, see http://www.videolan.org/vls-devel/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>