New issue
Advanced search Search tips
Starred by 50 users

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 105163
issue 106480

Blocking:
issue 72223
issue 310450


Show other hotlists

Hotlists containing this issue:
Top-Starred-Bugs


Sign in to add a comment

canplaythrough is incorrectly fired as soon as the media load begins (http/tests/media/video-play-stall.html)

Reported by m.gre...@gmail.com, Feb 21 2011

Issue description

Chrome Version       : 11.0.672.2 (Official Build 75134) dev
URLs (if applicable) : http://flim.org/~kinetik/tests/bug627153/
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
         Safari 5: OK
   Webkit nightly: OK
      Firefox 3.6: OK
Firefox 4 nightly: OK
             IE 9: OK
        Chrome 11: FAIL
         Opera 11: FAIL

What steps will reproduce the problem?
1. Open test URL provided above
2. Note times that canplay and canplaythrough fire (times display are delta from body.onload in milliseconds)

What is the expected result?
The test URL provided above serves the media via a rate-limited connection at around 40kB/s (approximately half of the media's average bitrate).  It is expected that canplaythrough would fire once enough of the media has downloaded that playback can complete without pausing to buffer.  Given the server's rate limit, the lower bound on firing canplaythrough should be around 80 seconds.

What happens instead?
In Chrome and Opera, canplaythrough fires as soon as the media load begins (or when the media's metadata is loaded).  Testing locally, Chrome is firing canplaythrough after approximately 10s.

This behaviour is resulting in bugs being filed against Firefox (for example, see https://bugzilla.mozilla.org/show_bug.cgi?id=627153) where users request that Firefox fires canplaythrough as quickly as Chrome does.

It's important for canplaythrough to fire at approximately the correct time (that is, when playback may complete without pausing to buffer additional data), otherwise the event is effectively useless.  If users come to expect or depend upon Chrome's behaviour, it may trigger a race to the bottom where other browsers are forced to begin firing canplaythrough very aggressively (or worse, as soon as the media load begins) to meet confused user expectations.
 
Until Chrome has a real implementation of canplaythrough, it would be better for the Web (and more spec compliant) to never fire it instead of always firing it immediately. That should be a simple change.
Labels: -Pri-2 -Area-Undefined Pri-1 Area-WebKit Feature-Media
Status: Available
Labels: -Pri-1 Pri-2 OS-All Mstone-12
We'll take a look but not exactly an easy fix.  Not firing canplaythrough would probably wreck more havoc than patching in a fix.
What about firing canplaythrough after the the video has finished loading instead of when it starts?

The longer this behavior stays in the more likely it is the early firing behavior will be depended on by webpages, which will result in the event being useless.
> What about firing canplaythrough after the the video has finished loading instead of when it starts?

Not a good idea as there is no guarantee that a media file will *ever* load completely.
Related layout test failure: http/tests/media/video-play-stall.html
Labels: OnSkipList LayoutTests

Comment 9 by *sjl@chromium.org, Apr 13 2011

Labels: -Mstone-12 Mstone-13

Comment 10 by mal@google.com, May 13 2011

Owner: *sjl@chromium.org

Comment 11 by *sjl@chromium.org, May 23 2011

Labels: -Mstone-13 Mstone-14
In addition to this, it would appear that the WhatWG and w3c specs have changed since Chrome first implemented the video element and it's "canplaythrough" event. The words used to describe _when_ the "canplaythrough" event should be fired have been changed to no longer imply that it only happens the first time HAVE_ENOUGH_DATA occurs, but in fact everytime this occurs.

This was discovered initially by filing a ticket against Firefox for seemingly firing "canplaythrough" events erroneously: https://bugzilla.mozilla.org/show_bug.cgi?id=664842


Changed wording to spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#event-media-canplaythrough

There is now a ticket filed with whatwg to have the "canplaythrough" event fired _only_ _once_, the first time HAVE_ENOUGH_DATA is reached.


http://www.w3.org/Bugs/Public/show_bug.cgi?id=12982

Comment 14 by m.gre...@gmail.com, Jun 17 2011

Rick, this bug is about when canplaythrough is fired, not how many times it may be fired.  It would be better if you filed a new bug for your issue to avoid any confusion.
Labels: -OnSkipList OnWatchList
Summary: canplaythrough is incorrectly fired as soon as the media load begins (http/tests/media/video-play-stall.html)

Comment 17 by *sjl@chromium.org, Jul 19 2011

Labels: -Mstone-14 Mstone-15
Owner: scherkus@chromium.org
Labels: ImportantForVideo
Cc: -scherkus@chromium.org -vrk@chromium.org -jam...@chromium.org -hclam@chromium.org
Owner: ----

Comment 21 by vrk@chromium.org, Aug 31 2011

Status: Started
Taking this on!

I have a CL (will upload tomorrow) that fires canplaythrough only if:
 - We've loaded/downloaded the entire file, including locally loaded files
 - We've reached the end of playback
instead of firing immediately.

Of course, the above behavior isn't ideal, but it's at least an improvement. Seems like it'd be worth committing as a first step, though we can talk about it if there's disagreement.

My fix doesn't totally fix http/tests/media/video-play-stall.html, but that's because the "waiting" event never gets called, which I believe is a separate issue. It does fix the canplaythrough-related segment anyway!
Owner: vrk@chromium.org

Comment 23 by kareng@google.com, Sep 8 2011

Labels: bulkmove MovedFrom15
moving non-essential bugs to m16. please move back if this was done in error and your bug is a blocker for m15.

Comment 24 by kareng@google.com, Sep 8 2011

Labels: Mstone-16
moving all non-essential bugs from m15. feel free to move back if this was an error and your bug is a blocker for m15. 
Labels: -OnWatchList -LayoutTests -ImportantForVideo -bulkmove -MovedFrom15
not exactly super important for video... but would be nice

Comment 26 by laforge@google.com, Oct 24 2011

Labels: -Mstone-16 MovedFrom-16 Mstone-17

Comment 27 by vrk@chromium.org, Oct 29 2011

Blocking: 72223

Comment 28 by vrk@chromium.org, Nov 1 2011

I have been working on implementing this event "properly" (i.e. disregard my comment #21!) and the work-in-progress CL is here:
http://codereview.chromium.org/8399023/

BUT I've also started a thread on WHATWG proposing the event's removal:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033730.html
Holding off on implementation until the thread is more or less resolved!
The 'canplaythrough' event is useful. Just have a look at when Youtube's FLV player begins playing. Accuracy may be a problem, but it's no deal breaker if the event is fired a bit too soon or too late.

I'm using 'canplaythrough' for <audio> in my game engine ( http://impactjs.com/ ) for the pre-loader. A game typically has a number of sound effects and a music track or two. While the sound effects are quite small, a music track can have several MB and may take a long time to download. 

I want to start the game as soon as possible: that is, as soon as all sound effects have been loaded and the music can play without interuption. Having to wait untill all music files have completely loaded is a waste of the user's time.

My suggestion is this: for small-ish sound files (<10sec or 100kb) fire the 'canplaythrough' event when the sound file is completely loaded. For longer sound files, wait until it "probably" can play through - err on the safe side.
	
Also, since Media elements don't have an onload event, it's easier to listen to 'canplaythrough' instead of going through the whole clusterfuck that is the 'progress' event.

For the record, Chrome 17.0.939.0 canary now refuses to load any Impact made game. Example:
http://playbiolab.com/
Popcorn.js uses "canplaythrough" in almost all of it's code examples. We have a core special event hook called "canplayall" that relies on the first firing of "canplaythrough".
Project Member

Comment 31 by bugdroid1@chromium.org, Nov 18 2011

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=110733

------------------------------------------------------------------------
r110733 | vrk@google.com | Fri Nov 18 11:52:08 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/webmediaplayer_impl.cc?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/webmediaplayer_impl.h?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/webmediaplayer_proxy.cc?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/filters/dummy_demuxer.h?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/buffered_data_source_unittest.cc?r1=110733&r2=110732&pathrev=110733
 A http://src.chromium.org/viewvc/chrome/trunk/src/media/base/download_rate_monitor_unittest.cc?r1=110733&r2=110732&pathrev=110733
 A http://src.chromium.org/viewvc/chrome/trunk/src/media/base/download_rate_monitor.h?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/pipeline_impl.cc?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/filters/ffmpeg_demuxer.h?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/filters/chunk_demuxer.h?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/media.gyp?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/filters/chunk_demuxer.cc?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/demuxer.h?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/pipeline_impl.h?r1=110733&r2=110732&pathrev=110733
 A http://src.chromium.org/viewvc/chrome/trunk/src/media/base/download_rate_monitor.cc?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/pipeline.h?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/buffered_data_source.cc?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/webmediaplayer_proxy.h?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/filters/dummy_demuxer.cc?r1=110733&r2=110732&pathrev=110733
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/mock_filters.h?r1=110733&r2=110732&pathrev=110733

Fire canplaythrough event at the proper time for audio/video

In this CL, the browser fires the canplaythrough event based on an
approximation of the download speed of the media instead of firing the
event right away.

BUG= 73609 
TEST=NONE

Review URL: http://codereview.chromium.org/8399023
------------------------------------------------------------------------

Comment 32 by vrk@chromium.org, Dec 1 2011

Blockedon: 105163

Comment 33 by vrk@chromium.org, Dec 5 2011

Status: Fixed
Marking Fixed; canplaythrough should be fired more accurately in M17.

(The conditions/metrics used to fire the event will likely need tweaking, but we should open other bugs for those problems as we notice them.)

Comment 34 by vrk@chromium.org, Dec 8 2011

Labels: -MovedFrom-16 -Mstone-17 Mstone-18
Status: Started
Reopening this up...

This is causing enough problems that it should be at least punted to M18, but it may even get punted indefinitely until we clear up some of the resource loading issues that are making this way harder than it should be to implement (e.g. see  issue 106800 ). Will update bug if the situation turns out that way.

Comment 35 by vrk@chromium.org, Jan 18 2012

CL to fix properly is here:
http://codereview.chromium.org/9113023/

But that can't land until after this WebKit CL lands:
https://bugs.webkit.org/show_bug.cgi?id=76568

(but both are LGTM/r+ed so should happen soon!)
Project Member

Comment 36 by bugdroid1@chromium.org, Jan 20 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=118546

------------------------------------------------------------------------
r118546 | vrk@google.com | Fri Jan 20 15:42:21 PST 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/webmediaplayer_impl.cc?r1=118546&r2=118545&pathrev=118546
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/download_rate_monitor.cc?r1=118546&r2=118545&pathrev=118546
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/buffered_data_source.cc?r1=118546&r2=118545&pathrev=118546
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/buffered_data_source_unittest.cc?r1=118546&r2=118545&pathrev=118546
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/download_rate_monitor_unittest.cc?r1=118546&r2=118545&pathrev=118546
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/download_rate_monitor.h?r1=118546&r2=118545&pathrev=118546
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/pipeline.cc?r1=118546&r2=118545&pathrev=118546

Fire canplaythrough as soon as download defers to fix autoplay

Reenables delayed firing of canplaythrough for media elements, and fixes
the bug that had been introduced where a video with autoplay=true sometimes
never starts. With this change, a video with autoplay=true should always
(though not necessarily immediately) start playback on its own.

BUG= 106480 , 73609 
TEST=media_unitests, manually checking video files in various conditions

Review URL: https://chromiumcodereview.appspot.com/9113023
------------------------------------------------------------------------
Project Member

Comment 37 by bugdroid1@chromium.org, Jan 21 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=118590

------------------------------------------------------------------------
r118590 | sadrul@chromium.org | Fri Jan 20 18:58:18 PST 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/webmediaplayer_impl.cc?r1=118590&r2=118589&pathrev=118590
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/download_rate_monitor.cc?r1=118590&r2=118589&pathrev=118590
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/buffered_data_source.cc?r1=118590&r2=118589&pathrev=118590
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/media/buffered_data_source_unittest.cc?r1=118590&r2=118589&pathrev=118590
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/download_rate_monitor_unittest.cc?r1=118590&r2=118589&pathrev=118590
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/download_rate_monitor.h?r1=118590&r2=118589&pathrev=118590
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/pipeline.cc?r1=118590&r2=118589&pathrev=118590

Revert 118546 because it caused PrerenderHTML5VideoNetwork to timeout on windows and linux

"""
Fire canplaythrough as soon as download defers to fix autoplay

Reenables delayed firing of canplaythrough for media elements, and fixes
the bug that had been introduced where a video with autoplay=true sometimes
never starts. With this change, a video with autoplay=true should always
(though not necessarily immediately) start playback on its own.

BUG= 106480 , 73609 
TEST=media_unitests, manually checking video files in various conditions

Review URL: https://chromiumcodereview.appspot.com/9113023

TBR=vrk@google.com
Review URL: https://chromiumcodereview.appspot.com/9269027
------------------------------------------------------------------------

Comment 38 by vrk@chromium.org, Jan 26 2012

Blockedon: 106480
Labels: -Mstone-18 Mstone-19
Blocked on  issue 106480 .

Comment 39 by vrk@chromium.org, Feb 1 2012

Labels: -Mstone-19 Mstone-20
Status: Assigned
Can't work on this for this Mstone. Punting to M20.
Labels: -Mstone-20 bulkmove MovedFrom-20 Mstone-21
If this is still need to be part of M20, punt back.
Project Member

Comment 42 by bugdroid1@chromium.org, May 11 2012

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=136500

------------------------------------------------------------------------
r136500 | tkent@chromium.org | Thu May 10 21:14:24 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/media.gyp?r1=136500&r2=136499&pathrev=136500
 A http://src.chromium.org/viewvc/chrome/trunk/src/media/base/download_rate_monitor.cc?r1=136500&r2=136499&pathrev=136500 (from /trunk/src/media/base/download_rate_monitor.cc revision 136485)
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/pipeline.h?r1=136500&r2=136499&pathrev=136500
 A http://src.chromium.org/viewvc/chrome/trunk/src/media/base/download_rate_monitor_unittest.cc?r1=136500&r2=136499&pathrev=136500 (from /trunk/src/media/base/download_rate_monitor_unittest.cc revision 136485)
 A http://src.chromium.org/viewvc/chrome/trunk/src/media/base/download_rate_monitor.h?r1=136500&r2=136499&pathrev=136500 (from /trunk/src/media/base/download_rate_monitor.h revision 136485)
 M http://src.chromium.org/viewvc/chrome/trunk/src/media/base/pipeline.cc?r1=136500&r2=136499&pathrev=136500

Revert 136486 - Delete DownloadRateMonitor since it's never worked right.
(and it complicates other things I want to do)

LayoutTests/media/video-error-does-not-exist.html crashes by r136486.

BUG= 73609 

Review URL: https://chromiumcodereview.appspot.com/10382109

TBR=fischman@chromium.org
------------------------------------------------------------------------
Labels: -bulkmove -MovedFrom-20 -Mstone-21 Mstone-22
Owner: ----
Status: Available
Labels: -Feature-Media Feature-Media-Network
Labels: -Mstone-22 Mstone-23
bulk punt of available bugs from 22 -> 23
Labels: -Mstone-23

Comment 48 by m...@brad.is, Oct 11 2012

Any updates on the status of this issue?

Comment 49 by anandc@google.com, Nov 2 2012

This bug is causing a failure in the http/tests/media/video-play-stall.html layout-test. Any update on the milestone when this is expected to be fixed? Thanks. 

Comment 50 by amdfc...@gmail.com, Feb 15 2013

bump.
Project Member

Comment 51 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-WebKit -Feature-Media-Network Cr-Content Cr-Internals-Media-Network
Project Member

Comment 52 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
This continues to cause Web compatibility issues; Web sites depend on Chrome's (mis)behavior and are broken in Firefox as a result. See https://bugzilla.mozilla.org/show_bug.cgi?id=933856 for example.

Please be a good Web citizen and either implement canplaythrough properly or drop support for it completely.
rocallahan: Chrome Canary & Dev channel will fire canplaythough multiple times because we now transition to HAVE_METADATA on seek as well. I've been working on fixing our readyState behavior as part of  Bug 144683  

Comment 55 by zve...@gmail.com, Jun 16 2014

Still firing as soon as "canplay" does as illustrated in the original example: http://flim.org/~kinetik/tests/bug627153/

This even should behave as defined in the specs, now that more and more multimedia is used in websites. Not having this event cripples having great multimedia heavy UIs with correct user feedback when video is ready to play. 

Original spec: "The user agent estimates that if playback were to be started now, the media resource could be rendered at the current playback rate all the way to its end without having to stop for further buffering."

Currently the event just fires immediately, while the behavior is correct in Firefox/Safari.

Are there any suggestions to implementing a shim/library to emulate the behavior like in Safari/Firefox using the buffered object?
3 years later..

Comment 57 by Deleted ...@, Aug 14 2014

Any progress on this?
Cc: acolwell@chromium.org scherkus@chromium.org
Owner: vrk@chromium.org
->vrk again since she did the last real work on this and could hopefully triage.
+CC acolwell due to sounding informed in comment 54, and scherkus as a backstop.

Can we do something about this bug?  The implication (to me) of comments 36/37 is that this is fixable but we backed the fix out and never re-landed it.

Causing web compat problems for other browsers is uncool, and I get the impression this has just fallen through the cracks.
Cc: -acolwell@chromium.org
Owner: dalecur...@chromium.org
acolwell/vrk don't work on this stuff anymore :(

However dalecurtis has some ideas/plans for revamping our networking code. There may also be some sort of shorter term fix we can do.
Cc: -scherkus@chromium.org
Labels: -Pri-2 Pri-1
Status: Assigned
I agree with the comment in https://code.google.com/p/chromium/issues/detail?id=73609#c53.  It's our responsibility to help enable interoperability here.  Web deva coding for Chrome's bugs hurts our big picture web platform goals.  Can we bump the priority of this?
Labels: -Pri-1 Pri-2 M-46
Owner: hubbe@chromium.org
Bumping priority without a milestone doesn't mean anything, so I've given it M46. hubbe@ has taken over my work on the src= cache improvements, once those are stabilized we'll look into changing this to reflect the current spec.
Hmm, what is the expected behavior if we fill up our preload buffer, but still estimate that we don't have enough to play through to the end without interruption?

I'm not sure, we'll need to consult the whatwg and w3c HTML5 media specs and choose a behavior if they differ.  The above comments seem to indicate we should never fire canplaythrough.
In Gecko we take the approach that canplaythrough will always be fired eventually. So if we stop the download for some reason (e.g., our cache is full), we'll go directly to HAVE_ENOUGH_DATA.
I'm not sure if it's a separate bug or not, but Chrome also fires canplay prematurely in some cases. For example if you have a video with preload="metadata", that shouldn't really fire "canplay" or "canplaythrough" since it shouldn't decode more than one frame, but Chrome fires both.
Labels: Hotlist-Interop

Comment 68 by phil...@opera.com, Jul 14 2015

Blocking: chromium:310450

Comment 69 by phil...@opera.com, Jul 14 2015

I've marked this as block  issue 310450 , because if preload="metadata" reaches a higher readyState than HAVE_CURRENT_DATA, making that the default will likely make it harder to fix this bug.

hubbe@, if you're working on fixing this, have you seen the related discussion on the WHATWG list? I think we could "fix" this inside Blink by clamping if it's too much work to fix every WebMediaPlayer implementation at this point.

Comment 70 by hubbe@chromium.org, Jul 14 2015

I was assigned this bug because I'm working on something tangential, I have not done anything to work on this bug specifically yet. Changing the behavior or our side seems relatively easy, given a good definition of how it *should* behave...


Project Member

Comment 71 by bugdroid1@chromium.org, Jul 15 2015

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=198955

------------------------------------------------------------------
r198955 | philipj@opera.com | 2015-07-15T13:47:12.333230Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/HTMLMediaElement.cpp?r1=198955&r2=198954&pathrev=198955
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/HTMLMediaElement.h?r1=198955&r2=198954&pathrev=198955
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/frame/UseCounter.h?r1=198955&r2=198954&pathrev=198955

Measure usage of HTMLMediaElement preload states

Refactoring into a preloadType() is necessary in order to count cases
where the preload attribute is never set, i.e. the missing value default
case. Also, it's nice to have less state in HTMLMediaElement.

BUG= 73609 ,  310450 

Review URL: https://codereview.chromium.org/1227403004
-----------------------------------------------------------------
Labels: StaleAssigned
this bug has no update since 8/1/2015. If you think it is worth to keep, please replace StaleAvailable label with StaleKeep. If no action is taken, this bug will be resolved by 3/31/2016. Thanks
Still a bug as far as I know
Labels: -StaleAssigned StaleKeep
Components: -Blink Blink>Media
Labels: Needs-BlinkMediaTriage
This is still a problem in Chrome v53. I see the 'playing' event fire 270-1100 msec before any sound leaves the speakers. This happens when I use WAVs in an audio element with preloaded=auto, so there is no network delay. I haven't seen it with preloaded OGGs nor MP3s, but another Chrome bug (https://bugs.chromium.org/p/chromium/issues/detail?id=158245#c47) prevents me from using those.
I'm not sure it makes sense to fix this bug. Here is why:

1. It's fairly complicated to get this right, and even when you're right, there are no actual guarantees that the download speed will be fast enough in the future. So anybody who really cares about not getting any glitches in playback should just download the whole media. (somehow)

2. Chrome generally never preloads more than 10 seconds of media, after that we stop or pause downloads and wait for playback to catch up. So "canplaythrough" would never work as intended in chrome for long media.

What about streams?
Streams aren't any different, except we might not know how long they are, in which case we *really* can't figure out when to fire canplaythrough accurately.

I understand that you can't predict whether enough bytes will arrive to
avoid stutter.

My complaint about this bug, stated in comment 77, is that the 'playing'
event fires long before any sound leaves the speakers. Surely this aspect
is fixable.
I am not sure comment 77 is directly related to this issue - just file an issue for it (if you cannot find an existing one, obviously). You can comment here with the issue number.
We don't 100% know when audio will leave the speaker. Probably we could make the estimate better, but you'll never get it perfect for the first frame of audio.
The problem I reported in comment 77 now has its own bug, because it was suggested here that I do that: https://bugs.chromium.org/p/chromium/issues/detail?id=671765&q=
Project Member

Comment 85 by bugdroid1@chromium.org, Feb 21 2017

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

commit 1c34d25f88bf52dd34b4047b8218be96096ba9bc
Author: yhirano <yhirano@chromium.org>
Date: Tue Feb 21 06:33:09 2017

Mark http/tests/media/video-play-stall.html as flaky

BUG= 73609 
TBR=hubbe@chromium.org
NOTRY=true

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

[modify] https://crrev.com/1c34d25f88bf52dd34b4047b8218be96096ba9bc/third_party/WebKit/LayoutTests/TestExpectations

Status: Started (was: Assigned)
Project Member

Comment 87 by bugdroid1@chromium.org, May 5 2017

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

commit b2d3efd2ec18ffd52c3dacfece9862366b565a3d
Author: hubbe <hubbe@chromium.org>
Date: Fri May 05 23:26:38 2017

fix canplaythrough

This makes canplaythrough follow the spec.
It fires when we estimate that we have enough data to play to the
end, or when we stop downloading because the buffer is full.

We do this by keeping a time series in BufferedDataSourceHostImpl
which is used to estimate the download speed over the last 10 seconds.

BUG= 73609 

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

[modify] https://crrev.com/b2d3efd2ec18ffd52c3dacfece9862366b565a3d/media/base/media_switches.cc
[modify] https://crrev.com/b2d3efd2ec18ffd52c3dacfece9862366b565a3d/media/base/media_switches.h
[modify] https://crrev.com/b2d3efd2ec18ffd52c3dacfece9862366b565a3d/media/blink/buffered_data_source_host_impl.cc
[modify] https://crrev.com/b2d3efd2ec18ffd52c3dacfece9862366b565a3d/media/blink/buffered_data_source_host_impl.h
[modify] https://crrev.com/b2d3efd2ec18ffd52c3dacfece9862366b565a3d/media/blink/buffered_data_source_host_impl_unittest.cc
[modify] https://crrev.com/b2d3efd2ec18ffd52c3dacfece9862366b565a3d/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/b2d3efd2ec18ffd52c3dacfece9862366b565a3d/media/blink/webmediaplayer_impl.h
[modify] https://crrev.com/b2d3efd2ec18ffd52c3dacfece9862366b565a3d/media/blink/webmediaplayer_impl_unittest.cc

hubbe@, I see that this is behind a flag. What's the plan towards turning this on by default?
Cc: mlamouri@chromium.org
Labels: -Needs-BlinkMediaTriage

Comment 91 by hubbe@chromium.org, May 11 2017

The plan is to first run an canary experiment and watch a few key metrics to make sure it behaves the way we want to and doesn't cause any surprises. After that I think we'll probably just default the flag to on and let it roll out at normal speed. (And if something blows up we'll use an experiment to turn it off.)

Project Member

Comment 92 by bugdroid1@chromium.org, May 17 2017

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

commit 7272b31c2cd71e1ef2f1b0161920d2e040eb5424
Author: hubbe <hubbe@chromium.org>
Date: Wed May 17 04:56:42 2017

Autoplay time metric

We're going to run an experiment to make the "canplaythrough" event fire according
to spec instead of at the same time as "canplay" this will sometimes delay autoplay,
and we want to know how much, so let's add a metric for that.

BUG= 73609 

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

[modify] https://crrev.com/7272b31c2cd71e1ef2f1b0161920d2e040eb5424/third_party/WebKit/Source/core/html/HTMLMediaElement.h
[modify] https://crrev.com/7272b31c2cd71e1ef2f1b0161920d2e040eb5424/third_party/WebKit/Source/core/html/media/AutoplayUmaHelper.cpp
[modify] https://crrev.com/7272b31c2cd71e1ef2f1b0161920d2e040eb5424/third_party/WebKit/Source/core/html/media/AutoplayUmaHelper.h
[modify] https://crrev.com/7272b31c2cd71e1ef2f1b0161920d2e040eb5424/tools/metrics/histograms/histograms.xml

Project Member

Comment 93 by bugdroid1@chromium.org, Jun 8 2017

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

commit e3338722a11a1b0cac7b4a189532bbf52b34193c
Author: hubbe <hubbe@chromium.org>
Date: Thu Jun 08 21:32:05 2017

Enable spec-compliant canplaythrough event by default

The results from this study are in. As expected, Media.Video.Autoplay.Attribute.WaitTime goes up, by up to 10%. In return we get a bigger than expected positive impact on Media.UnderflowDuration and Media.MeanTimeBetweenRebuffers.AudioVideo.SRC.
Going to default this feature to ON, but leave the flag in place for one release in case we need to revert it for any reason.

BUG=725576,  73609 

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

[modify] https://crrev.com/e3338722a11a1b0cac7b4a189532bbf52b34193c/media/base/media_switches.cc

Thank you hubbe@, very excited to see this fixed! :) Should we close the bug? :)
Status: Fixed (was: Started)
I think so...
Labels: TE-Verified-M61 TE-Verified-61.0.3128.0
Verified this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.5 using chrome latest dev #61.0.3128.0. By playing the video http://flim.org/~kinetik/tests/bug627153/ observed canplaythrough fire only once after the video has played completely as expected. Hence adding TE-Verified label.

73609.png
200 KB View Download
Hubbe, can we revert the CL marking of this test as flaky (times out)?

(https://bugs.chromium.org/p/chromium/issues/detail?id=73609#c85)

Comment 98 by hubbe@chromium.org, Aug 10 2017

No idea.

Sign in to add a comment