How does a video codec work?
github.com
github.com
Then you can try H.262/MPEG-2 and enjoy the intricacies of handling interlacing as well as being able to decode DVDs and a lot of existing content; and then there's H.263 which has intra prediction... I haven't gotten past the first two largely for reasons of time and other things to play with, but IMHO getting a basic implementation of a video decoder is not that hard especially when you're working from a standard.
This is H.261:
https://www.itu.int/rec/T-REC-H.261/en
Direct link to the spec itself is here:
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.26...
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.
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?
"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."
https://github.com/leandromoreira/digital_video_introduction...
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
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 felt a great disturbance in the Force, as if millions of engineers suddenly cried out in outrage and were suddenly offended.
Yet one more reason why Apple should be required to allow alternate browser engines IMO. Some will claim it's a battery issue but Apple has the resources to add hardware support for other codecs and I'm only guessing could already handle it just fine with their current "Bionic" chips. I'm not sure what other executes can be dreamt up. I'm sure they'll follow in the comments below.
Today, Apple is every bit as monopolistic and anti-competitive as Microsoft was during Peak Ballmer.
Apple not only uses standards-based compressed media formats exclusively, but the MPEG-4 file format is the QuickTime Movie file format (which Apple contributed to the standard).
One reason Google bought On2 and pushed VPx/webm/AV1 was because they didn't have video patents to use as trading chips in the cartel (On2 had several patents).
Full disclosure: I was co-founder of On2
As I'm sure you know, Apple joined AOMedia to demonstrate their support of AV1, and they're actively looking for Media Video Engineers with experience in AV1 and other video standards[1].
If there's been anti-standards gamesmanship, I'm not aware of it and would appreciate it if you'd share what you know.
[1] https://jobs.apple.com/en-us/details/200109105/media-video-e...
Play in Chrome (Mac/Win/Linux/Android) and Firefox (Mac/Win/Linux/Android) but not Safari (Mac/iOS).
Here's a few more
https://commons.wikimedia.org/w/index.php?search=webm
I would be nice if Apple would support open standards. It's unclear what their motive is for not supporting them.
What's unclear? They want to monopolize the market for smart phones, or at least hurt the competition and splinter the market. Clear as day: they are not good citizens, they are a publicly traded company with a fiduciary responsibility to maximize return to their shareholders.
Their website is not apple.org
Programmers don't work for free, Apple has to pay them. Motivation works the other way, they need a motive to support some tech.
If I remember, they were basically arguing against Google as it favored codecs that put costs on consumers, not the servers? Anyone remember this?
I think video patents have pretty much patented all the basics making new standards nearly impossible. So, organizations are stuck waiting to be sued if they adopt a codec. Apple seems to be waiting.
Apple joined the orgs but in the end made the dick move of not accepting a performant, free codec to become standard in HTML5 for purely selfish business reasons.
As far as support for open & free codecs goes, Apple have consistently been total assholes.
And AFAICT, All Smartphone shipped in the past 3 - 4 years has had Hardware H.264 encoder and decoder enabled. That is roughly 4.5 Billion of Smartphone and virtually all Smartphone users has H.264 decoder.
H.264 Video distribution over the Web is also Royalty Free in perpetuity.
H.265 is a bag of hurt, hopefully H.266, the MC-IF [1] will sort this out before release. The only major company missing from that list is Qualcomm.
I dont mind Royalty, there are huge amount and Research and Investment going each next gen codec. The problem is when they start being greedy. If they just collect $0.2 per hardware encoder & decoder shipped, that is a $400M annual revenue stream form the codec, or $4B to $8 Billion over its Codec lifetime split across different companies.
I guess reading source code of drivers and popular open-source video players will give me an idea, but it is too much work. Does anyone have a technical article highlighting differences between hardware decoders and important details.
Things like motion estimation, encoding the differences in frames, all that stuff is magic to the uninitiated. :) But this stuff is absolutely worth learning and every engineer should show interest :)
To not be liable to lawsuits and to support your own you need to come up with your own codec, resulting in your own platform and the circle starts once again.
Why in this age can we just not all work together and make something that’s usable by everything for everyone without any restrictions.