Video MSE issues as of March 01 2017

Confirmed Issue #11147314 • Assigned to Rafael V.


David V.
Mar 3, 2017
This issue is public.
Found in
  • Microsoft Edge
  • Internet Explorer
Reported by 7 people

Sign in to watch or report this issue.

Steps to reproduce

Copied from Description when changed from Task to Bug


Current MSE implementation in IE and Edge has two major issues:

  1. Unlike in Chrome, MSE player needs 2-3 seconds of content to start playing, so you cannot get a sub-second latency with live stream. Sometimes Edge and IE tries to play too early and as a result it only plays key-frames.

  2. Seamless switch to another media does not work well. According to MSE spec, browsers should provide seamless switch to another media after new BMFF video/mp4 initialization segment. That issue exists in other browsers as well.

Context: Unreal Media Server sends very short (30-500 ms) length BMFF video/mp4 segments via WebSockets. That allows to achieve very low latency (0.2 - 1 sec) and works in Chrome pretty well but in Edge and IE you have issue #1.

Unreal Media Server also supports live playlists so you can switch the same live stream to a different content. In that case a new initialization segment is sent but it only works well with video-only streams; if audio exists then it stops playing or playing badly.

On the demo page
you can see a link to HTML5 player stream; that stream demonstrates issue #1. The link to live playlist with timeshift, if attempted with HTML5 player, would produce issue #2.

Unreal Media Server:

Thank you!


0 attachments

    Comments and activity

    • Microsoft Edge Team

      Changed Assigned To to “James M.”

      Changed Status to “Not reproducible”

    • Hello,

      Thank you for providing this information about the issue. After thorough testing, we are unable to reproduce a unique problem in Edge; the delay in the playback is consistent across major browsers. Please reopen this case when you can provide more details, such as video capture or a performance analysis (of both Chrome and MS Edge browsers) for further investigation.

      Best Wishes,
      The MS Edge Team

    • Changed Status from “Not reproducible”

    • Hi James,

      How is this not reproducible?
      There is a demo live stream from IP camera:
      Open it with Chrome and open it with Edge. Compare the latency.

      What we have found is that Chrome only needs a few frames to start playing but Edge needs the whole h.264 GOP (maybe a second key-frame too) before it starts playing.
      I know Chrome uses MFT low-latency decoder in Windows, not sure what you guys are doing, but there is no reason to buffer so much before starting to play.

      Also, please take a look at
      this is another problem of Edge - this one is about seeking. Please open a separate bug if needed.

    • Microsoft Edge Team

      Changed Assigned To to “Steven K.”

      Changed Assigned To from “Steven K.” to “James M.”

    • Hello,

      Thank you for providing more information about this issue. We are unable to reproduce the problem and find your sample exhibits the same behavior in Edge as other browsers. Please update this case when you can provide some of the requested information and preferably run dxdiag (Windows key + r and type dxdiag, enter, then click Save all Information and attach the txt file).

      Best Wishes,
      The MS Edge Team

    • Dear James,

      1. If you open at the same time in Edge and Chrome, you can notice that stream in Chrome is 1-2 seconds ahead of Edge. This is because Edge buffers too much before starting playing.

      2. - have you looked at it?
        The problem in Edge still exists, even if we correct the mp4 container key-frame flags.
        The real issue here is: it seems like Edge expects each video segment added to SourceBuffer to start with key-frame. Maybe this is a requirement for MPEG-DASH, but MSE could be used not only with MPEG-DASH. Video segments that we send, not necessarily start with key-frame. Look at
        When you seek, Edge just starts with the segment corresponding to seeked time, as if this segment for sure will start with key-frame, which is not the case.

    • Microsoft Edge Team

      Changed Assigned To to “Venkat K.”

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

      Changed Status to “Needs root cause”

    • Some more information:

        This player buffers 1000ms of data before starting playing in any browser except Chrome.
        In Chrome it only buffers 100ms of data. So if we do the same for IE/Edge (buffer only 100ms) then IE/Edge would play choppy, showing key-frames only. That’s why we have to buffer more for IE/Edge.

        With IE/Edge make seeks in the local buffer. Notice how audio starts playing, but video waits for 2-3 seconds, or, even worse, video starts with p-frame. Never happens with other browsers. That’s because IE/Edge assumes every segment starts with Key-frame, which is not true.

    • Microsoft Edge Team

      Changed Status from “Needs root cause” to “Confirmed”

      Changed Assigned To from “Jerry S.” to “Angelo L.”

      Changed Status from “Confirmed” to “Needs root cause”

      Changed Assigned To from “Angelo L.” to “Gurpreet V.”

      Changed Assigned To from “Gurpreet V.” to “Angelo L.”

      Changed Status from “Needs root cause”

      Changed Steps to Reproduce

      Changed Assigned To from “Angelo L.” to “Rafael V.”

      Changed Status to “Needs root cause”

      Changed Status from “Needs root cause” to “Confirmed”

      Changed Status from “Confirmed” to “Needs root cause”

      Changed Status from “Needs root cause” to “Confirmed”

    • Is there plan for this issue or if there has any test version, I can try.

    • Microsoft Edge Team

      Changed Steps to Reproduce

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

    Sign in