[HN Gopher] Ask HN: Video streaming is expensive yet YouTube "se...
___________________________________________________________________
Ask HN: Video streaming is expensive yet YouTube "seems" to do it
for free. How?
Can anyone help me understand the economics of video streaming
platforms? Streaming, encoding, and storage demands enormous costs
-- especially at scale (e.g., on average each 4k video with close
to 1 million views). Yet YouTube seems to charge no money for it.
I know advertisements are a thing for YT, but is it enough? If
tomorrow I want to start a platform that is supported with Advert
revenues, I know I will likely fail. However, maybe at YT scale (or
more specifically Google Advert scale) the economics works? ps: I
would like this discussion to focus on the absolute necessary
elements (e.g., storing, encoding, streaming) and not on other
factors contributing to latency/cost like running view count
algorithms.
Author : pinakinathc
Score : 79 points
Date : 2024-05-19 17:51 UTC (5 hours ago)
| iwanttocomment wrote:
| YouTube generated _$31.5 billion_ in advertising revenue in 2023.
|
| https://www.businessofapps.com/data/youtube-statistics/#:~:t....
|
| That's... a lot! Plenty of historical precedent for fully
| advertising-supported media with high expenses, from OTA network
| television and radio to free weekly newspapers... or inexpensive
| subscriptions to daily newspapers subsidized by advertising.
| Advertising has been paying the bills for electronic media for a
| century now.
| KennyBlanken wrote:
| Revenue is not net profit.
| Waterluvian wrote:
| No, but it demonstrates they have at least $31 billion to
| make it all work.
| rgbrenner wrote:
| Yes. For comparison, Netflix has about $30B in revenue... paid
| up front for all of its content (something youtube doesnt) and
| accounts for a larger percentage of internet traffic (likely
| because of higher quality streams)... and they still made $6B
| net profit.
| londons_explore wrote:
| Netflix content is highly coachable (tiny library Vs
| YouTube), which dramatically reduces the cost of serving the
| data to users.
| samspenc wrote:
| The mind-blowing thing about this I found out recently, is that
| analysts think that Youtube is still losing money, even after
| making $31.5 billion in revenue!
|
| From 2015 "Some unnamed person at Google reportedly said that
| the site is "roughly break-even."
| https://www.cbsnews.com/news/4-reasons-youtube-still-doesnt-...
| which in turn quotes https://www.wsj.com/articles/viewers-dont-
| add-up-to-profit-f...
|
| From March this year (2024): "Analyst Michael Nathanson of
| MoffettNathanson estimates that YouTube TV will become
| profitable this year"
| https://www.newscaststudio.com/2024/03/29/youtube-tv-profit-...
|
| Part of this could be because they pay out roughly 40-60% of
| the revenue to the content creators, that leaves Google /
| Youtube with half the revenue that they use to pay salaries,
| maintain infrastructure, including storage, hosting and serving
| content.
| rgbrenner wrote:
| Netflix spends over 50% of it's revenue on content production
| and licensing ($17B out of $30B), and they made $6B net
| profit in the past year.
| Ferret7446 wrote:
| Netflix doesn't need to subsidize anything. YouTube
| subsidizes a lot of videos which don't have ads.
| 1986 wrote:
| YouTube TV !== YouTube
|
| YTTV is their "cable" product
| mcwhy wrote:
| youtube is the modern nanny and that is the most valuable ad
| space on the planet
| parasti wrote:
| I realized this as I saw many of my favorite gaming Youtubers
| chase the algorithm and change their content to stay relevant.
| It all eventually converges on content that children would find
| entertaining. They're the biggest demographic spending the most
| time looking at ads. That's where following the algorithm
| leads.
| reaperman wrote:
| > especially at scale
|
| The marginal costs go down a bit if your scale is truly immense.
| Google can afford to design/manufacture/deploy hyper-efficient
| custom silicon ASICs for encoding. Also because their critical
| mass of users provide valuable network effects, they can get away
| with particularly poor quality encoding (IMHO) and the vast
| majority of users still won't switch to other platforms with
| higher visual quality - but other (non-pornographic) video
| platforms generally don't have that luxury.
| abofh wrote:
| Encoding is largely super-linear for a single stream, so you just
| need enough cores for the intake * formats. Streaming is mostly
| chunking and a smart player that loads the right chunks at the
| right time. Storage is bottom dollar, use whatever the cheapest
| disks you've got that you can attach to fiber, then cache the
| hell out of everything.
|
| So in short, the only "on-demand" component is encoding, and if
| you don't have an 'available in an instant' promise, you can do
| it on spot instances on the cheapest cloud you can find; The rest
| is just storage and distribution - if you own a world-wide
| network of datacenters for your successful advertising service,
| that's kinda an already solved problem for you - just allocate a
| few racks to a new service.
|
| I of course downplay everything and simplify massively - but at a
| high level, it's just a lot of ffmpeg -> S3 -> html5 player. The
| harder problems are in the long tail - high latency, content
| licensing & geo fencing, etc.
|
| Source: used to SRE for a video streaming provider (not YT), also
| former GG
| sargun wrote:
| Video streaming is expensive _for you_. Google is incredible at
| making things cheap that we all thought were expensive.
| fuzzfactor wrote:
| >Google is incredible at making things cheap
|
| As Curly would say, "Eh, a big cheapskate, nyuk nyuk !" ;)
|
| It's true they do have a "cheapening" effect, especially over
| time, but Curly's a knucklehead, I wouldn't want to compete
| with them on their own terms. That's a big gorilla.
|
| >If tomorrow I want to start a platform
|
| Seems like one approach would be to start out with what you can
| easily afford to begin with.
|
| Which brings me exactly to the bare bones of storing, encoding,
| streaming and nothing else.
|
| If nothing else to minimize complexity and cost of getting
| started.
|
| And to possibly obviate the need for monetization up to a
| point.
|
| To launch, just pick one fairly popular & accessible
| format/bit-rate and encode all your raw content (or a test
| portion of content) the exact same way in advance. Afterward,
| you're done with that phase and free of any need for real-time
| encoding. You still need to store and subsequently "outstream"
| your ready-to-deliver content.
|
| It may actually cost you nothing to store a working copy of
| your encoded content "library" on your own private server on
| your own designated premises, especially if you already own the
| storage devices and there is plenty of unused storage space.
| There are also alternatives that are not without cost, only you
| could decide if it was worth money or not.
|
| Naturally you will be limited by the bandwidth and
| infrastructure at each storage location, as to how many viewers
| at what resolution you can directly serve at one time, and
| whether or not the ISP/router can be configured to allow
| outside access to your server.
|
| If you're going to use 100Mbps of surplus upload bandwidth from
| a business internet account for instance, and your content was
| encoded at 1.5Mbps (don't even think about 4K), it may be no
| additional cost to start serving viewers directly from that
| server, but you would not be able to serve more than about 50
| viewers at one time.
|
| That might get you started (at an appropriate scale) with no
| cash outlay whatsoever, and if the demand was there beyond a
| few dozen viewers then you could decide to pass your stream
| along to a more capable content delivery network of some kind,
| at various incremental cost.
|
| Alternatively, the whole thing could be outsourced and hosted
| for world-wide access in a turnkey operation where all you do
| is supply the content. Cost may be a prohibiting factor, it
| does seem like there are hosting plans with a free tier but not
| with enough bandwidth to serve a meaningful number of viewers
| compared to YT.
|
| Fortunately for YT, when they got started they didn't have
| competition already showing 4K stuff to compare to.
|
| But if the action you take, has cost within the range of what
| you can _easily_ bear, you could then afford to deliver a
| completely superior, ad-free experience for your fortunate few
| viewers. If you wanted to. Something a multi-billion-dollar
| company seems to be less and less able to afford. What a
| position to be in. If the whole thing actually was costing you
| no cash at all you 'd be free to make it seem as free and
| frictionless as YT, probably more so because it was free from
| the ground up.
|
| >a platform that is supported with Advert revenues
|
| If you did decide to go this route and were sustainable without
| ads to begin with, you could very judiciously choose your
| sponsors to be ones that did not conflict with any feature that
| is more meaningful to the visitors. You would also be
| financially ahead beginning with the first ad you decided to
| run. And you could decide to stop at any time.
| miyuru wrote:
| For streaming, google have caches in like every ISP network. Also
| majority of the people watches the latest and same type of
| content that is mainly served from the homepage, which is easier
| to cache and serve.
|
| If you have the ipvfoo extension, you can see it in action. (its
| easier to see with IPv6)
|
| https://github.com/pmarks-net/ipvfoo
| mysterydip wrote:
| I wonder if that's part of the reason for their algorithms to
| push the same videos to everyone, they're already cached at the
| edge so it costs them nothing?
| leros wrote:
| I would imagine it's an unintended side effect of the "people
| recently watched this so it's relevant" part of the
| algorithm.
| kmeisthax wrote:
| More popular works are more likely to be enjoyable to more
| people. There is no really objective measure of quality for
| any creative work, and taste doesn't scale, so publishers
| bias for popularity as it's one of the few things they can
| understand.
| michaelt wrote:
| _> taste doesn 't scale_
|
| The motto of so many social networks. Even if they don't
| know it.
| carlosjobim wrote:
| The majority will enjoy and like whatever is pushed on
| them. Decades of radio and TV should be enough evidence for
| this. Music or video is not popular because people like it,
| but because somebody decided to make it popular by pushing
| it on people.
| occz wrote:
| I would imagine that's too insignificant to factor into that
| particular calculation.
| hombre_fatal wrote:
| They're cached because they're popular, not popular because
| they're cached .
| cloudking wrote:
| This is the correct answer. Caches in local PoPs
| https://cloud.google.com/cdn/docs/locations
| miyuru wrote:
| They even have a map.
|
| https://peering.google.com/#/infrastructure#edge-nodes
|
| It also says "Static content that's very popular with the
| local host's user base, including YouTube and Google Play, is
| temporarily cached on edge nodes. Google's traffic management
| systems direct user requests to an edge node that provides
| the best experience."
| tialaramex wrote:
| Although note the map is only city addresses. For example
| the "London" pin is on the notional point where "London"
| is, ie Charing Cross. There is no giant network interchange
| at Charing Cross, it's just a convenient place co-ordinate
| for "London".
| jl6 wrote:
| It probably costs them a ton of money, but they probably make a
| ton more so that's OK.
|
| Also: bandwidth gets a lot cheaper when you own the pipes.
|
| And one that is less obvious: despite having hundreds of millions
| of videos available, a large contingent of people are watching
| the same ultra-popular ones. There are some economies of scale to
| be had there.
| kmeisthax wrote:
| For the streaming factor specifically, I can at least offer
| something resembling an answer: Google. In the early 2000s they
| bought up a bunch of dark fiber and peered with all the major US
| ISPs, and they were able to do this because no ISP wants to be
| the one that blocks or degrades Google. As a result they were
| able to host video streaming on their network without immediately
| being shut down by Comcast and co. Instead they had to go after
| Netflix.
|
| Google has a lot of custom encoding silicon, too, AFAIK.
|
| Storage is the biggest question of the three. Linus Sebastian
| specifically called this out when YouTube started really pushing
| to make the non-Premium experience _dreadful_. There isn 't
| really some secret special sauce you can buy or make for storage.
| Literally everything is being stored with the same hard drives,
| SSDs, discs, or tapes you can just go out and buy. The only
| specialization you can do is build or buy equipment to handle
| extreme numbers of them. Google _does_ buy these in bulk, so they
| probably get a discount on storage, but it 's not something that
| would make storage costs just go away.
| echelon wrote:
| When does YouTube start _deleting_ content?
|
| They'll have to do that eventually, right?
| sebzim4500 wrote:
| So long as storage costs decrease exponentially I think
| they'll keep everything.
|
| Especially if the amount of content uploaded keeps going up,
| so the relative benefit of deleting old stuff is small.
| throwanem wrote:
| > So long as storage costs decrease exponentially I think
| they'll keep everything.
|
| I agree. That's why I've recently made a practice of
| backing up things to which I'd regret permanently losing
| access.
|
| https://ourworldindata.org/grapher/historical-cost-of-
| comput...
| k8sToGo wrote:
| You don't need to keep everything "hot" all the time. Storage
| tiers exist for a reason.
| grepfru_it wrote:
| My 15 year old videos with 30 views still load nearly
| instantly. It's as close to hot as hot is
| SirMaster wrote:
| But they are tiny 480p files yeah?
| crazygringo wrote:
| Speed/latency doesn't tell you much, because it's all on
| a hard drive _somewhere_.
|
| The question is whether YT is serving up the _one_
| (redundantly-backed storage) copy they have of your
| almost-never-watched video, or whether it 's serving it
| up from one of 1,000+ copies it's made across the globe
| for currently popular videos.
| NBJack wrote:
| Think about what you actually need to start a video.
| Maybe a dozen MB?
|
| After that, you can plunge into colder storages and warm
| things up as you stream. Additionally, if you need longer
| to 'defrost' things, just cache a few more MB at the
| front. Cheat a bit by assuming 480p to start with if you
| need to; even less to store.
| londons_explore wrote:
| There is also location location location.
|
| Maybe Google holds your content in 7 data centers round
| the world (~1 per continent for planned maintenance +
| latency + reduced oceanic fiber usage).
|
| But with old rarely streamed content they might cut that
| down to just 3.
| pinakinathc wrote:
| Exactly! This was my go-to approach for reducing storage
| costs. Customers don't get spooked when they get an extra
| 1s delay for something they search once in a month.
| However, an extra 30ms delay in "everyday content" is a
| sure way to loose your users.
|
| However, implementing this in practice is non-trivial.
| Knowing what is "everyday content" versus what is "once a
| month content".
|
| To add more complexity -- you have these semi-predictable
| hype-waves especially two peaks in case of most YT videos
| where a "once-a-month" content becomes an "everyday"
| content before again becoming a "once-a-month" content. It
| feels you could specifically optimise for this -- reduce
| storage costs without sacrificing UX.
| nradov wrote:
| Old content has value for training AI models even if there
| are no human viewers anymore.
| Jyaif wrote:
| Yes, it's inevitable.
|
| My guess is that the first step will be to re-encode all the
| non-popular videos with severe lossy compression.
| londons_explore wrote:
| They still keep the original uploaded files.
|
| You know that because when they release a new format (eg.
| HDR or a different resolution), they re-encode from the
| original. Various people have tested that with moire
| patterns and various other ways to demonstrate if something
| was encoded more than once.
| vundercind wrote:
| The bandwidth costs are the key. Good luck getting rates
| anywhere near what Google's effectively are. Spoiler: you
| can't. You probably can't realistically get to 5x their costs,
| byte-for-byte.
|
| Which makes competing with them effectively impossible except
| for a very-few other megacorps.
| oceanplexian wrote:
| Bandwidth costs are actually free, so this isn't exactly
| accurate.
|
| Most bandwidth is via settlement-free peering with thousands
| of ISPs around the world. At least that's how we did it at
| Twitch, and how we did it when I worked at a large CDN before
| that. There are still costs for backhaul, interconnect,
| colocation space, dark fiber, network hardware, and transit
| to fill the gaps. But this talk about how "Google can
| magically do it 5x cheaper" is nonsense.
| michaelt wrote:
| Don't Comcast and friends throttle any peering points you
| use, until you hand over $x per subscriber per month for
| them to stop doing so?
| ckdarby wrote:
| Bandwidth costs are really not that bad.
|
| 95th billing, adaptive, progressive playing and just cap
| buffer to the minimum to keep playing. Equals ~$1M/month for
| +10 tbit/s egress.
|
| Source: Worked at one of the largest bandwidth consumers in
| the world.
| mattmaroon wrote:
| If bandwidth costs were very high a whole lot of the
| services we love would cost more or not exist.
| vundercind wrote:
| I am so confused here. Either I've been doing high-
| bandwidth bit slinging extremely wrong for quite a while
| or a lot of HN has never done it at all and is opining on
| it anyway. It's real money, IME.
| lopkeny12ko wrote:
| Anyone who says "bandwidth costs are not really that bad"
| should spend 2 minutes playing with the AWS cost
| calculator.
|
| You would think the VMs are the expensive part, but no,
| egress is easily multiple times the cost of the compute.
| NBJack wrote:
| To be fair, that is the penalty of being in a shared
| cloud. They are incetivized to keep their customers from
| using everything, everywhere, all at once.
|
| Jump into a 'bare metal' datacenter and things can get
| much different.
| vundercind wrote:
| Not even AWS. Any CDN. It won't be AWS-bad (way, way, way
| under) but it _ain't good_.
| manquer wrote:
| Cloud bandwidth pricing has nothing with do with costs
| and everything to do with lock in .
|
| You can get 100x cheaper and unmetered at a low cost
| provider like OVH or hetzner or similar bare metal data
| centers .
|
| It doesn't even need significant monthly commits to get
| that pricing if you are running video streaming at scale
| you are not running on AWS or even tier 2 like OVH for
| sure
| Jyaif wrote:
| My home connection uploads at 681mbit/s (just did the test
| over wifi) for 40 euros/months. At that price, I'd get
| 13tbit/s for 800k euros.
|
| It's a bit surprising that you were not getting
| significantly better prices than individuals.
| vundercind wrote:
| Price business pipes where they won't cut you off for
| saturating that 24/7.
|
| [edit] and that have good deliverability worldwide, no
| weird paths to other consumer IPs that intermittently
| fail to route or inexplicably have dial-up transfer
| speeds. And have anything like a real SLA.
| jononor wrote:
| Assuming 10 Mbit/s per stream that would serve 1 million
| concurrent streams 24/7. If we assume people watch 2.4
| hours per day on average, it could support 10 million
| active users. Or a cost to serve for bandwidth alone of 1
| USD/user per year.
| vundercind wrote:
| > Source: Worked at one of the largest bandwidth consumers
| in the world.
|
| Mindgeek? :-)
| tithe wrote:
| Bandwidth/Transport costs for live streaming, especially in group
| conference call scenarios (where N streams needs to be
| broadcasted to N-1 participants) become prohibitively expensive
| after about 8 or so participants unless you can offload those
| bandwidth requirements to other places (e.g., like in a peer-to-
| peer architecture).
|
| How Zoom manages to do this in a client-server fashion and is
| still financially solvent is also a question I've had for a
| while, but like others say, discounts on the transport and
| peering arrangements will be a key part in making those economics
| work, as compression and storage are relatively solved problems
| here.
| constantcrying wrote:
| The value of YouTube isn't purely monetary. Controlling YouTube
| is extremely advantageous for Google, even if it isn't
| particularly profitable.
|
| Besides the general advantage of having control over such a
| massive platform, which definitely plays an important part in the
| lives of hundreds of millions of people, Google likely views
| YouTube as important to control. If YouTube were a separate
| entity, it could e.g. freely choose their ad providers or even
| provides ads themselves, essentially creating competition for
| Google. Google also has trivial access to the data there and
| therefore the easiest access if they want to train AI on that
| data. Last but not least I think Google sees YouTube as vital for
| their corporate image and their social mission presented in
| Google Jigsaw.
| xivzgrev wrote:
| Disclaimer: I used to work at a live video streaming company as a
| financial analyst so quite familiar with this
|
| The biggest cost is as you imagine the streaming - getting the
| video to the viewer. It was a large part of our variable cost and
| we had a (literal) mad genius dev ops person holed up in his own
| office cave that managed the whole operation.
|
| Ive long forgotten the special optimizations he did but he would
| keep finding ways to improve margin / efficiency.
|
| Encoding is a cost but I don't recall it being significant
|
| Storage isnt generally expensive. Think about how cheap you as a
| consumer can go get 2 TB of storage, and extrapolate.
|
| The other big expense - people! All those engineers to build back
| and front end systems. That's what ruined us - too many people
| were needed and not enough money coming in so we were burning
| cash.
| tithe wrote:
| Curious: was your distribution client-server or peer-to-peer?
|
| Or both, similar to Skype's supernode model?
| michaelt wrote:
| The overwhelming majority of "legitimate" video streaming
| sites operate on a client-server model, which allows videos
| to be watched in web browsers, and on mobile devices (which
| don't generally do well in P2P as they find uploading
| difficult).
|
| And generally torrent-based streamers don't hire financial
| analysts :)
| foota wrote:
| I'm guessing live video looks a lot different from a more
| static video site. I think encoding and storage are both quite
| expensive. You want to encode videos that are likely to be
| watched in the most efficient ways possible to reduce network
| bandwidth usage, and every video needs at least some encoding.
|
| Based on some power laws etc., I would guess most videos have
| only a handful of views, so storing them forever and the cost
| to encode them initially is probably significant.
| contingencies wrote:
| Interesting background. I worked twice in digital video, once
| ~2000-2001 (ancient history - early IP, ISDN, the dead-end of
| H.323, bonded GSM channels, etc.) and once ~2009-2010. The
| second episode was fascinating, we specialised in mobile video
| at a time when it was just appearing on the consumer market.
| _Most_ of the global mobile device manufacturers were clients.
| It got to the point where they would build the hardware and we
| would get airdropped in to their R &D to make it work - they
| had no idea how performant the architecture was going to be,
| because they'd never tried it. We also built the server side,
| the billing architecture with revenue share, carrier billing
| support (only possible with device preloaded apps due to
| _Google Play_ (then "Google Apps"?) store restrictions on
| third party payment mechanisms), etc.
|
| Encoding, scaling and transcoding are relatively cheap for
| stored content, and relatively expensive if you want real or
| near-real time.
|
| If you want DRM (digital rights management = ~ineffective copy
| protection) then you need to add a bit more overhead for that,
| both in terms of processing and latency. If you need multi-DRM
| (different DRM systems for different devices the consumer owns)
| and a good cross-device experience (like pause and resume
| across devices), it gets real hard real fast.
|
| It helps to be targeting a standard platform, for example a
| modern widescreen TV with H.265 support and solid 4K decoding.
| Otherwise you need a different version for every resolution, a
| different version for every CODEC, a different version for
| every bitrate, etc. We had great experience adjusting bitrates
| and encoding parameters for different device categories, for
| example if you had a certain phone and you ran it at max spec
| it might look great but if you were looking to preserve battery
| and were running on battery save mode the decode would fail and
| you'd get choppy performance and stuttering audio. This sort of
| thing was rife then.
|
| As a series of specialist video providers emerged, ~all the
| cloud providers went and added these services, basically 95% of
| which are frontends to ffmpeg and some internal cloud storage
| scheme or similar.
|
| Finally, billing is hard. Users have an expectation of free
| content now.
|
| No experience with real time stream economics, but saw the
| inside of LA's stadium video control center one day. Didn't
| look inexpensive, I'll tell you that much. Probably for events
| with multiple cameras you're mostly paying site fees, ie.
| reliable bandwidth, humans, mixing desk if required. For studio
| broadcast these costs will be reduced. Both will have a slight
| real time encoding tax vs. stored content. If you want to
| figure out how to do it cheaply, look at the porn industry.
| gravescale wrote:
| > basically 95% of which are frontends to ffmpeg
|
| I wonder what the approximate net global economic benefit of
| ffmpeg is to this point?
| hnthrowaway0328 wrote:
| Thanks for sharing. Is it possible to join his team?
| bushbaba wrote:
| It's not that expensive at YouTube scale. We are talking
| fractions of a penny per GiB transferred.
| superb_dev wrote:
| Yeah, YouTube is big enough to put their own cache nodes
| directly in ISP datacenters
| WookieRushing wrote:
| Yup! This is the reason why its so cheap for them. Other
| companies in similar positions have cache nodes in the ISPs
| and this dramatically lowers the cost
| Ferret7446 wrote:
| "not that expensive" is relative; it's still a lot of money.
| Sure, it's not trillions of dollars, but it's still billions
| of dollars. YouTube has historically not returned a net
| profit (and I haven't heard of that situation changing).
| deadlyllama wrote:
| DIY (instead of the cloud) is the answer. If you're pushing
| terabytes+ from day 1 on a shoestring, you're going to want your
| own CDN. If you can manage a queueing system and the occasional
| wait, run your own (or rented physical) hardware for transcoding
| at as high a utilisation as you can.
|
| Build vs buy pushes you to "build" early on when your margins are
| slim and your volume is huge.
| exe34 wrote:
| they lose on the unit item, but make it up on the volume!
| master_crab wrote:
| Storage, transcoding/encoding, and any other compute operations
| (rendering, etc) are small compared to data transfer costs.
|
| At the scale of the largest streaming apps (Disney, Netflix,
| YouTube, etc) you are moving petabytes of data PER DAY. At that
| size, you have access to significant savings on CDNs, backbone
| providers, etc. in many cases the discounts will be 90% - I have
| seen as high as 99% - or higher off the "list" price (which are
| usually never paid by anyone anyway).
|
| You also tend to own your own backbone and can link in whichever
| ISP wherever you want for the "final mile."
|
| Final note, when you have been doing this long enough, you can
| start shaping the traffic based off previous patterns. I remember
| an eBay listing years ago for a Netflix local storage device that
| was meant to store shows at an ISP's data center.
| neongreen wrote:
| I suppose you mean these appliances?
| https://openconnect.netflix.com/en/
| AlbertCory wrote:
| Disclaimer: I worked at Google and occasionally did things for
| YT, but it was 2015 and before. I did look at their P&L,
| _somewhat_.
|
| egress costs were enormous and YT was not profitable. I don't
| know if it is now, but I wouldn't be surprised to find it is.
| They sure have enough ads.
|
| As several people say below, caching content around the world is
| key, so that not all requests are serviced in NoCal.
| kfarr wrote:
| Bingo, YT has always been a loss leader for Google dominance.
| Only recently have they squeezed the ads knob to maybe generate
| a profit but I'd bet it's nothing like the high margin AdWords
| cash cow.
| dankwizard wrote:
| It's so wild to see people so confidently being wrong in a
| comment. YouTube has seen profit since 2013, with margins
| growing each year.
| Waterluvian wrote:
| It sure doesn't feel free. YouTube has cranked the ads up so
| frickin' high that I swear they're quietly in panic mode about
| profitability.
|
| Every month I notice the temperature of the pot is up a few
| degrees. This month it's unskippable 15 second ads before most
| videos. Last month it was the first search result now being an
| ad. Before that it was how 5 second ads are now 7 seconds.
|
| If I thought to write them all down I'd have a dozen more steps
| to share.
|
| My kids now call it "the Bad YouTube" vs. YouTube Kids because
| the former is flooded with ads.
| crazygringo wrote:
| The economics are simple:
|
| > _I know advertisements are a thing for YT, but is it enough?_
|
| Yes, it is -- virtually certainly. We can assume YouTube is
| profitable. It's not broken out directly in quarterly reports,
| but it doesn't make any sense that Google would still be running
| it after all these years (almost 20) if it weren't.
|
| But obviously YouTube didn't _start out_ as profitable. You need
| scale, which provides two things:
|
| 1) Marginal storage and streaming costs go down (Google is big
| enough to save huge amounts of money by running its own data
| centers, peering agreements, caching near customers, etc.)
|
| 2) More advertisers running more ads that can be targeted to more
| users whose preferences you know more about
|
| So no, _you_ can 't run it profitably.
|
| This is a classic example of a business that is only profitable
| at scale, that needs to lose a lot of money at first as it grows
| until it achieves scale. And it's not just scale on the
| traditional tech/users side, it's scale on the advertising side
| as well -- advertisers aren't going to bother running ads on your
| platform until you have enough users for them to care.
|
| It's also pretty strongly a "winner-takes-all" network effects
| situation, where video publishers want to put up their videos
| where the viewers are, and viewers want to visit the site where
| all the content is. So if you wanted to create a YT competitor, I
| don't know how you'd convince content creators to post their
| videos to your site in addition to YT, or how to convince
| consumers to watch said videos on your site instead of YT.
| tialaramex wrote:
| Also scale on the supply side. It took time to get to a place
| where obviously the video should be on Youtube, and that's hard
| to replicate.
|
| This applies to the content which would exist anyway, and then
| doubly to content created for Youtube. Grand Pooh Bear would be
| on Twitch anyway, but it doesn't really make sense for a Tom
| Scott, let alone "Corrections" which is a Youtube-only addition
| to Seth Myers "Late Night" show.
|
| Likewise until it gets fairly "big" it doesn't make sense to
| _officially_ put your music videos on Youtube. Today that 's
| basically the main way they're getting seen.
| Strom wrote:
| > Streaming, encoding, and storage demands enormous costs --
| especially at scale
|
| When you look at costs per unit, then it gets cheaper at scale,
| not more expensive.
|
| For streaming, at scale you can afford to do peering yourself,
| instead of buying bandwidth.
|
| For encoding, at scale you can afford special purpose encoding
| hardware, instead of using general purpose hardware.
|
| For storage, at scale you can get cheap bulk deals with drive
| manufacturers.
| williamstein wrote:
| Is there any way that I can pay YouTube so that the videos I post
| do not have ads when people view them for free? I think there is
| a clear answer to this question for video, and it's ~$60/month.
| throwaway22032 wrote:
| YouTube is vertically integrated.
|
| They're not paying a margin to advertising companies because they
| are the advertising company, they're not paying a margin to
| datacenters because they are the datacenter.
|
| The data gleaned from YT views helps them to run search and vice
| versa.
| DreamFlasher wrote:
| "If something is free, you are the product."
___________________________________________________________________
(page generated 2024-05-19 23:00 UTC)