Video readyState doesn't change after playing

Won’t fix Issue #11459883

Details

Author
Jacob T.
Created
Mar 30, 2017
Privacy
This issue is public.
Found in
  • Microsoft Edge
Reports
Reported by 7 people

Sign in to watch or report this issue.

Steps to reproduce

While playing a video using MSE, the readyState field doesn’t update after playback has begun. It is updated during startup, but once it gets to 4 (HAVE_ENOUGH_DATA), it is never updated when the video runs out of data.

For example, if we append data from [0-10], when we play to the end of the buffer, the video pauses waiting for new data. The readyState attribute should change to 2 (HAVE_CURRENT_DATA) to indicate that there isn’t future frames to play.

Similarly, if we seek to an unbuffered region, the readyState should change to 1 (HAVE_METADATA) to indicate there isn’t any frames available at all.

This demo loads up 10s of video and plays until the end of the buffer:
https://storage.googleapis.com/shaka-demo-assets/_bugs/edge-video-readystate/index.html

Copied from Description when changed from Task to Bug

Copied from Repro Steps when changed from Bug to Task

While playing a video using MSE, the readyState field doesn’t update after playback has begun. It is updated during startup, but once it gets to 4 (HAVE_ENOUGH_DATA), it is never updated when the video runs out of data.

For example, if we append data from [0-10], when we play to the end of the buffer, the video pauses waiting for new data. The readyState attribute should change to 2 (HAVE_CURRENT_DATA) to indicate that there isn’t future frames to play.

Similarly, if we seek to an unbuffered region, the readyState should change to 1 (HAVE_METADATA) to indicate there isn’t any frames available at all.

This demo loads up 10s of video and plays until the end of the buffer:
https://storage.googleapis.com/shaka-demo-assets/_bugs/edge-video-readystate/index.html

Attachments

0 attachments

    Comments and activity

    • Microsoft Edge Team

      Changed Assigned To to “James M.”

      Changed Assigned To to “Venkat K.”

    • W3 Spec:

      Note: If the media element was potentially playing immediately before it started seeking, but seeking caused its readyState attribute to change to a value lower than HAVE_FUTURE_DATA, then a waiting will be fired at the element.

      Playing event should be fired after waiting event.
      Video readyState doesn’t change after seek caused that playing event does not fire after waiting event.

      Found in Microsoft Edge 14393 and 15063 (RTM).

    • Microsoft Edge Team

      Changed Assigned To from “Venkat K.” to “Nishant N.”

      Changed Assigned To from “Nishant N.” to “Shawn P.”

      Changed Assigned To from “Shawn P.” to “Gurpreet V.”

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

      Changed Steps to Reproduce

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

      Changed Status to “Confirmed”

      Changed Status from “Confirmed”

      Changed Status to “Confirmed”

      Changed Status from “Confirmed” to “By design”

    • Hello,

      Thank you for providing this information about the issue. By design we are pausing playback at 9.5 seconds because we are not getting any more buffer past 10 seconds. At that point we expect more data to be appended or endOfStream() to be called.

      Currently, we do not plan to release a fix for this problem, but we are always considering a long-term solution.

      Best Wishes,
      The MS Edge Team

    • MICROSOFT EDGE TEAM Any updates?

    • Changed Status from “By design”

    • The problem isn’t that the video stops, the problem is that the readyState attribute isn’t being updated once the video hits the end of the buffer. The readyState value should change as the video plays to represent how much content is available.

      This is a spec-compliance issue, see https://html.spec.whatwg.org/multipage/embedded-content.html#ready-states. Once the video stops playing, the readyState value can’t remain at 4 since the video can’t move forward.

    • Microsoft Edge Team

      Changed Assigned To to “Matthew H.”

      Changed Status to “Confirmed”

      Changed Status from “Confirmed” to “Won’t fix”

    • Hi,

      I maintain Hls.js and we’ve just run into this issue. I’m disappointed to see that it’s been marked as wontfix - lack of consistency across browsers makes it difficult for us to offer a quality experience to those viewing on Edge/IE. I’d like to emphasize (as Jacob T. did) that IE/Edge do not follow the spec in this regard.

      Our usecase is a bit different than the one listed. We have a stream which begins playback at 10 seconds. We can successfully detect and jump the gap at the start of playback, but if the viewer seeks back into the gap range, the readyState will remain at 4. This causes our existing gap jumping logic to think that there is no problem.

      Thank you for providing this information about the issue. By design we are pausing >playback at 9.5 seconds because we are not getting any more buffer past 10 seconds. At >that point we expect more data to be appended or endOfStream() to be called.

      Currently, we do not plan to release a fix for this problem, but we are always considering >a long-term solution.

      This explanation does not make sense in the context of our issue.

      Test stream: https://s3.amazonaws.com/bob.jwplayer.com/~alex/123633/new_master.m3u8

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

    Sign in