The current best solution is brute force, and local proxy servers distributed around the world (CDN = Content Delivery Network).
Multicast (https://en.wikipedia.org/wiki/IP_multicast) technically exists, but AFAIK it's not supported over the public Internet. (In the early days of video on the Internet, I recall reading about multicast getting used over a part of the Internet ("mbone", the multicast backbone) that connected some North American universities, especially for video conferencing with many-to-many connections.)
Using it for video could basically get routers to do the job that CDN servers (content delivery networks) do for live feeds: sending the data once to a city, and having all users in that city stream from a nearby machine, so there isn't one machine in the world sending out all that traffic many times over backbone links. (Maybe not "city" but "internet hub".)
For a live stream with huge numbers of viewers (e.g. the Olympics, world cup soccer) where most networks that have any viewers of the stream have multiple viewers, it's a potentially interesting idea, if we had networks that supported multicast. Or for software updates to major software (like Windows) right after they're released, you could imagine having a server multicast the update files a few times for everyone to get a copy.
But there are major technical challenges.
If a packet gets dropped, multicast doesn't have a good way for a single client to request a retransmit. With low-latency video conferencing suitable for two-way chats, you just accept the glitch in your stream as the price to pay for keeping latency low. But streaming a "live" event, normally we don't care about a few seconds of delay which give enough of a buffer for TCP retransmits. (Youtube, and the web in general, operates over TCP/IP, a protocol that retransmits dropped packets.)
The routers don't keep old copies of the packets, and it doesn't scale for every client in the world to send a request to the server to retransmit a dropped packet to them (perhaps over unicast UDP). (This would also open up a way for malicious users to create DOS (Denial of Service) attacks and consume a huge amount of the server's bandwidth.)
So perhaps we could use some forward error correction (like ECC) so receivers could reconstruct the correct data if a few packets were dropped. That would add some overhead all the time, with no dropped packets, but could potentially avoid many clients needing to retry. But dropped packets often come in bursts, so we'd need a large "chunk size" for FEC to help (like a few % overhead over many seconds or maybe a minute of video, requiring large buffers on each client to be able to reconstruct data with error correction).
This would be much less of a problem for software distribution via multicast (on release day when everyone's downloading it), since ECC codes could cover the whole thing, like Par2 or the recovery data that can be embedded in some archive formats like RAR.
But if we wanted to cover the worst case for a viewer comparable to what youtube buffering can absorb currently (multiple seconds of lost data), that would make the error-correction overhead way too high.
So we'd want clients to be able to fall back to unicast requests to fill gaps, presumably over TCP (to get its congestion-friendliness). So we need a high-bandwidth server or CDN, especially if people abuse this to always stream from TCP instead of multicast (e.g. to work around being on an ISP that doesn't support multicast). Or if we don't consider that "abuse", and just consider multicast as saving some bandwidth.
This is obviously much more technically complex than receiving a TCP stream, and may just let your CDN be cheaper and have fewer machines or capacity.
And building around this architecture doesn't let people pause and rewind, which some streams do want to support. (Unless their client had already received and locally saved the video they're rewinding into.)
