为了WebRTC能支持H.265，那些“在后端就把H.265转码成H.264再发给前端”的方法就是历史的倒退

先说一个故事：
八九年前，我当时准备自己做一款摄像机，于是我就找了深圳一家摄像机的方案商，希望能在他们的摄像机模组里面，把我的程序放进去，这样我就不用再重复做与芯片相关的编解码、Sensor相关的工作了，我只需要关心视频怎么跟云平台交互，如何控制好设备就行了，当时，他们用的是海思Hi3518E的方案，给的价格我记不清了，他们推给了两款Hi3518E的方案，一款是16M flash的方案，另一款是8M Flash的方案，我当时就比较诧异了，16M已经很不够用了，要把所有的摄像机系统、驱动、主程序、网页、配置文件，全部塞到一个16M的空间里面，已经是捉襟见肘了，居然还搞了个8M的，何必呢？8M和16M的Flash能差多少钱？一两块钱的事情，何必这么麻烦！！！

摄像机模组厂家的人跟我说，我们的模组一年大概能卖300万支，那这8M Flash的差距就是五六百万的成本差距，只需要我们的研发人员花点功夫专研一下，每年就能多出五六百万的利润，这是多划算的事情！

这个故事在后面一直都给我一个启发，就是写程序的人能坐在办公室里省下来的钱、多赚的钱，为什么不呢？为什么不在程序上下点功夫呢？所以，在后面的研发经历中，我一直都在提醒自己，能程序搞定的，绝对不多消耗硬件资源，所以，后来，我搞了一个关键帧快照，能帮社会省电《音视频研发分享：关键帧截图+wasm快照–我又做了一件有益于社会的事情》，后来我还免费开放了一个支持H.265播放EasyPlayer.js播放器《EasyPlayer.js 6.0全新发布，支持MSE、WebCodec、WASM多种解码模式，支持H.264/H.265/AAC/G711/MP3多种编码格式，支持录音、抓图、录像等各种控制，免费！》

为什么就不推荐H.265转码H.264？

现在市面上，好多产品在宣传视频H.265转码H.264，为了所谓的更好的播放效果，为了让WebRTC支持H.265，所以干脆就将H.265转码成了H.264。可以说，这种做法就是避重就轻，开历史的倒车！

试想一下：一台普通的i7 CPU机器，能支持多少路H.265转码H.264？10路已经差不多了吧？16路是不是已经基本极限了？上GPU？这不都得花钱吗？

有很多说是版权问题，那纯属不懂！版权是在芯片侧或者生产者侧的事情。

明明研发上多花一些时间，就可以解决的问题，为什么要H.265转码H.264，H.264比H.265更先进吗？所以，解决H.265传输与播放的问题，才是这个行业研发该干的事情！