Able to reproduce the issue and is a regression broken in M49 builds. Below are the bisect details:

Bisect Info:
============
49.0.2568.0 - Good Build
49.0.2569.0 - Bad build

Change Log: https://chromium.googlesource.com/chromium/src/+log/49.0.2568.0..49.0.2569.0?pretty=fuller&n=10000

Note: Unable to load the Video using the bisect script by appending the Flash Plugin command. Other flash videos works fine using the script. issue is only with the Video"http://brokedown.net/videotest.html" . A black empty player is displayed on chromium builds. Hence not able to provide a narrow bisect. Tried the same on multiple MAC machines. Also issue is specific to MAC OS. Works fine on Windows and Linux OS

Suspecting change #360665 as a possible culprit. Below is the Revision URL:

Change URL: https://chromium.googlesource.com/chromium/src/+/3d35a73c1d6e540ca01da4e38777b3222301b603

@ mcasas: Requesting you to please take a look into it. Please help us to find a possible owner or culprit from the above change log if not with respect to your change.

Removing bisect label. Thanks.!

xhwang@ I think my CL is innocent, can you help triage?

ranjitkan: Is this Mac only? Did you try other platforms like Windows or Linux?

If it's mac only, is it possible that this is related to sandersd's CL?

https://chromium.googlesource.com/chromium/src/+/07c07c368ccf43348058f771e95759b58921d6cc

Works on Linux for me, and I don't see anything obviously wrong with the stream itself. I do see that new frames are being rendered each time I switch tabs, so it may be compositing related.

ccameron: Does this look related to your recent changes?

I checked the usual compositing culprits (damage tracking, overlays, etc), and none of them fixed the issue. I suspect the issue is in decode. Let me know if you want me to take another look.

Surprisingly, it doesn't look like there is actually a bug here. What's actually happening is that the decoder is taking longer than 100ms to decode the frames, and so the next seek aborts them. Simply increasing the delay fixes that.

If you want to be sure that a frame is displayed before seeking again, you should wait for the 'seeked' event to fire.

(Unrelated, but autoplay="no" actually enables autoplay. You should remove the attribute entirely.)

I'll leave this bug open while I investigate to determine if there is a performance bug, but it will likely be closed as WAI.

I've created a quick modification to display average seek time, using the "seeked" event as suggested to increment to the next frame, playing the same video as quickly as possible. On my wimpy little Samsung S3 Chromebook, I'm averaging under 30ms per frame. I won't have access to my Mac until later today, but I'll repeat the test there and report back. I'll try to track down a Chromium 48.x build to compare against.

http://brokedown.net/videotest2.html

(Unrelated, thanks for the autoplay note, I missed that it was bool)

I have a proposed improvement to seek performance at https://codereview.chromium.org/1882533002/. I don't think you'll find a huge difference in Chrome versions that use hardware accelerated decode, as the code that recreates the decoder on seek has been in every version.

I don't know the exact use case for your code, but in general I would suggest using literally any other combination of hacks if you can't always control how often keyframes are; seeking can be very expensive in general.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dc5535cdd973f0bc70f258afb52bde49b3e37ab5

commit dc5535cdd973f0bc70f258afb52bde49b3e37ab5
Author: sandersd <sandersd@chromium.org>
Date: Tue Apr 12 21:03:28 2016

Don't force a full decoder reset on seek in VTVDA.

Instead, set a flag (|waiting_for_idr_|), and wait for the next IDR
before using the current configuration again (including for POC
computation). This allows us to re-use the same decoder if the config
has not actually changed.

BUG= 601892 

Review URL: https://codereview.chromium.org/1882533002

Cr-Commit-Position: refs/heads/master@{#386803}

[modify] https://crrev.com/dc5535cdd973f0bc70f258afb52bde49b3e37ab5/content/common/gpu/media/vt_video_decode_accelerator_mac.cc
[modify] https://crrev.com/dc5535cdd973f0bc70f258afb52bde49b3e37ab5/content/common/gpu/media/vt_video_decode_accelerator_mac.h

So a few notes...

Using my avg framerate measurement at http://brokedown.net/videotest2.html , I see these results:
. Safari 9.1 is averaging about 8ms
. Chrome 49 is averaging about 125ms
. Firefox is averaging about 17ms
. Chrome 49 *with hardware acceleration disabled* is averaging about 34ms

The times for Safari, Firefox, and Chrome with hw accel disabled were from them running on screen simultaneously.


By comparison, Chrome 49 on my home Linux desktop takes about 10ms, and my rather slow Windows 10 desktop is running about 31ms.

This video (and my actual use case, which involves accurate seeking around in videos) uses keyint=2, which is absurdly high if you're not trying to seek around quickly and accurately.. But it's worth that size penalty since I am. Seeking has been very reliable otherwise, much moreso than the other methods I've tried. 

Please test again using Chrome Canary, which has the change from #11.

This is night and day better. Average frame time has dropped from 125ms to 21ms! This appears to solve my problem.