【zlm】MS， 复合器与解复合器

MS： mediasource  左边挂着demuxer ,右边挂着muxer 

 当解复用的时候 ，就直接把demuxer 里产生的trackers ,通过addtracker，直接 调用 了ms的addtracker,给muxer上也挂上了tracker .

当进行解码 的时候，又通过之前 绑定好的关系 ，将数据流最后通过 muxer-》inputFrame进行了数据的复合！

webrtcpusher在收到rtp流后，果断新数据给了rtspMS .

然后给了demuxer

解释下这里：如果是代理模式，才会直接把rtp包放ringbuffer里，供 类似 webrtc play一样的命令来进行请求进行播放；但目前的模式，还是会经过 _demuxer进行解码，然后通过 MultiMediaSourceMuxer里的（rtmp,rtsp,mp4）等要求的编码格式 进行编码 。当然这里的rtspMuxer对它自己来说，自己的rtspDemuxer弄出来的frame又给它来了一遍，放到ringbuffer里了

果断给了v_rtp_decoder或者a_rtp_decoder, 

而decoder显然与track是绑定在一起的（在maketracker的时候就已经注定 了） 

注：比如 h264decode 设置代理为此video_track,解码后，将frame 写入了此track;

  而 addTrack 将 track又加到了sink (muxer）里，作为它的track,且给这个track加一个代理 ，即会让muxer里对track里的frame进行了inputFrame(frame)的动作。 即track作为了一个承载frame的中价，让muxer有机会作inputFrame这个动作。

track input frame 之后 ，通过下面已经在track里设置的代理 ，将input frame转发给， muxer的input frame .

FrameDispatcher 中，它会把inputFrame转给后面muxer去input Frame