One thing that I wish more folks did with DSP/media tech was to start with concepts instead of diving into details first.
Like, "how does a video codec work?" should start with: what is the problem? (reducing the bits per second required for a video stream, since it's big) and how? (don't send superfluous detail, since it's either redundant or imperceptible).
Than dive into the details of how color is represented, how images are structured, how 2d signal transforms work, the principle behind the DCT as a method of representing the same data with better energy compaction by decorrelating different components, and how that can be used advantageously to reduce the number of bits for a still image, then talk about shared data between images, etc etc.
I've noticed as a DSP guy that when I talk about things without concepts first that everyone's eyes glaze over. Although it is nice that everyone thinks it's black magic, good job security.
To be fair the article does that. The above URL just links to an anchor in the middle where it talks about codec implementation. For instance this quote from the article
"We learned that it's not feasible to use video without any compression; a single one hour video at 720p resolution with 30fps would require 278GB*. Since using solely lossless data compression algorithms like DEFLATE (used in PKZIP, Gzip, and PNG), won't decrease the required bandwidth sufficiently we need to find other ways to compress the video.
...
In order to do this, we can exploit how our vision works. We're better at distinguishing brightness than colors, the repetitions in time, a video contains a lot of images with few changes, and the repetitions within the image, each frame also contains many areas using the same or similar color."
278GB is a bit off. The real number is higher than that, but not by too much more, but they definitely messed up on their math somewhere. 1280 horizontal pixels times 720 vertical pixels times 8 bits per pixel color channel times 3 color channels (RGB) times 30 FPS times 60 SPM (sec per min) times 60 MPH (min per hour) divided by 8 bits to convert bits to bytes and finally divided by 1,024 bytes per kilobyte gives 291,600,000KB, exactly 291.6GB.
And now days, that kind of uncompressed video is more than feasible, at least in countries with developed gigabit internet capability, as you'd need just 634mbit of bandwidth to handle an uncompressed 720p stream at 30 FPS. Local storage on even first-gen SATA drives can hit double+ that.
Storage itself? Well, we've got the cloud, right? /s
You're mixing Si units and IEC units[1]. The article's measurement of 278 GB (sic) is really 278 GiB.
1280 horizontal resolution x 720 vertical resolution x 3 8-bit bytes per pixel x 30 frames per second x 3600 seconds per hour is 298,598,400,000 bytes per hour. 1GiB (1,024 bytes x 1,024 KiB x 1,024 MiB) is 1,073,741,824 bytes. Dividing that out gives ~278.09 GiB.
I'm responding directly to the GB claim. I'm very well-aware of binary prefix (in fact several of my other online names are those very words) and the general industry-wide mix-up that is used on the common consumer is to start with KiB and then just run that in plain units of 1,000 for MB and GB, which is what I went with.
I wish this about so many things. Instead of telling me that I should use some technology, tell me what problem it solves. How does the technology solve that problem?
You should use React. Why? What problem does it solve? How does it solve that problem? What did people do before React? When is React not the appropriate solution, or an overkill solution?
Yeah, this article had an odd progression. With the premise "How does a codec work?", it goes (Make a distinction between codec and container) -> (Discuss several codecs and their brief history and royalty scheme) -> (Use heavy industry jargon to discuss details that only someone who already gets compression could possibly understand).
How so? I took 3-4 DSP classes in university and none of them seemed particularly earth shattering. I think statistics and mathematic notation are a lot harder for students to work with. That said, information theory, which I would not consider a DSP course, was the hardest class I took. It requires mathematician’s math. None of that easy engineering math.
Like, "how does a video codec work?" should start with: what is the problem? (reducing the bits per second required for a video stream, since it's big) and how? (don't send superfluous detail, since it's either redundant or imperceptible).
Than dive into the details of how color is represented, how images are structured, how 2d signal transforms work, the principle behind the DCT as a method of representing the same data with better energy compaction by decorrelating different components, and how that can be used advantageously to reduce the number of bits for a still image, then talk about shared data between images, etc etc.
I've noticed as a DSP guy that when I talk about things without concepts first that everyone's eyes glaze over. Although it is nice that everyone thinks it's black magic, good job security.