hughfenghen.github.io
hughfenghen.github.io copied to clipboard
hughfenghen
blog
https://hughfenghen.github.io/posts/2023/08/19/webav-7-mid-review/
一个完整的 avcC box 示例数据内容 ``` 00 00 00 3A 61 76 63 43 01 64 00 1e ff e1 00 1d 67 64 00 1e ac d9 40 a0 2f...
https://hughfenghen.github.io/posts/2024/10/28/webav-video-editor/
搞点颜色
**Q：人是如何看见颜色的？** A：光是一种电磁波，人眼有三种视锥细胞（红、绿、蓝）； 不同波长的电磁波会刺激视锥细胞产生不同强度的电信号； 三个不同强度的电信号输入给大脑，产生不同颜色的感觉； 电磁波（客观）-> 颜色（主观）。 **Q：眼睛只有三种视锥细胞（三个电信号）为什么能看到这么多种颜色？** A：每种视锥细胞被激活的强度（档位）有多个，假如某人红色视锥细胞有10个档位，那他就能分辨10种不同的红色，同理能分辨10种绿色、蓝色； 不同档位的红配不同档位的蓝，大脑给我们反馈的是不同的紫色；所以这个人总共能分辨1000种颜色（10x10x10）。 **Q：人眼能分辨多少种颜色？** A：如上，取决于某人的视锥细胞有多少个“档位”，假设每个视锥细胞都是 N 档，即他能分辨 N 的3次方种颜色； 人类平均来说，有说100w种的，有说1000w种的；反而是人能用语言描述的颜色实在太有限了，我只能描述...赤橙黄绿青蓝紫。 据说存在稀有的四色视觉者（四种视锥细胞），将能看到比普通人更多种颜色。 **Q：显示器能显示多少种颜色？** A：显示器使用三原色来合成各种颜色，一般来说软件将每种原色（红绿蓝）分为255个档位，即能表示255的3次方种（16,581,375）； 现在很多显示器广告宣称能显示10.7亿种颜色，即将每种原色分为1024档（最佳的显示效果需要软硬件配合）。 **Q：世界上共存在多少种颜色？** A：无限个；客观世界存在的只是无限种不同波长的电磁波而已，人眼感知电磁波为颜色。 **附录** 三原色原理 https://baike.baidu.com/item/%E4%B8%89%E5%8E%9F%E8%89%B2%E5%8E%9F%E7%90%86/6969780 色彩深度和人眼对色彩的感知 https://zhuanlan.zhihu.com/p/102799658 四色视觉 https://baike.baidu.com/item/%E5%9B%9B%E8%89%B2%E8%A7%86%E8%A7%89/22735813
_编码一小时，调试一整天。。。_ 用原生的WebRTC接口、[peerjs](https://fenghen-p2p-server.herokuapp.com/myapp/peerjs/peers)写了一个p2p demo。 现象：同一设备下的两个页面（可以跨浏览器）可以建立链接，跨设备则无法连通（同一wifi或不同网络都不行）。 原因：因为我们的设备连接网络基本都经过[NAT](https://baike.baidu.com/item/NAT/320024)，但NAT有多种类型，只有部分支持P2P连接。 类型如下，**只有前两种支持P2P链接**： > 客户端主机所在网络可以分为以下类型: > > 1, Opened: 即主机拥有公网IP,并且没有防火墙,可自由与外部通信. > > 2, Full Cone NAT: 主机前有NAT设备,NAT规则如下: 从主机UDP端口A发出的数据包都会对应到NAT设备出口IP的端口B,并且从任意外部地址发送到该NAT设备UDP端口B的包都会被转到主机端口A. > > 3, Restricted cone NAT: 主机前有NAT设备,NAT规则如下: 从主机UDP端口A发出的数据包都会对应到NAT设备出口IP的端口B,但只有从之前该主机发出包的目的IP发出到该NAT设备UDP端口B的包才会被转到主机端口A. >...
首先，**代码简洁易懂通常更重要**，性能优化应在明确性能瓶颈后再开始优化； 其次，系统性能问题往往是 **DOM 操作**、 **IO 操作**（文件读写、网络请求）、**内存**大量分配占用导致，性能问题应优先往这些方向排查。 当你的项目确实需要消耗大量计算资源（如 音视频、游戏、大量数据处理），有许代码被高频执行（如 十万次以上的循环） 可参考这篇文章中提到的技巧，进行代码运行方面的优化。 [Optimizing Javascript for fun and for profit](https://romgrk.com/posts/optimizing-javascript) [0. Avoid work 避免多余的工作](https://romgrk.com/posts/optimizing-javascript#0-avoid-work) [1. Avoid string comparisons 避免字符串比较](https://romgrk.com/posts/optimizing-javascript#1-avoid-string-comparisons) [2. Avoid different shapes...
https://hughfenghen.github.io/posts/2024/08/13/google-io-webcodecs-opfs/
随着 ES6+ 普及和 TypeScript 大流行，前端代码中 class 有泛滥的趋势。 由于 JS 对函数支持良好，**很多情况下没必要使用 class**。 ### 主张克制使用 class 的原因 1. class 的代码模式鼓励使用副作用，通过方法修改 class 的属性，class的方法基本都不纯 2. class 属性（维护的状态）通常跟操作属性的代码（即 class方法）相隔较远（违反就近原则），且分散 3. class 的代码模式容易导致代码膨胀，因为维护者会习惯性追加代码，甚至不需要this 的函数也会被定义成 class 方法，不像函数组织结构会鼓励切分逻辑...
https://hughfenghen.github.io/posts/2024/03/14/web-storage-and-opfs/