What is bit rate?

[Blueprint]

I've always looked at different sources with different bit rates and just accepted that the file with the higher bit rate has the best quality. But what does bit rate actually mean? How can bit rate vary yet the fps stays the same? 

 

Let's say I had a 1920x1080p video which was of a higher bit rate in comparison to a video which was also 1920x1080p. If each video has the same frame rate and the same number of pixels but different bit rates, what has actually changed by increasing the bit rate??? How can one be higher quality if they have the same number of pixels?

 

Thanks,

Blueprint

[needmorewood]

bits per second if im not mistaken

 

higher bitrate is ussualyl equal to higher quality since more data is passing through but different codecs are more efficiant and such so yea. but if its the same codec then higher bitrate is better than low bitrate in terms of quality

 

im probably missing something important to say

[BlackMamba]

the higher the bitrate the higher the quality, because each frame contains more information (color, depht, ecc.)

[Blueprint]

the higher the bitrate the higher the quality, because each frame contains more information (color, depht, ecc.)

Do you know how one pixel can contain more information?

[colonel_mortis]

The bitrate is the rate at which pieces of information occur in a file (that has a time such as a video or sound file). For example, in a sound file with a bitrate of 4200Hz, the file will contain information on the position of the wave 4200 times per second. If you increase this, there is more resolution to the wave, so it more precisely emulates the analogue format of the sound, and therefore sounds better. With video, the same is basically true, but more clearly visible. On YouTube, you can often notice that the video doesn't look as good as the original, especially with different shades of black, because the video has been compressed so each pixel holds less information. A 1080p video at 1FPS (to make the maths easier ) in black and white will be 1920 * 1080 <video resolution> * 1 <Frame rate> * 1 <The colour depth of each pixel - they only need 1 bit of information to store the colour> = 2073600b/s = 2Mb/s = 259 KB/s. If you increase it so each pixel can be 4 colours, you need twice as many bits to hold the information, so it will run at 4Mb/s = 500kB/s. By increasing the bitrate, you increase the amount of data the file can hold, and therefore how close it is to the original file, at the cost of the size of the file.

I have not mentioned the different codecs that you can use, such as H.264, which can reduce the file size without degrading the video, because they just serve to complicate things, but suffice to say that they are why YouTube videos don't require massive internet connections.

[s3ns3]

Do you know how one pixel can contain more information?

i lold sorry. its not about the pixels.its about how much data. so we have the same 10 min clip of any resolution . one is 5 gb and other 2.5. with the 5 gig one you have more data comming at you per second. so higher quality. check a full blu ray movie and its rip to save space. the original looks better

[BlackMamba]

Do you know how one pixel can contain more information?

 

In a video that has a 8 bit color depht each pixel can contain one of 256 colors, while a 24 bit video can have something like 16 million colors

[Blueprint]

The bitrate is the rate at which pieces of information occur in a file (that has a time such as a video or sound file). For example, in a sound file with a bitrate of 4200Hz, the file will contain information on the position of the wave 4200 times per second. If you increase this, there is more resolution to the wave, so it more precisely emulates the analogue format of the sound, and therefore sounds better. With video, the same is basically true, but more clearly visible. On YouTube, you can often notice that the video doesn't look as good as the original, especially with different shades of black, because the video has been compressed so each pixel holds less information. A 1080p video at 1FPS (to make the maths easier ) in black and white will be 1920 * 1080 <video resolution> * 1 <Frame rate> * 1 <The colour depth of each pixel - they only need 1 bit of information to store the colour> = 2073600b/s = 2Mb/s = 259 KB/s. If you increase it so each pixel can be 4 colours, you need twice as many bits to hold the information, so it will run at 4Mb/s = 500kB/s. By increasing the bitrate, you increase the amount of data the file can hold, and therefore how close it is to the original file, at the cost of the size of the file.

I have not mentioned the different codecs that you can use, such as H.264, which can reduce the file size without degrading the video, because they just serve to complicate things, but suffice to say that they are why YouTube videos don't require massive internet connections.

How can a pixel be 4 colours? I thought a pixel was a combination of rgb producing 1 solid colour equalling 1 bit of information?

[rashdanml]

Bit rate in the most general sense is simply a data transfer rate. Data in a computer is stored as binary (0 or 1), which is also the equivalent of 1 bit. 8 bits = 1 byte. 

Data transfer rate could mean anything. For a video, it's usually that much data in a single second of video. For internet speeds, it's the rate at which you're transferring data to or from (upload or download) the rest of the internet. 

[applebook]

This is far more complicated than it needs to be. 

 

What happens when you compress a standard JPG image? The pixels are the same, but the quality deteriorates noticeably, and the file size is smaller. It isn't just color depth. You can compress a 10-bit image down while maintaining the same color depth. 

[LAwLz]

Please... Everyone talking about depths please stop. That is not the reason why (the vast majority) of videos have different bit rates yet the same resolution.

OP, the resolution is just the maximum number of pixels that can be different at any one time. In a 720p video a maximum of 720 vertical pixels can be different at any time. However, when you compress something, like a movie, all those pixels gets changed to be more similar, so that they take up less info.

 

How can it take up less info if pixels are similar to each other? Well imagine if all pixels were different completely different. Each pixel would take up 8bits. To make it easy let's assume we have a 10x10 image. If each pixel were unique then we would need 800 bits to save it (assuming a bit depth of 8bits per pixel). Now, let's imagine if we changed the image slightly so that the last 3 columns on the right side were the exact same color. How big would that picture be? We take 7 (number of columns) times 10 (number of rows) times 8 (data needed to save the specific color). That's 560 bits. Now we have to save the last 3 columns. We don't need to save each individual pixel though, because they are all the same. So let's assume we use 8 bits to tell the computer which color it is, and then 8 bits to tell it which pixels should be that color. Suddenly we have filled 30 pixels by only using 16 bits. 560 + 16 = 576 bits.

Our image with 3 columns of the same color is suddenly 224 bits smaller than our previous image, even though they are the same resolution.

 

Of course this is extremely oversimplified but that's the basics of how lossy compression works. By removing info, at the cost of quality, you can make files smaller (reducing bit rate).

 

 

Here is an example. Both of these images are 400x400 in resolution, but one has been compressed and the other one has not.

As you can probably tell, the one on the left is not as smooth in the transition as the one on the right. That's because the one on the left has been compressed by making colors more similar to each other, so that the computer can go "yeah, fill this whole area with this color", instead of having to address each individual pixel.

 

Edit: You got good eyes MG2R. :3

[MG2R]

There seems to be a lot of misinformation on this topic.

 

A bitrate simply tells you how many bits per given time interval (usually one second) a system (must) process(es) when it processes a given bitstream. For example, if you are downloading a file from your NAS to your local machine over a gigabit ethernet connection, in the ideal case you would do this at a bitrate of 1 gigabit per second. Seems easy enough. Now this also comes in to play when you are processing audio or video files to present them to the user (make them audible or visible).

 

In raw media files (meaning that the files have undergone no compression or encoding), the bitrate directly tells you something about the quality of the file. For audio files, this translates to a high sampling rate and/or a high number of bits per sample. The sampling rate defines how many samples per second the recording equipment will take from the audio signal. The Nyquist-Shannon criterion tells us that, in order to accurately reproduce the audio signal, the sampling rate must be at least twice as high as the highest frequency in the signal. For audible sounds, the highest frequency is generally 20 kHz, meaning that the sampling rate needs to be at least 40 kHz. Common sampling rates are 44.1 kHz (CD), 48 kHz and 96 kHz (DVD).

 

Of course, the number of samples alone isn't enough to get to the bitrate. The bit rate in raw audio files equals the sampling rate times the number of bits per sample. This last factor tells you how accurate the Analog-to-Digital Converter (ADC) can interpret the analog voltage it is given. The more bits, the more discrete levels it can distinguish, thus the more accurate the representation of the analog signal in the digital system will be. So, with raw audio files, a higher bit rate means either a higher sampling rate or a higher number of bits per sample.

 

Now, in the preceding story, I've always talked about raw files. These are files that are in no way compressed. It's easy to explain the system with those, because no voodoo magic has been involved with them. When you compress the data (for example with the MP3 codec), you lower the bitrate. In the ideal world, you compress lossless and thus you reduce the bitrate while still keeping the information (quality) in the file the same. This is possible, but to a limited extent. In order to compress audio files even further, MP3 for example encodes lossy, meaning that the reduce the bitrate so far that part of the original information is lost. Different codecs do this in different ways. This is why you can't just compare bitrates to know which file has the best audio quality: some codecs are better at compression than other, meaning that they need less bits to represent the same information (quality). When you compare the bitrates of different files encoded with the same codec, however, the bitrate will tell you which file holds the best representation of the original file.

 

With moving pictures, a similar story is true. Here, the bitrate equals the number of bits per frame times the number of frames per second. The higher the number of frames per second, the less blurred the image will be (motion blur lowers). The higher the number of bits per frame, the higher the picture quality per still image. This number of bits per frame equals the number of bits per pixel times the number of pixels in the frame. Usually, the number of bits per pixel is 24 (8 bit for resp red, green and blue), although 10 bit colors do get used as well. In the latter case, you would end up with 30 bits per pixel. This number corresponds to the number of bits per sample in audio files: how higher the number of pixels used to represent a color, the more accurate that color will be represented. The number of pixels per frame is pretty self-explanatory: you multiply the width and height of the frame.

 

The same story also goes here: how higher the bitrate (given the same encoding between two files), how higher the quality of the video.

 

For those still doubting: there is no such thing as a bitrate for pictures, because they don't get processed on a timely basis.

 

Bitrates also get applied to completely other things, such as compressors, processors, disk drives and so forth. The meaning of a bit rate may be different form application to application, but the definiton will always be "the number of bits something processes per time interval".

[MG2R]

As you can probably tell, the one on the left is not as smooth in the transition as the one on the right. That's because the one on the right has been compressed by making colors more similar to each other, so that the computer can go "yeah, fill this whole area with this color", instead of having to address each individual pixel.

Must be the one on the LEFT, no?

[LAwLz]

With moving pictures, a similar story is true. Here, the bitrate equals the number of bits per frame times the number of frames per second. The higher the number of frames per second, the less blurred the image will be (motion blur lowers). The higher the number of bits per frame, the higher the picture quality per still image. This number of bits per frame equals the number of bits per pixel times the number of pixels in the frame. Usually, the number of bits per pixel is 24 (8 bit for resp red, green and blue), although 10 bit colors do get used as well. In the latter case, you would end up with 30 bits per pixel. This number corresponds to the number of bits per sample in audio files: how higher the number of pixels used to represent a color, the more accurate that color will be represented. The number of pixels per frame is pretty self-explanatory: you multiply the width and height of the frame.

If we are going to be really picky, then a higher bit rate will most likely not reduce motion blur. The motion blur will be less banded though, and everything will look sharper.

Also, if you are referring to 10bit H.264 files then that's not 10 bit color depth the 10bit refers to, it refers to the internal precision. With a 10 bit signal you can have more relative errors without losing quality as you can with an 8 bit one. That allows for higher compression without actually using up more space. That's why you often see these 10 bit files being SMALLER than the 8 bit files (about 20% with a perfect encoder) with the same quality.

 

Bit rate is not how much info has to be processes either. It is how much data is being fetched/written. A 10 bit H.264 file that's 10MB will require far more processing than an 8bit H.264 file that's 10MB, because the 10bit file will be far more complex, even though they both will have the same bit rate.

 

Other than that, you're spot on.

 

Edit: Need to polish my reading comprehension.

[MG2R]

If we are going to be really picky, then a higher bit rate will most likely not reduce motion blur. The motion blur will be less banded though, and everything will look sharper.

Well higher bitrate means either more bits per frame (better image quality) or more frames per second (less motion blur).

 

 

Also, if you are referring to 10bit H.264 files then that's not 10 bit color depth the 10bit refers to, it refers to the internal precision. With a 10 bit signal you can have more relative errors without losing quality as you can with an 8 bit one. That allows for higher compression without actually using up more space. That's why you often see these 10 bit files being SMALLER than the 8 bit files (about 20% with a perfect encoder) with the same quality.

I'm talking about raw files, where the bits per (sub)pixel correspond to the accuracy of the actual sensor. Higher number of bits to represent a color = more accurate color. I'm in no way an expert on compression and encoding techniques and thus can't comment on the whole h.264 thing, sorry.

 

 

Bit rate is not how much info has to be processes either. It is how much data is being fetched/written. A 10 bit H.264 file that's 10MB will require far more processing than an 8bit H.264 file that's 10MB, because the 10bit file will be far more complex, even though they both will have the same bit rate.

If, for example, 10Mbps gets fetched, that means that 10Mbps gets processed Internally, the CPU (or whatever hardware would be the case) might need to do more calculations and thus be more powerful to actually process the 10 Mbps. But it's still processing 10 Mbps either way.

 

 

Other than that, you're spot on.

Thanks, coming from you, that means something

[LAwLz]

Well higher bitrate means either more bits per frame (better image quality) or more frames per second (less motion blur).

Fair enough.

 

I'm talking about raw files, where the bits per (sub)pixel correspond to the accuracy of the actual sensor. Higher number of bits to represent a color = more accurate color. I'm in no way an expert on compression and encoding techniques and thus can't comment on the whole h.264 thing, sorry.

Ah I see. I thought you were talking about regular videos people view. Sorry.

 

If, for example, 10Mbps gets fetched, that means that 10Mbps gets processed Internally, the CPU (or whatever hardware would be the case) might need to do more calculations and thus be more powerful to actually process the 10 Mbps. But it's still processing 10 Mbps either way.

Well this is getting into semantics, but my definition is that if 10MB gets processed, then the processor has counted 10MB. If you ask me, if it fetches 1MB and do calculations on that twice, then it has processed 2MB of data. Again, it's semantics and in the end we mean the same thing, just have different definitions of the words. I don't know definition is correct so maybe I am completely wrong here.

 

Thanks, coming from you, that means something

Aww thank you. That makes me glad to hear.

[squirrl]

baby don't hurt me.

[MG2R]

Ah I see. I thought you were talking about regular videos people view. Sorry.

Yes, I purposefully mentioned 'raw' multiple times. I think this topic is best explained with raw files, where the effects of compression/encoding doesn't come into play yet. It gets rather confusing when the explanation starts immediately with compressed files

 

 

baby don't hurt me.

I don't even know what this has to do with anything mentioned here...

[squirrl]

I don't even know what this has to do with anything mentioned here...

Read the title.

[MG2R]

Read the title.

HAHA, oh God, I so hope you're referring to this

[Guest]

I've always looked at different sources with different bit rates and just accepted that the file with the higher bit rate has the best quality. But what does bit rate actually mean? How can bit rate vary yet the fps stays the same? 

 

Let's say I had a 1920x1080p video which was of a higher bit rate in comparison to a video which was also 1920x1080p. If each video has the same frame rate and the same number of pixels but different bit rates, what has actually changed by increasing the bit rate??? How can one be higher quality if they have the same number of pixels?

 

Thanks,

Blueprint

The rate of bits

[Blueprint]

Now, let's imagine if we changed the image slightly so that the last 3 columns on the right side were the exact same color. How big would that picture be? We take 7 (number of columns) times 10 (number of rows) times 8 (data needed to save the specific color). That's 560 bits. Now we have to save the last 3 columns. We don't need to save each individual pixel though, because they are all the same. So let's assume we use 8 bits to tell the computer which color it is, and then 8 bits to tell it which pixels should be that color. Suddenly we have filled 30 pixels by only using 16 bits. 560 + 16 = 576 bits.

Our image with 3 columns of the same color is suddenly 224 bits smaller than our previous image, even though they are the same resolution.

 

 

 

 

 

With moving pictures, a similar story is true. Here, the bitrate equals the number of bits per frame times the number of frames per second. The higher the number of frames per second, the less blurred the image will be (motion blur lowers). The higher the number of bits per frame, the higher the picture quality per still image. This number of bits per frame equals the number of bits per pixel times the number of pixels in the frame. Usually, the number of bits per pixel is 24 (8 bit for resp red, green and blue), although 10 bit colors do get used as well. In the latter case, you would end up with 30 bits per pixel. This number corresponds to the number of bits per sample in audio files: how higher the number of pixels used to represent a color, the more accurate that color will be represented. The number of pixels per frame is pretty self-explanatory: you multiply the width and height of the frame.

 

Wow, amazing responses. Thank you very much Very clear and helpful. One last question: How are pixel colours processed? I know you said that one pixel is 8bits of information, but how can different colours all be 8bits? And if you had a 10x10 resolution square and all the pixels were red, why would it have to remember less information? Surely it would have to remember the colour of each individual pixel no matter what the colour of the other pixels are.

[colonel_mortis]

Wow, amazing responses. Thank you very much Very clear and helpful. One last question: How are pixel colours processed? I know you said that one pixel is 8bits of information, but how can different colours all be 8bits? And if you had a 10x10 resolution square and all the pixels were red, why would it have to remember less information? Surely it would have to remember the colour of each individual pixel no matter what the colour of the other pixels are.

So with the 8 bits thing, on raw video, each pixel has a specific size (depth), so it doesn't matter what colour you store in it, they will all be the same to avoid confusing the renderer. Compressed images/video is quite different, and depends entirely on the codec used.

Your second question is only relevant to compressed video, and the compression codec could allow you to (and most so I think) compress a block of pixels that are the same colour and reference them together to reduce the size of the file. Again, on raw video this would not happen because there's no codec, it just stores the information for each individual pixel on each frame. Fraps videos can get so large because in order to improve performance, the codec used is very basic and does not reduce the size too much.

[Blueprint]

So with the 8 bits thing, on raw video, each pixel has a specific size (depth), so it doesn't matter what colour you store in it, they will all be the same to avoid confusing the renderer. Compressed images/video is quite different, and depends entirely on the codec used.

Your second question is only relevant to compressed video, and the compression codec could allow you to (and most so I think) compress a block of pixels that are the same colour and reference them together to reduce the size of the file. Again, on raw video this would not happen because there's no codec, it just stores the information for each individual pixel on each frame. Fraps videos can get so large because in order to improve performance, the codec used is very basic and does not reduce the size too much.

Ah I understand now Thanks

[MG2R]

Wow, amazing responses. Thank you very much Very clear and helpful. One last question: How are pixel colours processed? I know you said that one pixel is 8bits of information, but how can different colours all be 8bits? And if you had a 10x10 resolution square and all the pixels were red, why would it have to remember less information? Surely it would have to remember the colour of each individual pixel no matter what the colour of the other pixels are.

Colors are represented in RGB space. We only store the amount of red, green and blue we need to recreate the original color. For example, you can select a color on this website and check out the red (R ), green (G) and blue (B ) components that make up that color. Most sensors use 8 bits per component, meaning that you can represent 256 individual levels per component. 256*256*256 make for approx 16.8 million colors. This means that there is not 8 but 24 bits per pixel.

 

An image (either a still picture or a frame in a movie) is simply a collection of RGB trios, one for each pixel. If you had a 10x10 pixel image and all pixels are pure red. Each pixel would be represented by (255,0,0) for (R,G,B ) respectively. In raw format, the file would be 24*10*10 bits = 2400 bit = 300 bytes. Compression techniques can lower this number. For example, a compressor could just store "100 pixels are red", which would amount to 7 bits (100) + 24 bits (the color).