Peru 8K HDR 60FPS (FUHD)
Jacob + Katie Schwarz0 HN recommenders · 2019–2025
63.8M views · other · dated · Uploaded 2017-04-09
A travel video of Peru shot natively in 8K HDR at 60fps on a Red Helium sensor. It covers Lima, the Amazon, Cusco and other places.
HN doesn't recommend it for its content but uses it as a handy example of file size and bitrate for high-resolution video.
1:25:348 Bit & '8 Bitish' Graphics-Outside the Box
GDC Festival of Gaming
23:53D/A and A/D | Digital Show and Tell (Monty Montgomery @ xiph.org)
FL Studio
29:361. How Buildings Learn - Stewart Brand - 1 of 6 - “Flow”
Stewart Brand
32:47The world's worst video card?
Ben Eater
1:13:57Floyd Toole - Sound reproduction – art and science/opinions and facts
CIRMMT
1:03:36Christopher Alexander - Patterns in Architecture
Peter Petrash
9:07The Great Wave - Part 1
David Bull
44:40MiniDisc - An Appreciation
Techmoan
3 comments from Hacker News
No way, 100Mbps is fast today for most people. This 8K youtube video is 5m38s long and 850MiB large: [VIDEO] Do the math on that and you need 21Mbps to stream that video without buffering, assuming a uniform bitrate: [LINK] 100Mbps down is fast for most people. What do you think the average user is doing that needs more than 100Mbps down?
> YT alone adds 500hrs of video per min . That is at minimum 9000 TB / day (500 18TB disks/day ...) ... assuming SD quality 220 mb per hour single format and one copy. Nitpick: Each bigger resolution stacks on top of the previous one, so 8K60fps means storing 8K60 (webm+av1), alongside 4K60 HDR (webm), 4K60 (webm+av1), 4K (webm), 1440p60 HDR (webm), 1440p60 (webm+av1), 1440p (webm), 1080p60 HDR (webm), 1080p60 (webm+h264+av1), 1080p (webm+h264), 720p60 HDR (webm), 720p60 (webm+h264+av1), 720p (webm+h264), 480p60 HDR (webm), 480p (webm+h264+av1), 360p60 HDR (webm), 360p (webm+h264+av1), 240p60 HDR (webm), 240p (webm+h264+av1), 144p60 HDR (webm), and 144p (webm+h264+av1). And as noted, a given resolution is often stored in multiple video formats, so there's that too. The data needed to store a single video thus adds up quickly: $ youtube-dl -F [VIDEO] | grep -o '[0-9\.]\+.iB' | sed 's/MiB/*(1024^2)/;s/GiB/*(1024^3)/;s/.*/(&)/' \ | tr '\n' + | sed 's/\(.*\)+$/scale=3;print(\1)\/(1024^3),"G\n"\n/' | bc -ql 8.423G So for [VIDEO] (a random 8K video I found), storing 5 minutes 37 seconds requires about 8.5GB due to all the transcoding. It's quite possible YouTube also keeps the original uploads around for a bit as well. --- It incidentally proved so complicated to correctly type out the format list above manually it was actually easier to figure out the following regex: $ youtube-dl -F [VIDEO] | sed -n '/video/{s/^.\{35\}//;s/ \+[0-9]\+k \+, \+/ (/;s/webm.*\|vp9.*/webm/;s/avc.*/h264
Video Streaming has surprising little overlap with Video Codecs . Once you choose input/output options, then there's little to change about the codec. The vast majority of options available to ffmpeg aren't supported in the browser. Streamers don't have options for precisely the same reason OP doesn't have options - you are limited entirely into what the browser supports. I've built the exact pipeline OP has done - Video, over TCP, over Websockets, precisely because I had to deliver video to through a corporate firewall. Wolf, Moonlight and maybe even gstreamer just shows they didn't even try to understand what they were doing, and just threw every buzzword into an LLM. To give you some perspective 40Mbps is an incredible amount of bandwidth. Blu ray is 40mbps. This video, in 8K on Youtube is 20Mbps: [VIDEO] There's really no explanation for this.