[Sugar-devel] GSoC Proposal: Multimedia Broadcasting

[Geza Kovacs]

On 04/11/2009 07:07 PM, Carol Farlow Lerche wrote:
> It seems like this conversation is somewhat at cross-purposes.  Martin
> discusses the general case of multicast from an arbitrary client through
> an access point serving many clients with a mixture of multicast and
> unicast traffic.  Well known performance problems result.  However, Geza
> proposes a special case (perhaps).  In a classroom, it would be nice to
> be able to have a "projector" to send a stream of video to the stations
> within that classroom.  Now, not every school could have extra hardware
> for this purpose, but I think many could, just as our schools of yore
> had that funky projector that got rolled into the classroom on the
> morning when our teacher wanted us to see (or sleep through :-) a movie
> about something or other.
>
> What might be interesting is to consider the possibiliity of connecting
> the projector client via a USB ethernet connector to a separate
> "multicast" access point, that the receiving clients associated with for
> the time of the "movie".  This allows the originator of the stream to
> use a wired connection to the AP, the AP to be chosen and configured to
> optimize multicasting, and the whole thing to be somewhat isolated from
> the unicast traffic happening elsewhere.
>

I don't think requiring an additional access point is the right way to 
accomplish this. As you said, hardware is expensive, so it would be 
unrealistic to install a new access point into every classroom, and if 
it were only available in certain classrooms then we're back to what we 
have right now with projectors - only those classrooms which have them 
at the moment can use them. As for adding the need for a wired 
connection to the AP, as I understand the XS already has one so it might 
be used as a "relay" so that the actual source machine is simply sending 
the XS the signal over unicast and the XS is handling the multicasting. 
Personally I don't like the notion of requiring any wiring because that 
would limit the locations from which video could be broadcast - say you 
wouldn't be able to project a video stream from a lab station unless it 
was pre-wired before class to do so. I think limiting airtime usage on 
the existing network, by limiting framerates, viewers, or similar 
mechanisms, is the optimal way to solve this issue - additional hardware 
requirements would mean that this couldn't immediately be of use in many 
existing deployments.

Right now I'm thinking that, given that I saw at max one full-motion 
video in class each school year in high school, full-motion video is 
really a limited niche to be addressing. Given that lecture slides are 
shown in many classes via projectors basically every day, then extremely 
low framerate video is really the key to be thinking about here (simply 
broadcasting the lecture slides in PDF format and using libpoppler to 
render them client-side and broadcasting slide transition notices could 
also work - I actually implemented something like this last semester, 
but then we have the issue that most teachers prefer to present slides 
directly from PowerPoint/OpenOffice, and that all kinds of issues might 
occur if the teacher uses specialized fonts or the like).

I don't believe that lecture slides, which could be broadcast at much 
lower framerates (1 fps MJPEG is 100 Kbps per stream) and would thus 
occupy very little bandwidth and airtime, would suffer any of the issues 
that Martin and I have been discussing. I've updated my proposal 
accordingly to reflect the emphasis on broadcasting of lecture slides. 
Of course this doesn't mean I'm not planning to implement the features I 
originally proposed - this is merely a contingency plan so that Sugar 
Labs is left with a useful product nevertheless if technical issues make 
full-motion video broadcasting infeasible.

> Not sure if this is workable, but some reading of the papers about
> multicast performance issues on the Intertubes suggest it might be
> promising.
>
> On Sat, Apr 11, 2009 at 3:07 PM, Geza Kovacs <gkovacs at mit.edu
> <mailto:gkovacs at mit.edu>> wrote:
>
>     Since you apparently have more experience with multicasting over
>     wireless I'll assume it's not a realistic option in this context
>     (though it might nevertheless be an interesting experiment to try if
>     have spare time over the course of GSoC after finishing a
>     unicast-based implementation).
>
>     Returning to unicasting and simply limiting net bandwidth usage, as I
>     understand the "slowest client sets the speed" issue with the access
>     node switching to Mode1 for broadcast applies only to multicasting. If
>     I have the XO send the video in a single UDP stream to the central XS
>     server (which as I understand has a wired connection to the AP), then
>     have those streams be individually relayed by the XS over the AP to
>     each designated viewer in over unicast UDP, then as I understand the
>     AP will be able to operate near its 56 Mbps net throughput limit,
>     which, factoring in the fact that the effective throughput will be
>     decreased due to noise and that my application of course can't hog all
>     the bandwidth and airtime, means that I will have around 20 Mbps
>     available for unicasting to all clients.
>
>     Rather than limiting the number of viewers as I originally proposed, I
>     believe that automatically limiting the framerate of the broadcast
>     based on the number of viewers will be a better way to scale for
>     larger numbers of viewers - that is, once the broadcaster gets to the
>     "broadcast" stage and selects the intended viewers, then based on the
>     available bandwidth and network congestion, then an ideal framerate is
>     calculated out and the stream is encoded and broadcast to all of the
>     viewers at that framerate. Given that the most interest has been
>     expressed over the remote desktop broadcasting feature, and given that
>     there's rather little motion overall on a desktop broadcast, the
>     desktop activity should still be easily viewed at very low framerates.
>      From my personal experience, I don't really miss any features of my
>     own typical desktop activity even at around 3-4 fps (except for
>     gaming, but presumably this will be used primarily for relatively
>     low-motion educational software). At 4 fps, the MJPEG video stream,
>     with a 96 Kbps audio stream, comes out at around 0.5 Mbps. Using 20
>     Mbps, this stream could be broadcast to 40 users, which I assume is
>     around the upper limit of the number of students in the classroom.
>     Assuming fewer viewers, then higher framerates could be used. Would
>     this be a reasonable approach to limiting airtime usage with unicast
>     streams?
>
>     On Sat, Apr 11, 2009 at 6:36 AM, Martin Langhoff
>     <martin.langhoff at gmail.com <mailto:martin.langhoff at gmail.com>> wrote:
>      > On Sat, Apr 11, 2009 at 1:37 AM, Geza Kovacs <gkovacs at mit.edu
>     <mailto:gkovacs at mit.edu>> wrote:
>      >> According to
>     http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4292735
>      >> then the slowest transmission speed, Mode1 (6 Mbps) is only
>     beneficial
>      >> for multicasting over very large distances; in the case of the AWGN
>      >
>      > I am sure they did their tests in quiet RF environments. In crowded
>      > environments nodes can tell the AP that they're having trouble
>     hearing
>      > the frames, please transmit slower.
>      >
>      > You've calculated 1.6Mbps but that's only the stream. You need to get
>      > each to the AP, and _then_ it'll be broadcast. The frame to the
>     AP may
>      > be transmittedfast if the XO is close to the AP. The datarate for the
>      > broadcast frame from the AP to all the nodes is set by the AP
>     based on
>      > the nodes it has registered...
>      >
>      >> In terms of airtime consumption, this of course depends on the
>      >> airtime-fairness mechanisms used by the wireless network. However,
>      >
>      > Which just don't exist (not in the QoS sense that you seem to be
>      > picturing at least), and deal rather badly with dense networks. There
>      > is a backoff mechanism that avoids collisions (rather than detect
>      > them) ... in very dense environment this means that the available
>      > bandwidth is significantly reduced.
>      >
>      > The tools that you want to reuse work well in a switched network with
>      > ample capacity. The workload of video streaming -- however
>     "light" you
>      > might thing 1.6Mbps is -- in a saturated shared medium with "slowest
>      > client sets the speed" broadcast and conservative backoff strategies
>      > is AFAIK an unsolved problem.
>      >
>      > There's surely a complex research project there -- can it be made to
>      > work? What strategies can work on that complex problem? But if you
>      > start by assuming you can reuse existing high level tools, it'll be a
>      > disaster. It might work in a test environment. But it will never ever
>      > work in a real life school.
>      >
>      > cheers,
>      >
>      >
>      >
>      > m
>      > --
>      > martin.langhoff at gmail.com <mailto:martin.langhoff at gmail.com>
>      > martin at laptop.org <mailto:martin at laptop.org> -- School Server
>     Architect
>      >  - ask interesting questions
>      >  - don't get distracted with shiny stuff  - working code first
>      >  - http://wiki.laptop.org/go/User:Martinlanghoff
>      >
>     _______________________________________________
>     Sugar-devel mailing list
>     Sugar-devel at lists.sugarlabs.org <mailto:Sugar-devel at lists.sugarlabs.org>
>     http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
>
> --
> "It is difficult to get a man to understand something, when his salary
> depends upon his not understanding it." -- Upton Sinclair
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel