PDA

View Full Version : Solving a simple equation for resolution?


duby229
02-22-2008, 02:08 PM
Hey guys. I need a little bit of your brain power becouse in this case my own is inadequate. I've never really been any good at math, and I really could use some help... Here is the problem, I'm trying to figure out how to solve a problem where everything is constant except the resolution... Maybe this will help better...

BPP=0.25
Bitrate=1000000
Refresh=24*1000/1001
Source Width=704
Source Height=256

Now in order to solve for BPP we have to figure out what the aspect ratio is, and that is simply dividing the width by height. Then we divide the bitrate by the refresh rate by the aspect ratio. The solution is the bits per pixel.

Aspect=Source Width/Source Height

BPP=Bitrate/Refresh/Aspect

Or if we want to solve for the bitrate we can multiply the BPP by the width by the height by the refresh rate. Seems simple enough.

Bitrate=BPP*Source Width*Source Height*Refresh.

...............................

Now where I'm stuck is, assuming that Bitrate, BPP, Refresh, and Aspect are fixed values, how would I solve for the width and height? This has to be done while maintaining the aspect ratio of the original source. I havent been able to figure out how to do it. Anybody have any suggestions?

StringCheesian
02-22-2008, 03:07 PM
Assuming BPP stands for bits per pixel: No, Bitrate/Refresh/Aspect does not equal BPP. Bitrate divided by Refresh is bits per frame. Divide that by pixels per frame (width * height) and then you've got BPP.

Bitrate / Refresh rate is bits per frame, divide that by BPP and you've got pixels per frame. width * height also gives you pixels per frame. So:
Width * Height = Bitrate / Refresh / BPP
Multiply both sides by Aspect
Aspect * Width * Height = Aspect * (Bitrate / Refresh / BPP)
Aspect = Width / Height, so substitute:
Width / Height * Width * Height = Aspect * (Bitrate / Refresh / BPP)

Width * Width = Aspect * (Bitrate / Refresh / BPP)

Width = SquareRoot(Aspect * (Bitrate / Refresh / BPP))
Height = Width / Aspect

duby229
02-22-2008, 03:50 PM
Assuming BPP stands for bits per pixel: No, Bitrate/Refresh/Aspect does not equal BPP. Bitrate divided by Refresh is bits per frame. Divide that by pixels per frame (width * height) and then you've got BPP.

Bitrate / Refresh rate is bits per frame, divide that by BPP and you've got pixels per frame. width * height also gives you pixels per frame. So:
Width * Height = Bitrate / Refresh / BPP
Multiply both sides by Aspect
Aspect * Width * Height = Aspect * (Bitrate / Refresh / BPP)
Aspect = Width / Height, so substitute:
Width / Height * Width * Height = Aspect * (Bitrate / Refresh / BPP)

Width * Width = Aspect * (Bitrate / Refresh / BPP)

Width = SquareRoot(Aspect * (Bitrate / Refresh / BPP))
Height = Width / Aspect


Exactly what I was looking for. Thank you so much. Like I said, I'm not much for math, and I would have never figured that out on my own.

Let me see if I can understand what you've said....

Bits Per Pixel is Bitrate/Refresh/Width*Height, however substituting names with the values I supplioed above I get this result.

1000000/24*1000/1001/704*256=15136.378

That doesnt seem correct for bits per pixel. If I substitute width*height with aspect=width/height, I get this..

1000000/24*1000/1001/704/256=0.230

That seems about right to me.I'm not sure whats going on. I think I have it right, but based on what you've said I'm not sure anymore.

Although in the end your width calculation works perfectly. Thank you so much. I would have been scratching my head all day, and would not have figured it out.

StringCheesian
02-22-2008, 08:41 PM
Bits Per Pixel = 0.25 makes absolutely no sense.

For example: the number 42 has 2 digits. The number 5 has 1 digit. What number has 0.25 digits?

A normal Bits Per Pixel is 8, 16, or 32. Sometimes it can be 1, 2, 4, or 24. It is never a fraction.

Maybe 0.25 is actually the dot pitch of a CRT monitor or something like that?

EDIT: Oh I see, it's a compressed video stream. Ok, in that case maybe you could have a compression ratio of 4 pixels to 1 bit or 0.25 bits per pixel.

StringCheesian
02-22-2008, 08:50 PM
1000000/24*1000/1001/704*256=15136.378

That doesnt seem correct for bits per pixel. If I substitute width*height with aspect=width/height, I get this..

1000000/24*1000/1001/704/256=0.230

That seems about right to me.I'm not sure whats going on. I think I have it right, but based on what you've said I'm not sure anymore.

Order of operations. This:
1000000/24*1000/1001/704*256
is different from this:
1000000/(24*1000/1001)/(704*256)

Note the parentheses- they can help you keep the order of operations straight when you substitute.

duby229
02-22-2008, 09:29 PM
Order of operations. This:
1000000/24*1000/1001/704*256
is different from this:
1000000/(24*1000/1001)/(704*256)

Note the parentheses- they can help you keep the order of operations straight when you substitute.

Ok, I understand. So using the brackets more or less means "do this first" then do the operations outside the brackets last. Ok, I see. Thank you for your patience.

duby229
02-22-2008, 09:35 PM
Bits Per Pixel = 0.25 makes absolutely no sense.

For example: the number 42 has 2 digits. The number 5 has 1 digit. What number has 0.25 digits?

A normal Bits Per Pixel is 8, 16, or 32. Sometimes it can be 1, 2, 4, or 24. It is never a fraction.

Maybe 0.25 is actually the dot pitch of a CRT monitor or something like that?

EDIT: Oh I see, it's a compressed video stream. Ok, in that case maybe you could have a compression ratio of 4 pixels to 1 bit or 0.25 bits per pixel.

Actually the codec I'm using is x264, so yes it's compressed. I'm not sure how the compression algorithms work though, just that they do it in a way that compares blocks of colors rather then each pixel individually. They call it a quantizer matrix. Chances are likely that multiple pixels side by side will have very similar colors, and what x264 does it it allocates blocks and assigns these blocks the same color in order to save bits. That is why low quality encodes you can actually see blocks in the video. Also instead of using a 24bit RGB value for the color they use a 12bit YUY value that comes pretty dang close to 24bit RGB quality.

How exactly it is done, and the details involved I really dont know.