Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Communications The Internet Technology

Low Cost Webcast Optimizations? 108

Posted by Cliff from the better-network-delivery dept.
ChunKing asks: "I work for a small community broadcasting organization, and we operate a limited streaming media facility for a number of not-for-profit webcasters. It has always been an issue to optimize our streaming media infrastructure to most benefit our users. We operate a small cluster of servers from a data center with good connectivity and a highly-rated ISP, who will occasionally allow us to burst to unlimited bandwidth. For big webcasts, we will load balance the stream over a number of servers using round robin DNS. However, we still get problems with stream buffering and network drop-outs, particularly with streaming video. We cannot afford a network of edge delivery servers like Akamai, so in what ways can we further optimize our streaming media capacity to better produce smooth webcasts?"
This discussion has been archived. No new comments can be posted.

Low Cost Webcast Optimizations? More

Low Cost Webcast Optimizations?

Comments Filter:

  • Torrent (Score:3, Interesting)

    by MyNymWasTaken ( 879908 ) on Friday February 03, 2006 @11:53PM (#14639990)
    (This probably won't be helpful to your present problem, unless something along this line of thought already exists.)

    I wonder how well a method such as bittorrent adapted to streaming data would do - i.e. decentralized streaming.

    The first few viewers receive the stream directly from the source, while acting as mirrors for subsequent viewers. It would dramatically cut down on the server load & overhead for the broadcasters.

    • Re:Torrent (Score:4, Informative)

      by jimmyhat3939 ( 931746 ) on Friday February 03, 2006 @11:56PM (#14640004) Homepage
      There was a system that came out to do this. There are numerous problems, including differential lag times between servers and firewalls. Most importantly, unlike torrents, you need to stream media in a linear fashion. The great thing about BitTorrent is you can get, say, piece 53 from one guy and piece 173 from another guy at the same time. Here, you'd have a mad rush for pieces 1 and 2 right from the outset. Also, I suspect it's much harder to get people to 'seed' stuff in the media world. I believe there's still some sort of system based on shoutcast that does this, though, if you want to look it up.
      • I vaguely recall using something with "Chain" in the name... this was years ago for a local radio station. Chaincast, maybe? Anyway, IIRC, the problem (to me) was that it required a special client install. On the plus side, I think it was smart enough to server other clients on the same LAN. So, if 50 people happen to like the same stream, there's only one feed through the broadband connection.

    • Re:Torrent (Score:3, Insightful)

      by humphrm ( 18130 )
      That is a great idea, really it is. The challenge it presents is, everyone has to "buy in" to the idea of being mirrors for the stream. That's fairly straitforward in bittorrent, everyone's there for the same purpose... but webcast viewers are not there to share, they are there to watch. I suspect some people (I'm not saying they aren't selfish people) would have a problem with sharing their own bandwidth, if they knew that's what it entailed. Especially casual webcast users.

      But, again, a really, real

      • That is a great idea, really it is. The challenge it presents is, everyone has to "buy in" to the idea of being mirrors for the stream.

        Seems to have worked well for Skype.
         
      • Actually, in P2P swarming, you're not sharing your bandwidth, which implies a loss of bandwidth otherwise available to you; rather, if the software is correctly designed, you're exploiting otherwise unused bandwidth.

    • Re:Torrent (Score:2, Informative)

      by mindtriggerz ( 914619 )
      Xiph is working on a system like the one you describe.
      You can find their informal wiki page at http://wiki.xiph.org/IceShare [xiph.org]

    • Re:Torrent (Score:3, Informative)

      by fsterman ( 519061 )

      Kinda like this? [dijjer.org]

      • Re:Torrent (Score:2, Informative)

        by LabRat ( 8054 )
        Cool link..though from what I see it only works with pre-recorded stuff and wouldn't be useful for live webcasting as is the intention of the OP. After all, it's tough to get pieces of a broadcast from other clients when it hasn't been created yet :p Unless, of course, one is willing to have clients cache segments of the broadcast...and distribute that to other clients (with a noticeable latency to those further "downstream"). Going that way seems kinda kludgy to me. Something along the lines of skype wou
        • There would be noticeable latency to those downstream, but they would also receive more robust streams, no? Since they would have multiple points to access the stream (whereas the direct streamers must access the one set of servers), it would be more resilient to network problems in one of the connections. I'd gladly watch a "live" webcast delayed by two minutes if it means it's more stable.
          • I don't see how one method would be any more or less inherently robust than the other. Each is relying on the bandwidth of intermediate nodes, and by definition each is exposed to the same risks. By the time you add in the caching mechanism that would be needed for a bit torrent type application, you've added more things in the chain to go wrong by increasing the overall complexity. After all, each client would be required to cache the broadcast in exactly the same way, with exactly the same time interval
    • I don't know about other parts of the world, but in Germany the vast majority of broadband users are connected via ADSL, most of them with an upstream of 128 kBit/s, from which a significant part is used for TCP ACKs from the downstream.

      I do not see sufficient bandwidth for distributed streaming in the near future here.

      • That's the problem of course, you're limited at best to the bandwidth of the average upstream, minus a bit. TCP acks are not a problem - you roll your own protocol.

        You're probably going to want to do forward error correction, dedicationg 5% or so of the stream to error correction, rather than wasting the bandwidth the other way with acks.

        OTOH, in some cases, such as radio, 128K is just fine, and is a lot better than 44K that some stations webcast in noe.

    • Re:Torrent (Score:2, Informative)

      by trozman ( 937900 )
      What you're describing sounds like PeerCast. http://www.peercast.org/ [peercast.org] I've tried it with some radio stations.. connectivity rate seems to suffer, but otherwise, there aren't any issues with quality (but I only used for radio, not video)
    • Hmm on sourceforge they have a roup investigating that idea as we speak, I forget the name, but they are moving ahead with the concept, albeit in a slow pace.

  • Unlimited Bandwidth (Score:5, Informative)

    by lax-goalie ( 730970 ) on Friday February 03, 2006 @11:54PM (#14639992)

    "who will occasionally allow us to burst to unlimited bandwidth"

    Well, unless your provider has "unlimited bandwidth" themselves, you're basing your webcast on a lie. Pretty much no one has unlimited bandwidth; even a couple hundred broadband streams can saturate an OC-3 connection.

    What you need to do is plan your webcasts a little better and ask a bunch of questions: What's the real bandwidth your ISP can provide (with redundancy)? What's the buffer size that your client apps are using? (Settable in some clients, like Flash.) Does your ISP (who promised you unlimited bandwidth) even know what the hell they're doing?

    Without going to a dedicated CDN like Akamai, it's still pretty easy to design a distributed service network with colocated servers scattered across the country. You might want to consider finding someone who knows this kind of thing and paying them a few bucks to fix your problems...

    • Re:Unlimited Bandwidth (Score:4, Funny)

      by Anonymous Coward on Saturday February 04, 2006 @12:01AM (#14640033)
      I actually do have unlimited bandwidth. That's because I'm connected to the Google DarkNet. Unfortunately, at present it's just me, a bunch of empty GoogleCubes and Marissa Mayer on here. So we just send porn back and forth really fast and gossip about who Larry's dating this week.

    • Re:Unlimited Bandwidth (Score:4, Interesting)

      by EggyToast ( 858951 ) on Saturday February 04, 2006 @12:38AM (#14640145) Homepage
      Would it be possible to simply have their server limit the amount of connections to ensure that everyone who has a connection keeps a solid stream going? It seems like that would be a more immediate option that would allow them to scale up bandwidth according to their budget.

      After all, even if they scale up with colocation and distributing their webcast to other servers, if they can handle [x] users but only get [x/2], with a burst of x+2 once every 6 months, it seems like they should focus more on what they can do to reasonably control dropouts among users who are already connected, vs the rare scaleup to accomodate a large number of users for a short period of time.


      Of course, it might also prove out that by having more solid streams, they'll have more users, and will inherently get more users, which would lead to an escalation of costs. Might be screwed either way.

    • I suspect "unlimited bandwidth" means "bandwidth which is not limited arbitrarily". i.e. They get as much of the pipe as they can use.
    • "unlimited bandwidth" can mean either no limit to the bandwidth itself, or no limits applied to your consumption of the available bandwidth. Take my current hoster. I'm on a 100Mbit/s ethernet link, and thus could burst up to around 95Mbit/s. On the other hand: If I expect heavy traffic I could arrange for GE or 10GE links to my hoster. Which in turn has a 2x10GE trunk to the nearest exchange, so 18Gbit/s should be possible. As long as I keep that under 12-24 hours I won't even have to pay for bandwidth, on

  • Forget webcasts... (Score:2, Interesting)

    by MicroPat ( 895649 )
    ... at least for the most part. Encourage your viewers to download instead of stream, if at all possible.

  • streaming is so 1997 (Score:5, Informative)

    by sPaKr ( 116314 ) on Friday February 03, 2006 @11:57PM (#14640019)
    Streaming? Are you for real, that is so 1997. Just more old media companies trying to push their way of doing things on the net. Give up on streaming. Produce several quailty versions of the same file support a few differnt codecs mp4, xvid, wmv... and setup torrents for each file. Then use your limited bandwidth to deliver the torrent files, run the tracker and with the remaining bandwidth seed the torrents with a good bittorrent client. Why suffer quailty and bandwidth requirements just so the show can be 'live'? I suspect you arn't even showing live events so why streaming? Stop thinking like a TV broadcaster and start thinking like an internet distributer.

    • Re:streaming is so 1997 (Score:5, Informative)

      by dasnov ( 900499 ) on Saturday February 04, 2006 @12:08AM (#14640056)
      It all depends on who the target is. If this is targeted to the average person, I doubt they would know what a torrent is, or want to spend the extra 5 seconds to figure out how to download the file. Plus more and more people are behind firewalls and routers, and I don't think the average person would open (or know how to open) the correct ports to seed. So if this site is for the average computer illiterate person I doubt using a torrent as a solution would be much more benefitial.

      People like the simplicity of just clicking a link and the video poping up and streaming in media player, no download overhead eather.

      • Re:streaming is so 1997 (Score:3, Interesting)

        by Gulthek ( 12570 )
        Most of the time, what you're describing isn't streaming, but downloading. Windows media and quicktime both "stream" downloaded content for the user.

        Torrenting is the new downloading, if people want to get the latest and greatest on the net then they'll just have to learn how it works. I'm sure that it will just eventually be configured automatically as well though.

      • Plus more and more people are behind firewalls and routers

        That's a very good point. Along those lines, many are behind routers/firewalls that actively block P2P and torrent traffic as a matter of policy. (e.g., at universities, businesses, etc.) So, depending upon the target audience, relying solely upon bittorrent could cut out a major group. -- Paul

        • If you cant get around those lame blocking attempts you dont deserve the content you want. Just setup a remote socks proxy that runs on port 443. No one blocks web traffic and with SSL they cant do traffic analysis.
          • Yes because everyone who attends university, for example, has an external box connected to a line with equivalent bandwidth to said university, that they don't need to pay for, and have sufficient access to setup such a proxy...no wait, thats rare.

            Another really good port btw is 1863, the MSN Messenger service uses this port, it's above the 1024 service level (so easily setup for use by IRC daemons on shell accounts for example), allowed through most firewalls, and, like 443, it's already SSL so won't raise
      • So embed the bittorent client into a web page and write it in java or activeX. Blizzard was able to figure out how to use bittorrent for their WoW client updates and those go to MMOG players.
        • If you write it in java you can only make outgoing connections to the domain from which you downloaded the applet... not very useful for bittorrent eh?
          • What about signed applets? ya.. you can do much more. Really we only need one signed bittorent applet that takes the torrent file as an arg and then everyone can just reuse that applet passing their own torrent file. Jebus I need to do everything.
          • That is, of course, simply wrong. Java applets can connect to anything, using TCP, UDP, or TLS.
            You must be thinking of Javascript's XMLHttpRequest object.
      • If this is targeted to the average person, I doubt they would know what a torrent is, or want to spend the extra 5 seconds to figure out how to download the file

        How can you say this when the average person will download a special media player just to play a certain site's files (name your DRM), or download special applications just to have certain mouse cursors (CometCursor), or download special applications to get a weather icon on their taskbar, etc etc. These are all targetted at the average user. Als

    • Re:streaming is so 1997 (Score:5, Informative)

      by aykroyd ( 82171 ) on Saturday February 04, 2006 @12:15AM (#14640077)
      A broadcast organization, like the poster is working for, is most likely in a live environment and can't just Bittorrent to success. There are Peer to Peer streaming tools out there including Abacast [abacast.com] and Red Swoosh [redswoosh.com] who I work with [ninesystems.com] on a daily basis that provide sound results for their customers.

      Unfortunately, though, a CDN-style infrastructure is still the optimal way to go. There are generally resellers of the CDN technologies that can give you reduced rates on the same service. I know our particular model allows for easy scalability with tools that allow you to control your bandwidth usage. </pitch type="shameless">

      • Re:streaming is so 1997 (Score:3, Informative)

        by aliens ( 90441 )
        We use ninesystems, not sure if you work for them or just use them as well. But they have always been top notch and quite a bit cheaper than Akamai.

        Keep up the good work!
      • Red Swoosh [redswoosh.net] also integrates seamlessly with web environments (unlike, say, Bittorrent which spawns a separate application), and offers a JavaScript API for creating iTune's like download managers -- all within a simple webpage.
    • I think you should examine the situation a little more closely.

      For instance, if you produce a video that uses a song from Britney Spears (not that anyone would ever do that, but play along), the licenses required to allow people to physically download copies of that song to their hard drives are different and usually vastly more expensive than releasing the video as a live stream or as part of an on-demand system. The primary question of this article was maintaining fiscal responsibility, not opening the

  • Do they *have* to stream? (Score:4, Interesting)

    by OverlordQ ( 264228 ) on Friday February 03, 2006 @11:58PM (#14640020) Journal
    Is it vitally important that they have to stream the data? You cannot just distribute downloads and Coral Cache em? Cut my bandwidth for files from 120GB/mo to ~15GB/mo
    • Can you think how else to do live webcasting? Sure somebody mentioned multicasting, and I can see the ISP's eyes rolling from here. But Torrents, Podcasts, and all the other fancy schemes folks are rambling about here, just won't work for live material.

    • Re:Do they *have* to stream? (Score:1, Informative)

      by Anonymous Coward
      heh, I love the people who think Coral Cache is this big giant unlimited source of bandwidth.. its slow, latent, and unusuable for this application
    • First, forget round robin DNS. It simply doesn't work. You cannot rely on the DNS clients to select the round-robin IP addresses in order except under very rare circumstances.

      Second, if it absolutely has to work, you can rent services from Akamai, who have a huge and under-used network for exactly this service. Let them deal with distributing the load from one feed to thousands of servers worldwide: they think it will make them lots of money. They will play more clever DNS games than merely round-robining.

      T
  • You don't say what compression you're using. Changing to a better codec (xvid?),resizing, or changing the bitrate, maybe you can improve the streaming

  • One word. (Score:3, Informative)

    by lw54 ( 73409 ) on Saturday February 04, 2006 @12:01AM (#14640035)
    Multicast.

    • You are correct (Score:3, Informative)

      by jd ( 1658 )
      And I'd almost given up hope that others realized the technology was useful! :)

      Seriously, because ISPs generally do not support multicast (even though their hardware does, it's just disabled, it requires 5 seconds to turn on, and is likely native downstream of them anyway), it is better to do this the way NASA Select did with their TV broadcasts in the days of CU-SeeMe. (Great program, died an ugly death, and is now a zombie in the hands of a corporation.)

      What NASA did was to multicast for anyone who could

      • Re:You are correct (Score:3, Informative)

        by TallMatthew ( 919136 )
        Remember, multicasting is your friend.

        Multicast is one of those technologies which was designed quite well and makes perfect sense in theory, but is seldom useful.

        If this guy is broadcasting to one person in Topeka, one in Taipei and one in Tennessee, does he need multicast? He doesn't. Should every router on the Internet participate in the creation of PIM trees or allow the inclusion of hundreds of thousands of /32 routes under the 224 prefix? They shouldn't. So is multicast useful for streaming au

        • You are in error at line 10 (Score:3, Insightful)

          by jd ( 1658 )
          If this guy is broadcasting to one person in Topeka, one in Taipei and one in Tennessee, does he need multicast? He doesn't.

          Think again. Three copies means you chew up three times the bandwidth to get the same file out. If you multicast, you can: (a) transmit to all three the same information at the bandwidth of a single person, (b) transmit to all three three times the information at no extra bandwidth, (c) anywhere in between.

          The first option basically means you can run a broadcast station and be doing ot

          • If there's nobody downstream in the group, then the router doesn't carry that group.

            So every core router on the Internet should passively accept multicast JOINs and maintain state for every single multicast session going on across the entire Internet? I don't think so. Do you have any idea how vulnerable that would make your core? There's a reason the MBONE is routed discretely.

            Turning on multicast so you can process OSPF HELLOs on 224.0.0.5 doesn't mean you're multicast routing. Your argument that

      • actually, what DID happen to CUSeeme? That was such a cool little proggie.
        • CU-SeeMe was originally from Cornell University and was black-and-white only, though the Mac version may have supported colour. I didn't use the Mac version much. White Pine bought the program, lock, stock and barrel, and switched it from being free to being $50 a copy. They added colour, but it wasn't terribly impressive, and the stability went to shit.

          A bunch of CU-SeeMe enthusiasts, meanwhile, produced a full colour version of the free program. I don't believe the colour interoperated with the White Pine

    • I was about to make that comment, kudos. More bandwidth is just brute force, multicast can git 'er done.

    • Re:One word. (Score:2, Informative)

      by LabRat ( 8054 )
      Great idea in theory...not so good across the internet when you are trying to reach people who might be connected to any arbitrary Tier-1 provider. MBONE really isn't a solution, either, as it requires a lot of coordination in order to make use of it, and is more of a development tool than production-quality. The OP has a very interesting problem, for sure. I think a skype-like P2P architecture would probably be the best solution rather than multicast...where you effectively create a multi-cast-like netw

  • bottleneck? (Score:5, Informative)

    by adrianmonk ( 890071 ) on Saturday February 04, 2006 @12:06AM (#14640052)

    You mention a lot of factors, but you haven't said what area you're having the most problem with. Have you at least managed to identify what the actual bottleneck is? It could be bandwidth at your servers, or between your ISP and some peer (through which most of your traffic is going), or it could be CPU load on your servers, or it could be disk I/O limits on your servers, or it could be lack of memory on your servers (causing them to thrash), or it could be uneven load balancing to DNS-based load balancing being somewhat random, or it could be that you've reached the maximum capacity (in terms of hosts per response record in DNS) with DNS load balancing and you need to add another layer of load balancing.

    The first step is going to be to check into all those areas and identify where the failure is currently happening. Once you know that, the solution will be more obvious. You might just need to add striping for your disks (to increase throughput by brute force) or RAM (to be able to cache all active streams) if the problem is that your disks can't keep up. But, if your ISP's connection to a major peer isn't sufficient, then you will need to do something much more involved (and will probably include gathering data during an actual event where the streaming can't keep up in order to prove that the ISP is the problem).

  • Akamai and other Content Delivery Networks (Score:4, Informative)

    by dirtyhippie ( 259852 ) on Saturday February 04, 2006 @12:08AM (#14640054) Homepage
    Stay away from CDNs if you're looking for performance (if it's pricing you're after, that's a seperate issue) - they are likely dealing with all the same issues that you are. Except that when something goes wrong, there's nothing you can do except shrug and say "it's the CDN's fault". My organization went to a CDN to save on ridiculous colo bills, and we heard all the claims about performance with skepticism, but we were shocked to find that despite all the "second generation edge servers" our CDN has, thruput actually went DOWN significantly when we switched to them. We didn't much care since it was saving us a lot of money and was usually unnoticeable or at least bareable...

    But to return to your original question - since you're dealing with not-for-profits, clearly the answer is a live streaming P2P "edge network". Let me know when you release that code :)

    If you don't have the development resources for that, the best solution is probably to scale down your investment in your current colo and pop a few servers in a different geographic locale, a kind of DIY edge network. With 3 or 4 colos (say, Europe, US-East, US-West), and smart determination of which host to route to using Geo::IP or the like, you could probably save a lot of traffic and latency.

  • Outsource it to Google video (Score:5, Interesting)

    by iamelgringo000 ( 928665 ) on Saturday February 04, 2006 @12:15AM (#14640075)

    Upload video to Google [google.com] video or YouTube [youtube.com].

    Use their bandwidth to stream your video.

    Use their API to embed the video on your website.

    You lose control over the distribution of the content, but you save a lot of money in the process. The other option is Bit torrent.

    Also, have you looked into DigitalBicycle [digitalbicycle.org]? They are working on a PeerCasting system for Using Bit Torrent, RSS, and web community software

    • Start your own "Flickr of Video" (Score:4, Informative)

      by StreetFire.net ( 850652 ) on Saturday February 04, 2006 @07:59AM (#14641090) Homepage
      First, I can give you unlimited bandwidth on a Dial up line but you're not going to stream video over it, so any ISP that is giving you "unlimited" probably isn't set up to host your video. ;-)

      Second on YouTube and Google
      I agree there is something to be said for "out sourcing" your video to a company like Google Video or YouTube, but if you don't mind I would like to throw my little Start-Up (Vidiac.com) into the ring since we've been doing free video hosting longer than either of those two without all the Web 2.0 Hype. Of course the difference with us is we give you a video hosting portal you can run on your website (Like video.YOURDOMAIN.com), so with us you can start your own "Flickr of Video" either free (ad supported) or pay-per stream. Sorry about the self promotion there.

      Regarding your Dilemma
      Here is my input on the question at hand based on my own experience (I'm streaming just over a million streams a day to 2.5 Million Unique visitors a month). First, as always, start with the needs of the users.

      1.) Are they sophisticated? How would they react to a Torrent? From my experience, if someone has a torrent client installed then they're fine with it, but if they don't you have a large "fear factor" to overcome convincing a user to install a program to watch your video.

      2.) Do they want to click and Watch, (stream), or do they want to download? If you produce content like a video podcast, then I highly recommend giving your users a download option over streaming. If you run a portal-site, like Big-Boys.com that aggregates content then you're better off streaming as you want to be viewed as more than an FTP site.

      3.) How big is your Audience? This is probably the single biggest factor for capacity planning. If they all hit your site at once you need a ton of bandwidth.

      4.) Is this a scheduled broadcast (like a weekly show), or is this content that will be downloaded over time? Scheduled events can cause massive spikes. 10,000 users all at once is harder on a server than a Million users spread out over a month.

      5.) What video quality will your users tolerate? What Software can they use to view it? Windows Media? Quicktime? Flash? Size? Bit Rate? If your users are watching these videos on an iPod they'll accept a lower quality than if they're viewing it on their Plasma HDTV.

      Based on the above you can get a firm handle on your
      1.) Delivery Method (Direct Download, stream, Torrent)
      2.) Video Size (Format, Quality, etc)
      3.) Pipe Size (How much do you need to stream at once)
      3.) Bandwidth Utilization profile (spikes and valley vs. flat)

      Compare the above to your current solution. If your users are buffering, is it because...

      Your upload pipe is saturated? Upgrade to a larger pipe (100Mbps is about the minimum if you have more than 10 people hitting your video at the same time)

      Is your Disk I/O saturated? SATA and IDE are fine for most sites, but if you have 50 viewers requesting 30 different videos you need some strong I/O. we were burning through SATA drives on a weekly basis before switching to a SCSI SAN.

      Does your ISP have proper Network access to get to your end users? Consider pulling in a pipe from an appropriate network. (AT&T strongly peers with Cox cable for instance, MCI has fantastic AOL connectivity).

      Anyhow, I hate to answer a question with more questions, but there are so many ways to deliver video, there is no one silver bullet solution. You just have to do what works for your users and company. From experience though capacity planning for an online video application takes a lot of work, but once you wrap your head around the bandwidth issue, it gets easy. Good Luck!

      -Adam
    • Ugh are you kidding me? The video quality of both YouTube and Google's Video looks.. downright disgusting.

      Just got with torrents.

  • Use decent modern compression for streams (Score:3, Interesting)

    by springbox ( 853816 ) on Saturday February 04, 2006 @12:16AM (#14640078)
    For audio, use aacPlus [codingtechnologies.com] (probably not free) or Ogg Vorbis [xiph.org] (free!) Mainstream players support these (like Winamp.) Don't push junk like Realplayer. Vorbis alone will save a lot, and even super low bit rates will end up sounding decent compared to other compression technologies (I'm looking at you, MP3.) You can also set up a free streamcast server and use vorbis with it.

    For video? I'd recommend XviD [xvid.org], and not just because I use it almost exclusively, but it creates a compliant MPEG-4 video stream (compresses nicely), which will hopefully be streamable by any player that supports MPEG-4 video.

    • Why use plain old MPEG-4 when you can go one up to H264?

      The difference IS noticeable the lower down the bitrate you go.

      So what, you'll need more resources to encode the video but its worth it.

    • aacPlus and Ogg Vorbis aren't supported on a lot of players (the majority?) so you have to inform users to download and install a specific program. So don't be harsh on MP3, it is supported by almost every device (except for people still using sub 386 machines) and it takes less power to decode on portable devices. Concerning the performance at low bitrates: lame -V9 --abr 8 -mm -a --lowpass 5 --athtype 2 -X3 sounds better to my ears then the Ogg (latest Aotuv) or aacPlus equivalent.

  • so many bad answers.. (Score:2, Insightful)

    by Anonymous Coward
    Akamai is a premium priced streaming provider, there are many others, most of whom will do what you need at a much lower cost. We are currently streaming live streams (live television channels) with akamai, vitalstream, limelight, and others. We are pulling the seed streams from the middle east and south asia and broadcasting to thousands of users over a very wide geographic area. We have load tested to the 10s of thousands of users and none of the CDNS have even broken a sweat. I know of several sites
  • We operate a small cluster of servers from a data centre with good connectivity and a highly-rated ISP, who will occasionally allow us to burst to unlimited bandwidth.

    How small is that cluster? and what value is unlimited and burst? You don't say which brand of streaming you're running. It wouldn't be meaningful for me to extrapolate from my single QuickTime X-Serve experience, but I have saturated a 100mb/s link between my site and a test site with multiple streams, and no sign of stress on the box. The
  • if you have fine control of encoding try cutting your framerate in half, as long as your sound quality is good even very bad video isn't distracting
    • I generally find the exact opposite to be true. I suppose, though, that it depends on whether the source material's interest is primarily visual or audio. For news programs and the like, the audio is probably much more important than the video. For pr0n, the audio track can be missing and 8 out of 10 viewers won't even notice. Heh...

      In any case, for video watched on a TV vs. a computer monitor, I find that even 320x240 is very watchable (roughly equivalent to VHS videotape, I think) if the frame rate remain
  • First you need to figure out your problem, as some others have pointed out. Until you actually get it nailed down, asking other people's kinda pointless.

    It's probably that your bandwith is being maxed out... but you'll want to hire someone that knows what they're doing. That'd be the place I'd start, were I in your shoes.

  • Ourmedia.org (Score:3, Informative)

    by digitalfilmmaker ( 935507 ) on Saturday February 04, 2006 @12:42AM (#14640159) Homepage
    http://ourmedia.org/ [ourmedia.org] is setup for just such occassions. My video podcasts [askaninja] to a 100,000 people in the last month without complaint. CC friendly. And free.

  • Investigate Ultravox (Score:5, Interesting)

    by kriston ( 7886 ) on Saturday February 04, 2006 @01:12AM (#14640241) Homepage Journal
    This problem has been solved already. It's called Ultravox. It's a protocol that is format-agnostic and is used to efficiently multicast a broadcast within the data center up to the point it leaves your network. America Online and Cisco designed and implemented the protocol both in software and in the firmware of specialized Cisco routers and it is used for AOL Radio and for Winamp radio It's very interesting. All your viewers need is Winamp to hear or view your program.

    http://ultravox.aol.com/ [aol.com]

  • I just reread the summary: we operate a limited streaming media facility for a number of not-for-profit webcasters

    More items for your checklist -
    1. Supplier bandwidth, for live material;
    2. Material optimised for streaming? whether live or files for on-demand.
  • Check the load on the servers... that's not your problem. Check your bandwidth pipe. That is your bottle neck. Now just because you might have a 20 MB pipe doesn't mean you have 20 MB to the Internet. Bandwidth providers are famous for overselling pipes... that's how they make money! What you need to look into is getting a second ISP that feeds from a different data center than the one you have now. Now another option is to co-locate to a center that has multiple ISP feeds and place a publishing server

  • Sounds like bandwidth (Score:5, Informative)

    by Malduin ( 207683 ) <virtual_primate@ ... m ['ee.' in gap]> on Saturday February 04, 2006 @02:45AM (#14640478) Homepage
    It sounds like your problem is bandwidth. Either on the client-side, coming off your net to your ISP, or routing problems elsewhere on the Internet. The hard part is tracking down where the bottleneck is. Try to have multiple end-user test points. The company I work for has employees on a couple of different local ISPs and servers at various colo facilities. Try logging in to each machine and testing the stream. If it's across the board, you can safely bet it's your "unlimited" pipe to your ISP or a problem at your ISP. If it's a problem with a fraction of the clients, try doing traceroutes and see how the packets hop across the Internet and look for any similarities to see where the hang-ups can be. It's also possible that some clients just aren't getting the bandwidth they think they should be getting. Try everything you can to optimize your streaming application of choice. Reduce the number of FPS if you can. If it's only a talking head or something with little movement, try spacing out the keyframes more. Unless you're broadcasting a music video or movie, try using mono instead of stereo for audio. If it's a speech, you probably don't need CD-quality sound. Dropping the sound to 32, 24, or even 16kbps for a WMA/MP3/RA stream will still sound decent for something that doesn't have a lot of variation in sound.

    Also, if it is possible, try to expirament around with variable bit-rate streams for video and/or audio. That can come in handy if your target audience spreads from AOL dial-up in the middle of nowhere to your urban 8 Mbps+ broadband connections.

    In streaming, the big three big things that you have to worry about are the encoder's connectivity (to push the stream to the distribution point), the encoder's power (to make sure it can really compress all that video without overheating or dropping frames), and the distribution point's connectivity. Distribution servers don't use much bandwidth as all they do is simply regurgitate the data back out to clients without having to do any processing other than logging.

    I've been doing streaming for about 5-6 years now. I've done everything from web cam streaming to large convention streaming that put out 300+ Mbps of connectivity. By no means am I an expert (I've done streaming--it's not what I do), but everything above is my experience with it. Most of all, just stick with what you know and are comfortable with. Your client base will determine most things. Personally (even being a BSD guy), my preferred streaming setup is using Windows Media Encoder at the source, Windows Media Server 2003 at the distribution point, and Windows Media Player (or anything else that can play Windows Media v9) at the end-user. In my experience, it has been rock-solid and can be deployed quickly. If you're already running Windows 2000/XP/2003, all the software mentioned above is provided free-of-charge.

    Hope this helps.
  • Why, if you're concerned about bandwidth limitations would you encourage all your users to connect at once? Just like TiVo lets viewers watch at their leisure, podcasts let people download when they want to watch, not during some arbitrary time something interesting is happening.

    Set up a video podcast. You may host it all that way, but it's not designed around having everyone sucking bandwidth at the same time. You'll want a delayed download option anyway so those who can't sit in front of the screen whe
  • I'm certainly not doing it on as large a scale as you, but I use VLC from videolan.org.

    Not having done anything like it before, it was not TOO difficult for me to set up.
  • Well, unless it needs to absolutely be live, podcasting is a good alternative to streaming since it doesn't present the same problems and the audio quality is better. But if it needs to be live, maybe hook up with live365's service or something similar so you have co-hosted streams.

  • Wow (Score:1)

    by MEast ( 951927 )
    I expected more savvy from Slashdotters. A couple different companies offer mature P2P streaming solutions. Ping me offline if you want to know more. Beyond that, the only advice I can offer you is this: It's no longer cost-prohibitive for most to contract the services of a CDN. Don't assume that doing so will cost you far more than a DIY solution.
  • Stop using real media for your streaming.

    you need to pick a solid client, and the only thing that does a decent job is (irk, windows media) or flash, but flash eats bandwidth for lunch.
    • If you attempt to force me to use that DRM-laden virus-bus to view your stream, you had might as well stab yourself in the face with a fork, because otherwise I'll have to do it for you.

  • Look at what Pr0n is doing (Score:4, Interesting)

    by xoip ( 920266 ) on Saturday February 04, 2006 @08:08AM (#14641107) Homepage
    When ever you're in need of a streaming solution look and see what the Pr0n industry is up to. Awhile back Wired ran an article on an adult site [wired.com] who claim to offer P2P streaming Pr0n...great way to save on bandwidth if it works.

  • Contact the folks at Carnegie Mellon University's "End System Multicast" gang. Its a P2P video streaming sysytem!

    It's at http://esm.cs.cmu.edu/ [cmu.edu]

  • LX Systems(TM) technology helps multimedia providers efficiently market and distribute content to millions of consumers. Powered by Wurld Media's patent-pending Cooperative Communication Network(TM) (CCN(TM)) protocol, LX Systems harnesses the true power of Grid Computing and applies it to the commercial marketplace.

    http://www.lxsystems.com/index.html [lxsystems.com]
  • Perl based, works with ICS's DNS. Load balance based on load avg from uptime.
    Works great, we use it for application login servers, proxy pac file sites, citrix servers, etc. DNS will return IP address of least loaded machine. simple easy and definately cost effective.
  • Let's have a look to :

    http://www.peercast.org/ [peercast.org]
    and
    http://www.freecast.org/ [freecast.org] (java based)
    ;)
    yomguy
  • but some friends rely on PowerStream [powerstream.net] from time to time.

Slashdot Top Deals

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Close