Additionally there's a bug on the Android app that it sometimes doesn't show video titles (or the worlds worst A/B test?), so scrolling through I just see talking heads (since it autoplays instead of showing the video thumb) and have to force restart it to actually understand what's going on.
If you manually increase the quality on that video, it will only apply for that video, and whatever videos you play next, will still be limited to 480p.
All this is just to save costs..A truly fucking shady tactic to fuck over paying users. Fuck Google for what they do and how they cheat naive users.
Also the compression algorithm is very aggressive and it works reasonably well for general content but for edge cases (like starcraft streams), the 1080p loses enough details to make it hard to see important things like observers and outlines of individual units in crowded clusters. The compression algorithm just isn’t trained/tuned for these types of content, so even on a 1080p screen I need to stream at 4K just to see the details properly.
These were unlisted videos, so I’m not a YouTuber or anything, but I’m pretty sure this is one thing some people do to make their videos appear better sometimes
The original functionality of the quality selector was to throw out whatever video had been buffered and start redownloading the video in the newly selected quality. All well and good, but that causes a spinning circle until enough of the new video arrives.
The "new" functionality is to instead keep the existing quality video in the buffer and have all the new video coming in be set to the new quality. The idea is that you would have the video playing, change the quality, and it keeps playing until a few seconds later the new buffer hits and you jump up to the new quality level. Combined with the fact that YouTube only buffers a few seconds of video (a change made a few years prior to this; back in the Flash era YouTube would just keep buffering until you had the entire video loaded, but that was seen as a waste of both YouTube's bandwidth and the user's since there was always the possibility of the user clicking off the video; the adoption of better connection speeds, more efficient video codecs, and widespread and expensive mobile data caps led to that being seen as the better behavior for most people) and for most people, changing quality is a "transparent" operation that doesn't "interrupt" the video.
In general, it's a behavior that seems to come from the fairly widespread mid-2010s UX theory that it's better to degrade service or even freeze entirely than to show a loading screen of some kind. It can also be seen in Chrome sometimes on high-latency connections: in some cases, Chrome will just stop for a few moments while performing DNS resolution or opening the initial connections rather than displaying the usual "slow light gray" loading circle used on that step, seemingly because some mechanism within Chrome has decided that the requests will probably return quickly enough for it to not be an issue. YouTube Shorts on mobile also has similar behavior on slow connections: the whole video player will just freeze entirely until it can start playing the video with no loading indicator whatsoever. Another example is Gmail's old basic HTML interface versus the modern AJAX one: an article which I remember reading, but can't find now found that for pretty much every use case the basic HTML interface was statistically faster to load, but users subjectively felt that the AJAX interface was faster, seemingly just because it didn't trigger a full page load when something was clicked on.
And, I mean, they're kind of right. It's nerds like us that get annoyed when the video quality isn't updated immediately, the average consumer would much rather have the video "instantly load" rather than a guarantee that the video feed is the quality you actually selected. It's the same kind of thought process that led to the YouTube mobile app getting an unskippable splash screen animation last year; to the average person, it feels like the app loads much faster now. It doesn't, of course, it's just firing off the home page requests in the background while the locally available animation plays, but the user sees a thing rather than a blank screen while it loads, which tricks the brain into thinking it's loading faster.
This is also why Google's Lighthouse page loading speed algorithm prioritizes "Largest Contentful Paint" (how long does it take to get the biggest element on the page rendered), "Cumulative Layout Shift" (how much do things move around on the page while loading), and "Time to Interactive" (how long until the user can start clicking buttons) rather than more accurate but "nerdy" indicators like Time to First Byte (how long until the server starts sending data) or Last Request Complete (how long until all of the HTTP requests on a page are finished; for most modern sites, this value is infinity thanks to tracking scripts).
People simply prefer for things to feel faster, rather than for things to actually be faster. And, luckily for Internet companies, the former is usually much easier to achieve than the latter.
They're making slot machines, effectively.
Most useless message ever, placed exactly where you do not want it to be.
> It's the same kind of thought process that led to the YouTube mobile app getting an unskippable splash screen animation last year; to the average person, it feels like the app loads much faster now. It doesn't, of course, it's just firing off the home page requests in the background while the locally available animation plays, but the user sees a thing rather than a blank screen while it loads, which tricks the brain into thinking it's loading faster.
So they decided it's better to show lower-quality content (or not update the screen) than a loading screen, and it's the same school of thought that led to a loading screen being implemented? I agree both examples could be seen as intended to make things "feel" faster, but it seems like two different philosophies towards that.
(Also, I remember when quality changes didn't take effect immediately, but I've been seeing them take effect immediately and discard the buffer for at least the past few years-- at least when going from "Auto" that it always selects for me to the highest-available quality.)
Except "a few seconds later" can become minutes. Sometimes it just keeps going at the lower quality while the UI claims to play a noticeably higher resolution than the one actually playing. To be clear, I don't care that the "automatic" quality is actually automatic, I care that the label blatantly lies about which resolution is playing. "Automatic (1080p60)" shouldn't look like a video from 2005.
Filmed in HI8 480p, but YouTube's 480p looks like mud and doesn't do the uncompressed analog source justice. You can see this when you select 4K
> Careful there are programmers here watching
And good! Fix your shit. Take some god damn pride in your work! Just because all code is shit doesn't mean it can be infinitely shitty.
You're excuse for doing something shitty is... that someone else will? What does another person even have to do with it?! Seriously, let them have the blood on their hands. You can't even assume that someone else will! If you do it, you guarantee that it happens. Even if it is likely that someone else will, there's a big difference between a certainty. This is literally what creates enshitification.
Plus, the logic is pretty slippery. Certainly you're not going to commit crimes or acts of genocide! You were "just following orders"[0], right? Or parents often say to their children "if everyone jumped off a cliff, would you?" Certainly the line is drawn somewhere, but frankly, it is the same "excuse" given when that extreme shit happened, so no, I won't accept it.
You have autonomy[1], that makes you accountable. You aren't just some mindless automata. You may not be the root cause, but at best you enable it. You can't ignore that you play a role.
And consider the dual: if you don't make it better, who will?
I believe you have the power to make change, do you? Maybe not big, but hey, every big thing is composed of many smaller things, right? So the question is which big thing you want to contribute to.
[0] https://en.wikipedia.org/wiki/Superior_orders
[1] https://talyarkoni.org/blog/2018/10/02/no-its-not-the-incent...
I use YouTube 6+ hours a day and I have for probably 10 years, and I don’t even work there. (I have a few annoying personality limitations which make it so that I usually work better with YouTube on in the background, and NOT on autoplay, autoplay always chooses something I don’t want to see/hear; I know that because I use the tool a lot.)
I can tell you that it has steadily and continually gotten worse in that 10 year time. “I have to come up with stories or I won’t have a job” no you don’t, but even if you did, there are so many things YouTube needs more that enlarged thumbnails with visible compression artifacts.
I did. Not that anyone listened tho.
Ie I hovered over one video of some Ronny Chieng commentary of RFK jr yesterday which somehow popped out of blue, and next time half of my feed was hardcore political with current admin (nothing what few Not interested clicks won't solve but then I am battling over-optimization of video platform).
I guess it suits certain audience well and keeps the feed fresh, but such behavior would cater to some maybe other type person better than me.
e.g., https://www.t-mobile.com/offer/binge-on-streaming-video.html
> All detectable video streaming is optimized for your mobile device so you can watch up to three times more video using the same amount of high-speed data.
As a counterpoint I love that feature on desktop and use it all the time.
Often I don't even click videos but just watch them with the preview autoplay (with sound enabled). I also zoom in on my mousepad so that it covers the whole screen and I only need to click through to like the video or for the comments. Much more seemless experience for me.
I might be traveling and be on very expensive 3g data, and want to listen to a video and not care about the display but low quality setting means little when you are a premium user.
You have to explicitly change video resolution every time the next video starts playing.
You cannot choose explicit resolution preferences like you used to.
And I get no difference in what happens to resolutions chosen for me between these two quality settings. Seems random/non-deterministic.
There is no way to handle autoplay correctly. It's simply been broken for the past few years. There is also no way to detect autoplay using workarounds. I.e. autoplaying a silent audio, because you can only prove the existence of autoplay, but never its absence, since autoplay could be delayed for whatever reason and happen outside of your timeout based hack.
Using the most commonly version of the product, on the commonly used hardware, at least 2 days a week should be a prerequisite for every product owner.
But I still stand, you aren't mindless automata and your actions matter.
If that doesn’t work – reach out to YouTube support – as a Premium subscriber, you get to speak with a human.
I am a firm believer that the software should also be developed on commonly used hardware.
Your average user isn't going to have the top-of-the-line MacBook pro, and your program isn't going to be the only thing running on it.
It may run fine on your beefed up monstrosity, and you'll not feel the need to care about performance (worse: you may justify laggy performance with "it runs fine on my machine"). And your users will pay the price for the bloat, which becomes an externality.
Same for websites. Yes, you are going to have a hundred tabs open while working on your web app, but guess what - so will your users.
Performance isn't really product's domain, as in — they would always be happier with things being more snappy; they have to rely on the developer's word as to what's reasonable to expect.
And the expectation becomes that the software should and can only run fine on whatever hardware the developer has, taking all the resources available, and any optimization beyond that is costly and unnecessary.
Giving the devs more modest hardware to develop with (limited traffic/cloud compute/CPU time/...) solves this problem preemptively by making the developers feel the discomfort resulting from the product being slow, and thus having the motivation to improve performance without the product demanding it.
The product, of course, should also have the same modest hardware — otherwise, they'll deprioritize performance improvements.
----
TL;DR: overpowered dev machines turn bloat into an externality.
Make devs use 5+-year-old commodity hardware again.
<flame=ON>
Usually, but not always, it ignores scroll events while an animation is playing…and hovering over a tile in the list cause a pointless zoom-in animation (the result of which occludes parts of adjacent tiles). Sometimes, the animation won't start immediately, but will still play. To prevent the cannot-scroll-while-animating problem, the only safe place for the mouse pointer is over the scrollbar.
Clicking the (completely invisible) track of the scrollbar has random multi-second delays.
Most of the search filters are hidden by default…and can't be shown without waiting for a slow animation. You can click the show-filters widget over 30 times if you're in a hurry, and still the animation hasn't even drawn the first frame. That delay before it starts means that even if you try to wait, you might click one extra time, and then see both the show-filters animation and then the hide-filters animation…all while none of the rest of UI responds. …And then you might realise you want to refine your search terms…which will reset all filters and re-hide the filter options.
Once you find a tile you want to click, be prepared for another two animation delay: one, if the tile isn't already zoomed in, and another while the app mysteriously animates a slew of placeholders instead of just dumping the items information directly into view. It's slow like a 33.6 moder on a noisy phoneline, but now you finely have details about the item you clicked on maybe 7 to 40 seconds ago.
Now maybe you click a screenshot to enlarge, and decide it wasn't the app for you. You hit your mouse's 'back' button or click the app's strangely tiny (given how freaking huge most of the UI is) back button. Nothing happens. You try again, potentially numerous times…because the app ignores those inputs while a screenshot is enlarged. The app's so unresponsive, it at first doesn't occur to you that no amount of waiting or retrying will help. No, you have to click the little close widget on the opposite side of the window, or 'back' will never mean 'back' again.
You try to go back to your search results. The app eventually responds, but decided to discard that data for some reason and has to play more placeholder animations while reloading it and rediscovering your scroll position.
Then you go into another search result and decide the sidebar of other apps people viewed has some interesting items. These don't have animations on the tiles or any details, so you have to click each one of interest, waiting for more placeholders while imagining modems noises and being outpaced by a Colorado glacier that's crossing the road. And when you page back, the item you just came from does /more/ animations while reloading everything via IP Over Avian Carrier With Quality Of Service.
But when burrowing through the people-also-viewed sidebars, don't go too many layers deep, or when you return to your search results, it will have forgotten your scroll position and turned of your search filters. Ah, time for more UI-blocking animations.
But that's okay, right? Nobody ever made an app that responds in milliseconds to every user input, right? And we all know that doing long, blocking operations on the UI thread is right and holy, right? Even routines single-threaded apps never need to yield to other code blocks or process interrupts, …right?
<flame=OFF>
<meta-flame>
Yes, I have reported this to MS via Feedback Assistant. A few times. No, I don't know why they haven't appeared to do anything about this unshippable pile random bits that somehow slopped out of the Bit Bucket.
"Rectify?" No, the only answer is “Games."
</>
This isn't (exclusively) a forum for programmers (in fact, since it belongs to YC, maybe you'd expect businesspeople etc.) For example, I'm not a programmer, and I've never worked anywhere near the IT sector, yet I visit HN often. Also, if you look at the frontpage there are usually many topics not related to programming, or even tech in general.
May your screams into the void be heard by the stakeholders, and not just people.