[vlc] Re: vlc/vls + ltsp(or some other thin client solution)

[Ben Green]

On Fri, 16 Jul 2004 15:38:20 +0100, Cian Cullinan  
<cian at medialabeurope.org> wrote:

> Hey everyone, I'm in the process of designing a system where several  
> clients
> will be able to tune-in at will to one of several concurrent video   
> streams
> from VLS.
> The clients and server will all be on the same dedicated network. It
> seems like some kind of thin client solution like LTSP would be suited to
> solve at least some of the challenges here. My thoughts are that I  
> basically
> have the following options:
>
> 1) Do "pure" LTSP with a big  VLS/LTSP server, several minimal clients  
> (no
> harddisks), with all the video decoding happening on the LTSP server.  
> Seems
> like this is going  to be VERY punishing on the LTSP server.
>
> 2) As above, but run the video decoding/displaying app (VLC) as a local  
> app on
> the clients.
>
> 3) Don't use LTSP, have clients boot from their own harddisks, and run  
> VLC
> locally
>
> To overcome harddisk bandwidth issues of streaming multiple movies from  
> the
> video server I would plan on using some version of striping RAID.
>
> My choice would be 2, but I don't know if it's possible, or even  
> sensible.
> Am I completely off track here? What do all the experts here think?
> I'd really love to hear from anyone who has done something similar or  
> knows someone who has.
>
> Cheers,
> Cian
>

Well, I haven't tried number 2), but have tried the others. I guess we  
have all tried 3), as that's the main use for vlc/vls, so I will relate my  
experiences of 1). This doesn't work too well. Having experimented on 3  
different LTSP system, I have come to the conclusion that there are two  
severely limiting factors:

a/ Network bandwidth
b/ Speed of graphics cards in the client

If you know that you have fast enough graphics cards (and associated buses  
/ memory of course) then you are left with network bandwidth. All clients  
accross our LTSP networks have 100Mb/s cards. This doesn't seem fast  
enough to send full screen video decompressed over. X seems to need to  
send full 24-bit frames of the movie you want to send. No matter the  
resolution of the video, if it's displaying on a 1024x768 screen, then  
that is what gets sent over the network. Obvious solution, drop the screen  
resolution / color depth. Still hard to get 25fps or whatever. Another  
solution would be to use Gigabit Ethernet. These ideas aren't streaming  
though, just remote X session.

Funnily enough, the first demonstration of LTSP I saw was sending a video  
(Apocalypse Now) and the sound over to an client with a 256 color display.  
The client dealt with it admirably. This was done with XINE.

As to your idea 3) I have been meaning to try this for a while. I can  
think of two limiting factors here too:

a/ Speed of graphics cards in the client
b/ Speed of processing in the client

We run our LTSP on 133Mhz+ pentiums. These rock for LTSP and desktop work  
but I don't think they would handle video de-compression too well, unless  
it where lowish resolution (360x288 would probably be a acceptable size  
and give your a decent frame rate). If you have faster clients with decent  
video cards, then the world is your oyster. This option would really take  
to load off the network and allow loads upon loads of connections,  
streamed in a manner of your choosing. In that sense it is by far the best  
solution, if you can get it to work. PLEASE PLEASE PLEASE give this a try,  
I have wanted to but haven't had the time. Please tell us, or at least me,  
how you get on.

There are instruction on how to run local apps with LTSP in the version  
3.x documenation:

http://www.ltsp.org/documentation/ltsp-3.0-4-en.html#AEN1378

LTSP 4.0 has local apps set up for you, but VLC isn't one of them.

Good luck.

-- 


--Ben Green--

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