Streaming 101: The Basics - Codecs, Bandwidth, Data Rate and Resolution

The ability to produce streaming media has suddenly become a critical skill set for many web producers. However, though many of us use streaming-related terms like data rate and bandwidth every day, there may be some residual lack of certainty as to what they precisely mean and why they are important. For this reason, in this introductory article on streaming media concepts, I define file related terms like codecs, bandwidth, frame rate, data rate and resolution, and then delivery options like streaming and progressive download.

Codecs

Codecs are compression technologies with two components; an encoder to compress the file in your studio or office and a decoder to decode the file when played by the remove viewer. As the nifty capitalization in the previous sentance suggests, the term codec is a contraction of the two words encoder and decoder.

There are still image codecs (like JPEG), audio codecs (like MP3) and more video codecs than you could shake a digital stick at. Currently, there's H.264, VP6, Windows Media and Sorenson Spark in the streaming space, with MPEG-2 dominating the DVD and Blu-ray spaces. H.264 and MPEG-2 are huge in the network and particularly satellite spaces.

It's instructive to distinguish codecs from development and delivery environments. For example, QuickTime and Video for Windows are two development environments that support a number of codecs, including DV, MPEG-2, AVCHD and DVCPROHD, just to name a few. If you see an AVI file, you know it's a Video for Windows file; ditto for MOV and QuickTime. But, each format can contain multiple codecs.

Similarly, Windows Media, Flash and QuickTime are the most widely used distribution environments, and each can contain multiple codecs. For example, each delivery environment can deliver video encoded with the H.264 codec.

When producing your streaming files, you typically need to know which delivery environment you'll be using, since you may prepare the file differently for the different environments. For example, H.264 files encoded for Flash have an .f4v extension, but QuickTime encoded H.264 files with an MOV extension work fine for QuickTime delivery.

Ensuring Playback

To ensure that your files will play on the remote client, you need to make sure that they have the appropriate player installed. For example, with the Flash Player installed, a computer can play H.264 video delivered via the Flash distribution environment, but not Silverlight - for that, you'll need the Silverlight player.

It's not as complicated as it sounds; most producers know the distribution environment that they're targeting and that their potential viewers need the appropriate player. What's important is that you understand how a codec differs from a development or delivery architecture. Next time someone says "they're producing in Flash," you can ask, "Oh, which codec?"

Or, if someone commits the incredible gaffe of saying "I'm producing a QuickTime file," you can respond haughtily "please don't be so imprecise. Do you mean that you're encoding with a QuickTime-based encoder, or producing an MOV file? And, by the way, QuickTime is a developmental and delivery environment, but not a codec, so which codec are you using?"

Bandwidth

Bandwidth is the viewer's connection speed to the Internet. To a great degree, this connection bandwidth controls your viewer's ability to retrieve and play video smoothly over the Internet. Higher delivery bandwidths, like those enabled with cable and DSL, allow you to stream higher quality video to your viewer. In contrast, those viewers who still connect via modem won't be able to view most of the video available on the Internet, at least not in real time. More on that in a moment.

Note that in the early days of streaming video, producers encoded video to meet the bandwidth capabilities of their target viewers. That is, back when most viewers connected via modems, you had to produce postage stamp sized video compressed to somewhere south of 28.8 kilobits per second (kbps) or the viewers couldn't watch it. Today, with most viewers connecting via broadband capable of 1-2 megabits per second (mbps), most producers encode their video to meet quality and cost concerns.

For example, if you scan the websites of television networks and/or large corporations, most videos max out at 640x480 resolution at around 600-700 kbps, even though many viewers have the capacity to watch higher bit rate streams. That's because these producers have to pay for their bandwidth and have decided that 640x480 video at 600-700 kbps provides a sufficiently high quality experience to meet their viewer's needs. In short, back in the day, most producers encoded their files to meet the target bandwidth of their lowest common denominator viewer. Today, as bandwidth to the home has increased, it's largely a cost/quality issue.

Data Rate

The Data Rate (or bit rate) is the size of the video file per second of data, usually expressed in kilobits or megabits per second. When I say that ESPN distributes their video at 600Kbps, this means that each one-second chunk of audio and video comprises about 600 kilobits of data.

 
Figure 1. Setting the Data Rate for the file at 468 kbps.

As you can see in the Figure, you set data rate along with other configuration options during the encoding process. Note that to a large degree, data rate is the most important factor in streaming video quality. That's because all streaming codecs use what's called "lossy" compression, which means that the more you compress, the more quality you lose. For this reason, all other file characteristics (like resolution, frame rate or codec) being equal, the lower the data rate, the lower the quality of the compressed file.

Frame Rate

Most video starts life at 29.97 or 24 frames per second (fps). Usually, those that shoot at 24 fps deliver at that rate, while many producers that shoot at 29.97 fps deliver at 15 fps to save bandwidth. Though, in concept, it feels like dropping the frame rate by 50% would also drop the data rate by 50% with no loss in quality, it seldom works this way. Rather, according to the research that I’ve performed, the average data rate of video produced at 15 fps is about 20% lower than that produced at 30fps, not 50%. Still a substantial reduction, but often that comes at a subtle quality cost.

For example, when considering 15 fps, note that high motion video will look noticeably choppy to many viewers. In addition, tight facial shots, where lip synch is critical, often a look a bit out of sorts at 15 fps as well. When deciding which frame rate to use for your video, you should produce video at full frame rate and the lower rate, and then compare to see which delivers the best overall presentation.

Resolution

Resolution is the height and width of the video in pixels. Most video is original stored at either 720x480 (standard definition) or 1920x1080 (high definition), but gets sampled down to smaller resolutions for streaming, usually 640x480 resolution or smaller. That's because as the number of pixels in the file increase, you have to allocate more data rate to maintain the same quality.


Figure 2. A 640x480 video has four times the pixels of a 320x240 file.

For example, a 320x240 video has 76,800 pixels in each frame, while a 640x480 video file has 307,200, or four times more, which is evident in Figure 2. That means you have to apply four times the compression to achieve the same data rate, which usually means noticeably reduced quality. That's why data rate and resolution are integrally linked in quality related streaming decisions. As you can imagine, a video data rate of 250 kbps should produce excellent quality at 320x240 resolution, but would look disastrous at 640x480 resolution.

When producing streaming video, you have two options. Option 1 is to choose a data rate, then produce at the highest resolution that looks good at the data rate. Option 2 is to choose the desired resolution, then produce at the data rate necessary to produce good quality at that resolution. The key point is that you should always consider one when discussing the other. Just for the record, note that the most common video resolutions for 4:3 video are 640x480, 440x330, 400x300, 320x240, 240x180 and 160x120. The most common resolution for widescreen 16:9 videos are 640x360, 480x270 and 320x180.

Editor's Note:  You can find a more up-to-date article on bandwidth, data rate, and resolution here.

___________________________________________

If you're finding this article helpful, note that the author of this post now has a book out entitled

Video Compression for Adobe Flash, Apple Devices and HTML5. Click here for more information.

___________________________________________

Delivery Modes

It's important to recognize that when you deliver video over the Internet, you have multiple options, including streaming, progressive download and download and play. Note that the mode you choose will have significant impact on how you produce your files.

Streaming

The concept of streaming means that you click the button on a website, the video starts playing immediately, and it continues to play more or less smoothly to the end. When you stream video, the data rate of the encoded file must be somewhat smaller than the bandwidth capacity of the remote viewer; otherwise, the video will frequently stop playing. For example, if you try to watch ESPN.com on your broadband connection, the videos will probably stream smoothly from start to finish. If you connect via a 28.8Kbps modem, the video will stop and start like pre-strike Major League Baseball salary-cap negotiations.

Video delivered via streaming is delivered via a streaming server. Some streaming servers have specific requirements for files that they deliver; for example, files delivered via the Apple streaming server must be "hinted" for streaming. In addition, streaming performance is usually enhanced if you encode your file using constant bit rate (CBR) encoding, which I’ll define in a subsequent article.

So, when producing files for delivery via streaming, you should:

a. Encode at a data rate that's comfortably less than the bandwidth of most target viewers
b. Determine if there are any streaming server specific requirements for these files. More on this I future articles.
c. Encode using CBR data rate control.

Progressive Download

Progressive download is a fancy name for video delivered by a regular HTTP web server, and not a streaming server. In most instances, video delivered using this technique is stored to the viewer’s hard drive as it’s received by the server, and then played from the hard drive. In contrast, streaming video is usually not cached locally, so is more secure.

The benefit of progressive download (in addition to saving the costs and administration of a streaming server) is that though the initial playback may not be that smooth, if you wait long enough, the video will play smoothly because you've got a local copy stored to your disk. Apple reportedly pioneered this technique for George Lucas, who famously said, referring to one of his Star Wars movies, "there are 24 frames per second in this movie and none of them are optional."

I still remember my oldest daughter waiting hours for a high-resolution preview of the Disney movie Dinosaur to download over our modem connection. When it finally finished, it looked great. Like George Lucas, when you distribute your videos via progressive download, you can encode at a data rate high enough to ensure compressed quality. If you're concerned that your viewers won't wait even a few minutes for high-quality video, you can always post a low-resolution version for quick viewing and a high-resolution version for optimal quality.

However, note that the hard-drive caching involved with progressive download makes your video easier to pirate. Streaming is a much safer alternative because the video you deliver is never resident on the end user's hard drive.

Again, as with files produced for streaming, note that some progressive download technologies also have specific requirements. For example, files delivered to the QuickTime Player must be encoded with the Fast Start option selected.

Finally, most producers who deliver via progressive download produce their files via variable bit rate (VBR) techniques, which I’ll define in a subsequent article, since it delivers the optimum blend of file size and quality. To summarize, when producing for deliver via progressive download, you should:

a. Encode at a data rate the presents a decent balance between quality and delivery waiting time
b. Make sure that you comprehend any technology specific requirements for progressive delivery
c. Encode your files via VBR data rate control.

Download and Play

In some instances, you may choose to force the viewer to completely download the video file before they can play it. In this case, there are typically no production specific requirements for these files.

That’s it for now. In the next article, I'll dig a bit deeper, defining terms like codecs, and discussing compression related parameters like constant vs. variable bit rate encoding, and frame types like I, B and P frames. If you’ve ever stared at an encoding configuration screen and wondered what these terms meant and how to choose from the available options, tune in next week. 


Comments (46)

Tom Rupp
Said this on 2-26-2009 At 06:39 pm
I like to say thank you for posting these articles. They have been very useful. I first found you on www.streamingmedia.com in a video archive from 2008 west presentation. I was but into a role to become the expert at our company. I had an idea what I was trying to do, but these articles have helped go beyond and learn what I didn't know I need to learn. Thank You!!
admin
Said this on 2-26-2009 At 09:15 pm
Glad you liked it, and thanks for letting me know.

Best.

Jan
Said this on 3-11-2009 At 01:35 pm
Excellent Article, I will send link to my encoding clients.

Look forward to reading more...

Keith Eland
Jan Ozer
Said this on 3-11-2009 At 06:39 pm
Thanks, glad you found it useful.

Thanks for taking the time to let us know.

Jan
Linda
Said this on 3-19-2009 At 10:42 am
Thanks for bringing practical advice to to this thicket of options. I just watched a 17-min video on Wash Post in its large size (454x305) and it played absolutely perfectly. This is my possible goal ... I'm still stuggling to get smooth playing on 3-min videos in HD on YT and Vimeo. Will try your suggestions in this article and that of a commenter on the H.264 article ... looking forward to more articles, tips and tricks. Thank you.

Linda
Jan Ozer
Said this on 3-19-2009 At 12:18 pm
Linda:

Thanks for your note. Here's a piece you might find useful for YT.

http://www.pcmag.com/article2/0,2817,2330990,00.as...

Good luck!

Jan
Dimitar
Said this on 5-20-2009 At 10:54 am
First of all,great website.

How can we tell Streaming from Progressive Download?

Thanks
Jan Ozer
Said this on 5-20-2009 At 11:00 am
I don't think there's an easy way to tell. I know that if i'm trying to capture a file using FireFox's Download Helper, and the file doesn't appear in that utility, it's being streamed via a server.However, not all files that do appear are being transmitted via progressive download.

Sorry that i can't be more helpful
Adam
Said this on 5-29-2009 At 09:58 am
Thanks for posting your useful articles.

I have got a very basic question.

How do you calculate the bitrate of video stream of 320x240 pixels window size?
Jan Ozer
Said this on 6-1-2009 At 06:17 pm
Not sure what you mean. Do you mean how to calculate the best bitrate to use for your 320x240 video, or how to tell what bitrate of a compressed video file?

If the former, check out:

http://www.streaminglearningcenter.com/articles/2/...

if the latter, check out:

http://www.streaminglearningcenter.com/articles/23...
Gwen
Said this on 9-23-2009 At 12:56 pm
Great, only I was waiting for you to define the term Codec. It's in your heading, but you never mention it again. It means, precisely...everything you've discussed, or what?
Said this on 9-24-2009 At 01:19 pm
My bad:

Codec stands for compressor/decompressor or encoder/decoder, depending upon who you ask.

It means a compression technology that lets you encode in the studio and decode on the viewer's computer. There are still image codecs (JPEG/PNG), audio codecs (MP3, AAC) and video codecs (H.264, VC-1, VP6, MPEG-1, MPEG-2).
Said this on 12-12-2010 At 06:46 pm

Nice article.  Clearly and concisely explains the ins and outs of streaming media.

 

Thanks

Said this on 12-16-2010 At 12:29 pm

Thanks! Glad you found it useful.

:-)

nada
Said this on 2-10-2011 At 01:48 am

hi am nada from egypt and am in final year in media engineering department

my graduation project is iptv and my part in this project specify in streaming and there is question i want to ask

there is general rule that to encode media at lower rate that rated bandwidth ok, so why in single isdn and dual isdn rated bandwidth=media rate?

plz answer me as fast as u cannn

it's urgent and thanxxxxxxxxxx

Jan Ozer
Said this on 2-10-2011 At 11:53 am
Hi Nada:

Thanks for your note. Unfortunately, I'm not clear what you're asking. If you're asking whether you should encode for streaming over ISDN at 144 or 288 kbps, I would say no - you should leave some headroom (you always leave headroom). Is there a source for this recommendation?

if that's not the question, please ask again.

Thanks!

Jan
nada
Said this on 2-11-2011 At 10:08 am

ok

let me ask another question plz

why there is general rule to encode media rate lower than rated bandwidth?

Said this on 2-11-2011 At 11:39 am
Nada:

OK, that's easier. The media rate has to be lower than the rated bandwidth because otherwise the video probably won't play smoothly. Few transfer mediums work optimally at their maximum rated connection speed - let's use ISDN as an example.

The rated speed is 144 kbps. If you encode higher than that rate (say 200 kbps), the video can't transfer fast enough to play smoothly, so the video will play for a few moments, then stop waiting for additional data, then resume, then stop (and so on).

If you encode at 144 kbps, the video will stop anytime the device can't achieve the maximum transfer rate. To be conservative, you might encode at 80 kbps, which should stream smoothly.

Of course, this assumes that you value real time streaming over quality. If your deliver via progressive download and store the video locally on the viewer's computer (like movie trailers typically do) you can encode at very high data rate, but the user will have to download the file to view it smoothly. Back when I was using ISDN at home, my daughters would start playing the latest Disney trailer, which might take hours to finally download, but looked great once it did.

So, if you're looking for real time streaming, be conservative with your data rate and encode well below the maximum achievable by your tranfer medium. If you're looking for top quality and your viewers don't mind waiting, choose whathever data rate that you like.

Better?

:-)
nada
Said this on 2-12-2011 At 12:12 am

JAN thank u very much really great help, and i wanna to ask u another question from ur answer u mentioned that there is mediums work optimally at their maximum rated connection speed - let's useISDN as an example  so why isdn work optimally? 

Said this on 2-12-2011 At 09:58 am
Nada:

poor language choice on my part. It's been ten (very happy) years since I said goodbye to ISDN - it was awesome before broadband, but now it's a slow as a camel compared to my DSL line.

That said, as I recall, ISDN was a dedicated connection between my office and the phone company, a more or less direct wire. In contrast, most technologies today are shared at some level. For example, cable modems share bandwidth with all others on the same ring, cellular phones share bandwidth with all others connecting to the same tower. If you connect via wireless LAN, you share bandwidth with others connecting to the same router. Once you involve the internet, all sorts of things can happen.

There's a web site here in the states that you may be able to access - www.speedtest.net. This will measure the effective bandwidth of your connection. On my current DSL line, I get 10 mbps download, about 800 kbps upload. But that measures speed from my office to the nearest test connection.

If I was streaming video from CNN and tried to view a 10 mbps stream, chances are I'd never retrieve it in real time - others might be trying to connect to the stream at the same time, and CNNs servers might not be able to serve all at that speed. Or, there may be bandwidth issues between the various routers on the internet between my office and CNN. Or, someone also using DSL that connects to the same telephone central office might be downloading a huge movie, which might detract from my effective bandwidth.

So, to the best of my recollection, no video producer EVER rendered to the maximum bitrate supported by the viewer's connection speed, irrespective of the type of connection. In the old days, it was because you could never be sure to get the video there, due to all the factors discussed above.

Today, it's because it's too expensive. That is, you might think CNN could send me 5 mbps instead of 10, and that might get through. But CNN actually transmits at about 800 kbps because the stream looks good enough and they can serve 6 or 7 customers for the same cost as a 5 mbps stream. The highest bitrate that I've ever heard of is about 3.1 mbps, used by MTV for some of its premium shows.

Hope that helps.
nada
Said this on 2-12-2011 At 12:20 am

jan is it silly from me when ask u a help?

plz i wanna to understand how to configure my computer at public internet to stream my videos for users am already have broadcam streaming server software as apart of my project ,but the only problem that am fraid from open my firewall so plz can u help me.

Said this on 2-12-2011 At 09:59 am

Nada:

Glad to try to help, but i'm more of a compression guy rather than firewall guy.

Let's go off the site - email me at jozer@mindspring.com

:-)

Jay Lopez
Said this on 3-1-2011 At 04:11 pm

Please forgive the fact that this domain of expertise is beyond my profession, but I have a problem to begin to solve nonetheless.  I work for a water utility that is digitally video taping the internal condition of miles of sewage pipes in the collection system.  Unfortunately the storage of these video files is exceeding projections by 300% and the cost of adding more storage is of budgetary concern.  I need to figure out what I can to reduce the file size and maintain quality at the same time.  The software involved provides for adjusting: video standard (NTSC), Stream type (mpeg 1 or 2), resolution, and bit rate.  The vendor suggests we trial and error the settings to achieve our goal but that would take teams of staff members to shoot and reshoot sections of pipe at a cost that isn't appealling.  Can you offer any advice on how to approach the problem in the likely hopes of minimizing the number of trials?

Jan Ozer
Said this on 3-1-2011 At 09:20 pm

Jay:

A good starting point would be to divide the available storage space that you have by the seconds of video that you have (all compression schemes encode by applying a per second data rate). That would give you an idea of the data rate you would have to apply to the video to compress it to fit the available disc space.

Once you have that number, you'll know whether your quest is achievable or Quixotic. If you have even 400-500 kilobits per second (kbps), you could be OK so long as HD video isn't required. if you have 1200 kbps, you're in like Flint. if you have 20 kbps, you're SOL.

Hope this helps.

Jan Ozer

Jay Lopez
Said this on 3-3-2011 At 03:32 pm

Current video quality achieves a 1 gigabyte file for 1 hour of recording.  File type is mpeg1, bit rate is 2000Kbps, resolution 352x240, aspect ratio 4:3, frame rate 29.97 fps.  We can change these settings.  Could use Mpeg2 or 4, with same other settings but don't yet know the impact.  I suppose we could also try any # of these settings in combination to achieve an acceptable video quality with the smallest byte footprint but know where to start, really.  We still have 3 terabytes of a 9 terabyte storage array which means we'll run out of space in a year with know change.  We don't need movie quality video as much as a resolution to make out roots in pipes, cracks, etc.  I greatly appreciate your comments.

Jan
Said this on 3-4-2011 At 08:07 am
Jay:

You should be able to achieve acceptable quality by using the H.264 codec at 500-600 kbps, keeping all other parameters the same. That would cut storage requirements by a third right there.

What encoding tool are you using?

Jan
Bharathesh
Said this on 8-30-2011 At 12:00 am

Hi,

I am working on multimedia as a Multimedia tester in one company. I need to convert few Audio and Video with different bit and frame works for Streaming. I am not getting any free tool in google. can any one please let me know which is the good tool to download to convert audio and video with different frame and bit rates for STREAMING.

Said this on 8-30-2011 At 08:15 am
Said this on 9-17-2011 At 01:08 am

so what's the best codec for capturing in realtime and streaming, eh?

Said this on 9-17-2011 At 08:18 am
H.264 Jan
Tia
Said this on 11-17-2011 At 06:20 am

Hello there,

I would like to ask a simple question as i want to know more in depth about it.

"How can you prevent users from consuming too much bandwidth when streaming?"

Thanks for taking the time to read :)

Said this on 11-17-2011 At 08:48 am
Could you be more specific? You can limit user bandwidth by:

- using a streaming server, ensuring that if the viewer stops watching, there's little extra video sent to the viewer.
- reducing the number of videos that you offer
- password protecting your videos, and limiting consumption
- using YouTube to serve your videos, in which they pay for it.

If none of these work, provide more info and maybe I can help.

Jan
Neil
Said this on 12-6-2011 At 03:09 pm

Hello,

I am an indie filmmaker who is developing a site to stream my feature length movie.
I am having issues in finding proper parameters to achieve quality and streamability.
The original file format is XDCAM EX 1080p 24fps @35mbps.
I'm encoding into .h264

I would LOVE for the movie to retain 1080p resolution but I can't seem to get to a bitrate that is streaming friendly. I suppose I would consider scaling down to 720 res if I had to,

I've been told to have a bitrate around 512kbps but when I do that it looks like shite!

When I go higher with the bitrate the file size becomes unmanageable. The server I'm using has a 600mb max file size and when I get the movie below that treshold it is unacceptable in quality.
I found other servers that don't have that small a max file size but I'm still running into trouble with quality.
I guess my question is, what bitrate should I encode at if my goal is for the end user to stream my movie (not progressive download) on their home HD TV. A proper bitrate for both 720 and 1080 would be appreciated. THanks!! Im in dire straits here:)

Jan
Said this on 12-6-2011 At 04:01 pm
Neil:

I'm not sure you can get there from here. More specifically, you absolutely can't streaming 720p video at 512. At that resolution, YouTube is at 2 Mbps. I would start there.

Most H.264 encoders produce similar quality except for Apple Compressor, which is the worst at aggressive bit rates. Any other should do.

Use the high profile, CABAC enabled, key frame interval of 30, 3 b-frames, 5 reference frames. Audio at 128 kbps stereo AAC.

Read this:

http://www.streaminglearningcenter.com/blogs/the-e...

Consider adaptive streaming (watch and read here).

http://www.streaminglearningcenter.com/articles/en...

Hope this helps. If you need more, I'd be glad to chat. Here's how it works.

http://www.streaminglearningcenter.com/streaming-v...

Best.

Jan
Phil
Said this on 2-12-2012 At 09:00 pm

Hi,

unfortunately the link to the up-to-date article isn't working.

Maybe you could give me an advice.

What bitrate would be appropriate for a 720x576 h.264 live stream over the internet and what key frame frequency would you suggest?

It's mostly low motion mainly showing slides and speakers.

Wirecast is being used in case you have experience with it.

 

Thank you in advance!

Jan
Said this on 2-13-2012 At 12:31 pm
Here's the link:

http://www.streaminglearningcenter.com/articles/be...

Sorry for the problem. Sounds like 1 mbps would be a safe rate to try, with keyframes every 300 frames (or 25 if PAL.

Thanks.

Jan
Pavlos
Said this on 10-17-2012 At 05:45 am

Great and "to-the-point" article. Very useful and direct information. Through google searches, I came across many formulas of calculating bandwidth but the point is to understand the "how and why"...which you did. 

 

Thank you

Moses Johnson
Said this on 11-26-2012 At 01:07 pm

God bless you for using your VALUABLE time to help me and others!

We all appreciate you!!

 

moses Johnson. 

Said this on 11-26-2012 At 01:22 pm
Moses:

You're welcome; thanks for taking the time to write.

Jan
John Doe
Said this on 1-16-2013 At 12:12 pm

Thank you so much this website saved my life :)

Said this on 1-16-2013 At 01:03 pm
Wow, a post from the real John Doe. I'm impressed! Thanks for your note.

:-)
Seb
Said this on 2-1-2013 At 06:38 am

Hello, thanks for this helpfull article. I am trying to implement a live streaming communication, between an embedded camera (on a CPU limited environment) and a web browser. Whats do you think about WebRTC ? They have full C++ API, well documented. And dont need any plugin (javascript +html5 only). But video codec is VP8 and not H264. 

Thanks in advance and well done again for this website =)

Jan Ozer
Said this on 2-1-2013 At 08:57 am
Seb:

Sorry, I'm not a coder and can't really help. Thanks for the kind words; sorry I can't do any more for you.

Jan
Jereld
Said this on 5-10-2013 At 04:08 am

Hi Jan, Can your answer me this? What are 3 requirements that a client device needs for receiving audio and video feed through the internet. Aside from Codec? Thanks

john
Said this on 3-20-2014 At 12:57 pm

I'm pricing ISP service. I understand the download speeds but need help in computing what I can get with the various "Data Allowance" used in the different plans. For example, one plan has 12mbs download with a 10 GB data allownace per month. I have Netfilx but I'm not a gamer. I want to ensure that I my monthly allowance meets my needs without overpaying. BTW - nobody posts what happens if the monthly allowance is exceeded? Do they shut you down? Charge a higher fee?

TIA

jan
Said this on 3-20-2014 At 01:55 pm

John:

Thanks for your post. I honestly have no idea what happens. Whether 10 GB is sufficient depends upon your viewing and surfing habits. As a rule of thumb, figure 1/2 a GB (500MB) for each hour of video. With my two daughters and wife, I'm guessing we average 3 hours of TV a day, almost all of it from Hulu or Netflix. Plus one daughter is a gamer.

I have Comcast and don't know if there's a limit, but I haven't seen any extra charges.

Sorry I can't be more helpful.

Jan  

Post a Comment
* Your Name:
* Your Email:
(not publicly displayed)
Reply Notification:
Approval Notification:
Website:
* Security Image:
Security Image Generate new
Copy the numbers and letters from the security image:
* Message: