This is only useful for audio as video or subtitle usually only have one frame (some video codec may hide reference frames but they don't have a timestamp as they are not displayed).
To help muxers it should be useful to tell how many (audio) samples a codec uses per frame.
Some codec may have different values so either all values should be listed or the Greatest Common Denominator that can be used to match all the values.
Some codec may also have a delay of X samples before the first sample is out. This value(s) should also be mentioned, especially if it doesn't fit the GCD mentioned above. In that case either this value needs to be integrated to compute the GCD or the amount of samples (the duration wouldn't work since it isn't matching the GCD of samples) should be mentioned in the codec mapping and in the file (so that means adding a new element, so probably not a good solution).
As seen in https://github.com/cellar-wg/matroska-specification/issues/422#issuecomment-711133926 to have better sample precision (and without adding new elements) it can useful to know how many frames a codec pack per frame.
This is only useful for audio as video or subtitle usually only have one frame (some video codec may hide reference frames but they don't have a timestamp as they are not displayed).
To help muxers it should be useful to tell how many (audio) samples a codec uses per frame.
Some codec may have different values so either all values should be listed or the Greatest Common Denominator that can be used to match all the values.
Some codec may also have a delay of X samples before the first sample is out. This value(s) should also be mentioned, especially if it doesn't fit the GCD mentioned above. In that case either this value needs to be integrated to compute the GCD or the amount of samples (the duration wouldn't work since it isn't matching the GCD of samples) should be mentioned in the codec mapping and in the file (so that means adding a new element, so probably not a good solution).