[Sugar-devel] GSoC Proposal: Multimedia Broadcasting

[Geza Kovacs]

Hi all, I've noticed that I haven't been invited for the application
interviews. Does this imply that my proposal has been ultimately and
conclusively rejected, or will I still have a chance at participating
in GSoC if I address any remaining issues that were brought up with my
proposal?

On Sat, Apr 11, 2009 at 9:39 PM, Geza Kovacs <gkovacs at mit.edu> wrote:
> 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
>
>