Re: Flash, Youtube and Thin Clients

Warren,

People often use the simple calculation of resolution*colordepth*fps to
determine bandwidth.  This is not a valid calculation in all cases, and
really clouds the issue without proper measurements.  Let me clarify...

This calculation only holds true if every pixel on the screen is sent to
the X server for drawing and no "intelligence" is built into the
protocol used.  This is probably valid if the Video output of the
application uses only X11.  Still, if there is buffering involved on
either end of the line, a full 70Mbps may not be needed for adequate
performance.

If you use a video output other than raw X11, one in which not every
pixel needs to be transmitted over the wire, you will see a massive
reduction in bandwidth requirements.

An excellent example in the Windows world is RDP.  Play flash through
rdesktop on a fat client, and you will likely see better performance,
simply because the RDP protocol in some ways is more efficient than X11.

It should be noted here that mplayer, with the correct settings, will
often perform rings around Flash in a thin client environment, and
consume less bandwidth for the same movie.  Note differences in using
"xv" versus "x11".
 
Meanwhile, also keep in mind, that there are two kinds of video to
concern yourself with:
1.  Streaming video
2.  Interactive video

Streaming is by far easier, because with buffering, you can safely
accommodate most any bandwidth requirement, because you can trade
bandwidth for temporal offset.

Interactive video (like games, ekiga, and such) is a harder nut to
crack, because you do not have that trade-off.  In most of my
environments, if streaming video works well and interactive video does
not, then I have satisfied customers.   

If I would ask anything of Adobe, it would be to be able to tune the
output audio and output video methods (perhaps through gstreamer? or
some such), so that we can find the best video output method for a thin
client environment.

I believe that since Flash only has an X11 video output method, this is
what makes it suffer more than mplayer and other video players.

-Gadi

On Tue, 2008-09-02 at 23:57 -0400, Warren Togami wrote:
> I had a talk with someone from Adobe today about our problem with Adobe
> Flash, Youtube and Thin Clients.
> 
> A video of 320x240 resolution at 30fps uses ~70Mbit/sec bandwidth.  This
> kind of bandwidth is completely unusable for thin clients.  For safety
> reasons many of us are forced to disable Flash plugin on our LTSP
> servers in order to avoid killing our networks with only a few clients
> swamping all available bandwidth.
> 
> This is a shame, because Flash is plenty useful without Youtube and
> similar videos.
> 
> I had an idea, what if there were a boolean option in /etc/adobe/mms.cfg
> that could turn off playing of .flv movies?  Then Flash could remain
> very useful for LTSP thin clients, and we wouldn't have to disable it
> entirely for safety reasons.
> 
> Adobe is hesitant.  They say that this is only a policy problem:
> 
> - We should simply tell users not to use any Youtube-like video.  This
> is simply an unreasonable expectation.  Even if all users knew to avoid
> it, it is simply too easy these days to accidentally load a page with
> embedded Flash video.
> - We should use QoS to throttle bandwidth between the terminal server
> and thin clients to protect the network from this kind of failure.  This
> adds complexity in network configuration, and indiscriminately punishes
> all applications, while being ineffective to solve the problem.
> - We should block all possible video sites at our proxy server.  This is
> problematic because there is an arbitrary number of video sites out
> there growing all the time.  Also the below reasons apply.
> - We should block all .flv URL's at the proxy server.  This sounds
> pretty good and would be the simplest workaround, except this fails for
> several reasons including:
> 1) Not every site has or wants proxy filtering.
> 2) A site may want normal desktops to be able to use .flv video while
> disabling it only on the LTSP server.
> 3) It is impossible to selectively filter .flv on a https server.
> 
> I am suggesting to Adobe in response that these suggestions require us
> to jump through hoops, adding lots of complexity and are ultimately
> ineffective in solving the problem.  Meanwhile a tiny change to their
> plugin to implement a boolean variable for an optional config file would
> enable a complete and simple solution, where Flash remains plenty useful
> for many other non-video uses.
> 
> The alternative that we are forced with if they do not agree to this
> simple request: We must disable the plugin on our terminal servers in
> order to protect the stability of our networks.
> 
> To be fair, Adobe didn't know that we existed as a very sizeable
> deployment base of Linux desktops until this conversation.  Also they
> are very late in the Flash Player 10 development cycle and any change,
> no matter how seemingly simple, can create risk.  I would suggest
> however, that in this case the benefit is very large, while the risks
> are small.
> 
> I am asking for the support of all Linux distributions before I approach
> Adobe with a stern but polite appeal.  May I count on your leadership's
> co-signing in asking for this option?
> 
> Do you run a school or business with LTSP and have been plagued by this
> Flash video bandwidth problem?  Please let the list know your
> organization, location, and # of thin clients affected.  I would like to
> include this as a random incomplete sample of affected users when I
> submit the formal letter.
> 
> Warren Togami
> [email protected]
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _____________________________________________________________________
> Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
>       https://lists.sourceforge.net/lists/listinfo/ltsp-developer
> For additional LTSP help,   try #ltsp channel on irc.freenode.net


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net