acolwell/mse-tools

panic: First block is not a keyframe!

Closed this issue · 1 comments

Hi,

I'm attempting to livestream using a webm format and I've used slightly unorthodox ffmpeg settings on libvpx 1.3.0:

    [
      '-f', 'rawvideo',
      '-s', `${width}x${height}`,
      '-pix_fmt', 'yuva420p',
      '-r', '30',
      '-i', '-',
      '-c:v', 'libvpx',
      '-vf', 'setsar=1:1',
      '-g', '30',
      '-minrate', '1M',
      '-maxrate', '1M',
      '-b:v', '1M',
      '-lag-in-frames', '1',
      '-threads', '4',
      '-deadline', 'realtime',
      '-pix_fmt', 'yuva420p',
      '-auto-alt-ref', '0',
      '-metadata:s:v:0', 'alpha_mode="1"',
      '-cluster_size_limit', '0',
      '-f', 'webm', '-'
    ]

Which produces this webm file. Attempting to remux this file produces the aforementioned error, panic: First block is not a keyframe!. Using webm_dump gives the following:

[...]
  <Cluster type="list" offset="426">
    <Timecode type="uint" value="0"/>
    <BlockGroup type="list" offset="441">
      <Block type="binary" size="59425" trackNum="1" timecode="0" presentationTimecode="0" flags="0"/>
      <BlockAdditions type="binary" size="68972"/>
    </BlockGroup>
  </Cluster>
  <Cluster type="list" offset="128861">
    <Timecode type="uint" value="33"/>
    <BlockGroup type="list" offset="128876">
      <Block type="binary" size="4424" trackNum="1" timecode="0" presentationTimecode="33" flags="0"/>
      <ReferenceBlock type="int" value="0"/>
      <BlockAdditions type="binary" size="12999"/>
    </BlockGroup>
  </Cluster>
  <Cluster type="list" offset="146324">
    <Timecode type="uint" value="67"/>
    <BlockGroup type="list" offset="146339">
      <Block type="binary" size="4043" trackNum="1" timecode="0" presentationTimecode="67" flags="0"/>
      <ReferenceBlock type="int" value="0"/>
      <BlockAdditions type="binary" size="11297"/>
    </BlockGroup>
  </Cluster>

As you can see, the first block doesn't have the keyframe flag set, but all subsequent frames use block 0 as a reference frame. Is this a problem file or something that is allowable by spec?

Thanks.

I believe this should now be fixed.