So many permissions, but meanwhile autoplaying video and audio is still hidden behind a horrible heuristic model in Chrome that fundamentally prioritises internet giants like YouTube, Netflix and alike.
I work in the video streaming industry, and we continue to support TLS 1.1 extensively for a wide range of "smart" TVs and set-top boxes, very frustrating, there was even a long period where large CDNs were trying to shut down 1.1 and realised they'd lose a lot of business in the streaming space if they did...
Customers regularly ask us whether we support TLS 1.0 and 1.1 for this very reason. We do, and support policies to raise the min version, but that’s not the default.
Smart TVs and many streaming boxes often ship with vendored libcurl/OpenSSL/other libraries that are already years old when the device itself is new. It is frustrating and insecure, but cutting these users out isn’t a clear solution either.
It's not an issue, until someone finds a way to mitm the request, send a special payload to your Roku that is then opened by an unpatched ffmpeg (https://www.linuxcompatible.org/story/asa2020074-ffmpeg-arbi...) that allows an RCE and turn your Resident Alien into a Resident Zombie.
Your credentials might go to a different endpoint, but the device is still limited in its TLS support as a client.
The attacks aren’t entirely practical, and the threat model for “someone cares enough to MitM my streaming connection” isn’t a common one, but it’s much closer to practical compared to attacks on TLS 1.2 & 1.3.
I know [edit: guessing] you're not being serious, but until there are laws mandating this in given markets, the security risks will ALWAYS be unknowingly carried by the consumer. In a hypothetical world where a manufacturer differentiates by advertising a product as "Now with security updates guarenteed for 10 years!" consumers will suddenly realise they've been sold garbage until that point. It just won't happen.
Or for that matter: any digital device that is not a computer or a mobile phone.
When was the last time you applied a security update for your networked printer? I'm guessing never, because no printer vendor has a security department, none have security updates, etc...
This is why smart networked printers are where state-sponsored attackers like the NSA like to hide their persistent malware...
They can be, but like phones the manufacturers often at best keep up with fixes/upgrades for a year or so after release after which they only care about newer products unless there is a really embarrassing security problem.
I am in the same industry and we have the same problem. We are moving to having "insecure" proxies that support TLS 1.1 for devices that can't update. It won't add much security but at least demonstrates its was an active decsion to support it rather than a config mistake.
I don't think that saying technology is an evolving problem is an "authoritarian" stance
Software is written by human beings, human beings make mistakes. The fact these devices can't be updated by the vendor is an implicitly economic problem
Right-to-repair likely wouldn't "solve" these problems for 99% of people, unfortunately. Netflix would never have its customer service people advocating to download custom firmware for smart TV's from "some Russian website" for instance
The real change it would cause is allowing "tech savvy" people to carve out a niche repairing and reselling used, but functional devices. Which even if it's only a 1% decline in sales is an unacceptable proposition for companies.
Selling millions of something every year somehow isn't worth it if even a single PENNY is left on the table, or "spent" in the wrong place instead of lining their pockets
The authoritarianism is that companies should be aware that technology progresses and still lock users out from their hardware so they can’t fix it when the world inevitably changes.
> Netflix would never have its customer service people advocating to download custom firmware for smart TV's from "some Russian website" for instance
They wouldn't tell that to people directly, but they could tell you to go to a repair man. Who then, would proceed to download that same firmware from the Russian website and apply it, and the TV now works. Netflix gets to keep their reputation, and the customer is happy with the TV.
I don't realistically see this as being a killer feature for most users, but it's super interesting none the less.
Sony are saying the bitrate will be "Up to 80Mbps", which is around 3x that of most UHD streaming service profiles. However there will be significant diminishing returns on the perceptual quality at this bitrate - 20Mbps to 40Mbps for example will only increase perceptual quality by a couple of percentage points. Much of this "Up to 80Mbps" will be wasted perceptually speaking.
It's also worth keeping in mind that the encoding on BluRays is often lazy because there's lot of space available, where as a huge amount of work goes into encoding content for streaming delivery in the lowest bandwidth possible for a given target quality, using technologies like per-title and per-scene encoding. [1] [2] [3]
This isn't accurate at all. HLML 5 video, MSE etc. have a world of improvements over the mess of FLV / Flash / RTMP streaming.
Can you give some examples of what's wrong with HTML5 video streaming and these implementation issues? There's a huge community of video engineers working to make streaming video better, and we'd love to hear feedback.
There's a few approaches depending on your target latency. If you need to get below 2 seconds, yes, you'll likely want to use a WebRTC based technology to deliver the video. There's a couple of open source approaches out there, including Pion [1], which is a go implementation of a WebRTC stack. You could also build something on top of Jitsi [2]. Commercially there's also a few solutions, including Milicast [3], Red5Pro [4] and others.
The biggest problem with WebRTC based stacks is that the cross device compatibility is still generally poor, and the cost of operation is generally very high, as you can't use commodity CDNs for delivery.
If you're comfortable around the 2-5 seconds latency mark, there's more traditional HTTP based technologies available. MPEG-DASH has a Low Latency mode which uses chunk transferred HTTP fragments, and Apple has recently introduced a Low Latency HLS mode, which works in much the same way [5] [6]. You can build LL-HLS and DASH-LL solutions on top of open source toolchains like Streamline [7], and use commodity CDNs for delivery to reduce cost.
Great question, this is a large, complicated topic, but here's a quick overview. For context I've been building live streaming video infrastructure for a little over 10 years now.
At a fundamental level, yes, the encoding is one of the most expensive components of a live-streaming system (at low scale), and honestly, your guess of 2 bitrates for each video is very much on the low end - generally on average most platforms create about 5 different qualities created for any one stream, ranging from ~500kbps to ~5+mbps.
If you look at the pricing of modern video platforms, you can see the high cost of ingest and transcode captured in their pricing:
AWS IVS - $2.00 per input hour.
API.video - $2.40 per input hour.
Mux - $4.20 per input hour.
Generally there isn't too much use of hardware acceleration on ASIC or GPU for h.264 processing today. FFmpeg (x264) is plenty "fast enough" when tuned on commodity X86 hardware, when you have things like AVX extensions. Generally transcoding a 4-6 second segment of video should only be taking a couple of hundred milliseconds at a maximum.
As for how the larger platforms deal with keeping live streaming cost competitive, the number of qualities (and often codecs used) varies depending on the number of viewers you have, so that they're not wasting resources encoding for a couple of viewers. Many platforms also implement just-in-time encoding, to limit the amount of content that's transcoded when it isn't being viewed.
Some platforms also drop all the way down to a transmux for streams with very low viewer numbers - transmux in this context just changes the packaging of the inbound stream without changing the actual encoded picture data.
It's also worth considering from a business perspective that many UGC live platforms will also be taking a loss on small streamers with a low number of viewers, and covering that with the revenue from larger streamers with ad revenue / subscribers.
thanks for the info. i did not say there are two streams. i said there are two levels of transcoding - normalizing the ingress into some standard codec and container and second one is the lower bitrate variant - that does not mean just one but as you said - it is/can be 240p, 360p, 480p, 720p, 1080p(source) and so on. in other words the encoding takes place at least two times.
> FFmpeg (x264) is plenty "fast enough" when tuned on commodity X86 hardware, when you have things like AVX extensions. Generally transcoding a 4-6 second segment of video should only be taking a couple of hundred milliseconds at a maximum
can you elaborate on this? i find that hard to believe from what i have seen and from the ton of "ffmpeg is slow" google search results. if that is truly the case, there might be light at the end of the tunnel. annecdotally, today i encoded 2sec h264 mp4 into av1 and it took only 2-3 minutes... vp9 took 8 seconds(still 4x). sure, that was not on a server but still, it's not like i am computing PI on the background.
Sure, but this was my point, x264 is very fast on commodity hardware, the overwhelming amount of video delivered is still h.264, especially on live video, and in particular for low-viewership, live user generated content.
If you want/need to transcode to VP9 or AV1 at scale with good quality, yes, you'll absolutely need GPU or ASIC accelerated encoders, of which there are a couple for VP9, and none for AV1 today.
h.264 will get you to 95-99% market penetration on the device landscape.
ok, i see what you mean. though vp9 usually gets me 1/4 or 1/5 of h264 video so i thought it was worth to save the network traffic(even av1 got me larger file at incredibly slow speed) but as you directly pointed out, without direct support on the hardware, like h264 has these days, it will become a bottleneck so i would have to sacrifice traffic for speed and practicality and i guess vp9/av1 makes sense for youtube, bitchute or simply video HOSTING service, not for lvie streaming. thanks for lighting the bulb above my head :D
While some of the larger UGC platforms do use VP9 for live streaming, it is only for a limited subset of high concurrent viewer streams, and yes, in many cases those aren't running the encodes on commodity hardware.
As for AV1, there really aren't any live implementations ready right now, a few have been demo'd, but I'm not aware of any deployments today.
I have checked [1], so the VP9 already has generally available hardware support, and Intel just a few days ago releasted their Tiger CPUs that do support AV1 [2].
Great question, it's actually not quite that simple. HTML5 was indeed supposed to bring trivial video to the browser, and it almost did.
If you want a good video streaming experience for all your viewers, you need something called Adaptive Bitrate (ABR). Some protocols that you may have heard of the implement ABR include HTTP Live Streaming (HLS) and MPEG Dynamic Adaptive streaming over HTTP (DASH).
ABR allows the stream to adapt to the bandwidth capabilities of the viewer. If you don't do this, some users will experience buffering, and some will have to sacrifice on quality.
Unfortunately most browsers don't support an ABR format natively, so you need to use Media Source Extensions, and a more complex player to support these protocols in a browser.
Well, I don't know about you, but sometimes I'm on a 3G network. Yes, I could wait to get home. But some people also have really terribly bad providers offering them very little bandwidth.
So, by doing this, you make sure your content can reach more people. Which, to me, seems to be the whole point of making and putting it online in the first place
Of course, but there are instances of the opposite. I encounter both from time to time. For example I want to show someone a video while having a drink, usually it doesn't have to be crisp 4K 60fps, just play the god damn thing before we lose interest. Other times I want to watch a video, I'm in the middle of nowhere anyway, I have time and data in the monthly cap, just not enough bandwidth.
User choice and smart defaults would go a long way.
Well, people do expect YT/NF level. And sadly we've trained everyone to expect that everything starts playing instantly.
So if your income depends on people not rage-quitting your page, you'll have to provide something that satisfies their "needs", or more appropriately "desires".
I'm not saying people shouldn't do more for user experience, but the cost-benefit seems to be bimodal. Do the minimum, or pay YT/NF/Vimeo (or CF or AWS Streaming, or get ready to bankroll your own).
It is by no means a clean or modern solution (I agree, go with Youtube etc or provide a transcoding js player), but about a couple decades ago many sites would simply link to several resolutions of a video, allowing the user to play either a low, medium or high res version as per their current data connection. So that is one option that sidesteps adaptive bitrate players as well as a large CDN.
As has been pointed out above, having some kinds of video downrated to be streamable on 2G isn't much different from not having the content at all. While 4K is rarely required, pushing out coding tutorials at any resolution below 1080p is nearly worthless, and pushing it out at 480p is worthless (Unless it's a retro C64 BASIC tutorial in which case rock on).
Work... Yes, you can watch a video fluently, but it takes (on Desktop, Firefox, with Throttling on "Good 2G") maybe ~2min to load the video page. However, you can start watching the video before the full page is even loaded.
You can probably implement a dumb version of this where transcode a few different versions with ffmpeg (which is amazing, but takes some tinkering), use browser API's to guess the right one as a default, and give the user control if they'd like to switch.
I'd still try HLS but this may be good enough for v1, depending on what you're building.
Please correct me if I'm wrong, but my understanding was that Cloudflare should not be used to deliver video files unless using Cloudflare's "stream" product, IE specifically this [1].
