Open Bug 1229631 Opened 4 years ago Updated 4 years ago

More accurately determine when we can fire canplaythrough

Categories

(Core :: Audio/Video: Playback, defect, P5)

defect

Tracking

()

Tracking Status
firefox45 --- affected

People

(Reporter: jya, Unassigned)

References

(Blocks 1 open bug)

Details

In bug 1194624, the basic on conditionally checking when canplay and canplaythrough would be fired.


From the spec: http://w3c.github.io/media-source/index.html#buffer-monitoring

"Having enough data to ensure uninterrupted playback is an implementation specific condition where the user agent determines that it currently has enough data to play the presentation without stalling for a meaningful period of time. This condition is constantly evaluated to determine when to transition the media element into and out of the HAVE_ENOUGH_DATA ready state. These transitions indicate when the user agent believes it has enough data buffered or it needs more data respectively."

and in particular:
"An implementation may choose to use bytes buffered, time buffered, the append rate, or any other metric it sees fit to determine when it has enough data. The metrics used may change during playback so web applications should only rely on the value of HTMLMediaElement.readyState to determine whether more data is needed or not."

in bug 1194624 the logic is very basic, only looking at the amount of data buffered ahead.

We could add some statistics such as the progress rate of the buffered range over time, or how fast the appendBuffer are being called etc...

It would still an approximation, but would give a more useful picture on whether we can play to the end without interruption or not.
Priority: -- → P2
as it is, it works well enough as far as i can tell.

doing anything more is far from trivial and may be too much effort for the potential gain
Priority: P2 → P5
You need to log in before you can comment on or make changes to this bug.