2,803 karma · joined July 22, 2012
Or, to quote Peter Lynch: "Far more money has been lost by investors preparing for corrections or trying to anticipate corrections than has been lost in corrections themselves."
[0] https://gitlab.xiph.org/xiph/theora/-/blob/main/lib/x86/mmxl... is an example of what we are talking about here.
When I was in grade school, I took notes for my classes using Tengwar (elvish) runes as a way to alleviate boredom and force myself to pay attention (just taking the table in Appendix E from Lord of the Rings and transliterating English letters into them). I could do this at a speed sufficient to keep up with a teacher talking, so pretty fast. I cannot read any of these notes today, much less write them.
If you don't use this stuff for a few decades, you do forget, even when it's just an alphabet.
I disagree. Video is such a large percentage of internet traffic and licensing fees are so high that it becomes possible for any number of companies to subsidize the development cost of a new codec on their own and still net a profit. Google certainly spends the most money, but they were hardly the only ones involved in AV1. At Mozilla we developed Daala from scratch and had reached performance competitive with H.265 when we stopped to contribute the technology to the AV1 process, and our team's entire budget was a fraction of what the annual licensing fees for H.264 would have been. Cisco developed Thor on their own with just a handful of people and contributed that, as well. Many other companies contributed technology on a royalty-free basis. Outside of AV1, you regularly see things like Samsung's EVC (or LC-EVC, or APV, or...), or the AVS series from the Chinese.... If the patent situation were more tenable, you would see a lot more of these.
The cost of developing the technology is not the limitation. I would argue the cost to get all parties to agree on a common standard and the cost to deploy it widely enough for people to rely on it is much higher, but people manage that on a royalty-free basis for many other standards.
I have never seen this standard reached for any real codebase of any size.
Even in projects with a reputation for a strong review culture, people know who the "easy" reviewers are and target them for the dicey stuff (they are often the most overloaded... which only causes them to get more overloaded). I've seen people explicitly state they are just "rubber stamping" PRs. Literally no one reviews every line of third-party dependencies, and especially not when they are updated routinely. I've seen over a million lines of security-sensitive third-party code integrated and pushed out to hundreds of millions of users by a handful of developers in a matter of months. I've seen developers write their new green-field code as a third-party library to circumvent the review process that would have been applied if it had been developed as a series of first-party PRs. None of that had anything to do with AI. It all predated AI coding tools. That is how humans behave.
Does this create ticking time-bombs? It absolutely does. You do the best you can. You triage and deal with the most important things according to your best judgment, and circle back to the rest as time and attention allow. If your judgment is good, it's mostly okay. Some day it might not be. But I do not think that you can argue that the optimal level of risk is zero, outside of a few specialized contexts like space shuttles and nuclear reactors.
I know. It hurts my soul, too. But reality isn't pretty, and worse is better.
No, HN has, "This has been thought of a thousand times before and it's not actually that good of an idea," people.
The motion search in a video encoder is highly optimized. Take your side-scroller as an example. If several of your neighboring blocks have the same MV, that is the first candidate your search is going to check, and if the match is good, you will not check any others. The check itself has specialized CPU instructions to accelerate it. If the bulk of the screen really has the same motion, the entire search will take a tiny fraction of the encoding time, even in a low-latency, real-time scenario. Even if you reduce that to zero, you will barely notice.
On the other end of the spectrum, consider a modern 3D engine. There will be many things not describable by block-based motion of the underlying geometry: shadows, occlusions, reflections, clouds or transparency, shader effects, water or atmospheric effects, etc. Even if you could track the "real" motion through all of that, the best MV to use for compression does not need to match the real motion (which might be very expensive to code, while something "close enough" could be much cheaper, as just one possible reason), it might come from any number of frames (not necessarily the most recent), etc., so you still need to do a search, and it's not obvious the real motion is much better as a starting point than the heuristics an encoder already uses, where they even differ.
All of that said, some encoder APIs do allow providing motion hints [0], you will find research papers and theses on the topic, and of course, patents. That the technique is not more widespread is not because no one ever tried to make it work.
[0] https://docs.nvidia.com/video-technologies/video-codec-sdk/1... as the first random result of a simple search.
If a very small percentage of the people own a large percentage of the wealth, it compounds. They literally cannot spend all of their income on consumption, except maybe by lighting piles of cash on fire, but that is not a route to doubling the real wealth of everyone in society.
That means that asset prices rise, and fewer people can afford property. Jobs concentrate near where rich people live, because they are the ones with disposable income to spend, making this worse. Transfer payments (rent) from ordinary people to the remaining property owners are high. Wages stagnate, because wealthy people spend most of their money on assets, not goods and services. Consumer demand decreases. Capital moves away from producing things that ordinary people need, because they can no longer afford them, and is instead allocated to producing luxury goods. Social mobility is low because low wages and high property prices make it impossible to work your way up.
The cycle is self-reinforcing, not self-correcting. Most of history throughout the world has consisted of a few very wealthy feudal lords and a large population of serfs.
Strengthening the political system might be nice, but post-Citizen's United, that does not seem to be the direction the US is headed, at least, nor is it in the interests of those who benefit most from the current system.
They didn't need to and couldn't have expected to. The real problem was that to get to a successful product, you needed to be willing to lose money for a long time. Android and iPhone were years ahead in terms of polish and optimization, and were not exactly sitting still. Firefox OS was going to be bad for a long time before it could ever be good, and did not have the luxury of its competitors being in the same state any longer (people don't remember how bad Android used to be). These are necessary growing pains for any incredibly complex system: mythical-man-month stuff that should be familiar to anyone in software development.
At the time, Mozilla had just renegotiated their search deal for $900 million over 3 years [0], with guaranteed payments that did not depend on actual search traffic. That was a lot more money than the project had ever seen before, and meant there was a limited window in which Mozilla could neglect the desktop browser in the hopes that the mobile OS would take off. In hindsight it proved to be too limited.
When Firefox OS was finally killed, management told us [1] something along the lines of, "The growth expectations we had going in to the project turned out to be unrealistic." I think it is okay to stop doing something when it is not working. This is just the inverse of Charlie Munger's advice to, "Figure out what works and do it." One wonders what could have been done with more realistic expectations, though.
[0] https://arstechnica.com/information-technology/2011/12/firef...
[1] I was also there, although outside of fixing a few media-handling bugs, I never worked on B2G directly.
"In the 1497 expedition of Vasco da Gama, the curative effects of citrus fruit were already observed and were confirmed by Pedro Álvares Cabral and his crew in 1507.
...
In 1614, John Woodall, Surgeon General of the East India Company, published The Surgion's Mate as a handbook for apprentice surgeons aboard the company's ships. He repeated the experience of mariners that the cure for scurvy was fresh food or, if not available, oranges, lemons, limes, and tamarinds.
...
It was not until 1747 that James Lind formally demonstrated that scurvy could be treated by supplementing the diet with citrus fruit, in one of the first controlled clinical experiments reported in the history of medicine." [0]
All of these things are bounded for actual codecs. AV1 allows storing at most 8 reference frames. The sequence header will specify a maximum allowable resolution for any frame. The number of motion vectors is fixed once you know the resolution. Film grain requires only a single additional buffer. There are "levels" specified which ensure interoperability at common operating points (e.g., 4k) without even relying on the sequence header (you just reject sequences that fall outside the limits). Those are mostly intended for hardware, but there is no reason a software decoder could not take advantage of them. As long as codecs are designed to be implemented in hardware, this will be possible.
I get a kick out of it when I see it, because you can understand how it happens. "Well, at least you tried."
The economist Ha-joon Chang likes to quote the statistic than in the 1950's, companies reinvested 65% of their profits back into growing the business, and today that number stands at 5%. The stock market overall returns more cash to shareholders through buybacks and dividends than it raises from investors by selling equity. It is no longer primarily a funding mechanism for companies. It's how investors cash out.
I don't even think it is about making Ph.D's write production code: I support that, as it makes them much more realistic about what is technically feasible (I say as a Ph.D who was written a lot of production code, and has had to work with Ph.D's who haven't). It is that whatever you are doing must be able to be tied directly to near-term revenue. Even just cost-savings is rarely attributed back to the people who created it, because no one wants to give you credit for money they didn't spend. And certainly no one wants to fund something that will not generate a tangible return for 5+ years, or that might not even succeed.
At one point I was asked, as a research Ph.D focused on very low-level software, to come up with subscription-revenue generating product ideas, because "subscription revenue" was the latest buzzword among upper management. They wanted me to build the next TikTok for them. And all I could think was, even if I had the product design talents to be able to do that, in a ZIRP era, why would I build it for you? We are not in that era any longer, but it lasted a long time, and its passing has only made people more near-term focused.
> Could agree. Not sure of Google's real contribution to those.
They were not the only contributor (I was the technical lead for Mozilla's efforts in this space), but they were by far the largest contributor, in both dollars and engineering hours.
I think this may be domain-specific. I help maintain several open-source audio libraries, and wind up being the one to review the patches when people contribute SIMD for some specific ISA, and I think without exception they always get the tail handling wrong. Due to other interactions it cannot always be avoided by padding. It can roughly double the complexity of the code [0], and requires a disproportionate amount of thinking time vs. the time the code spends running, but if you don't spend that thinking time you can get OOB reads or writes, and thus CVEs. Masked loads/stores are an improvement, but not universally available. I don't have a lot of concrete suggestions.
I also work with a lot of image/video SIMD, and this is just not a problem, because most operations happen on fixed block sizes, and padding buffers is easy and routine.
I agree I would have picked other things for the other two in my own top-3 list.
[0] Here is a fun one, which actually performs worst when len is a multiple of 8 (which it almost always is), and has 59 lines of code for tail handling vs. 33 lines for the main loop: https://gitlab.xiph.org/xiph/opus/-/blob/main/celt/arm/celt_...
One of the things I was told in my mandatory DEI training was that male job applicants will frequently apply for jobs even when they satisfy less than half of the required qualifications, but female job applicants rarely do. Additionally, language in the job description that hints at a stereotypical 'tech bro' culture can also be off-putting to female candidates. So just by being aware of these issues and paying attention to them when crafting your job posting, you can get a more representative distribution of applicants. You then evaluate those applicants on their actual merits.
But if you are scaring off half the population before they even get to the interview, you are greatly reducing the chances of hiring the best candidate, and certainly not treating the individuals equally.
That is just for gender, but I am certain you can find similar things for race.
And surprisingly hard to do well in practice. My guess is that the problem is that there is very little information in your training dataset (because only the transition from "talking" to "done talking" matters), but the actual knowledge required to perform well is large (up to and including full speech recognition, in theory). So even with over a terabyte of training data, your choices are a small model that performs badly or a large(r) model that overfits severely.
It's possible there was something I was overlooking when I tried it, though. I couldn't think of a good way to confirm my guess experimentally.
Actual traffic enforcement does not seem to produce this result. This woman is fairly famous on Reddit for her erratic driving, and was reported in 2019 as having been involved in 31 crashes since 2000: https://www.wral.com/story/lawyer-stayumbl-driver-a-victim-o...
She is still driving (with a new license plate after 2019): https://old.reddit.com/r/bullcity/comments/1ji3y82/jesusdos_...
* It has to be limited in scope. It cannot just be "everything we give or tell you is confidential information."
* Confidential information has to be clearly marked or indicated.
* It has to be limited in duration. Not, "You are required to take this information to your grave."
If your project does not have lawyers backing you up, you might not know to ask for these things, or might not think you have the negotiating leverage to get them. But I think they make a real difference to a developer working on an open-source project, and I encourage anyone presented with an NDA to insist on them.
The Netflix post is sort of bizarre. They claim to be optimizing for minimum mean-squared error (MSE) given a conventional (bicubic) upscaling process [0], but... that should have an analytic closed-form solution, as this post states? You definitely do not need multiple layers of neural networks to achieve it. Then they present VMAF results, but VMAF is very much not equivalent to MSE, so you have no idea if they even improved the metric they optimized for. Subjective results are similarly unpersuasive: it isn't clear if "the deep downscaler was preferred by 77% of test subjects" means they thought it was closer to the original or simply "better" than Lanczos[1]. Netflix may not care: longer watch times are longer watch times. But as an engineer you might want to know if that is because you actually achieved the thing you were optimizing for, or it is due to an artifact of the process that might go away the next time you change something to actually improve what you were optimizing for. You can famously make people prefer one audio track over another by making it louder, and video has similar things around sharpness and contrast (and now, thanks to ML, hallucinated detail).
I agree that you can do better than Lanczos for large downscale factors [2]: you need to do something area-based, like you suggest (I have not looked at OpenCV's implementation, but it could be fine). The biggest thing to get wrong is handling gamma incorrectly, but the right thing to do depends on whether you intend to display the result at the downscaled size or upscaled back to the original size as seems to be assumed here (and whether or not your upscaler is gamma-aware, which it probably isn't).
As an aside to those struggling to see the visual differences, make sure you are looking at the image in its original (1874x1596) resolution: https://redvice.org/assets/images/netflix-downscaler-compare... (or right-click, View Image on the original page). Otherwise you also have your browser's resampling algorithm in the mix. To my eyes on my display there is also a pretty big color shift in the featureless pink background of the painting on the right wall, but when I look at the actual pixel values, that appears to be an optical illusion. Subjective comparison is hard!
[0] Unlike the post, I think this is reasonable. In the past, we did experiments that showed that optimizing for bilinear when nearest-neighbor is used (for chroma) is worse than optimizing for nearest-neighbor when bilinear is used. I suspect something similar will be true for bicubic and bilinear, but these days it may be safe to assume that you will get at least bicubic upscaling (for luma), because bilinear luma looks really bad. I haven't done a recent survey of actual playack devices, though.
[1] It's also not how you report subjective test results: what was the statistical significance? There are standard protocols for these kinds of tests and it would have been helpful to cite which one was used.
[2] Nobody ever says what downscaling factors are being tested here. The example graph shows 1080p to 342p, or ~3.16x, but Netflix goes as low as 144p (from, e.g, 2160p), so they can get pretty large (15x) in practice. A 6-tap filter is not going to cut it.
I would not really say this is true. BWT is spiritually similar to the various Prediction by Partial Matching (PPM) algorithms, except that instead of needing to decide how much context (i.e., preceding symbols) to use to model the next symbol, and carefully learning the probabilities for each unique context, it naturally sorts symbols with the same context (of _any_ length) so they appear next to each other, and relies on adaptation to update your learned statistics as you move from one context to the next, without ever explicitly tracking context boundaries [0].
[0] N.J. Larsson, "The Context Trees of Block Sorting Compression," 1998. https://ieeexplore.ieee.org/abstract/document/672147