闲敲棋子落灯花

很多机器学习或者自适应场景需要对某个特征变化趋势进行分析, 如果假定该特征是线形特征, 则需对其趋势作线性拟合. 问题可以描述为:存在样本集(xi,yi)(x_i, y_i)(xi​,yi​), 样本集的数量为nnn. 假设满足下列关系: y=mx+by = mx + by=mx+b, 期望求得m,bm, bm,b的值, 使误差最小.ei=yi−(mxi+b) e_i = y_...

对于基于内容分享的Internet应用来说, 拥塞控制都是其无法回避的问题,     而实时多媒体应用的拥塞控制, 相比于其他应用而言, 更具有挑战性.      原因在于:        1.  媒体数据对于 packet loss,  jitters都非常敏感,   数据的丢失,   接受的抖动与延迟,  都会严重的影响主观体验.         2.  网络情况的变化往往难以预测,

VideoTrack的定义如下:class VideoTrack : public MediaStreamTrack<VideoTrackInterface>, public rtc::VideoSourceBase, public ObserverInterface { public: static rtc::sco

AudioRtpSender 是连接WebRtc Session 和 AudioTrack的纽带. 如前文所言, AudioTrack 封装了AudioSource, 但是WebRTC Session尚需要AudioRtpSender 来获取数据. 在讲述AudioRtpSender之前, 先来看这个类// LocalAudioSinkAdapter receives data

WebRtc Stream 里封装了AudioTrack和VideoTrack Vector.    WebRtc的 A/V Track 其实就是 Video/Audio Source 和一些状态。   Track的状态定义在　MediaStreamTracktemplate class MediaStreamTrack : public Notifier { public: type

PeerConnection 是WebRtc native interface 最外层的模块,  通常来说, 用户使用Peerconection就可以构建最简单的p2p 应用.     下面的UML里是PeerConnection的最重要的属性和方法.         PortAllocator 用来为媒体连接分配可用的端口      LocalStreams 存放本端的Video/Aud

WebRTC for iOS的编译可以参见 www.webrtc.org下面是我写的为了简化日常工作的编译脚本， 将WebRTC的库打包到一个libwebrtc.a  实现了 armv7 和  arm64两种架构的编译和combile到一个 库.   模拟器版本只需仿照即可实现。  代码如下：  #! /bin/sh# out directoriesIOS32_OU

Sigslot 是Sarah Thompson 设计实现的C++ 事件处理的框架,    这套框架非常轻量级,  全部代码只有一个sigslot.h 文件,   其设计也非常出色,  最大限度的将事件和处理机制解耦, 并且保证了线程安全.  在WebRTC中, sigslot 是其基础的事件处理框架,  在多个模块的消息通知, 响应处理中被使用.  下文, 我们简单的来剖析下sigslot 的

在Opus 1.1.2 的目录下建立Android 子目录,   建立 Android.mk 和 build.sh两个文件, 内容如下 运行build.sh 就可以完成opus for android的编译.   Android.mkLOCAL_PATH := $(call my-dir)/..include $(CLEAR_VARS)include $(LOCAL_P

是否要保证线程安全是底层SDK设计中的一个问题。  SDK API 线程安全是SDK易用

WebRTC 的 Android 编译脚本如下：#! /bin/bash#out directoriesARMV7_OUT_DIR="out_android_armv7"ARM64_OUT_DIR="out_android_arm64"X86_OUT_DIR="out_android_x86"X64_OUT_DIR="out_android_x64"ARCH_ARM64

PJSIP 是非常精致的SIP Client 协议栈,   其层次结构清晰的API设计, 良好的跨平台属性, 在业内有很高的声誉,  有不少SIP商业应用基于它开发.   可是PJSIP早期版本从未对IPV6有很好的支持.     Apple 在今年5月时发布声明,  要求6月1号以后所有的iOS应用都必须包含对IPV6-ONLY网络的支持.   这个对基于PJSIP开发的iOS应用来说可谓是当头

项目中需要使用Opus Codec for iOS， 在github 上找了一个不错的脚本，  对其稍作修改， 编译非常顺利。 如下为脚本代码。 #!/bin/bashVERSION="1.1.2" #Opus VersionSDKVERSION="9.2"MINIOSVERSION="7.0"# by default, we won't build for debug

基于邻域信息的扣图算法,  Shared Sampling for Real Time Alpha Matting, 相比其他的Alpha Matting,   复杂度低, 效果不错.  原文可以在此下载: http://inf.ufrgs.br/~eslgastal/SharedMatting/参考网上的例子, 整理实现了算法:   https://github.com/volvet/A

且让我们从WebRTC的实例来继续分析Ninja.        下载编译WebRTC, 首先要下载Chromium depot_tool,  Ninja就在deopt tool 之中.         WebRTC的代码可以支持多平台,  我们以MAC平台为例:           WebRTC的代码下载完成后,  执行:export GYP_DEFINES="OS=mac ta

WebRTC已经开源五周年了,  其鼎鼎大名, 在实时多媒体通讯领域无出其右.   学习应用WebRTC的热潮,  从未消减.    要理解借鉴WebRTC中的算法或实现, 虽然未必需要了解其如何编译,    不过窃以为,  有志于掌握WebRTC者 不可不知其编译系统运作机制.    庖丁解牛,恢恢乎游刃有余,  学习WebRTC者, 当以此自勉.

跟AudioRtpSender 相似, AudioRtpReceiver是连接AudioTrack跟WebRtcSession的纽带. 不过方向却是相反的, 在AudioRtpReceiver里, Source 是 WebRtcSession. 看代码:AudioRtpReceiver::AudioRtpReceiver(MediaStreamInterface* stream,

RTP in WebRTC RTCP 1. FIR, Full Intra Request, 申请一个I-Frame, 用于新用户加入的时候, 申请一个I-Frame 作为解码的起点 2. PLI, Picture Loss Indicator, 丢帧提醒，　　用于解码遇到错误时候，　给源端的一个Indicator, 普通源端要生成一个I-Frame 来

写作本文的初衷是： 前些日子为WebRTC设计Simulcast, 把所有相关的代码又重新阅读了一遍， 想着WebRTC代码结构复杂， 代码量巨大， Google的release迭代改动快， 改动量大， 代码常读常忘， 忘了再读， 也许应该写点啥东西保存起来。 适之先生说， 要使你所得印象变成你自己的， 最有效的方式是记录或者表现成文章。 故此不揣浅薄， 记录一些东西， 以为未来参考， 也算是响

FEC 的 Pattern定义为 [m,k],n=m+k,m是数据包的个数,k是FEC包的个数,n为两者之和 [m, k], n = m+k, m是数据包的个数, k是FEC包的个数, n为两者之和 nn个包为一个Group, 在这个Group中, 任意丢k个包, 都可以通过收到的m个包恢复. 这里的k个包可以是数据包或者FEC包. 所以在给定丢包率 ll, 给定源数

OpenGL中描述几何图形的方法是用顶点(vertice)和指号(indice)， 在SceneKit中也完全一样. SCNGeometrySourceSCNGeometrySource 在SceneKit中就是顶点的集合. 这些点用来构成一个几何图形. 下面的代码就创建了一个SCNGeometrySource对象，包含有2个顶点， 可以用来绘制一条直线. let verti

Quality Scaler 是WebRTC中根据视频质量， 自适应调整分辨率的方案， 其思路大体是: 观察视频编码的丢帧率和qp的变化， 确定Capturer中的video adaptor 是否要调整编码的分辨率. 其代码位于: $(ROOT)/src/webrtc/modules/video_coding/utility 实现相当简单, 观察5秒内编码的平均qp和丢帧率，

OpenGL渲染中有一个线程相关的上下文(EGL Context), OpenGL所创建的资源, 其实对程序员可见的仅仅是ID而已, 其内容依赖于这个上下文, 有时候为了方便起见, 在某个线程中创建了上下文之后, 所有的OpenGL操作都转到此线程来调用. 这样在简单的2d/3d 渲染中尚可, 但是如果涉及复杂的OpenGL渲染时, 这样就未必妥当. 举例来说, Google 为A

Google 提供了2种虚拟现实(Virtual Reality) 平台, Cardboard 和 Daydream.

带宽评估(BWE)也许是WebRTC的视频引擎中最关键的模块了, 它将决定视频通信中, 不引发网络拥塞时最多可以产生的视频数据量. 早期的带宽评估算法比较简陋, 大多是基于丢包来估计, 基本的策略是逐步增加发送的数据量, 直到检测到丢包为止. 为了让发送端获悉网络上的丢包信息, 可以使用标准的RTCP的RR来发送周期性的报告. 现代的带宽评估算法则可以在网络链路发送丢包以前就监测到网络

WebRTC的更新频率很快, 最新的稳定版本已经是branch-heads/58了. 从branch-heads/52开始, 大致是2个月更新一个版本. 编译工具也从gyp+ninja 换到了 gn+ninja. 相比gyp, gn带来的最大的好处是编译速度的提升, 使用gyp生成ninja 文件一般需要10~20秒左右, 使用gn生成ninja文件, 仅仅需要400ms ~

Google 开源了guetzli项目， 它可以在主观质量无损的条件下， 将jpeg图片减少20%～30%的码率， 相信这个是利用了人眼的视觉特性所得到的增益。 今天我对guetzli做了些测试， 下面是测试的结果原图 Lena Size = 126KBguetzli处理 with Quality = 95, Size = 83KBguetzli处理

WebRTC 自诞生之日起, 就代表了实时通信领域的最好的技术. 不过很长时间里, 它所支持的视频编码器只有VP8, 后来随着H265/VP9为代表的下一代视频编码器的诞生, WebRTC里出现了VP9 Codec. 而当前应用最广泛的H264 却一直不受待见. 一直到Cisco 宣布旗下的H264 Codec开源为OpenH264, 并且提所有OpenH264的使用者支付了H264

WebRTC 中的带宽侦测WebRTC的带宽利用率相当高, 在测试中, 绝大多数时间都可以在可用带宽的95%以上, 而且在高利用率的同时, 还能保持音视频的高质量, 其带宽侦测机制在其中扮演了关键的角色. 有几个关键点:Pacing BitratePacing Bitrate 为allocated_bitrate_bps/1000 * kDefaultPaceMultiplier,

BDPSNR的运算多是通过Joel Jung所设计的excel的 宏函数来计算的, 不过Joel Jung并没有提供源代码， 而且有时候excel在使用上并不方便， 幸好Serge 用matlab实现了BDPSNR的计算, 贴他的源码:function avg_diff = bjontegaard2(R1,PSNR1,R2,PSNR2,mode)%bjontegaard2 Bjonteg

Outline 1. Bandwidth Estimation Delay Based Control Loss Based Control 2. Error Concealment RTP Retransmission(NACK) FEC PLI/SLI/RPSIPacket Arrival Model G

FEC FormatWebRTC 应用RFC 5109所定义的 XOR 来对RTP 数据进行保护, 以抵抗网络丢包. 协议所定义的包结构如下:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| RTP Header (12 octets or more) |+-+-+-+-+-+-+-+-+-+-+-+-+-

WebRTC 的FEC(前向纠错编码) 是其QoS的重要组成部分, 用于网络丢包的时候恢复原始数据包, 减少重传次数, 减少延时, 改善视频质量. 它是RFC 5109标准的实现. 下文, 我们将深入剖析其原理. Redundant Coding要理解WebRTC中的FEC, 首先需要先了解Red Packet. 所谓Red Packet, 就是Redundant Coding

线程地址空间(Thread Address Space)   thread地址空间修饰符表示其所修饰的地址为线程的私有空间， 仅仅在其被声明的线程可见， 在graphics和kernal函数内所声明的变量都是在线程地址空间上分配的。代码实例如下：kernel void my_func(...){ // A float allocated in the per-thread add

函数参数与变量    除了定义在常量地址空间的变量和定义在程序域的采样器之外,  graphics和kernel函数的输入输出都需要通过函数参数,  函数参数可以是下面之一:    设备缓存(Device Buffer):　一个指向设备地址空间任意数据类型的指针或者引用　　常量缓存(Constant Buffer):   一个指向常量地址空间任意数据类型的指针或者饮用　纹理对象(T

矢量和矩阵类型Metal Shading 语言的矢量数学库提供了对矢量和矩阵类型表示和运算的支持。   矢量的命名规则如下所示：booln,   charn,  shortn,  intn,  uncharn, ushortn, uintnhalfn, floatn这里 n 可以是 2, 3, 4 的其中一个数字，  表示 2-， 3-， 4- 维矢量。  矩阵的命名规

隐式类型转换  (Implicit type conversions)   Metal 着色语言支持标量间的类型转换， 这种转换是试图用把等价的值用一种新的数据类型来表示， 比如：int的5 被转换为float的时候为5.0.     矢量的类型转换更为严格，　矢量到另一种矢量或者标量的转换是非法的，会引起编译错误，　　例子如下：　int4 i;float4 f = i; // c

紧致矢量类型 (Packed Vector Data Type)     如前文所述, 矢量类型是有其规范的对齐方式(基于性能优化的考量).   但是你也许会有需要你所定义的矢量是被紧密地包装着的,  比如, 你定义了一个顶点的数据类型, 其成员有坐标,  法线矢量， 正切矢量和矩阵坐标，  并且希望它们是被紧密地包在一起作为给Vertex 函数的输入参数.      Metal 着色语言

数组与结构(Array and Structs)     Metal 着色语言支持数组和结构, 但是有如下限制:   纹理和采样器不能声明为数组.   纹理和采样器不能定义在结构中   Graphics 和  Kernel 函数的参数不能为size_t 或者 ptrdiff_t 类型,  也不能为包含了这两种类型的结构.    结构中的成员必须被声明为属于同样的地址空间.    

Metal and C++11   Metal Shading 语言是基于C++11的标准[http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690.pdf]设计的, 在这个基础之上   增加了一些扩展和限制.  这些具体可以参考详细的语法描述.  本文会简单介绍Metal对C++11所做的一些修改和限制.