Over to Internals>Media>Video for triage.

This is not just an issue in Mac, but also Windows as well.

I am not able to reproduce this on Mac using M52 stable or M54 canary, with either H.264 or VP9.

Note that this is the same technique used by YouTube when you press ,/. to advance frames, so this is a generally well-tested path. While it is expected to be slow (it restarts decoding at the previous keyframe every time), the implementation was not changed in M52.

Can you provide your actual test files that reproduce the changed behavior?

These files show the behavior on my system right now. You can use left-arrow or right-arrow to step backwards/forwards or use the STEP buttons on the screen.

Deleted: steptest.zip 42.3 KB

steptest.zip 42.3 KB Download

Thanks, I am able to reproduce the behavior you describe with this test file on Mac. It does not occur with hardware decoding disabled, so we can be sure that the problem is in either the accelerated decoder or the compositing path.

As a workaround, I would try re-encoding with no frame reordering (aka no B frames). Chrome's handling of seek timestamps is much more reliable for such media.

I am not able to reproduce this behavior on Windows 10.

ccameron@: Can you take a look to see if there is a compositing problem here?

May be related to use of AVSamplebufferDisplayLayer, which was in M52, but was disabled at the last minute. Taking a look.

Issue 633581 has been merged into this issue.

After instrumenting the code, it looks like this is a trivial bug around handling flushing in VTVDA. Between when GVD calls Reset() (to start the seek) and when VTVDA notifies that the reset is complete, VTVDA also emits the frames that remain in its reorder buffer.

GVD should be dropping such frames, but I'll fix it in both places tomorrow and see if that resolves the issue.

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

commit 8cbe5d69e18a9c387cfc61adf826ae121cf89834
Author: sandersd <sandersd@chromium.org>
Date: Thu Aug 25 19:04:07 2016

VTVDA: Fix computation of |reorder_window|.

Prior to this change, VTVDA would disable reordering when there was no
VUI max_num_reorder_frames syntax element. This is incorrect; excluding
an explicit list of profiles, it should be MaxDpbFrames.

The incorrect behavior is masked during normal playback, because
decoding is typically faster than rendering. This causes the reorder
queue to fill up even though reordering is supposed to be turned off,
and frames therefore get a chance to be ordered correctly.

BUG= 634007 

Review-Url: https://codereview.chromium.org/2272233002
Cr-Commit-Position: refs/heads/master@{#414499}

[modify] https://crrev.com/8cbe5d69e18a9c387cfc61adf826ae121cf89834/media/gpu/vt_video_decode_accelerator_mac.cc
[modify] https://crrev.com/8cbe5d69e18a9c387cfc61adf826ae121cf89834/media/video/h264_poc.cc

This fix is included in M54, and is available now in the Canary channel.

ffeldman@, can you confirm that the issue is fixed for you in Canary?

I can confirm that the issue looks like it is fixed in M54, when comparing the same web application to M52 on Mac. I do not see the frame-glitch issue on Windows (in either M52 or M54) but in general the frame-stepping performance is slow. If we try the same web app in K-Meleon, for example, on the exact same machine we get much snappier performance. I didn't know if the performance of frame-step would somehow be improved by this fix too. Any ideas? Thanks!

Thanks for testing!

Seek performance in Chrome is almost entirely determined by keyframe density--the media pipeline will seek to the previous keyframe and play forward (preroll) to the requested media time for each currentTime modification.