手握灵珠常奋笔, 心开天籁不吹箫
订阅一份报纸，到时候就会投递给你。 订阅一个新闻频道，一有新闻就会推送给你。 本质上，它是一种异步通信的架构模式 与之对应的代码模式就是观察者模式，其注册 register 对应于 subscribe, notify 对应于 publishe subscribe subscriber -> router: subscribe router–>subscriber: ack publisher publisher -> router: event router–>publisher: ack router –> subscriber: event subscviber–>router: ack 典型用例有 Ingestion user interaction and server events. To use user interaction events from end-user apps or server events from your system, you might forward them […] →Read more
这个世界再烂，也拒绝摆烂，写书，写代码，写评论，我写故我在。 与朋友去交流，跑步，打球，让自己流汗，不让自己流泪。 →Read more
在 WebRTC 中常用的 QoS 策略有 反馈：例如 PLI , NACK 冗余， 例如 FEC, RTX 调整：例如码率，分辨率及帧率的调整 缓存: 例如 Receive Adaptive Jitter Buffer, Send Buffer 这些措施的采用需要基于拥塞控制(congestion control) 及带宽估计(bandwidth estimation)技术, 不同的网络条件下需要采用不同的措施。 Webrtc 默认是开启 RTX (重传)，它一般采用不同的 SSRC 进行传输 RTX 包的 Payload 在 RFC4588 中有详细描述，一般 NACK 和 Bandwidth Probe 也可能走 RTX 通道。 FEC 用作丢包恢复需要占用更多的带宽，即使 5% 的丢包需要几乎一倍的带宽，在带宽有限的情况下可能会使情况更糟。 RTX 不会占用太多的带宽，接收方发送 NACK 指明哪些包丢失了，发送方通过单独的 RTP […] →Read more
1) 是否容易重现 如果容易，它的复现步骤是什么 如果不容易，它在什么条件下的出现机率比较大，有没有可能缩小排查的范围 2) 是否最近才引入的，发现的时机和频率如何 找出 crash 出现的时间范围，时机，和频率 根据 backgrace 和 git log, 回顾 crash 相关代码的修改记录 3) 灵活运用演绎法，归纳法和二分法 演绎法: 从一般到特殊，从常见的 crash 问题和解决方案推断 归纳法: 从特殊到一般，从最近频发的 crash 问题找出共性特征 二分法: 用二分法合理划分问题域，不断缩小范围 4) 大胆假设，小心求证 假设条件，测试，排除，不断重复，缩小范围 有必要时画一张思维导图，记下每条排查路径 5) 君子性非异也，善假于物也 查询 google, stackflow, 听取同事的意见 最后一条，看看破案和推理小说及剧情，学学侦破技术 如何找线索， 如何勘查现场， 如何排查嫌疑 如何查询积案，进行并案 有一些惯犯和惯用作案手段值得研究 多线程处理不当 多个线程操作一块内存区域，没有安全地加锁和串行化 合局和单例对象是重点排查对象 内存处理不当 内存管理不当，用到的内存却给别人破坏了，例如 试图释放已经释放了的内存 试图释放并未分配的内存 试图读写已经释放了的内存 试图读写并未分配的内存 内存分配错误, […] →Read more
脚手架工具 生成模板代码，例如 yeoman 依赖管理工具 管理依赖代码，例如 bower 构建工具 预处理代码，例如 gulp →Read more
简介 Simulcast 可以翻译成联播，不是新闻联播，而是多个媒体流的传播，如图所示 注: SFU 即 Selective Forward Unit, 媒体转发服务器 刚开始，发送方 sender 发送一路 1080p 的视频流给服务器 SFU， SFU 再转发给多个接收方 receiver1, receiver2 和 receiver3。 一会儿，receiver 2 和 receiver 3 通过 RTCP 反馈带宽不够，丢包率和延迟都比较大，也就是说 上行带宽对于 sender 是足够的， 下行带宽对于 receiver 1 也是没问题的 下行带宽对于 receiver 2 和 receiver 3 都有问题 这样联播的好处就来了，SFU 可以根据带宽评估的结果让 Sender 同时发送 1080p, 360p 和 180p 三路流，并分别转发给 receiver1, receiver […] →Read more
最近看了同事写的一块代码，逻辑非常复杂，我们讨论了实现的方式，我建议他改用状态模式, 这样可以省去很多复杂的判断分支 这是用状态模式的做法 不用状态模式的代码大致如此 if(cpuRatio < xxx && memRatio < xxx) { state=Normal } else if(cpuRatio > xxx && memRatio > xxx) { state=Busy } else if(cpuRatio > xxx && memRatio > xxx) { state=Crazy } if(state == Crazy) { delegateOtherDoSomething() } else if (state == Busy) { complainAndDoSomething() } else if (state == Normal) […] →Read more
note of https://gstreamer.freedesktop.org/documentation/tutorials/basic/hello-world.html GStreamer is a framework for constructing graphs of various filters (termed elements here) that will handle streaming media. Any discrete (packetizable) media type is supported, with provisions for automatically determining source type. Formatting/framing information is provided with a powerful negotiation framework. Plugins are heavily used to provide for all elements, allowing one […] →Read more
概述 视频流水线是指视频从发送端摄像头捕捉视频图像，将视频流进行转换，编码，打包，发送，直到接收端进行解包，缓存，解码再到将视频图像渲染到画布上或者视频元素中 # linux send h264 rtp stream: gst-launch-1.0 -v ximagesrc \ ! video/x-raw,framerate=20/1 \ ! videoscale ! videoconvert \ ! x264enc tune=zerolatency bitrate=500 speed-preset=superfast \ ! rtph264pay \ ! udpsink host=127.0.0.1 port=5000 # Macos send h264 rtp stream: gst-launch-1.0 -v avfvideosrc capture-screen=true \ ! video/x-raw,framerate=20/1 \ ! videoscale ! videoconvert \ ! x264enc tune=zerolatency […] →Read more
大约有两种基本的异步编程模式 Task-Based Asynchronous Pattern 基于任务的异步模式 以一个单个的方法（Task）来表示异步操作的发起和完成， 它引入了 Async, Await 这样的关键字 任务执行会返回一个 Promise 或 Future, 代表未来执行的结果 Event-Based Asynchronous Pattern 基于事件的异步模式 以事件驱动的模式来提供异步的行为，主要使用了事件回调和事件处理器的方式，类似于观察者模式的结构 它遵循了著名的好莱坞原则 “Don’t call us, we’ll call you” – “别打电话给我们，我们会打给你的” 在具体实现上，有三种模型 多进程 RPC 远程过程调用就是典型的用例，在多个进程间通过网络消息传输来进行异步调用，例如 Ajax。 在一台主机的多进程还可以使用众多的 IPC 方法，我觉得最好用的还是 UDS (Unix Domain Socket) 其地址族为 AF_UNIX，Socket type 可以是 SOCK_STREAM(类比 TCP) 和 SOCK_DGRAM(类比 UDP), SCOK_SEQPACKET(类比 SCTP) nc -U /tmp/test.sock […] →Read more