video is frozen forever during a live broadcast with variable FPS

By design Issue #12588868


Cool C.
Jun 30, 2017
This issue is public.
Found in
  • Microsoft Edge
Found in build #
Reported by 1 person

Sign in to watch or report this issue.

Steps to reproduce

Steps to reproduce the issue: load the coolcmd.html from attached testcase.

***** Expected *****

audio track is playing back from 8:53:18 to 8:53:28, video track is playing back from 8:53:18 to 8:53:22 and from 8:53:24 to 8:53:28. at the end number 96 is shown at the upper right corner.

***** Actual *****

audio track is playing back from 8:53:18 to 8:53:28, video track is playing back from 8:53:18 to 8:53:22. at the end number 91 is shown at the upper right corner.

***** Explanation *****

segment 3.ts contains only 1 video frame (key frame). Edge selects duration for this frame… i think 33 or 16 ms. in fact, the duration of this frame (and the entire segment) is 2000 ms. so in the video track we have a gap ~2000 ms long. HTMLVideoElement.buffered has only 1 range – this gap is "invisible". all of this is not issue. issue is that Edge finishes playing the video track before the gap and does not continue after the gap. Note: the script does not call MediaSource.endOfStream(), because this is live broadcast. If you uncomment in the script MediaSource.endOfStream(), then the playback runs without problems.

Edge should do one of two things:

HTMLVideoElement.buffered contains 2 ranges and when the end of the 1st region is reached, playback stops. Chrome and Firefox do just that.

  • OR -

HTMLVideoElement.buffered contains 1 range and Edge plays all 10 seconds of the video.


1 attachment

Comments and activity

  • Changed Steps to Reproduce

  • Microsoft Edge Team

    Changed Assigned To to “James M.”

    Changed Assigned To to “Venkat K.”

    Changed Assigned To from “Venkat K.” to “Jerry S.”

    Changed Assigned To from “Jerry S.” to “Matthew H.”

    Changed Status to “By design”

  • Hello,

    Thank you for providing this information about the problem. This behavior is by design. We pause playback roughly 0.5 seconds before the end of the first buffered range so that we do not fully drain the pipeline, and wait for data to be appended to fill the gap. The issue is the gap in the data that is appended.

    Best Wishes,

    The MS Edge Team

You need to sign in to your Microsoft account to add a comment.

Sign in