New issue
Advanced search Search tips

Issue 868092 link

Starred by 2 users
Status: Available
Owner: ----
Cc:
xhw...@chromium.org
dalecur...@chromium.org
mlamouri@chromium.org
foolip@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Timeupdate events are triggered during preroll

Project Member Reported by jiaqzhao@google.com, Jul 26 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce the problem:
https://yt-media-test.appspot.com/2019.html?tests=24,25

These tests could fail because it's using the currenttime from the first timeupdate as a base.

What is the expected behavior?
Timeupdate event is not triggered if currenttime stays 0

What went wrong?
During preroll, couple timeupdate events could be triggered when currenttime stays 0.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 67.0.3396.99  Channel: n/a
OS Version: OS X 10.13.6
Flash Version:

Comment 1 by xhw...@chromium.org, Jul 26

Cc: xhw...@chromium.org dalecur...@chromium.org mlamouri@chromium.org
Components: Internals>Media
Status: Available (was: Unconfirmed)
+mlamouri and dalecurtis

According to the spec [1], it seems timeupdate should only be fired when the current playback position has been changed. So we should only see one timeupdate event with currenttime being 0 during preroll?

[1] https://www.w3.org/TR/2011/WD-html5-20110113/video.html#event-media-timeupdate

Comment 2 by dalecur...@chromium.org, Jul 26

Cc: foolip@chromium.org
Hmm, I thought blink filtered these out when they're equivalent.

https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/media/html_media_element.cc?l=3214

...but it doesn't look like it. Probably we should not generated the event if the time is the same as last poll?

Comment 3 by marcin.z...@gmail.com, Jul 27 

I'm not sure there should be any timeupdate events for currentTime 0 for a new player. The event should be scheduled, if the currentTime _changes_ and I do not see any change _to_ zero at the start of player's lifetime.

And anyway, with regards to tests 24 and 25, if there was even one zero-currentTime timeupdate and preroll would still take 300ms from that point on, any other measurements done by this test would probably be off by those 300ms. For example, for 300ms preroll and first time update reported after, let's say two frames:

1532683150.345s - 0.0s == 1532683150.345s
1532683150.645s // playback starts
1532683150.728s - 83ms == 1532683150.645s
1532683150.645s - 1532683150.345s == 300ms

and the test would fail.
►

Sign in to add a comment