The technical reason is that digital TV is a heavily compressed signal [1] (used to be MPEG2, perhaps they have moved on to h.264) with a GOP (group of pictures) length that is usually around 0.5-2 seconds. When you switch channels, the MPEG-2 decoder in your receiver needs to wait until a new GOP starts, because there is no meaningful way to decode a GOP that's "in progress".
[1] And the technical reason for the compression is that analog HD needs a lot more bandwidth than analog NTSC/PAL/SECAM, while raw HD transmission would need an absurd amount of bandwidth per channel (about a gigabit/s for 1080p30). So HD television pretty much requires the use of digital compression. Efficient digital video compression requires GOP structures.
The real reason problems like this aren't solved is that the organization does not allocate resources to fix them. The status quo has been deemed to be good enough and not leading to the loss of too many customers to the competition, so that's where it stands. This pervades all engineering -- everything just barely works, because once it barely works, for most things, it's good enough, and no more resources are deployed to make it better.
> you could send keyframes more often, or you could even use a totally different compression scheme that didn't use keyframes.
GOP length / I-frame interval directly relates to bitrate. Longer GOPs generally result in a lower bitrate at similar quality; in DVDs or Blu-rays I believe the GOPs can be quite long (10+ seconds) to achieve optimum quality for the given storage space.
Non-predictive video codecs are usually pretty poor quality for a reasonable bitrate (like a bunch of weird 90s / early 00s Internet video codecs), or near-losless quality but poor compression (because they're meant as an intermediate codec).
Users want to change channels quickly? Okay, let's decompose a problem into what they really want to do, then make N "preview of i-j" channels in 720p with channel pictures in e.g. 8x5 grid and show numbers so that a user could just dial them on a remote. After finding an interesting preview, it's not an issue to push some buttons and wait a couple of seconds to get 2160p or whatever quality there is. Didn't like it? "99<n>", "ok", repeat. This solution would be a jquery of tv world, dumb, straightforward, non-automated, but it would be a thousand (fourty to be honest) times better than nothing.
When I had an hd tv set, I just checked 3-5 channel numbers that I remembered and turned tv off if there was nothing of interest, because you could easily spend half an hour by just peeking them one by one.
My point is that there are many ways you could apply engineering, money, bandwidth, etc to reduce or eliminate the problem but they don't because they see it as good enough to not lose customers.
Bandwidth matters because spectrum is a finite commons. Digital TV required giving up bands that were in use for other things (e.g. wireless microphone systems and some ham bands) as it is, using even more bandwidth would have required even more spectrum. Other people have stakes in the spectrum for very good reasons and often much more important reasons than "I wanna watch TV". Even for satellite TV, which uses frequencies high enough that there is lots of bandwidth is limited, because using a lot of bandwidth would require new LNBs and multiswitches for all customers.
> My point is that there are many ways you could apply engineering, money, bandwidth, etc to reduce or eliminate the problem but they don't because they see it as good enough to not lose customers.
Can you name one for each category you bring up? Especially the "engineering" one would be interesting. Obviously dedicating an even huger chunk of spectrum to "I wanna watch TV" would make things easier, so that's not really interesting. And "let's just give each customer a TVoIP stream that can start immediately" is also a pretty obvious "money is no concern" (and also "we don't care about customer adoption costs") option.
We agree that there a whole series of parameters that can be traded off against each other: 1. Bandwidth required
2. Number of channels
3. CODEC complexity/engineering effort/cost for encoders and decoders
4. Iframe interval
5. Number of tuners/decoders in receiving equipment
6. Resolution
7. Frame rate
8. Video quality
So the standardization people decide how to set those, and basically channel switch time gets set to the maximum value that doesn't cause people to cancel their service.
If you want to see something pretty astonishing that can happen if you set the tradeoffs differently, check this out: https://puffer.stanford.edu/player/
Many people wouldn't even be able to reliably tell the difference with common dpi's and viewing distances.
What does make a difference? Surround sound. I'd take 5.1 or up with DVD-quality picture over 4K with stereo any day, no hesitation.
I claim it's because DRM, since if it wasn't for DRM wanting control of the whole reception to display path to be protected, you could just stick an open computing device in between the streaming signal and the display device, and make your own technical choices.
You still can, AFAIK, for content that doesn't require HDCP.
It's because we have a trendy now-decades-long wave of product managers and designers who assume their job is to know better than the user.
Open source software is not immune.
cough systemd cough
Cable: no, you'd need a CableCard, and approved device (i.e. DVR), etc.
Do you mean Unix-like? I'm not sure what you mean by "open" in this instance, but Unix definitely was not very open, leading to nascent platforms and movements such as GNU and Free/Libre software.
I recall reading about TVs with multiple tuners to resolve adjacent channels when flipping, but I don't remember if they actually made it to market.
Yet does it use any of those extra decoders when not recording to proactively decode the previous and next channel, or something smart like that? No, of course not...
The incoming channel data stream is saved as-is. It will need a demultiplexer to separate out one channel from the multi-channel data stream, but it won't need to decode that stream, which is the intensive bit. Decoding happens when you play it back later.
Mental slip then. Thanks for the correction, very interesting.
Do you find yourself actually moving up and down the channels, and not through the guide to somewhere else entirely different than where you once where? My first move if I'm switching channels is to go to the guide, not to a channel one above or below my current channel.
I suppose it could run on the previous channel, but it certainly can't guess my next channel.
Toxic culture and relationships so the startup imploded, but there was some cool tech.
Today if you had such a scene they'd be like, "okay <presses remote, waits five very immersion-breaking seconds>".
But they still have these scenes in movies
The way these scenes work now is "picks up phone - check the news!", they grab the remote, and turn the volume up on one of the many already running and tuned in wall-mounted 24/7 on TVs ... :)
Yes, and if such a TV turns on instantly, that scene is not realistic.
(I think if the were going for realism today, they'd say "pull up reddit/Drudge/google news".)
You get the cable box for the new system BEFORE they switch the old system off, or else you wouldn't have service until you got a new box. That's why you saw behavior change with the new box.
It simply isn't possible to send all the channels to customers at all times. There isn't enough bandwidth. So, the cable box at your house negotiates with the central or regional system so only a subset of channels are sent to you. There is no other way to do it in digital cable systems, and the switch to digital was made because it uses significantly less bandwidth than analog.
Right now I would be satifsied with at least some caching of the menus, so it doesn't have to pull the data every damn time I scroll up or down. Come on, it should be able to remember what channels I have for more than 5 minutes in a row.
You didn't think a cable company was going to deal with it's customers fairly, did you?
Every time you interact with a customer, there is an opportunity for profit. Telecommunications companies, cable TV included, are masters at this type of behavior.
Just because they transmit keyframes and deltas in the steady state doesn't mean they need to wait for the next keyframe when starting the stream. They could also choose to send you the current reconstructed frame as a keyframe immediately instead of waiting several seconds for the next pre-made one. The cost to them would be epsilon (one new stream client per channel to be the source of reconstructed keyframes), and the customer experience difference would be noteworthy.
At worst it would only be as bad as a transcoded stream for the first few seconds until the subsequent true keyframe arrives. That's loads better than no stream at all.
An MPEG transport stream is sent over that 40Mbps "channel". Inside of that transport stream are several elementary streams, each carrying either video, audio, or data/program information. A TV station will be carried by a combination of a video (MPEG-2/4) and audio stream. These streams are packetized such that a receiver won't get buffer underruns or overruns. The transport stream is further packetized. Adjacent station broadcasts aren't always carried on the same transport stream.
So when you hit the button to "change channels" the cable box may need to tune to a new radio channel, wait for transport stream packets for the station, and then buffer enough data to start playback.
The GOP size then plays a part because the decoder needs an I-frame to do anything useful with the P-frames inside the GOP. Cable providers use longer GOPs to get better quality at a given bitrate, I-frames are much larger than P-frames so the more you send the higher the bitrate you need.
Sending I-frames for other broadcasts in the same transport stream would be a waste of bandwidth. The data used for these rarely used extra I-frames takes away from bandwidth programming in the stream could use. There's also still the lag from tuning a new channel and waiting for those I-frames to show up. So you've wasted bandwidth for a very slight increase in responsiveness.
Cable systems don't often re-encode streams they receive from upstream sources. The video from upstream is already compressed so the elementary streams are remuxed into the cable system's channel plan. The cable head end doesn't receive raw video and encode it in real-time. Even local OTA stations just get remuxed rather than re-encoded.
Sending some out of order I-frame every time a channel was changed means every stream has to be decoded in real-time at the head end in case someone flips a channel. Cable is a shared medium so every channel flip by every user on a node will to be sent to everyone.
Even IPTV isn't a bidirectional signal. It uses IP multicast and the tuners just change their multicast address to change stations. The stream is the same MPEG transport stream as the QAM signal but sent as IP packets. The head end still doesn't decode every station to send bespoke I-frames in the event someone flips the channel.
This hasn't been true in many places since the takeover of digital cable in the 2000s. Without a bidirectional data link, how do you think cable internet works? Or cable telephony? Or pay-per-view for that matter? It's all on the same line into the same box.
> Cable systems don't...
Don't isn't couldn't. When talking about solutions to problems, merely describing a problem isn't where the conversation ends.
> Sending some out of order I-frame every time a channel was changed means every stream has to be decoded in real-time at the head end
That's what I described. The cost of doing it is epsilon.
> Cable is a shared medium so every channel flip by every user on a node will to be sent to everyone.
If you can stream Netflix while watching TV without hurting your neighbors, then you can receive one single I-frame.
It's all based on ATSC. While there is an ATSC 2.0, they skipped that in Canada, there will be ATSC 3.0, which will use HEVC (H265) for 4K. But don't hold your breath on that...the TV stations aren't exactly opening their wallets to upgrade anything!
There is no technical reason you can't have instant channel switches, it's just that they aren't making the right technical decisions to allow it and/or don't want to pay for it.
It seems to me that we have lower performance, exponentially higher resource consumption, and often no more functionality in a “modern” web app / Electron app compared to some desktop apps from the 90’s. And for what? To have even worse UI’s and UX’s that never conform to platform guidelines? Where’s the progress?
Not to mention flat design, which is without exception bad design. Buttons have borders, show them.
> Remember when channel changes on TVs were instantaneous?
There's nothing less satisfying than smushing down those rubbery remote control buttons for an extra 2000 to 4000 milliseconds to change the channel.
Don't get me started on entering the wrong channel numbers. That gives me PTSD.
The cynical side of my brain feels that this is exactly what TV stations and show producers wanted. If it's fast and easy to spin the dial and maybe stop on a competitor (and more importantly, watch their ads instead of yours) then you have to put our quality product and not annoy the customer with as many loud and irritating ads, which means that you don't make as much money from the content that bookends your ads.
These things are like these fake volume controls reddit made up.
I don't think it's the nature of progress so much as it is laziness. Most developers (myself included) don't worry much about optimization until the UX performance is unacceptable.
I sometimes wonder what the world could be like if we just froze hardware for 5 years and put all of our focus on performance optimization.
The effect doesn't have to be expensive, and my original implementation was fast on millenium era machines. The goal is preserve the context of the background, while keeping foreground data readable, in a way that is natural to our human visual system. If you are doing it properly you also shift the brightness values into a more limited range to diminish the contrast and keep the tonal values away from the chosen foreground text color (this is also cheap). Done properly it is visually pleasing with virtually no effect on readability.
People have coded some boneheaded imitations along the way though. They don't add the blur, or they don't adjust the brightness curve, or they make the radius much too big, or they compute some over exact Gaussian blur that is too slow.
It's the nature of blur that it doesn't have to be exact to be visually pleasing and convincing.
HDCP obviously being consumer-hostile, but the others are decent features to make things "just work".
As for the rest: Resolution negotiation is optional and wouldn't matter if the device is already outputting at some resolution, also this happens on different pins, so even if the device would first query the EDID of the TV to figure out what mode it prefers, the TV could meanwhile already display whatever the device is outputting. Same with CEC, this is another protocol on different pins than where the picture data is sent. HDMI really is just DVI with some extras, at least for the older versions.
Particularly in Enterprise software, the time to complete a workflow or view specific data matters a lot - the time to load a page is a component of that, but customers will gladly trade latency for a faster e2e experience with less manual error checking.
In consumer the big limiting factor is engagement, a low-latency experience will enhance engagement. However it's possible to hide latency in ways that weren't possible before such as infinite scrolls and early loading of assets. The engagement on the 50th social feed result has less to do with the latency to load the result, and more to do with how engaging the content is.
Of course software now uses more computing resources, so that’s not doing more with less. But the computer is cheap. What’s expensive is the humans who program the computer. Their time is expensive, and getting experienced, expert humans is even more expensive.
So we now have websites that have rich features bolted together using frameworks. Same for desktop software, embedded systems, and whatever else. They’re optimized for developer time and features, not for load time because that’s not expensive, at least not in comparison.
As a user the only solution I see to this is to use old fashioned dumb products rather than cheaply developed “smart” ones. For instance I’m not going near a smart light switch, or a smart lawn sprinkler controller. Old dumb ones are cheap and easy and fast and predictable.
This is a nice half-truth we tell ourselves, but that's not the full story.
There exists plenty of optimizations where the programmer-time would be smaller than the additional hardware cost. And those losses compound. But they're a little too hard to track, and cause is a little too far divorced from effect.
I did our first ever perf pass on an embedded application as we started getting resource constrained. I knocked 25% off the top in a week. Even if I had spent man-months for a 10% savings, try and tell me that's more expensive than spinning new boards.
That's not to say we're opposed to hardware changes; we do them all the time. But the cost curve is weighted towards the front so it's more attractive to spend a non-zero amount of developer time right now to investigate if this other looming spend is avoidable. That's not the case when you're looking at controlling the acceleration of an AWS bill that spreads your spend out month to month through eternity.
Who wants to spend a big chunk of money up front to figure out if you can change that spend rate trend by a tiny percentage? Even if you do, and get a perf gain, but someone else on the team ships a perf loss? Then it doesn't feel real, and you can only see what you spent. Even if you have good data about the effect of both changes (which you don't), the fact the gain was offset means the sense of effect is diminished.
And rather than investigate perf, people can always lie to themselves that the cost is all about needing to "scale." That way they convince themselves not only was there nothing they could have done, the cost is a sign that their company is hot shit.
If you don't think that kind of perf difference is real, Look at Maciej's comparison of pinboard and anonymized-del.icio.us https://idlewords.com/talks/website_obesity.htm (ctrl-f "ACME")
And if perf has any impact on sales, cause and effect are even further apart. You might be able to measure the effect perf has on your sales website directly, but if that feedback loop involves a user developing an opinion over days/weeks? Forget about knowing. Oh, sure they'll complain, but there are no metrics, so we get the rationalizations we see in this thread.
Related: https://www.youtube.com/watch?v=kZRE7HIO3vk
I'm not expert enough to say if his technical solutions are correct, but it's a pretty good explication of the problem.
[1] https://unix.stackexchange.com/questions/223746/why-is-the-l...
Phones used to be rotary dial but then touch tone phones with number buttons were introduced. I was reading an article about human brains and its expectations. Going from a touch tone phone to an old rotary style phone seems excruciatingly slow to our brains. Depending on the number a 1 on each it's very close in duration but a 9 or a 0 on a rotary compared to a touch tone 9 or 0 seems glacial in speed.
Someone had to more or less decide to handle it that way for some reason. So I am skeptical that "it's just the nature of progress."
I think about this every time I use the Hulu "Guide" on my Fire TV. It's extremely slow and cumbersome.
I remember using the early digital cable boxes in like 2005 which were much more responsive, and honestly, the UI was much better too.
One of the worst parts of the over the air digital switch over was how much harder it was to channel surf quickly.
Remember when turning a TV on was <0.5s?
My current dumb TV takes a good while to turn on. When I press the power button, it takes about 1s for the indicator light to change than another 2 or 3 to begin displaying anything.
No, actually. Most CRTs took a long time to come on. Early LCDs, maybe?
Now, quite often I have to wait 5s to see whether the button push was registered, push again because the TV still does nothing, and then watch as the thing turned on just as I was pressing and interprets the second push as a signal to go on standby (5 more seconds with an obnoxious message about it going to sleep, and yet 5 more to wake it up). It’s like the USB-A that needs to be rotated twice every time you want to plug something.
Still, I remember never having confusion about whether my CRT TVs where responding to the power on button press or not. There are plenty of times where I turn my current TV off since I think it didn't receive the first button press.
The purpose of technology (in the POSIWID sense) is to concentrate wealth.
https://www.wnycstudios.org/podcasts/otm/segments/self-drivi...
Of course cars do take up a lot of space, but even factoring that in you have more choices in a reasonable time with a car than without.
Don't read this as me approving of cars. I understand the appeal and drive, but I hate it.
I personally believe we should start having "bootcamps" which talk about optimizations, and the cost of stupid designs. I'm also looking forward to compile time and run-time optimizations so that we don't even have to rely on the developers for it.
I suspect that the root cause is that nobody understands what's going on from the UI down to the hardware, and nobody is incentivized (or even allowed) to spend the time it would take to actually do so.
I don't even think most phone apps are bloated, because most phone apps - and web sites - are just electronic forms decorated with a bit of eye candy.
Security and reliability worry me far more. Many sites have obvious bugs in $favourite_browser, and some just don't work at all. Some of this is down to ad blocking, but that shouldn't be a problem - and the flip side is that blocking ads, trackers, and unwanted cookies seems to do wonders for page load speeds.
Modern computers should be much faster, but they aren't. They do more, but when you do something you notice the slow speed.
The astonishing thing is that bandwidth isn't a big deal now, and we could have improved basically all aspects of mobile calls to be within spitting distance of what we used to have 30 years ago.
No wonder people don't like to talk on the phone any more.
Isn't that a little like saying "The only thing boats have over cars is that they can go on water. In all other ways they suck"? Portability is the entire point. Even in the "good old days" most people would have accepted nearly any tradeoff for the ability to carry even the simplest global communications device with them.
Originally POTS was circuit switched analog connection between you and the other party --- only delays from the wires, and maybe amplifiers. Nowadays POTS is most likely digitally sampled at the telco side, but each sample is sent individually --- there's no delay to get a large enough buffer to send, because for multiplexed lines each individual line is sampled at the same rate and a frame has one sample from each.
Then try various things like saying “ping”. The results are quite amusing. Or put one phone on speaker.
Is this an android problem? I don't really ever have to close apps unless the app itself gets stuck into a broken state and forcing close to restart can correct the issue.
Not really. It's just not a priority.
No, not with technology as a whole. With software ...
At least car crashes are still low latency.
Remember when channel changes on TVs were instantaneous? Somehow along the way the cable/TV companies introduced latency in the channel changes and people just accepted it as the new normal.
Phones and computers were at one point very fast to respond; but now we tolerate odd latencies at some points. Apps for your phone have gotten much much bigger and more bloated. Ever noticed how long it takes to kill an app and restart it? Ever notice how much more often you have to do that, even on a 5-month old flagship phone? It's not just web pages, it's everything. The rampant consumption of resources (memory, CPU, bandwidth, whatever) has outpaced the provisioning of new resources. I think it might just be the nature of progress, but I hate it.