I don't repro this bug in Mac + Chrome 53.0.2785.8. I am able to seek while video is in play or in pause state. seek event is also fired. can you upgrade to Chrome 53 and try again?

I am able to repro it in 
Version 52.0.2743.82 (64-bit)
Version 54.0.2815.0 canary (64-bit)

Sorry, I don't have Chrome 53.

I found that executing following snippets in console would make it easier to repro this bug

window.document.getElementsByTagName('video')[0].currentTime = 550;
(function(){
  'use strict';
  var videoElement = window.document.getElementsByTagName('video')[0];
  var time = -1;
  var seek = function () {
      if (videoElement.seeking) {
          console.log("DEBUG: Video Element is already seeking");
          return;
      }
      var currentTime = videoElement.currentTime;
      var seekTarget = currentTime + time;
      console.log("DEBUG: Seeking to " + seekTarget);
      videoElement.currentTime += time;
  }
  var intervalId = window.setInterval(seek, 100);
  console.log("DEBUG: Started timer with Id " + intervalId);
})();

Thank you for providing more feedback. Adding requester "yiningc@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 hi.ansh@gmail.com, I am unable to play the mpd stream you provided above. The error is: 
http://dash.edgesuite.net/dash264/TestCases/1a/netflix/ElephantsDream_H264BPL30_0100.264.dashnull 404 (Not found)
Can you check the repro steps?

It is weird that I didn't face the 404 earlier, but faced it after reading the last comment. On pressing the load button a couple of times the 404 error disappeared.

So, here are the revised steps to reproduce this issue.
1. Open the DASHIF player url http://dashif.org/reference/players/javascript/v1.6.0/samples/dash-if-reference-player/index.html 
2. Enter the stream url in the Stream input box http://dash.edgesuite.net/dash264/TestCases/1a/netflix/exMPD_BIP_TC1.mpd
3. Hit the load button and wait for the stream to play. If the steam doesn't play and you see a 404 error in the Network logs, hit Load button again. Refresh the page if it still doesn't work.
4. Enter and execute the following snippet in Console, and wait for the video to complete seeking to the new position
window.document.getElementsByTagName('video')[0].currentTime = 550;
5. Enter and execute the following snippet which seeks back 1s every 100ms
(function(){
  'use strict';
  var videoElement = window.document.getElementsByTagName('video')[0];
  var time = -1;
  var seek = function () {
      if (videoElement.seeking) {
          console.log("DEBUG: Video Element is already seeking");
          return;
      }
      var currentTime = videoElement.currentTime;
      var seekTarget = currentTime + time;
      console.log("DEBUG: Seeking to " + seekTarget);
      videoElement.currentTime += time;
  }
  var intervalId = window.setInterval(seek, 100);
  console.log("DEBUG: Started timer with Id " + intervalId);
})();

6. Notice that the video is stuck in seeking state, without ever recovering even when buffer is available at the seek point.

I am able to repro this issue by following repro steps on #5. But this is not a regression. I see the same behavior on Chrome 37 too.
wolenetz@, can you take a look and decide should we fix it?

I'll take a look. Of note, I'm not sure how resilient the DASHIF player is against 404's on fetches of media segments. Given the mpd has been shown to give 404's sometimes, perhaps fetches of those media segments do the same. If so, and if DASHIF doesn't retry those fetches, that would very well explain why playback might stall. It wouldn't explain directly why playback might stall though if there is buffered media at the seek target (unless the DASHIF player has intervened and paused the playback itself).

Hmm. Another suspicion is that if this is specific to Mac (e.g., VTVDA h/w decode), then a poorly muxed media segment which identifies incorrectly a nonkeyframe as a keyframe might cause seeking (and decoder preroll from) such a real nonkeyframe to trigger decode error. S/W decoders aren't always as strict about this situation; VTVDA is more strict.

Repro on linux 52.0.2743.116 (Official Build) (64-bit)

This appears to be a DASHIF player issue.

Once the repro (using #5) reaches multiple "DEBUG: Video Element is already seeking", I queried the video element:

$('video').currentTime
522.373348

$('video').buffered
TimeRanges {length: 1}

$('video').buffered.start(0)
522.522

$('video').buffered.end(0)
638.637999

$('video').currentTime
522.373348

--

Net result: the seek target is *not* within the currently buffered region. The app needs to fetch and append media for the seek target position to unblock playback. I don't see any 404 Status types in my repro's devtools Network window.

--

hi.ansh@gmail.com, can you confirm similar in your repro? If so, ISTM there's a DASHIF bug to fix. I also tried the same mpd using shaka player (http://shaka-player-demo.appspot.com/demo/), but received multiple mpd parse warnings leading to parse error from shaka player. Is that mpd well-formed?

Hmm. I also wonder if this might be an artifact of Chrome MSE MP4 conflation of PTS and DTS. If DASHIF player (as it seems it must have to with this mpd) parses the segments to determine subsegment boundaries and their timestamps, it probably thinks it has buffered the right stuff even though the mediaElement is reporting differently (since Chrome reports, incorrectly, buffered ranges in DTS, not PTS). Group of known related bugs: https://bugs.chromium.org/p/chromium/issues/list?can=2&q=owner%3Ame+MSEptsdtscleanup&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids

Assuming this is such a PTS/DTS conflation issue, marking as blocked on. Meanwhile, hi.ansh@.gmail.com, please see my queries in c#9, above.

Correcting the link in c#10: https://bugs.chromium.org/p/chromium/issues/list?can=2&q=MSEptsdtscleanup&colspec=ID+Pri+M+Stars+ReleaseBlock+Component+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=ids

assign to wolenetz@
hi.ansh@gmail.com, can you answer question in #9?

I confirm wolenetz@chromium.org observation is correct in comment #9.
The seek point lies outside the buffered range, and thus the video remains in seeking.
The DASHIF player reports the ranges correctly, but doesn't download the required fragment to be able to reach the seek point.

But, this bug in DASHIF is actually preventing the repro of an issue in Chrome. I am able to repro on my codebase, but unfortunately can't share publicly.
The video remains stuck in seeking state, but the ranges are gone and are returned as undefined

window.document.getElementsByTagName('video')[0].seeking
true
window.document.getElementsByTagName('video')[0].ranges
undefined
window.document.getElementsByTagName('video')[0].ranges.start(0)
VM876:1 Uncaught TypeError: Cannot read property 'start' of undefined(…)

@#13 if you can email me a private, minimized repro of the Chrome issue, please do so. Note that there is no "ranges" member of an HTMLMediaElement. Did you mean "buffered"?

My bad, I did mean 'buffered' instead of 'ranges', and that member is available.
window.document.getElementsByTagName('video')[0].currentTime
358.673345
window.document.getElementsByTagName('video')[0].seeking
true
window.document.getElementsByTagName('video')[0].buffered.start(0);
233.557333
window.document.getElementsByTagName('video')[0].buffered.end(0);
360

Sorry, I can't share even the minimized code without clearance from legal of my company (Adobe Systems).

I will try to make changes to the dash.js code to repro the issue. But, it might take some time.

Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919

@#15 are you still able to reproduce this issue?
Note, if it's due to incompliant buffered range reporting by DTS but currentTime reporting by PTS, note that my Chrome PTS/DTS compliance work is expected to land soon (behind a feature flag at first, "MseBufferByPts"). If you can reproduce this issue still, please retry once  issue 718641  is fixed, using an appropriate Canary or Dev Chrome (and give --enabled-features=MseBufferByPts on cmdline to ensure the new buffering behavior is being used). Follow along the main compliance CL (https://chromium-review.googlesource.com/c/chromium/src/+/678443) as it is going through review and gets landed if you want to try things out soon in Canary.

I tried with Canary build Version 63.0.3239.0 (Official Build) canary (64-bit), and with --enabled-features=MseBufferByPts flag, but the issue is still reproducible.

These are the logs from chrome://media-internals
00:03:34 782	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
00:03:34 783	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:03:35 228	seek_target	870.423745
00:03:35 228	pipeline_state	kSeeking
00:03:35 228	audio_buffering_state	BUFFERING_HAVE_NOTHING
00:03:35 228	video_buffering_state	BUFFERING_HAVE_NOTHING
00:03:36 204	pipeline_state	kPlaying
00:03:36 206	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:03:36 206	info	Selected video track: [2]
00:03:36 206	video_buffering_state	BUFFERING_HAVE_NOTHING
00:03:36 207	audio_buffering_state	BUFFERING_HAVE_ENOUGH
00:03:36 211	video_buffering_state	BUFFERING_HAVE_ENOUGH
00:03:36 211	pipeline_buffering_state	BUFFERING_HAVE_ENOUGH
00:03:36 246	seek_target	863.423745
00:03:36 246	pipeline_state	kSeeking
00:03:36 246	audio_buffering_state	BUFFERING_HAVE_NOTHING
00:03:36 246	video_buffering_state	BUFFERING_HAVE_NOTHING
00:03:37 763	pipeline_state	kPlaying
00:03:37 764	audio_buffering_state	BUFFERING_HAVE_ENOUGH


And this is what the video element returns

17:57:21.285 window.document.getElementsByTagName('video')[0].seeking
17:57:21.287 true
17:57:29.189 window.document.getElementsByTagName('video')[0].currentTime
17:57:29.194 863.423745
17:57:33.565 window.document.getElementsByTagName('video')[0].buffered.start(0);
17:57:33.567 826.1
17:57:36.293 window.document.getElementsByTagName('video')[0].buffered.end(0);
17:57:36.295 873.002333

From the logs in #19, it appears that currenTime is not advancing beyond the seek_target yet because the video renderer is still prerolling to reach its first transition to BUFFERING_HAVE_ENOUGH after the seek (Chrome doesn't differentiate have_current vs have_enough at this point in the rendering engine). Do you perhaps have a significantly out-of-order video frame sequence that is delaying the preroll?

Same problem. Custom player, based on Media Source Object.
Chrome 64.0.3282.186, Win7.

Reproduction scheme is the same. 

CurrentTime is in buffered ranges, but video is stuck and "seeking" attr returns "true".

This is still a reproducible issue. Do you have any updates on this topic? Thanks in advance!