[1] https://bunny.net/affiliate/

Now if only HEVC wasn't such a hot patent / licensing mess.

[1] https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...

I've spent more of my time than I'd like to admit managing both OpenAPi spec files [1] and fighting with openapi-generator [2] than any sane person should have to. While it's great having the freedom to change the templates an thus generated SDKs you get with using that sort of approach, it's also super time consuming, and when you have a lot of SDKs (we have 6 generated SDKs), in my experience it needs someone devoted to managing the process, staying up with template changes etc.

Excited to see more SDK languages come to Stainless!

[1] https://www.mux.com/blog/an-adventure-in-openapi-v3-api-code...

[2] https://github.com/OpenAPITools/openapi-generator

Are you seeing the video re-buffer (a loading spinner re-appearing), or just the video looking stuttery?

My video engineer gut tells me that this is a frame rate conversion issue - do you know what frame rate your graphics card is outputting to your display, and do you happen to know the frame rate of the content that you're seeing issues with (or more generically, what type of content is it - film? TV) ?

It's also worth noting that YouTube also now builds its own transcoding chips [1], and AWS just launched a dedicated transcoding instances based on Xilinx chips:

[1] https://arstechnica.com/gadgets/2021/04/youtube-is-now-build... [2] https://aws.amazon.com/ec2/instance-types/vt1/

We do offer LL-HLS in an open beta today [1], which in the best case will get you around 4-5 seconds of latency on a good player implementation, but this does vary with latency to our service's origin and edge. We have some tuning to do here, but best case, the LL-HLS protocol will get to 2.5-3 seconds.

We're obviously interested in using WebRTC for use cases that require more real-time interactions, but I don't have anything I can publicly share right now. For sub-second streaming using WebRTC, there are a lot of options out there at the moment though, including Millicast [2] and Red5Pro [3] to name a couple.

Two big questions comes up when I talk to customers about WebRTC at scale:

The first is how much reliability and perceptual quality people are willing to sacrifice to get to that magic 1 second latency number. WebRTC implementations today are optimised for latency over quality, and have a limited amount of customisability - my personal hope is that the client side of the WebRTC will become more unable for PQ and reliability, allowing target latencies of ~1s rather than <= 200ms.

The second is cost. HLS, LL-HLS etc. can still be served on commodity CDN infrastructure, which can't currently serve WebRTC traffic, making it an order of magnitude cheaper than WebRTC.

[1] https://mux.com/blog/introducing-low-latency-live-streaming/ [2] https://www.millicast.com/ [3] https://www.red5pro.com/

Our main motivation is to try to educate on the complexities and intracies of streaming video. Despite streaming video representing 80+% of the internet, it's all underpinned by a fairly small community of engineers, which we're eager to help grow through tools like this, and the Demuxed community [3].

Edit: I should also mention that Leandro was kind enough to adapt a this content from his amazing Digital Video Introduction [4]

[1] https://mux.com/ [2] https://howdns.works/ [3] https://2021.demuxed.com/ [4] https://github.com/leandromoreira/digital_video_introduction

Decryption keys are then exchanged using one of the common proprietary DRM protocols, usually Widevine (Google), Playready (Microsoft), or Fairplay (Apple). The CDM (Content Decryption Module) in the browser is then passed the decryption key, so the browser. Can decrypt the content for playback.

Ultimately, HLS isn't designed for downloading and storing videos, it's designed for streaming.

Comments URL: https://news.ycombinator.com/item?id=29379064

Points: 4

# Comments: 0

Looks like this is the homepage: https://www.padka.com/ - why not just link there?

Comments URL: https://news.ycombinator.com/item?id=26993624

Points: 30

# Comments: 5

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]

[1] https://netflixtechblog.com/per-title-encode-optimization-7e... [2] https://bitmovin.com/per-scene-adaptation-going-beyond-bitra...

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.

[1] https://github.com/pion [2] https://jitsi.org/ [3] https://www.millicast.com/ [4] https://www.red5pro.com/ [5] https://mux.com/blog/low-latency-hls-part-2/ [6] https://mux.com/blog/the-low-latency-live-streaming-landscap... [7] https://github.com/streamlinevideo/streamline

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.