YouTube to limit default video quality around the world for a month
bloomberg.com
bloomberg.com
Everything I've read is about the last mile.
And considering the major uptick is caused by video for work and for classes, I would guess that is 99% domestic, so what would be the cause of a massive increase in international traffic?
In large congestion scenarios, what impacts people is large amount of data being transacted by large nodes.
CDNs are caches. I am sure it gets much more complex with systems at Youtube scale, but they don't keep all files at all edges. Furthermore, they know what the fuck they are doing, and if ISPs and governments are going "shit, our bandwidth is nuts, hey Youtube/Netflix can you cool it a little?" then maybe there is something to it.
Why and how is everyone an armchair NOC operator/epidemiologist/supply chain manager? How is it so hard to believe that when you get past certain politicians/bureaucracies, there are smart people working to figure out these hard problems that likely know a little bit more than we do?
> Users will still be able to watch in high definition if they want, but will have to choose to do so.
College seminars, as well as all of grade school, are conducted live. High school doesn't have "lectures" the way college does, or middle school or elementary school.
Most of the time you don't even need to really set up much. You just take the key and plug it into OBS.
Most users are not techies.
Most of the fiddling that happens happens because of your specific hardware and encoders you have. A commercial solution faces the same problem.
I'm all for free or open source software, but I'm still dealing with a commercial entity either way. Plus, I don't have to worry about YouTube's algorithm flagging some content.
Also, the probability is very high that if you would have run into problems with OBS, then you're going to run into problems with whatever commercial solution you go with. Most of the problems people have with video capture and streaming don't stem from the specific recording software you use. It stems from how your drivers, OS, and settings work together on your hardware.
We deal with Native American history and YouTube is a true pain in the butt where the brutality of the truth is concerned. Plus, the instructors have many more tools available on GoToMeeting, and would also like things we put on YouTube to be a bit more polished then a broadcast from their dining room table. Also, both YouTube and GoToMeeting are commericial, non-open source solutions.
Also, the probability is very high that if you would have run into problems with OBS, then you're going to run into problems with whatever commercial solution you go with.
OBS is a very fine, professional solution to streaming. Its capabilities bring complications and is not specifically designed for facilitating meetings. GoToMeeting has a paid professional support staff to answer any questions and provides tools to help.
Most of the problems people have with video capture and streaming don't stem from the specific recording software you use.
I would need to see proof of this statement. GoToMeeting seems very easy for our instructors to start and work with.
I love open source, but we are dealing with something here that requires a solution now which mean spending $380/month on GoToMeeting is a very good idea. We cannot do face-to-face training and deploying OBS and a working setup to 20 laptops at homes, just doesn't seem like a good use of time and way more costly than the $380/mo for a couple of months. Plus, its an easy recommend to other institutions that don't have full IT departments.
[edit]Also, I'm pretty sure that since our instructors are at home they would probably prefer we put something a little more polished and formal on YouTube to represent their work[/edit]
Unfortunately there may be/will be people that because they can't enjoy a movie, they will go for a walk. That doesn't help. So we're captive of the second-rate-ISPs, the stupid people that want to go for a walk because "internet is slow". I'll take "that bullet" to just save even ONE grandparent.
Common sense is not so common. If govs encourage "people going for a walk" then majority of Greeks, Italians, Spaniards would be in the parks with a bottle of wine and sandwiches having picnics "while out on a walk".
It's the stupid ones that ruin it for all. The ones who don't want to limit themselves for a couple of weeks for the greater good.
That seems like an attempt to stereotype, when the same has been observed in Denmark, Ireland and Britain.
I am on (UK) the business voda connection (35 mbs) in the uk and pay about 80% more than the cheapest you can get but not seen any problems
How does less video traffic save lives?
Losing some quality on Netflix didn't hurt me. Wathing trainings on 720 instead of 1080 was also just fine (and I do need to save locally, watch again, take screenshots, write on them, meaning I need good quality).
Most video conferences are not audio-only with perhaps a low-quality/bitrate screenshare. We are moving to the direction of "all of us" using it, and cutting corners in quality while companies gear up to increase capacity/bandwidth/throughput. It won't take a week, but once we get to the next level, and I hope we stay there (WFH, commute/polue less) we'll all be in a better place!
Because I agree completely; a few pixels of definition or hues of colour are a great deal less important than a bunch of dead people.
The problem isn't that your videoconferencing goes from 1080p to 360p -- it's that it stutters and stops working for seconds at a time, so students completely miss content, and introduces a lag that makes it impossible to have conversations because people are always talking over each other.
While YouTube buffers ahead, so playback tends to be smooth regardless.
And clearly this has nothing to do with net neutrality, which is about ISP's throttling types of content. This is the content provider itself. And they're giving you the option to manually go back to hi-def.
So I hardly see what there is to complain about. YouTube is just trying to make sure kids are more likely to have usable online classes.
AIUI google uses BBR which attempts to not fill up buffers and thus only add minimal extra latency. Plus in many cases the last mile is the bottleneck, in which case proper queue management on the router or its counterpart can keep the latency low. I think fq-pie is a mandatory part of docsis 3.1 for that reason.
Congestion should only result in limited bandwidth, not in significant latency spikes, and youtube will automatically lower resolution anyway if available bandwidth is too low to sustain playback.
So no changes should be needed at this point.
For people at home, the bottleneck is often something like their apartment building or block or neighborhood -- wherever their ISP didn't provision enough. Obviously "proper queue management" on your home router doesn't affect this. To the contrary, a series of routers full of buffers means that congestion absolutely does increase latency, and drastically.
"Bufferbloat" is a known phenomenon. We may wish it didn't exist, but it does.
So your claim that "no changes should be needed" to ensure videoconferencing latency is unimpacted is just wrong, and flat in the face of all real-world evidence.
Have you ever tried personally using videoconferencing on a saturated network? This isn't theory... it's something you can try yourself. (I used to work in videoconferencing and latency caused by network congestion was the #1 quality issue.)
Yes, my domestic connection often is saturated by p2p software. My router is running CAKE, thus video conferencing runs fine even when the link is close to saturation.
> For people at home, the bottleneck is often something like their apartment building or block or neighborhood -- wherever their ISP didn't provision enough.
In that case better AQM would have to be on those bottlenecks of course.
Bufferbloat.
Ideally, at least for TCP applications, with perfect network congestion control, reduced bandwidth due to streaming should only degrade data rate, but never massively increase the latency. A slight increase is normal, but a huge increase is not. Unfortunately, in real life, it's often the case, and this aspect is often overlooked by vendors, developers, and sysadmins, making things even worse than it should be.
Network hardware or software is optimized for throughput, and its performance under heavy traffic is often not tested. One common practice is using a buffer that is as large as possible, so that you can push the data rate to the maximum and avoid dropping packets at all cost. This is called Bufferbloat and it's a latency disaster. When the upstream bandwidth is saturated, the downstream buffer keeps accepting more bytes/packets, effectively breaks the proper feedback signal used by congestion control algorithms, so it never kicks in in a timely manner, and the FIFO nature of the buffer means the latency of a saturated link is always as high as the buffer size. As long as something is using the bandwidth, the network will always be slow like a snail. When people start having this problem, they simply blame the bandwidth-intensive application, and set a QoS up to prioritize things like DNS and VoIP, and to punish downloaders (and big networks usually have incrediblely complex and elaborate rules), This appeared to "fix" the problem, but it does not solve the underlying problem, all it does is moving the problem to the low priority queue. Another trouble is unwanted buffer can exist everywhere, in applications, operation systems, and underlying hardware, and since there's a conflict between throughput and latency, and some buffers are even technically necessary (Wireless networks are the worst offender), there's still a long way to do to fix everything.
I am only speaking from my experience of managing small LANs, but I got most of the information from Dave Täht and Jim Gettys, who have been working on this issue in the last 10 years. Gettys writes extensively on bufferbloat in his blog that states similar issues exist at a much larger scale, including the ISP edge and backbone. Perhaps the vast majority of the case we are seeing here is caused by a lack of bandwidth and not related to bufferbloat, but I guess bufferbloat is still here to blame for at least 20% of the cases.
Here is a talk Dave Täht recently made: https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-...
And here is Gettys' blogpost: https://gettys.wordpress.com/2018/02/11/the-blind-men-and-th...
Fundamentally, TCP is designed to get all the bits to their destination. That’s great for file transfer, but not ideal for streaming video— at the transport level, there’s no way to decouple data rate from latency because it’s not allowed to drop anything.
UDP is the latency-prioritized transport protocol for the internet. It drops packets that it can’t handle because they are expected to contain out-of-date information anyway. It’s generally mote complicated to use because all of the flow control needs to happen at the application layer.
Yes, fundamentally, TCP is not designed for applications with controlled latency. I only used TCP as an example here because TCP is supposed to provide a reasonable congestion and flow control mechanism at the protocol level, its behavior under congestion is well-specified, and suitable as an example. Unlike UDP, which depends on applications, as you said,
> It’s generally mote complicated to use because all of the flow control needs to happen at the application layer.
I'm actually aware of some UDP programs that deliberately send multiple packets in a row without any regards of flow control, winning extra throughput at the expense of other programs.
On the other hand, the TCP specification includes Slow Start, Sliding Window, Congestion Control algorithms, and recently, Explicit Congestion Notification. A main design goal is the detection of available bandwidth in an end-to-end manner, so that the sender does not send at an unnecessarily high data rate which the network or the receiver is incapable of processing. Packet drops is usually required in TCP as a feedback signal to enable detection of mismatched bandwidth. It's not always optimal (a well-known example is wireless networks - a dropped packet often does not indicate mismatched bandwidth), and it doesn't have to use dropped packets as the feedback signal (TCP Vegas & TCP BBR use latency, ECN uses a status bit), but in practice, the vast majority of systems (BIC, Cubic, Veno, CTCP) do require it, and it represents 80%+ of the installation.
> UDP is the latency-prioritized transport protocol for the internet. It drops packets that it can’t handle because they are expected to contain out-of-date information anyway.
It's supposed to work in this way. Unfortunately, two issues exist, the first challenge is applying the congestion control techniques invented for Bufferbloat to UDP, this needs to be done in a per-app basis. Another issue is, Bufferbloat is not simply a breakdown of flow control, but the existence of the large, uncontrolled FIFO buffer in networking programs, drivers and devices without queue management with latency in mind, which leads to an inherent latency in a saturated link. It's equally detrimental to TCP and UDP, as it takes an unusually long time for any packet to leave the FIFO queue. Breaking protocol-level flow control is only an additional effect that keeps adding fuel to the fire.
An earliest example was the large buffer in TX queue in DOCSIS modems, discovered, documented and reported by Jim Gettys, and fixed in a later DOCSIS specification. Another was the uncontrolled TX queue with 2000 frames in many Ethernet drivers that plagued early Linux kernels. At that time, fixing the problem in a LAN was as easy as, "ifconfig eth0 txqueuelen 1", effectively disabling it. Later, queue management was introduced and it's no longer a problem.
But many devices are still broken, the only way to stop it, is to ensure the uncontrolled buffer never have a chance to be filled, either by upgrading the upstream bandwidth to be greater than one could ever use, or by traffic policing your own TX bandwidth. Then you can only cross your finger and hope there isn't another uncontrolled buffer in another piece of network equipment at downstream (usually works at home, where there's only a router and a PC that runs the latest Linux/BSD systems). And even when it's the case, TX buffers on the opposite direction are not under your control, and ISP edge can be a place for them to exist.
I like that it describes them in terms of goals ("If you prioritise X over Y, then use..."), not mechanics like stream-oriented.
I wish more technology choices were presented in terms of the fundamental tradeoffs in high-level goals rather than mechanics of the particular abstraction.
It won't have a significant impact.
YouTube itself largely mitigates buffer delays, it uses BBR with TCP and QUIC with UDP, good news for YouTube and its users, but what happens when there's an interaction between bufferbloat-aware flows and other applications? For example, under congestion, my observation is that TCP BBR usually "wins" the game against TCP Cubic/Reno, and is able to utilize a large portion of bandwidth that others couldn't. A 10x increase of throughput is not unseen before, the bandwidth share won't be "fair" until everyone has upgraded. I'm not sure if it's the case for YouTube, but I guess it's a possibility.
If you get a grade below "B", then your home router is likely bufferbloated. Then read "What can I do about Bufferbloat?" at https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_d...
Please report back to the list so we can refine our knowledge. (It's like Covid-19 testing. We cannot know the incidence of infection if we don't test lots and lots of people to find a true rate...) Thanks.
Thing is, ISPs in the UK (including mine) are saying that typical evening use is 10-20x typical daytime use, so the uptick in remote working isn't actually an issue for them at all.
They've seen a 35-60% increase in daytime traffic, but it's still only half of what they're seeing in the evenings and nowhere near their network capacity.
AT&T has noted that their network traffic is up only 27% (https://about.att.com/pages/COVID-19.html).
I'm not saying that it isn't reasonable to lower streaming quality (a luxury item) at a time when the internet has become an even more critical link in our well-being - be that economic, social, or even physical as information on the physical danger gets transmitted over it. It's also reasonable to guess that there are a lot of people at home streaming content mid-day. However, the data seems to indicate that while daytime usage is up, it's still well below evening peaks and the increase in traffic isn't as huge as many people are probably thinking.
FWIW, my ping seems to have more than doubled to about 30 ms while download and upload speed seems unaffected but i'm with VM
That is assuming the bottle neck is not caused by wifi - if there are others using the wifi spectrum kids partner, neighbours etc - that could explain it
Lots of companies do, and have had to quickly buy new license, and are finding out they don't have the network capacity to handle all their employees working from home.
[0]: https://www.de-cix.net/en/locations/germany/frankfurt/statis...
So remote working during daytime might not be an issue, but increased recreational use of internet in the evening might be. (I'm just speculating here, haven't seen anything from the ISPs about this)
> Why should the video bitrate be dropped because some second rate ISPs are oversubscribing super badly? Isn't all of this totally against the principles of net neutrality?
No. This is entirely separate from net neutrality. That principle says, "No ISP should discriminate on the basis of content."
In the case of an oversubscribed ISP, the "magic of the markets" that so many lobbyists talk about is that you can simply switch to a new provider. Oh, you only have one provider? Tough cookies.
I'm not sure where this would save Google any money. It seems to just be a helpful (if more symbolic) thing to do.
https://chrome.google.com/webstore/detail/audio-only-youtube...
If not, I would second the "zero pixel" option!
youtube-dl -k gave me two files, one webm/opus audio file and one mp4/av1 video file.
The files had roughly same sizes, the audio being 9728k large, the video 9476k.
The video had 127 keyframes, out of 17030 frames total, distributed over 567 seconds of video (one keyframe every 4.5 seconds). I don't have a method at hand to measure the encoded size of the keyframes but if I extract the first 90k of the file using dd (bs=90k count=1), I get 21 frames, so that's a lower bound for the size that's actually needed to encode one single keyframe, more shouldn't actually be neccessary.
So of the 9.4M video file, > 99% is waste. Quite literally as 1% of 9476k is 95k. With the addition of audio, the amount of waste has to be adjusted to roughly half of the total audio+video data. Still a large amount of data that can be saved, especially at youtube scale where reductions of traffic in the sub-percent range are material for promotions.
The 480p video-only file sizes for this video as reported by youtube-dl have VP9 at 9.70MiB, AV1 at 9.25MiB, and H.264 at 3.55MiB.
If your content is audio only then use an audio encoding site like SoundCloud. Or, if you really want to use YouTube, then you need to get them to develop an audio specific option.
And then additionally, there should be better recognition of the "picture not changing" conditions, to allow better use of such a feature.
I was trying to distribute a 3 hour lecture with a single slide. I suppose seeing the speaker for a few seconds would be nice too. haha, I'm asking a lot? The slide had a lot of detail so the video uhhh I mean the jpg got enormous and few keyframes so no seeking? No thanks, ill do the "compression" in javascript. (eeewww!)
A 0 pixel video would defeat this by being in effect an audio stream separated from the video. I always wondered why manufacturers don't just resize the video stream to 1 pixel and use any of the device LEDs to "display" the video thus bypassing this part of the ToS.
Hilarious hack, love this idea
Isn't this backwards? It seems more likely that the TOS follows the business decision here. I believe old versions of the official mobile apps continued to play the video with the phone screen off.
it's not like we don't have ads on radio
It is not impossible to go over all music videos, automatically fetch lyrics and replace video with static album cover or something, but who would do it? If YouTube does this then they are responsible for any copyright infringement, and they become huge competition to user-created content on their own platform.
This does what you want.
For a specific example, it has a nice toggle above every track, where you can flip between video and audio-only. It works great, except that I cannot find a way to force it to stay on audio-only. As soon as the current track ends, the toggle resets back to "video".
And this kind of stuff is all over the app.
youtube-dl -F https://youtube.com/video-url
As others have said, if the "video" is a static image, the bandwidth usage should be negligible in practice. But I've seen lots of promotional album streams that intentionally add busy graphics, motion lyrics, etc; while they're sometimes cool, they're wastes of bandwidth and processing if I just want it play audio in a background tab.
Many times I've listened to a YouTube video or stream without watching it by just starting the video and then pocketing my phone and being careful not to touch it. I hear the audio and continue my shopping or cleaning or whatever while battery and bandwidth is wasted displaying the video to the debris inside my pocket.
I can only assume Google has run the numbers and decided it's actually more profitable for them to make something so silly and wasteful on both sides of the connection necessary, but that's what it is.
I've never seen it be active outside of a phone call.
mpv --no-video [youtube url]
youtube-dl -f bestaudio https://youtu.be/YT0k99hCY5I
mpv --ytdl-format=bestaudio https://youtu.be/YT0k99hCY5Iyoutube-dl can directly stream as well, e.g.,
youtube-dl -o - "https://www.youtube.com/watch?v=BaW_jenozKcj" | vlc -
And there's mps-youtube as well.
mpv --ytdl-format=bestaudio 'ytdl://ytsearch1:John Butler Trio Ocean'
!#/bin/bash
yt(){
mpv --ytdl-format=bestaudio "ytdl://ytsearch1:$*"
}
Shall amend my scripts immediately.
You can still watch 4k videos by changing the setting manually.
Here's an add-on to do this automatically:
https://addons.mozilla.org/en-US/firefox/addon/disable-polym...
Not sure if they have regulated themselves or the sources are reduced. Or both.
I wish they would use special compression for text that's not moving.
Do you have a better suggestion?
For low-motion static content like a slideshow or console window, a ultra-low frame rate usually results in acceptable fidelity while minimizing bandwidth, but not all hardware decoders (think Chromecasts, TVs) play well with them, so it wasn't possible to go down this road in general.
(Disclaimer: This is my personal opinion and not that of my employer.)
It's been interesting watching them scale up Netflix Party in the meantime...
It mislead me for sure.
If you don't like the ads, just pay for premium.
Everyone here goes on about how "it's just the price of 3 cups of coffee", but here it's most definitively not.
5.37 EUR is the price of 2 Starbucks lattes, 8.06 EUR the price of 3 lattes.
Not insignificant, but given the lack of ads (very important for my kid to not be exposed to brainwashing crap), or option of playing in the background for my phone, it's totally worth it. And I think overall I watch more YouTube than Netflix.
Yeah, and that's why there are like three Starbucks in my whole EU country. A latte in any coffeeshop here costs 1.2€, because they're adjusted to local salaries.
Also the "Google Play Music All Access" is 4.90 USD and YouTube Premium is 5.80 USD, not much of a difference.
Also a family pack for Play Music isn't available. And the Family Pack (5 members) for YouTube Premium is 8.69 USD, which is what I'm on and all slots are occupied, so it's obviously a better deal.
(I understand the sentiment, but it's actually more like $15 a month here. Plus I make about a fifth of what a developer in the USA might make, pre-taxes. After taxes, rent, and groceries, $15 is about 10% of my monthly budget. I am not going to spend it on cat videos.)
Alternative for iOS users. Bookmark, save to home screen - search for your YouTube video on there.
The only time I care about quality is some educational content where there are e.g. small equations on the screen.
Good call.
https://addons.mozilla.org/en-US/firefox/addon/enhancer-for-...