Add coverage for videoKeyFrameIntervalDuration and videoKeyFrameIntervalCount MediaRecorder properties.

[handellm]

The specification was updated with a new property for MediaRecorder and MediaRecorderOptions which allows the keyframe distance of the emitted stream to be controlled. Web platform tests need to be added to track feature compatibility. https://w3c.github.io/mediacapture-record/#mediarecorder-api

[foolip]

@handellm can you say a bit more about what's needed to test this? On blink-dev you said "Testability requires muxer parsers which MediaRecorder WPTs are currently lacking", do you mean something that would demux the outgoing stream and inspecting its properties? Does the loopback testing approach not work in this case? cc @henbos

[handellm]

Yes, it's not possible to deduce that a key or delta frame was decoded from decoded material.

To verify that a recorded bitstream with the new properties set up, one needs to verify that the SimpleBlocks emitted to the WebM file contains keyframes at timestamps/distances that correlates with the properties set up in the MR properties. For example, when inspecting https://dl6.webmfiles.org/big-buck-bunny_trailer.webm with mkvinfo -v, you see the keyframe property dumped:

|+ Cluster
| + Cluster timestamp: 00:00:00.000000000
| + Cluster position: 3911
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.000000000 <<<< KEYFRAME
|  + Frame with size 431
| + Simple block: track number 2, 1 frame(s), timestamp 00:00:00.000000000
...
| + Simple block: track number 2, 1 frame(s), timestamp 00:00:00.059000000
|  + Frame with size 155
| + Simple block: track number 1, 1 frame(s), timestamp 00:00:00.080000000 <<<< DELTA FRAME
|  + Frame with size 1339

[handellm]

In some more detail, the parser needs to be smart enough to

• figure out which of the recorded tracks is video i.e. basic EBML header parsing
• parse video SimpleBlock timestamps (for the IntervalDuration), order of occurrence (for the IntervalCount)

[foolip]

Ah, I see. So what we'd need here isn't any new testing infrastructure, but a WebM demuxer implemented in JavaScript.

Are there other things that are currently not tested that would benefit from an approach like that? To me it seems like a bit too much to test only the keyframe generation, but if there are other things lacking coverage it might make sense to do.

[handellm]

I think behavior related to bitrates requested in the MR settings is not covered currently. However that will have it's own problems as you get dependent on encoder bitrate controllers which are often YMMV or simply broken.