by fanxiushu 2022-03-12 转载或引用请注明原作者。
接上文。
我们先来编译kvswebrtc开源代码。
首先得从github下载 ksvwebrtc源码，
分别需要  amazon-kinesis-video-streams-pic， amazon-kinesis-video-streams-producer-c，
amazon-kinesis-video-streams-webrtc-sdk-c 三个，其中amazon-kinesis-video-streams-producer-c其实只需要头文件即可，不必编译。

另外还必须要 usrsctp，libsrtp 两个开源库。openssl 开源库也是必须的。这些开源库都可以直接从github下载。
openssl如何编译这里就不罗嗦了，网上很多介绍。
先来看usrsctp和libsrtp如何编译
（这里以windows的编译为例，其他平台下尤其linux下，这些开源库都是非常容易编译的）
首先在windows中安装最新的cmake程序，
然后打开 cmake-gui程序，直接在cmake界面中操作即可，直接编译成 visual studio 的sln工程文件，
（libsrtp需要 openssl ，因此在 cmake-gui中需要配置 OPENSSL_ROOT_DIR 等变量）
打开sln，直接通过vs编译成lib静态库。编译生成 srtp2.lib 和 usrsctp.lib两个静态库。
就这么简单。
同样的，对于kvswebrtc的上面提到三个开源代码（其实只需要编译两个）
使用cmake生成amazon-kinesis-video-streams-pic 的sln工程文件的时候，需要注意在cmake中设置 BUILD_DEPENDENCIES=OFF，
这样就不会自动下载和编译关联项，因为我们只需要 amazon-kinesis-video-streams-pic，
编译成功之后，会生成 kvspic.lib, kvspicClient.lib, kvspicState.lib, kvspicUtils.lib 四个lib静态库。

接下来就是稍微麻烦点的 amazon-kinesis-video-streams-webrtc-sdk-c 编译问题。
首先，我们得把 各种头文件复制到某个公共目录中，比如新建一个 include 目录，
把 usrsctp, libsrtp, amazon-kinesis-video-streams-pic，amazon-kinesis-video-streams-producer-c ，
amazon-kinesis-video-streams-webrtc-sdk-c 里边的头文件复制到 include目录中，
同时，我们必须手工修改 amazon-kinesis-video-streams-webrtc-sdk-c  的CMakeList.txt文件。
把kvsWebrtcSignalingClient 相关工程部分屏蔽掉，因为只需要webrtc标准通信部分，至于信令我们自己实现即可。
编译 amazon-kinesis-video-streams-webrtc-sdk-c 的时候 cmake除了添加 BUILD_DEPENDENCIES=OFF，
也必须添加 OPENSSL_ROOT_DIR，
生成sln工程，使用VS打开sln之后，把上面的include目录加入到包含目录中，
还得修改某些代码，主要是屏蔽 libwebsocket的调用和注释掉kvsWebrtcSignalingClient 相关部分。
编译会生成 kvsWebrtcClient.lib 库。

所以，最终连接到我们程序中的就是上面编译成功的7个lib静态库文件，当然还包括openssl生成的两个静态库文件。

不管怎么说，这些编译和修改比起gstreamer的编译和修改（上一篇文件中描述编译gstreamer过程），简直是太简单了。
也比谷歌自己的WebRTC编译简单的多，更重要的是kvswebrtc全部使用纯C语言开发，在各种平台下编译都变得很友好。

接下来，我们再来介绍如何使用 kvswebrtc的API接口，其实也是非常简洁的。
API接口的调用方式接近javascript的webRTC接口.
首先，在程序开始的地方调用 initKvsWebRtc 函数，初始化 kvswebrtc。
调用 createPeerConnection 函数创建 RtcPeerConnection ,
再然后调用 peerConnectionOnIceCandidate 和peerConnectionOnConnectionStateChange 设置 回调函数，
调用 addTransceiver 设置媒体通道的传输 Transceiver，
如果是数据通道，调用 createDataChannel 创建数据通道，接着调用 dataChannelOnOpen打开数据通道，
调用 dataChannelOnMessage  设置数据通道接收回调函数。

接着调用createOffer 创建OfferSDP，setLocalDescription 函数把OfferSDP设置到本地，调用此函数之后，
kvswebrtc开始收集本网络和ICE等信息，通过 peerConnectionOnIceCandidate  设置的回调函数返回给调用者。
然后我们把OfferSDP通过我们自己的通信协议发给浏览器客户端，同时也把生成的 IceCandidate等信息发给浏览器客户端。
当接收到浏览器客户端的AnswerSDP之后，调用setRemoteDescription 设置到本地，
接收到浏览器客户端的IceCandidate之后，调用addIceCandidate 添加到本地。
当成功建立webrtc连接之后（具体通过peerConnectionOnConnectionStateChange 设置的回调函数指示是否成功建立WebRTC）
我们要把已经编码成H264的视频流传输给浏览器客户端，直接调用kvswebrtc提供的writeFrame 函数即可。
于是整个kvswebrtc就这样跑通了。

是不是比起谷歌的WebRTC和gstreamer的调用方式简单得太多，而且我测试的使用效果也并不差。
真是没有比较就没有伤害啊。
具体如何使用kvswebrtc，请去查阅kvswebrtc提供的例子代码。

上一篇文章中说过了，在开发WebRTC中，偶然发现 MSE 也可以提供低延迟，实时性的基于video标签的渲染。
于是接下来我们再来研究MSE的实现方式。
开始之前，先来张已经在xdisp_virt中实现了webRTC和MSE的截图用于提神：

上图中，video标签渲染部分就是xdisp_virt最新实现的WebRTC和MSE的功能，
在最新实现中，声音编码依然是通过原来的方式进行处理，只有视频编码才通过WebRTC或MSE进行处理。
下面的 “通用（WebGL渲染）”，就是xdisp_virt原先实现的功能，并且在其中还新添加了WebRTC数据通道传输音视频数据。
最新版本请关注GITHUB上的更新，最近会把新版本xdisp_virt发布上去。

我们接着再来阐述如何实现MSE功能，
MSE需要生成 fMP4 格式的流，然后再喂给 MSE，这样才能正常使用。
现在关键是如何生成 fMP4 的格式流，
并不打算在xdisp_virt程序端生成 fMP4，因为这样改动较大，还得专门增加一个协议来传输fMP4流，
于是最好的办法，保持现有的传输方式不变（WebSocket传输 H264 编码），直接在javascript端把H264编码流转成 fMP4 流。

现在的问题是如何使用javascript把H264编码转成 fMP4 流。
其实网上也有一些直接使用js实现的 转 fMP4 的代码，比如 jmuxer等，但使用并不理想，
主要是因为我这边xdisp_virt有自己的一套实现方式，而且更主要的当使用jmuxer运行MSE渲染，
然后把电脑从浏览器切换到其他程序，
再然后切换回来，结果要么浏览器上的画面卡死，要么就是非常神奇的画面快速播放，在极速清空切换后没有播放的画面。
也懒得去修改jmuxer了，况且可能会越改越乱。

于是再次想到了 ffmpeg 这个神器。既然前面实现中，统一使用生成wasm的ffmpeg来解码各种图像和音频编码。
现在再增加一个 生成 fMP4 的接口，自然也没任何问题。事实上也确实这样。

如何使用 ffmpeg框架，把 H264 编码流转成 fMP4 流呢？
其实跟 转成 本地MP4，flv，mkv这些视频等没啥区别。
还记得我很早前的文章中，有专门描述过如何利用 ffmpeg 转成RTSP，RTMP以及本地视频文件。地址：
Windows远程桌面实现之五（FFMPEG实现桌面屏幕RTSP,RTMP推流及本地保存）_fanxiushu的专栏-CSDN博客_ffmpeg 桌面推流
具体就是讲述远程桌面文章系列的第五篇文章所描述的内容，
并且在GITHUB上还提供了 stream_push 开源代码与此文相对应。
地址：https://github.com/fanxiushu/stream_push

现在，我们只需要把 stream_push 的源码稍微做些修改，就可以把 AnnexB格式的H264裸流 转成 fMP4 流。
1，首先在调用 avformat_write_header 写头之前，需要设置 fMP4属性，
      av_dict_set(&options, "movflags", "empty_moov+default_base_moof+frag_keyframe", 0);
      avformat_write_header(ofm_ctx, options ? &options : NULL);
      这样就能确保 生成 fMP4 格式的流。
2，当然需要删除stream_push里边某些不必要的代码，因为只需要生成 MP4 格式的视频。
     因此在stream_push工程的open函数中，也就是创建 AVFormatContext的过程中，按照如下方式创建：
      avioc_buffer_size = 8 * 1024 * 1024;
      avioc_buffer = (uint8_t *)av_malloc(avioc_buffer_size);
      ofm_ctx = avformat_alloc_context();
      ofm_ctx->oformat = av_guess_format("mp4", NULL, NULL);
      ofm_ctx->pb = avio_alloc_context(avioc_buffer, avioc_buffer_size, AVIO_FLAG_WRITE, this, NULL, write_packet, NULL);
    其中write_packet是个回调函数，表示当ffmpeg 生成fMP4流的时候，这个回调函数就会调用，
     通常是调用 av_write_frame 之后，或者ffmpeg缓存满了需要写出数据的时候调用。
    相当于是已经生成了fMP4流数据，按照普通方式是直接写到本地文件中，而在这里，我们需要这个数据，因此直接通过回调函数来获取。
3，在上一篇文中讲述过，因为我们需要实时性的 fMP4 格式流，也就是意味着每来一帧 H264编码帧，都应该立即刷出 fMP4 流。
      这在 ffmpeg的实现中，是可以做到的。
     具体就是在 stream_push工程的 send_packet 函数中，在调用完成  av_interleaved_write_frame 函数之后，
     再次调用 av_write_frame(ofm_ctx, NULL); 记住最后一个参数是NULL，
     这样就会让 ffmpeg 把av_interleaved_write_frame 写入的数据帧，立即刷新出来，也就是 write_packet回调函数立即会被调用。

以上就是利用stream_push工程改造生成 fMP4 流的需要注意的三个要点。
有兴趣可以自己使用 stream_push去实现 fMP4 流的功能。
当然，最后再使用 emscripten 工具，编译生成 wasm，提供给js前端调用。

接下来，浏览器前端已经获取到H264转成的 fMP4 流，如何喂给MSE呢？
这个其实也是挺简单的，我们不要使用各种开源框架，直接使用MSE的接口函数就可以了。

按照如下方法创建：
    var mimeCodec = 'video/mp4; codecs="avc1.42E01E"'; //是否支持 H264

    if ('MediaSource' in window && MediaSource.isTypeSupported(mimeCodec)) {
    }
    else {
        alert('Can not Supported MSE(Media Source Extensions)');
        return;
    }

    /
    media_source = new MediaSource();
    canvas.src = URL.createObjectURL(media_source);
    media_source.addEventListener('sourceopen', function () {
        
        media_source.duration = Infinity; ///
       
        media_buffer = media_source.addSourceBuffer(mimeCodec);

        media_buffer.mode = 'sequence';
    });

这样在每次到来 fMP4流的时候，调用  media_buffer.appendBuffer( fmp4_stream_data ) 添加到MSE中。
真是要多简单就有多简单。

不过这里需要注意一些问题，应该在media_buffer 没有updating的时候添加fmp4流，否则会添加失败，这样会造成丢帧。
因此我们实际上是先把 fmp4 流数据拼接到 某个队列中，然后判断updating，再决定是否添加到 media_buffer 中
具体如下：
var media_queue = new Uint8Array();
function media_source_push_data(data)
{
    var t = new Uint8Array(media_queue.length + data.length);
    t.set(media_queue, 0);
    t.set(data, media_queue.length);
    media_queue = t;
    /
    if( media_buffer && media_queue.length > 0 && !media_buffer.updating){
        media_buffer.appendBuffer(media_queue);
        
        media_queue = new Uint8Array(); //reset
    }
    /
}

其次，因为我们需要实时性的MSE，因此一个非常重要做的事情，就是得不断清空多余的缓存，
我也不清楚现在的浏览器实现MSE的时候，为何总是喜欢缓存，缓存一旦变大，很大的延迟就会来了，
这对于远程桌面这类需求(需要非常高的实时性)是无法容忍的。
具体做法如下，（下面的canvas是 video标签的变量值）
设置一个每间隔100毫秒就执行的定时清理任务：
setInterval(function () {
        /// flush
        if (media_buffer && media_queue.length > 0 && !media_buffer.updating) {
            console.log('-- setInterval flush media queue.len=' + media_queue.length);
           
            media_buffer.appendBuffer(media_queue);
            
            media_queue = new Uint8Array(); //reset
        }

        ///剔除缓存太多的帧，目的是为了实现实时性，否则造容易成长期缓存,
        ///这么做的结果就是对于MSE的实时性支持差的浏览器，非常卡顿。
        if (canvas.buffered && canvas.buffered.length > 0 && !canvas.seeking) {
            const end = canvas.buffered.end(0);
            if ( (end - canvas.currentTime )*1000 >= 200 ) { // > 200 ms
               
                console.log('video delay seek to end, curr=' + canvas.currentTime +', end='+end );
                canvas.currentTime = end - 0.001;
            }
        }

       
    }, 100);

按照如上方式实现的MSE，在chrome内核浏览器上运行，实时性的效果是比较理想的，
不过比起 webRTC和WebGL渲染，依然有一些逊色。
至于在其他内核浏览器（其实主要是WebKit和Firefox浏览器，现在主流的浏览器内核无非就这三种）
则是非常卡顿，卡顿的原因是上面代码中，超过200毫秒的缓存就会被清除掉。
也就是说其他两个内核版本的浏览器，对低延迟的MSE，支持得比较差。

最后，gif图片简单演示一下xdisp_virt最新实现的 WebRTC和MSE功能的效果：

演示中，还可以看到xdisp_virt实现了 FrameBuffer截屏，
也就是可以截取到登录纯字符界面的linux。

因为上传图片大小有限，因此压缩的很厉害。
实际体验请去GITHUB下载最新版本的xdisp_virt ,
稍后会把添加WebRTC和MSE功能的xdisp_virt发布到GITHUB上：
https://github.com/fanxiushu/xdisp_virt