Seems to be too format specific to be a Blink issue.

matt@, is this a bug or by design change starting Chrome 54? it does not repro on Chrome 53.
shaofeng.tang@intel.com, can you provide a repro page?

I repro'ed this locally on linux (and using the 4k60fps version of that vpx+opus stream, along with lots of parallel busy-wait processes to load the CPU). It looks like decoder underflow might be the root cause of repeated transitions into and out of HAVE_CURRENT_DATA here.

Over to chcunningham@. IIUC, this is related to recent change to transition HTMLMediaElement.readyState back to just HAVE_CURRENT_DATA from > HAVE_CURRENT_DATA if a renderer runs out of decoded media. This can happen due to either lack of buffers to decode, or decoder underflow.

The HTML5.1 spec for HAVE_CURRENT_DATA is a little ambiguous about whether or not a decoder (but not buffering) underflow could trigger falling back to HAVE_CURRENT_DATA from > HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA.

Chris, any ideas?

Yep, this is my bug :). Matt is right - this is decoder underflow (can't keep up) causing repeated 'waiting' and 'playing' events to be emitted as we 1) attempt to fill up the queue of decoded frames, 2) immediately run out again, and 3) repeat. 

I'll be working to fix this in the current quarter. waiting/playing should only be emitted in response to network buffering underflow. ATM our media element is not properly distinguishing between the two.

Could you share the latest status of this bug?
It is fixed or when it will be fixed? 
If you need any help from me? please let me known.

Thanks a lot

Sorry, this bug didn't make the cut for last quarter (Its still not fixed). Its on my back burner list for the current quarter. 

If you can share more about your use case I may be able to suggest a work around to unblock you. 

Thanks to your response. My use case is below：

We have a web server to play some videos（H264/VP8/VP9） and measure the FPS, Dropped Frames, and Decoded Video Frames.
Once the "playing" event is emitted. the method videoStarted is invoked.

var videoStarted = function() {
        console.log("Video Started at " + getCurrentTime());
        startTime = getCurrentTime();
        updateIntervalId = setInterval(updateStats, updateInterval);
};

and the "startTime" is used to calculate the playbackRate, FPS in the interval method “updateStats”

var updateStats = function() {
        var data;
        var tableCell;

        for ( var x in stats) {
            tableCell = document.getElementById(stats[x].id);

            if (stats[x].id == "playbackRate") {
                var elTime = (getCurrentTime() - startTime) / 1000;
                data = Math.floor(videoElement.currentTime / elTime * 100 + .5);
                if (data < 100) {
                    tableCell.className = "danger";
                } else {
                    tableCell.className = "success";
                }
                data += "%";
            } else if (stats[x].id == "fps") {
                var elTime = (getCurrentTime() - startTime) / 1000;
                data = Math.floor(videoElement.webkitDecodedFrameCount / elTime
                                  + .5);
            } 

            .......
            tableCell.innerHTML = data;
        }

And the result of playbackRate, FPS is shown in the web page.
When this issue happen, the "startTime" is reset by the "playing" event many times, and the FPS, playbackRate will be wrong with the rest startTime.

We hope to calculate the average FPS and playbackRate during playing video.

We will really appreciate if you can give us some suggestion for a workaround with this issue.

inside videoStarted(), can you check to see if startTime already has a value and simply return right away for these later "playing" events?

If you want to reset startTime for user interaction like seeking or pause-then-play, you can additionally listen for "paused" and "seeking" events to reset startTime.

Thanks a lot. I will take a try.

not a issue anymore, thanks a lot