No, because they'd have to decompress and then recompress every stream. This would reduce already-lame quality (not that they'd particularly care) and require a bunch of resources.
Nah that's not how it works. Streaming video is usually cut up into small segments. By having a couple of variants per segment, they can serve you a unique and identifiable sequence of segments without having to decompress (and encrypt) them for each user.
I've been using Xcode since it was Project Builder. It has improved in many ways. And since the advent of the App Store, the insufferable/inexcusable nightmare of "signing" has vastly improved.
Most of the problems I encounter now resulted from the fiasco that is SwiftUI. I used to really enjoy development, and built a few mobile apps singlehandedly... even at a well-known company or two. But now I'm struggling to get one chunk of functionality at a time done on a from-scratch app, because SwiftUI and the underlying "reactive" paradigm were so poorly conceived and defectively implemented. Development is now miserable drudgery, and I never feel confident about the result. The absurd gymnastics to trick the UI into doing what you want; and the hypocritical, conflicting edicts for Swift and SwiftUI... it all barely hangs together.
The fact that Apple rolled out a new UI toolkit that didn't support the most fundamental paradigm in mobile applications, a stack of progressive views for the user to proceed through, tells you how far off the rails they went since introducing the original and solid SDK.
And testing is going to be a nightmare... or simply futile.
But the best part is what it DOESN'T install when you think you've updated. You get on a plane and settle in for some work, only to be prompted to download and install a bunch of required crap you weren't told about. OH WELL, says Apple, your time is FREE!
You should read about the invention of color television. There were two competing methods, one of which depended on a spinning wheel with colored filters in it. If I remember correctly, you needed something like a 10-foot wheel to have a 27-inch TV.
Sure enough, this was the system selected as the winner by the U.S. standard-setting body at the time. Needless to say, it failed and was replaced by what we ended up with... which still sucked because of the horrible decision to go to a non-integer frame rate. Incredibly, we are for some reason still plagued by 29.97 FPS long after the analog system that required it was shut off.
Originally you had 30fps, it was the addition of colour with the NTSC system that dropped it to 30000/1001fps. That wasn't a decision taken lightly -- it was a consequence of retrofitting colour onto a black and white system while maintaining backward compatibility.
When the UK (and Europe) went colour it changed to a whole new system and didn't have to worry too much about backward compatibility. It had a higher bandwidth (8mhz - so 33% more than NTSC), and was broadcasting on new channels separate to the original 405 lines. It also had features like alternating the phase of every other line to reduce the "tint" or "never twice the same color" problem that NTSC had
America chose 30fps but then had to slow it by 1/1001ths to avoid interference.
Of course because by the 90s and the growth of digital, there was already far too much stuff expecting "29.97"hz so it remained, again for backward compatibility.
Yep, once again thanks to broadcasters spreading FUD. When the progressive vs. interlaced debate raged during the development of ATSC, broadcasters whined that progressive would disrupt their entire production pipeline... which was utter BS because they'd been showing film-based content for generations.
In the UK the two earliest channels (BBC1 and ITV) continued to broadcast in the 405 line format (in addition to PAL) until 1985. Owners of ancient televisions had 20 years to upgrade. That doesn't seem unreasonable.
I understand the origin of the 29.97 frame rate. They did have a choice, though: Shift the audio signal's frequency and orphan the (relatively limited number of) receivers at the time, or saddle generations of people with this dumb frate rate.
An engineer at RCA in New Jersey told me that at the first(early) NTSC color demo the interference was corrected by hand tweaking the color sub-carrier oscillator from which vertical and horizontal intervals were derived and the final result was what we got.
The interference was caused when the spectrum of the color sub-carrier over-lapped the spectrum of the horizontal interval in the broadcast signal.
Tweaking the frequencies allowed the two spectra to interleave in the frequency domain.
understanding the affect of the 1.001 fix has given me tons of job security. That understanding came not from just book learning, but OJT from working in a film/video post house that had engineers, colorists, and editors that were all willing to entertain a young college kid's constant use of "why?". Then being present for the transition from editing film on flat beds to editing film transfers to video. Part of that came from having to transfer audio from tape reels to video by changing to the proper 59.94Hz or 60Hz crystal that was needed to control the player's speed. Also had a studio DAT deck that could slow down the 24fps audio record in the field to playback at 23.976.
Literally, to this day, am I dealing with all of these decisions made ~100 years ago. The 1.001 math is a bit younger when color was rolled out, but what's a little rounding between friends?
For one thing, it’s much easier to measure spans of time when you have an integer frame rate. For example, 1 hour at 30fps is exactly 108,000 frames, but at 29.97 it’s only 107,892 frames. Since frame numbers must all have an integer time code, “drop-frame” time code is used, where each second has a variable number of frames so that by the end of each measured hour the total elapsed time syncs up with the time code, i.e. “01:00:00;00” falls after exactly one hour has passed. This is of course crucial when scheduling programs, advertisements, and so on. It’s a confusing mess and historically has caused all kinds of headaches for the TV industry over the years.
In addition to the other poster's on-point remarks, film cameras have always run at integer frame rates. We have generations of motion pictures shot at 24 FPS.
Many TV shows (all, before video tape) were shot on film too, but I'm not sure if they were at an even 30 FPS.
To store application-specific data about users. The Supabase doc or examples show this. Where else would you put such data?
But what the docs don't cover is the provided Users table. Missing documentation is why I gave up on Supabase; and the Users table was one of the first problems I encountered. I could find no details on what to expect in each column at any given time.
Upon creating a new user, values get set in this table for no apparent reason. So if your application depends on knowing the verification status of a new user (for example), good luck... Supabase claimed every user was verified upon creation.
The auth schema is intentionally not exposed to the rest api for security reasons. You need to use an auth hook to put data where you need, or an RPC with appropriate privileges, and of course RLS on any tables.
I don't even have to read this to agree, and point out that the problem with popular music today is that it has all been destroyed with DYNAMIC compression. The harm caused by this despicable trend exceeds that caused by lossy data compression.
reply