Time to take a moment and describe today's feed from the encoding perspective. We do lots of on-site coverage, and usually bring in a dedicated ISDN for the encoder feed back to the server(s) and out to the network. In UDP mode, our encoder and server can buffer quite deeply (say, 300 seconds) to accommodate some pretty significant network outages. Until today, we couldn't imagine a scenario where this wasn't good enough, but as luck would have it, we were wrong. Fortunately today's net problem was resolved by the end of the general session and Tuesday *should* be much cleaner. On the subject of camera positioning and exposure, we know, it was not good. I think we can pull together a somewhat more coherent set of post-produced presentations with what we have on tape -- we'll find out when we get a look at them. But we should have better cameras, a video switcher, and somewhat better lighting to do this virtual conference thing right. Next meeting? I heard lots of questions on multicast today...here's how it works with RealMedia. If you have decent MBONE connectivity, you'll negotiate multicast when you connect to the audio or video stream. If you don't, the client falls back to unicast UDP mode. If even that fails (say you're behind a firewall), it rolls to TCP mode, and will ultimately resort to HTTP "cloaking" if nothing else works. Users can override the automated fall-back through the preferences dialog if there's a strong preference for a particular mode. Jeffrey Payne, GM Broadcast Operations RealNetworks, Inc.
On Tue, 10 Feb 1998, Jeffrey Payne wrote: ==>I heard lots of questions on multicast today...here's how it works with ==>RealMedia. If you have decent MBONE connectivity, you'll negotiate ==>multicast when you connect to the audio or video stream. If you don't, the ==>client falls back to unicast UDP mode. If even that fails (say you're ==>behind a firewall), it rolls to TCP mode, and will ultimately resort to HTTP ==>"cloaking" if nothing else works. Users can override the automated ==>fall-back through the preferences dialog if there's a strong preference for ==>a particular mode. The goal here would be to allow other clients to see the session via traditional multicast tools (i.e., h.261 video and some form of RTP audio). /cah
I heard lots of questions on multicast today...here's how it works with RealMedia. If you have decent MBONE connectivity, you'll negotiate multicast when you connect to the audio or video stream. If you don't, the client falls back to unicast UDP mode. If even that fails (say you're behind a firewall), it rolls to TCP mode, and will ultimately resort to HTTP "cloaking" if nothing else works. Users can override the automated fall-back through the preferences dialog if there's a strong preference for a particular mode.
Odd. If MBone native tools aren't going to be offered, can you please make sure source code is available for the player? I normally use vat/sdr/rat on Digital Unix for watching NANOG, and it seems RealNetworks, Inc. haven't figured out how to compile their source on that platform yet. :-( Have we sunk to proprietary, closed protocols for NANOG? 'Tis a sad, sad day. :-(
Jeffrey Payne, GM Broadcast Operations RealNetworks, Inc.
As a representative of RealNetworks, do you have any comments on the availability of source code to your player, for those of us with multicast-supported systems you have chosen to ignore? Or is it simply time to declare NANOG yet another bastion of closed minds, and closed protocols? Matt Petach disgruntled NANOG non-viewer
I was really looking forward to tuning into today's proceedings via my Real Player. Unfortunately this didn't happen for various reasons. Even though the MBONE was buggy at times, I could still manage to hear the speakers that I was interested in. I feel that we need to give Real networks a chance, after all they do have some "running code" and the shear number of players out there could be considered some form of "rough consensus",(yes and I know NANOG is not the IETF :) but what worries me is that with the MBONE, I or some of my collegues can "lend a hand " if the stuff isn't working, knowledgable people can rip into the code and maybe come up with a temporary fix or at least learn enough that the "next time" will be better. Perhapse Progressive Networks will take the not too subtle hint that today's performance provides and realize that they can't go it alone if they really want to scale to the size that I think they want to. There are folks out here that can help and are willing to help but maybe first PN needs to come down of their high horse and get somewhat of a clue. geoffw Virtual Sites
Matthew Petach wrote:
Jeffrey Payne, GM Broadcast Operations RealNetworks, Inc.
As a representative of RealNetworks, do you have any comments on the availability of source code to your player, for those of us with multicast-supported systems you have chosen to ignore? Or is it simply time to declare NANOG yet another bastion of closed minds, and closed protocols?
I would be happy if there was actual support for non-Intel/non-MMXprocessors, aside from Macintosh. As it is, everything since their version 3 release has been "Error 88" in our office since they won't support these so-called 'orphan' CPUs. -- Mark Hernandez RepairNet Information Services markh@repairnet.com http://www.repairnet.com
### On Wed, 11 Feb 1998 09:14:06 -0800, Mark Hernandez <markh@repairnet.com> ### wrote to Matthew Petach <mpetach@netflight.com> concerning "Re: RA/RV ### Feeds from RBN": MH> Matthew Petach wrote: MH> MH> > > Jeffrey Payne, GM Broadcast Operations MH> > > RealNetworks, Inc. MH> > MH> > As a representative of RealNetworks, do you have any comments MH> > on the availability of source code to your player, for those MH> > of us with multicast-supported systems you have chosen to MH> > ignore? Or is it simply time to declare NANOG yet another MH> > bastion of closed minds, and closed protocols? MH> MH> I would be happy if there was actual support for non-Intel/non-MMXprocessors, MH> aside from Macintosh. MH> MH> As it is, everything since their version 3 release has been "Error 88" in our MH> office since they won't support these so-called 'orphan' CPUs. Yes, I too found this to be incredibly annoying and I _am_ running an Intel-based system. However, I'm running BSD/OS on my laptop so the FreeBSD binary of RealAudio-3.0 is the only thing I have available to me. I don't too much care about the video (it's usually useless even if it does work) but when I tried to connect I got an error message telling me to upgrade my client. The problem is... there is no upgrade available. A few of us decided to expiriment and set up an mbone tunnel with one person sitting near the front with his laptop's mic enabled. While the RBN feed was giving people Error#14, some people got at least a little bit of our mbone broadcast (it was faint and choppy someone reported on IRC). However, because of the way we had the tunnels set up, we were pegging the local network with about 3000pps of traffic so we quickly abandoned it. I have a feeling that an mbone boadcast would have been more reliable and useful had it been set up more properly. Now, I believe that vat, rat, vic, and sd(r) are all available for every major platform and every major OS out there (someone correct me on this if I'm wrong) plus the source code is freely available. However, I suppose those without an mbone tunnel would lose out just as well. Good thing I could get a "live feed" since I was actually at the meeting. |8^) -- /*===================[ Jake Khuon <khuon@Merit.Net> ]======================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | VOX: (734) 763-4907 FAX: (734) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/
On Thu, Feb 12, 1998 at 03:47:13AM -0500, Jake Khuon wrote:
Now, I believe that vat, rat, vic, and sd(r) are all available for every major platform and every major OS out there (someone correct me on this if I'm wrong) plus the source code is freely available. However, I suppose those without an mbone tunnel would lose out just as well. Good thing I could get a "live feed" since I was actually at the meeting. |8^)
The right answer, of course, is to run _both_ sorts of feeds. Those who can, can Do The Right Thing, and use the Mbone tools, those who must -- or for some reason, would _prefer_ to, could use the RV stuff. Has someone collected the Mbone tools for all platforms, and set up a web page? Bill? CHeers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
Jay R. Ashworth said once upon a time:
Has someone collected the Mbone tools for all platforms, and set up a web page? Bill?
On a dark and stormy night, Jay R. Ashworth said:
On Thu, Feb 12, 1998 at 03:47:13AM -0500, Jake Khuon wrote:
Now, I believe that vat, rat, vic, and sd(r) are all available for every major platform and every major OS out there (someone correct me on this if I'm wrong) plus the source code is freely available. However, I suppose those without an mbone tunnel would lose out just as well. Good thing I could get a "live feed" since I was actually at the meeting. |8^)
The right answer, of course, is to run _both_ sorts of feeds. Those who can, can Do The Right Thing, and use the Mbone tools, those who must -- or for some reason, would _prefer_ to, could use the RV stuff.
Has someone collected the Mbone tools for all platforms, and set up a web page? Bill?
www.merit.edu/~mbone/
On Fri, Feb 13, 1998 at 12:10:10AM -0500, Jared Mauch wrote:
Has someone collected the Mbone tools for all platforms, and set up a web page? Bill?
www.merit.edu/~mbone/
<thunk> D'oh! Thanks, - jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
participants (9)
-
Craig A. Huegen -
Geoff White -
Jake Khuon -
Jared Mauch -
Jay R. Ashworth -
Jeffrey Payne -
Mark Hernandez -
Matthew Petach -
Pete Ashdown