Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes, so it's precisely another case of "we tested on chrome and it works", which falls under "don't care" software development best practices.


Unfortunately, hardware VP9 decoding isn't really well-supported except in high-end phones (in context of multiple decoding, single decoding works fine) due to bugs in Mediatek's implementation. There's software decoding, but that's still taxing to a phone, and transcoding to H.264 server-side but that doesn't bode well to end-to-end encryption.


No, it's very practical. A lot of devices are just too weak to encode anything other than H.264 so that's the one codec you must support.

Other codecs are better, but you have to do more testing and enable those codecs only on calls where all members are using a device that supports it.


> A lot of devices are just too weak to encode anything other than H.264

Not that your point is wrong, but a lot of devices are too weak to encode/decode H264 as well. It's very recent for me to have access to second-hand hardware with H264 support and still i'm in western Europe where it's easier to come by.

Though as the other commenter pointed out, if you can afford to use hardware en/decoders then it's always the better option.


Are you sure you're not thinking of H265?

I'm kinda curious which devices don't support H264




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: