GeneticGenesis
Joined 11 years ago
Karma
782
Submissions
74
Member since
Nov 19
Recent submissions
Comment · 1 month ago
Thanks for the nostalgia hit!
Comment · 2 months ago
Yep, spot on - this and some level of inbound filtering are the only reason we use an external platform.
That said, with the volume of inbound reports coming from LLMs, the signal-to-noise ratio has plummeted, and the time taken to triage has gone through the roof.
Comment · 5 months ago
Congrats to the team at Stainless, it's a great team to be joining over at Anthropic.
We were an ealy adopter of their Node SDK generator at Mux (and latterly their Typescript and other generators), and the product worked great, and I'm sad to see it be shut down.
At the same time, it's easy to understand why this is a complciated product/market to be in at the moment - it's very tempting and easy to vibe code SDKs from a OpenAPI spec files right now. I would think a lot of teams will just go in that direction (for better or worse), using the same toolchain that the product developers are using today for the product, for effectively no extra cost.
Comment · 7 months ago
In the interests of transparent disclosure on such a positive blog post, It might be worth calling out that all the links on the page are all linked to the Bunny Affiliate Program. [1]
Comment · 1 year ago
I know it's not public domain per-say, but for me, the thing that's most exciting is that in 2025, the last remaining patents on the h.264 (AVC) video codec will expire [1].
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...
Comment · 2 years ago
Disclaimer: We're an early adopter of Stainless at Mux.
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...
Comment · 3 years ago
A more energy efficient dishwasher would be nice though...
Comment · 4 years ago
Super interesting, it really depends on what you mean by "choppy".
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) ?
Comment · 4 years ago
Great question! The real answer is it varies, but for H.264, most just encode on software right now, because GPUs are expensive (especially in the cloud), and the failure rates are really high (if you try to build your own). ffmpeg and lib264 is really fast on modern hardware with decent X86 extensions.
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/
Comment · 4 years ago
Hey, I work in the Product team at Mux, and worked on the LL-HLS spec and our implementation, I own our real-time video strategy too.
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/
Comment · 4 years ago
We actually built How Video Works as a side project at Mux [1] (inspired by How DNS Works [2]) - there's a note about it at the top of the page. We have contributions from our own team as well as others in the industry.
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
Comment · 4 years ago
DRM'd video content uses the same video codecs and containers, but introduces segment encryption during the packaging phase. In most cases, this encryption is within the audio and video samples rather than on the entire segment. Most content is encrypted using MPEG Common Encryption (CENC) - though there are a couple of variants.
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.
Comment · 4 years ago
While HLS isn't the cleanest protocol (Yay for extensions of the M3U playlist format...), it's actually really good at what it's designed to do - provide reliable video streaming while using HTTP/S over variable networks.
Ultimately, HLS isn't designed for downloading and storing videos, it's designed for streaming.
Comment · 5 years ago
Do you have a marketing site or landing page for Padka? It sounds interesting, but just linking to a .pkg file on S3 really isn't the way to educate HN users about your offering!
Looks like this is the homepage: https://www.padka.com/ - why not just link there?