On Thursday, November 24, 2011 7:50:07 AM UTC-8, Spooky wrote: > > On Thu, Nov 24, 2011 at 03:51:50PM +0530, arun kumar wrote: > > > *The basic bitrate formula is > > First, I don't see where you've included framing and CRC overhead. > You need to include that, unless you're only interested in the HDD-HDD > throughput. > > > S = Size you like to use in KB (note 700 MB x 1024*?* = 716 800 KB) > > KB is not a valid unit. I think you meant kB.... Uppercase 'K' has > absolutely *NO* meaning in this context. kilo is a lowercase 'k'. >
It is universal in the computer world to use "KB" to mean "kilobytes". You weren't aware of this? It's been like this for decades. "In non-standard use, K is often used as a symbol prefix to the units bit and byte to designate the binary prefix kibi = 210 = 1024." - < http://en.wikipedia.org/wiki/SI_prefix#Units_used_in_computing_and_telecommunications> > A = Audio bitrate in KB/s (note 224 kbit/s = 224 / 8*?* = 28 KB/s) > > V = Video bitrate in KB/s, to get kbit/s multiply with 8*?*. > > Same for both of these (but you got it right for kb/s). As for your > formula, I'm not wasting my time to even review it. Too much to do > this morning. > So basically, you chimed in merely to berate the OP for something they hadn't even done wrong, but not to answer their question? You have "too much to do this morning" but still found a few minutes to troll, eh? Good you have your priorities straight, at least. > Audio bitrate, A = 224 kbit/s / 8 = 28 KB/s > > (711 680 - (5400 x 28) ) / 5400 = 104 KB/s x 8*?* = 830 kbit/s. > > Again, you need to get your units straight.... > That chore list isn't getting any shorter! One knows the length of the video file up front, be it in seconds or KB or whatever unit, The only tricky thing is to determine what fraction of that size/length has been consumed at a particular point in playback. The technique depends in part on how precise you need to be. If you're just showing a progress bar, or calculating to, say, the nearest 5%, you can probably get away with ignoring the wobble factors like CRC, perhaps with a correction applied every 100 MB or so to reduce cumulative error. If you need ppm resolution your calculations will need to be more precise. You can measure time or you can measure stream size. If you know the number of seconds of the entire video, and you have the current tickmark from the video, then Bob's your uncle. You can skip all that fooferol of bytes/second, yada yada, and just use the timestamp-to-duration ratio. If you cannot get at that data, you can use the system clock to approximate, but you'd have to factor out any pauses, fast-forward or whatnot. I'd venture that dealing with rewind, pause and fast-forward will cause you more trouble than the raw calculation of ratio completed. It all hinges on determination of your current position in the video. -- Lew -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
