我来帮你拆解这些问题，其实核心都和MediaSource的解码机制、媒体容器的结构息息相关，咱们一个个说：

为什么不推送第一个Blob就无法播放？ #

第一个由MediaRecorder生成的Blob可不只是普通的视频帧——它通常包含WebM容器的初始化段（Initialization Segment），里面有解码器必须的元数据：比如编码格式参数、音视频轨道信息，没有这个，MediaSource的解码器根本不知道该怎么解析后续的二进制数据。

另外，第一个Blob里一般还包含视频的第一个关键帧（Keyframe），后续的P帧（预测帧）、B帧（双向预测帧）都依赖关键帧才能解码，没有关键帧当“锚点”，解码器完全无法还原画面。所以跳过第一个Blob，相当于既没给解码器“说明书”，又没给它“起始画面”，自然播不了。

如何实现跳过部分Chunk后vdo1仍可播放？ #

要跳过Chunk还能正常播放，你得满足两个前提：保留初始化段，并且从下一个关键帧开始推送数据。具体可以这么改你的代码：

步骤1：识别并保留初始化段 #

WebM的初始化段开头有固定的EBML标识字节：0x1A 0x45 0xDF 0xA3，我们可以通过这个特征把它单独保存下来，确保它一定会被推送给sourceBuffer：

// 新增变量存储初始化段
let initSegment = null;

mediaRecorder.ondataavailable = function (e) {
  if (e.data && e.data.size > 0) {
    var reader = new FileReader();
    reader.addEventListener("loadend", function () {
      var arr = new Uint8Array(reader.result);
      // 判断是否是WebM初始化段
      if (arr.length >=4 && arr[0] === 0x1A && arr[1] === 0x45 && arr[2] === 0xDF && arr[3] === 0xA3) {
        initSegment = arr;
      }
      chunks.push(arr);
    });
    reader.readAsArrayBuffer(e.data);
  }
};

步骤2：调整推送逻辑，确保从关键帧开始推送 #

修改recv函数，先强制推送初始化段，然后跳过不需要的Chunk，直到遇到下一个关键帧（这里我们简化处理，直接从第11个Chunk开始推送；实际场景中可以通过解析WebM帧头精准判断关键帧）：

var recv = function(){
  var chunk = chunks.shift();
  if(chunk){
    i++;
    // 初始化段必须优先推送，不能跳过
    if (chunk === initSegment) {
      sourceBuffer.appendBuffer(chunk);
      recv();
      return;
    }
    // 跳过第5-10个Chunk，从第11个开始推送
    if(i > 10){
      sourceBuffer.appendBuffer(chunk);
    }
    recv();
  }else{
    setTimeout(recv, 20);
  }
};

如果想要更精准的关键帧检测，你可以解析WebM的帧结构——VP8的关键帧开头有0x9D 0x01 0x2A的标识，在每个Chunk的字节数据里查找这个特征，只有包含关键帧的Chunk才开始推送。

MediaSource如何接收任意Blob？ #

MediaSource可不是什么Blob都能接收的，它有严格的要求：

1. 格式匹配：Blob的MIME类型必须和你创建sourceBuffer时指定的完全一致（比如你用的video/webm;codecs=vp8，就不能推MP4的Blob）。
2. 必须包含初始化段：不管是第一个Blob还是单独提取的初始化段，必须先推送给sourceBuffer，让解码器完成初始化。
3. 媒体段必须可解码：后续推送的Blob要么是连续的帧序列（从关键帧开始），要么本身包含关键帧——如果推送的是依赖前面已跳过帧的P帧/B帧，解码器还是无法解码。

所以“接收任意Blob”是不现实的，必须符合媒体容器的规范，并且包含解码器需要的初始化信息和可独立解码的帧数据。

内容的提问来源于stack exchange，提问作者Cao YongFeng