Skip to content

Arbitrary BlockAddID values are being written regardless of source

Strictly speaking, this is a request to support BlockAdditionMapping as defined in the spec.

Right now, if you remux a VP9 WebM source with HDR10+ metadata in a BlockAdditional that has BlockAddID 4, mkvmerge will ignore said id and write a 1 to the output, be it to Matroska or WebM. This is wrong as 1 is strictly reserved for opaque, codec specific data, which for VP9 it means Alpha channel.

Blindly propagating the BlockAddID from the source would be fine as a solution for WebM output, but for Matroska output the correct solution is to implement writing a BlockAdditionMapping:

  • For WebM sources, BlockAddID 4 effectively means an ITU-T T.35 payload, so that's straightforward, and a BlockAdditionMapping with BlockAddIDType 4 and BlockAddIDValue 4 must be written.
  • For Matroska sources, there should not be any real world file with BlockAddID other than 1 out there or with a BlockAdditionMapping until my FFmpeg patches are merged to support this same stuff, so in the absence of a BlockAdditionMapping it should be safe to keep using BlockAddID 1 and not write a mapping, but if there's any BlockAdditionMapping, they should be propagated. The source BlockAddIDValue in them can be replaced as long as the spec allows it (e.g., for timecodes), to get the smallest value possible (This would therefore be reflected in the relevant BlockAddID too, of course). Matroska output also needs to always write a MaxBlockAdditionID if there's any BlockAddition at all in the track.

Here's a WebM sample with HDR10+ metadata to reproduce what i mentioned earlier.

hdr10_plus_vp9_sample