Tested this issue on windows 10 with chrome #57.0.2987.133, #58.0.3029.81 
Observed that video is played continuously for 40 sec without any freezes.

Attaching the screen-cast for reference,

coolcmd@ Could you look into it and let let us know any steps i have missed while reproducing the scenario.

Thank You...

Deleted: Issue 710856.mp4 5.5 MB

	Issue 710856.mp4 5.5 MB View Download

> Observed that video is played continuously for 40 sec without any freezes.
at 0:41 in your screen-cast, i see that the picture froze in 4 seconds.

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

I could repro this bug. It is not a regression though. enable/disable GPU decoding makes no difference. There are quite a few glitches on both video and audio. And the video/audio completely freeze on 33:40 timestamp.
Dale, can you assign appropriately?

I suspect this is something that hubbe@ fixed / made better in M58. I'm not able to repro, but coolcmd@ can you try Chrome Canary and see if this is resolved?

> but coolcmd@ can you try Chrome Canary and see if this is resolved?
I tried to run in version 60.0.3080.5 (Official Build) canary (64-bit)
The issue is still present.

> It is not a regression though.
I did not encounter this issue in the old Chrome versions.

> enable/disable GPU decoding makes no difference.
On my machine issue never happen if GPU decoding is disabled.
Windows 7, Windows 10, NVIDIA GTX 770

> There are quite a few glitches on both video and audio.
Every 4 seconds, very short. This is normal.

> And the video/audio completely freeze on 33:40 timestamp.
This is normal.

Ah, I mistakenly thought this was a src=video when it's mse +matt,chris.

H.264 videos still freeze up randomly with Chrome on Windows (when loaded using an HTML5 <video> tag). Is there an ETA for a fix?

Disabling hardware acceleration for video playback appears to have no impact on this issue.

Taking a look

I haven't reproed it yet, but I have a theory about the cause...

When chrome is playing video+audio, it will not immediately pause the video for under-flow if it still has audio to play. It will allow audio to play with video frozen for up to 3 seconds (suspiciously close to your 4 second observation above). This is intentional, as a way of smoothing over momentary hiccups in video. 

With MSE, it is possible that you can append a chunk that temporarily advances the audio timeline beyond the video timeline. In most cases the next chunk will catch up video. Glancing at your demo script, I see some intentional delays between xhrs, which increase the likelihood that your currentTime will run up against the end of what you've buffered, potentially passing the end of buffered video while playing through a tiny bit more buffered audio.

Again, no repro yet - just a theory. Matt, LMK if this sounds reasonable. 

> This is a serious problem. In a real application, "freeze" often occurs at the beginning of playback and remains until the user reloads the page.

This theory does not address this "real" scenario. Its possible my theory is wrong. Also possible the "real" freeze has a different cause. Will update as learn more. 

#11 had a bunch of typos... I'll try again:

@#10 Your theory makes sense -- a video stall that is not un-stalled by appending video into the timeline where stall occurred will indeed retain video stall state until explicit seek is done (or endOfStream() is done - though that is discouraged if the app is not really done appending media to element due to known bug 530698). 

This is because the video decoder is still waiting for media from the video timeline adjacent/continuous with the last thing it decoded.

I'm not sure what's going on w.r.t. stall at beginning; in such a repro, is it ever the case that *no* video is decoded, yet audio plays?

Regardless, what does the media element's "buffered" attribute report when there's a repro? It's working as intended if gaps in the intersected audio+video buffered timeline appear in that attribute and consequent playback stall occurs at the beginning of such a gap. Note that we don't stall audio if it is continuous itself across such an intersection range gap, though perhaps we should consider doing that...

And in #12, endOfStream() won't always un-stall video -- it'll just let the video know that it's ended iff it has started decoding the last video buffer in the last video range -- if video is stalled at the beginning of a gap in some previous video range, endOfStream() *won't unstall video* in that case.

Video will immediately stall if there is no video buffered beginning within the first ~1000ms of the video timeline (and no seek to some other time is attempted). That might explain the rest of the theory.

> Disabling hardware acceleration for video playback appears to have no impact on this issue.
partially. without HW decoding, this issue is appearing MUCH less often. i think this is the clue for the developers.

here is a NEW testcase to easily reproduce issue:
https://drive.google.com/open?id=0B8rMkU05qoZMRzlGWlA3R0phWDA

the video freezes IF you pause() while (buffer_duration > 0 && buffer_duration < magic_number).
i think, magic_number == size of the buffer that holds the decoded frames.
in case the HW decoding is turned off, the size == may be 1-2 frames.
in case the HW decoding is turned on, the size on Windows == may be 4-5 frames in "low delay" mode. (4*16=64 ms)
i think, developers forget "something" on pause(), regarding to flushing buffer.

some more information about the testcase. video is "unfreezes" on the next pause()+play(). after that, all unplayed frames  are playing back in "fast-forward" mode. the Chrome has another issue, than video glitches after playing back some time on inactive tabs. symptoms are the same, so i think both issues have one cause.

>It will allow audio to play with video frozen for up to 3 seconds
if i remember right, my issue reproducible without audio.

see PAUSE_IF_BUFFER_DURATION_BELOW in coolcmd3.js for magic_number.

=> chcunningham@ per #9. Assign back to me if needed.

Sorry for slowness here - will take another look tomorrow morning.

Dale, 

I think I've tracked this bug to some faulty logic in VideoRendererImpl. Specifically, this early return in VRI::OnTimeProgressing() is preventing us from restarting the sink when the demo calls <video>.play() because the algorithm queue is empty.

https://cs.chromium.org/chromium/src/media/renderers/video_renderer_impl.cc?rcl=f750e5a9ad2bea7f48243fa1a8bfc54620884e85&l=427

Can you tell me what scenario these lines are supposed to be invoked in? How should we separate that from the scenario we're actually in (details below).

The reporter's demo appends mp4 chunks to MSE *while playing*. Between each chunk, the demo calls <video>.pause() and then almost immediately calls <video>.play().

What I think is happening:
1. VRI transitions to HAVE_NOTHING as the playback reaches the end of the most recently appended chunk
     The parent RendererImpl defers the transition, as audio still has some buffer.
2. The app calls <video>.pause() 
     VRI seems to wrongly take this to mean that the underflow caused the pause. "Increased min buffered frames..."
3. The app appends a new chunk (4.mp4) and calls <video>.play()
     RendererImpl::SetPlaybackRate(1) leads to VRI::OnTimeProgressing, BUT we never start the sink because aglo has no buffered frames

Log snip for the above:
https://paste.googleplex.com/4989219751591936


Seems both VRI::OnTimeProgressing and VRI::OnTimeStopped make incorrect assumptions about whats caused them to be invoked.

Clarification: RenderImpl defers the transition in step 1 above, but that deferral is ultimately cancelled - new data arrives (new chunk append) before the deferral timer fires.

Also, I observed all of this on linux - didn't have to run on windows or mess w/ hw decode. 

The video freezing (video sink not calling Render(), but audio continues playing) happens ~2 times over the course of the demo. It does not always repro at the same point in the playback. We have to get unlucky about underflow/pause racing.

Demo running here:
http://chcunningham-linux.sea/freezy/v3/

Hmm, my expectation is that RendererImpl will eventually trigger the deferred HAVE_NOTHING and thus pause playback. Later VRI should transition to have enough once enough reads complete.

I think what might be happening is:
1. our video buffer is completely full
2. we get a pause call and wipe that entire buffer since the frames are not effective (too far behind)
3. the deferred have_nothing eventually triggers and waits for have_enough.

We then never leave have_enough because we hadn't scheduled a read callback.

I think what we probably need to do is the following:
1. RendererImpl::SetPlaybackRate() should immediately fire any deferred buffering states, which should set |time_ticking_| to false in the underflow case and thus prevent OnTimeStopped/OnTimeProgressing from being called within SetPlaybackRate.
2. VideoRendererImpl::OnTimeStopped() should call AttemptRead_Locked() within the HAVE_NOTHING check after culling frames. This will do nothing if there is nothing to be done.

I think that might solve the issues.

I believe I experienced this issue and will link my media player log below. Video was loaded from cache (blob: url).

Notable events in log:
00:00:03 961: Video loads and pauses on first frame for ~ 2:30
00:02:42 988: play and pause pressed to attempt to restart video
00:04:41 542: seek forward in video and press play again, video plays

https://docs.google.com/document/d/1EfMeUDNbDn8PWxIXirAL8lQxJ-zww1Pnjha6Rw1dFuA/edit

Any updates on this issue? Or if my media player log above indicates the same behavior as the initial report?

Sorry, still on my radar but I've not had a chance to implement the workaround. 

Unfortunately, the log you provided doesn't have enough granularity to be certain you're hitting the exact same issue. If you have a repro URL I can take a closer look. 

@chcunningham https://pwtvboudreaux.arreya.com is the URL I am able to replicate it on. So far I've observed the issue on the ASUS Chromebit (Mickey). 

The repro URL is a slideshow of videos, ~15 minutes after opening that URL, a video will pause a few seconds into playing. Video controls/media player log show the video is still in 'play' state but the video is no longer playing.

Others have been running that site for issue 761852 for hours on end without hangs on Mickey. On Linux I've had it going for a few hours now without any issues. I think there may be some CrOS specific issue with memory leaks there.

I think my statement in c#21 still stands, but I'm beginning to suspect that's not the same as your issue.

The repro URL has changed to https://disabled-pwtvboudreaux.arreya.com/