This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Some media data use variable frame rates (e.g. speech coding, video surveillance, subtitles ...). It would be interesting to have support for that in MSE. In the case of the ISOBMFF, samples can be created with a given duration and later on, this duration can be extended (e.g. adjusting using tfdt or signaled using sample flags sample_depends_on=2 and sample_has_redundancy=1)
Marking all pre-Last Call bugs
I don't believe there is any existing text in the MSE spec that prevents variable frame rate. It has always been my intent to support that case. Can you point to specific text that is problematic? I'm assuming that the specific details that you mention are applied during coded frame construction time. I expect the duration of the coded frame to reflect whatever transformations these flags may apply.
Marking as WONTFIX because I believe the spec already supports variable frame rate. Please reopen if you have specific suggestions on what text needs to be changed.
I was probably a bit too quick when I filed the bug. What I meant was that the Coded Frame Processing algorithm assumes that the frame duration is known. But when you have variable frame rate streams, the duration of a frame may not be available and cannot be assumed to be the duration of the previous frame. In some cases, the duration of a frame may span over more than one segment. In MPEG-2 TS, where duration is not coded, you have to wait for the next frame to arrive to compute the PTS difference. That frame may arrive a long time after (e.g. in video surveillance application), that may cause the previous video frame to be dropped because not processed on time or the playback to stall. This raises also the question of the last frame in an MPEG-2 TS segment, for which no duration can be computed. As I explained in my original comment, for the MP4 case, it is possible to update the duration of the previous sample. You would create a segment whose last sample does not have the entire duration, and then send an update in the next sample (in the next segment) to extend the duration. For these cases, I think the MSE spec as is cannot be used.