I know it's not public domain per-say, but for me, the thing that's most exciting is that in 2025, the last remaining patents on the h.264 (AVC) video codec will expire [1].
Now if only HEVC wasn't such a hot patent / licensing mess.
If you translate it literally, "per" is closer to "for".
If you don't translate it literally, I'd vote for "in itself". "In itself" (viewed in its essential qualities; considered separately from other things[0]) has a different meaning than "by itself" (alone/unaided). And to me it's clear that "per se" pretty much universally means the former.
A less literal translation like "essentially" or "in essence" is deployed by master Latin translators like Robert Fagles. I've even seen "in a vacuum" which does a better job at communicating the original intent than a string of cryptic prepositions.
That's another valid translation for the same preposition.
And there are many definitions of English "for" as well. This would fit the one used in the phrase "if not for this, ..." In other words, for itself = by virtue of itself, through the existence of itself.
Also note in terms of Indo European roots, per is a cognate with English for.
Prepositions are some of the least translatable bits of language. For that matter, even without translation they tend to get slippery within a language, especially over time (one that springs to mind is the whole “quarter of” referring to a time which I first encountered some 50 years ago and still don’t know if it’s quarter to or quarter after).¹
⸻
1. Cue some dude to tell me in 3…2…1²
2. And this knowledge will promptly disappear from my brain five minutes later, sort of like the guy I knew in my 20s whose name was either Jack or Chad and to this date, I still am not sure, but I do know that every single time I called him by name, I got it wrong and it totally wasn’t on purpose even though he didn’t believe me.
I once had a Spanish teacher, who also had problems remembering what that kind of time specification stands for and I came up with maybe a trick to remember. We do the same thing in German, so I guess it translates:
Lets say you have 11:00. That's easy. But what about 11:15? We would say "quarter 12", so I guess the English version is "quarter of 12". How to memorize, that this is 11:15? Well, you can imagine a round clock and the minute pointer has moved _quarter of its way to 12_. So you only have a quarter of that hour "already done". 10:30? We say "half 11". So I guess English is "half of 11", meaning that the minute pointer has moved half the way to 11.
Maybe this will help.
(Actually I personally usually don't use those ways of specifying the time, neither in English nor in German. I just say the 24h format as it is written: "11:15" is "eleven fifteen", 13:35 is "thirteen thirtee five" not 1pm something.)
Whatever "quarter of 12" means in English, whether it's 11:45 (quarter to 12) or 12:15 (quarter past 12), it definitely isn't 11:15. We do fraction of an hour forward or backward relative to the hour mentioned, not fraction of an hour elapsed in approach to hour mentioned.
I recently encountered a German asking for the English phrase equivalent to bis unter, looking for a phrase like "up to below". There isn't one in common use. We just don't count things in equivalent ways.
Can you please specify the dialect of English you're referring to, instead of falling for the obviously ridiculous notion that there's one English.
I have never heard "quarter of 12", and wasn't aware it was a thing. In Ireland - Hiberno-English, Irish-English, whatever you like - I've only ever said and heard "quarter to 12" for 11.45.
So, serious question: who says "quarter of 12"? It sounds makey-uppy and illogical, so I'm supposing it might be a linguistic development in the old U.S. of A. I don't feel like I've ever heard it in movies or shows though, in spite of having been subjected to a certain amount of U.S. cultural produce, so this is somewhat mysterious to me.
And I'm pretty sure the Spanish matches (except in reverse, like Spanish usually is relative to English):
11:15 -> once y cuarto
11:30 -> once y media
11:45 -> doce menos cuarto
edit: and about the subject of the thread, "por sí" or "por sí mismo." "per" afaik is a preposition like "por" that means to pair or match things: so it can mean by, through, around, with, for, and even times("×") i.e. doesn't mean anything in English.
"si" is the 3rd person reflexive pronoun (when placed after the verb), and is probably similar to "se." ("mismo" is a redundant clarification is Spanish, probably because "si" and "sí" are homonyms.)
Se and si (as used here) are the same word in different cases. I would draw comparisons to latin se and sibi respectively. I'd also draw parallels between sui, suus, secum and suyo, su, consigo.
Quarter to and quarter past are not rare in Britain, so
11:15 -> quarter past 11
11:45 -> quarter to 12
are very normal to me. In fact any number above 5 to or past are normal. Even smaller numbers come up, where, of course, 1 to 1 and 2 to 2 are particular favourites.
I hear quarter to and quarter after a lot. I think rarity might be a regional thing (or perhaps generational—despite growing up four miles from my childhood home, my children have a different Chicago accent than I do and when I did student teaching in the school district where I went to high school, those kids also commented about the difference in accent).
This is not great advice - the only way I have heard it in English would be "quarter past 11" to mean 11:15. Most people would just say "eleven fifteen".
You were just wrong. They explicitly gave the understood options as 15 before or 15 after. These are the options everyone uses in English -- not 45 before or a quarter of the hour before. In English no one says quarter of 12 to mean 11:15. You just explained it completely different from the ways it is interpreted in English. I understand the logic and how it might come about. Maybe it's very common in German, but it is not used that way in English. If you referred to 11:15 in that way to a native English speaker you would be misinterpreted.
As is often the case, Randall Munroe has already delivered: https://xkcd.com/1602/. Perhaps the joke in this context would be if it said "bi-weekly".
"You should come to our Linguistics Club's bi-weekly meeting. Membership is open to anyone who can figure out how often we meet." (I mean, you have a 50-50 shot. I wonder if there's any personality insights one could learn from such a selection.)
Tok Pisin, a.k.a. New Guinea Pidgin, has exactly two prepositions: bilong, which means "of" or "from" in a possessive or attributive sense; and long, which means everything else.
I have to admit that I was a bit surprised when my ex-wife listed off Spanish prepositions to discover that it excludes a lot of words I would have thought were prepositions but Spanish considers adverbs and only become prepositional when used in conjunction with one of the enumerated prepositions, usually (always?) de.
Yes, and in fact this is explicitly the business model[0] of ISO MPEG and ITU VCEG. They pay for their basic research by letting participants patent and license the resulting standards-essential inventions[1].
HEVC/H.265 has been in development since 2004, i.e. right after AVC/H.264 was published, and took almost a decade to actually be standardized. There's even an H.266, which started in 2017, a few years after H.265 was released. Though the primary concern of patent holders is not AVC patents expiring. Those patents actually aren't that valuable, because AVC is licensed way too cheap. MPEG-LA had negotiated a very generous free rate for online video[2], in response to MPEG-4 ASP (aka "DivX :-)") basically not getting much use online.
What patent owners want is to go back to the days of MPEG-2 where they were making money hand over fist just for owning a functional codec. They even sacked Leonardo Chiariglione, the founder and head of ISO MPEG, because he was trying to change ISO's patent policy to be more favorable to developing royalty-free codecs.
[2] Which is why YouTube's allowed to use H.264 without paying $$$ for it. Before that, they used whatever codec was available in Flash Player. Adobe (and Macromedia before it) used On2 VP6 primarily because it had no patent licensing royalty; before that they'd used H.263.
That's incredible. With MP3 already completely patent-free as well, we have an extraordinary free set of audio and video codecs for the next couple of decade, at least until HEVC becomes free.
Opus and Vorbis are far from useable everywhere. On the other hand, there isn't a piece of software or hardware that won't accept MP3. MP3 is the lingua franca of sound, and should stay that way for a century.
How does that work? They force AOM to pay up and then I guess either AOM passes the royalty burden onto AV1 users or they take the hit and pay it themselves?
Disclaimer: We're an early adopter of Stainless at Mux.
I've spent more of my time than I'd like to admit managing both OpenAPi spec files [1] and fighting with openapi-generator [2] than any sane person should have to. While it's great having the freedom to change the templates an thus generated SDKs you get with using that sort of approach, it's also super time consuming, and when you have a lot of SDKs (we have 6 generated SDKs), in my experience it needs someone devoted to managing the process, staying up with template changes etc.
Excited to see more SDK languages come to Stainless!
> An engineer with no such customer awareness and instead an incessant obsession with optimizing everything that can be optimized, might try to optimize for speed… when it’s likely the consumer cares more about: cleanliness, energy rating and capacity.
I don’t want more energy efficient things. I want more clean energy so that the things I use can work better by using as much energy as they need instead of cutting corners for efficiency.
That is a fair point, although I wonder how long this will hold true considering the ever increasing prevalence of heatpumps, sun-boilers, and other such equipment.
Stuff you should know did an episode on dishwashers and I believe if you washed your dishes for a minute, you've already used more water than a dishwasher. It was pretty mindblowing. They did, though, go through some studies that made it seem that dishwashers were too sterile and getting a little leftover or germ from your handwashed plates was better for your immune system.
That is precisely why you should let your $0/hr spawn pick up this menial task rather than doing it yourself - assuming your time is worth more than theirs, obviously :)
If your spawn is only worth $0/hr., they won’t have the capacity to handle it. If they are worth anything more, they would be more productive elsewhere. The income they produce for you will more than pay any dishwasher costs.
That's the current tradeoff in dishwashers (and washing machines), more energy efficiency means lower temperature, and then the detergents take longer to work. This is why we have 3:30 eco programs.
Super interesting, it really depends on what you mean by "choppy".
Are you seeing the video re-buffer (a loading spinner re-appearing), or just the video looking stuttery?
My video engineer gut tells me that this is a frame rate conversion issue - do you know what frame rate your graphics card is outputting to your display, and do you happen to know the frame rate of the content that you're seeing issues with (or more generically, what type of content is it - film? TV) ?
Great question! The real answer is it varies, but for H.264, most just encode on software right now, because GPUs are expensive (especially in the cloud), and the failure rates are really high (if you try to build your own). ffmpeg and lib264 is really fast on modern hardware with decent X86 extensions.
It's also worth noting that YouTube also now builds its own transcoding chips [1], and AWS just launched a dedicated transcoding instances based on Xilinx chips:
Hey, I work in the Product team at Mux, and worked on the LL-HLS spec and our implementation, I own our real-time video strategy too.
We do offer LL-HLS in an open beta today [1], which in the best case will get you around 4-5 seconds of latency on a good player implementation, but this does vary with latency to our service's origin and edge. We have some tuning to do here, but best case, the LL-HLS protocol will get to 2.5-3 seconds.
We're obviously interested in using WebRTC for use cases that require more real-time interactions, but I don't have anything I can publicly share right now. For sub-second streaming using WebRTC, there are a lot of options out there at the moment though, including Millicast [2] and Red5Pro [3] to name a couple.
Two big questions comes up when I talk to customers about WebRTC at scale:
The first is how much reliability and perceptual quality people are willing to sacrifice to get to that magic 1 second latency number. WebRTC implementations today are optimised for latency over quality, and have a limited amount of customisability - my personal hope is that the client side of the WebRTC will become more unable for PQ and reliability, allowing target latencies of ~1s rather than <= 200ms.
The second is cost. HLS, LL-HLS etc. can still be served on commodity CDN infrastructure, which can't currently serve WebRTC traffic, making it an order of magnitude cheaper than WebRTC.
We actually built How Video Works as a side project at Mux [1] (inspired by How DNS Works [2]) - there's a note about it at the top of the page. We have contributions from our own team as well as others in the industry.
Our main motivation is to try to educate on the complexities and intracies of streaming video. Despite streaming video representing 80+% of the internet, it's all underpinned by a fairly small community of engineers, which we're eager to help grow through tools like this, and the Demuxed community [3].
Edit: I should also mention that Leandro was kind enough to adapt a this content from his amazing Digital Video Introduction [4]
DRM'd video content uses the same video codecs and containers, but introduces segment encryption during the packaging phase. In most cases, this encryption is within the audio and video samples rather than on the entire segment. Most content is encrypted using MPEG Common Encryption (CENC) - though there are a couple of variants.
Decryption keys are then exchanged using one of the common proprietary DRM protocols, usually Widevine (Google), Playready (Microsoft), or Fairplay (Apple). The CDM (Content Decryption Module) in the browser is then passed the decryption key, so the browser. Can decrypt the content for playback.
While HLS isn't the cleanest protocol (Yay for extensions of the M3U playlist format...), it's actually really good at what it's designed to do - provide reliable video streaming while using HTTP/S over variable networks.
Ultimately, HLS isn't designed for downloading and storing videos, it's designed for streaming.
Came to say this exact thing. HLS and it's fancy brother LLHLS aren't storage formats like MP4/FLV are. I think of HLS as a playback format: I'd play a Playlist when watching a VOD/livestream but I'd probably save it as an MP4.
Do you have a marketing site or landing page for Padka? It sounds interesting, but just linking to a .pkg file on S3 really isn't the way to educate HN users about your offering!
Thank you for pointing this out. I thought that a direct link to download the app will be better for HN users to try it out. It looks like I read it wrong?
Updated: I tried to edit the link but it's not allowed T_T
Now if only HEVC wasn't such a hot patent / licensing mess.
[1] https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...