Add a very basic played() method

[dmlap]

Expose the played attribute on the HTML5 tech. Add a default implementation of played() to the base tech that tracks whether the video has played at all but doesn't provide valid ranges.

For #2323

[pam]

Tests passed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: CONFIRMED

Commit: f839478
Build details: https://travis-ci.org/pam/video.js/builds/71789788

(Please note that this is a fully automated comment.)

[pam]

Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED

Commit: aa77c10
Build details: https://travis-ci.org/pam/video.js/builds/71795620

(Please note that this is a fully automated comment.)

[pam]

Tests failed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: BUSTED

Commit: 64b785b
Build details: https://travis-ci.org/pam/video.js/builds/71967853

(Please note that this is a fully automated comment.)

[dmlap]

@pam retry

[pam]

Tests passed. Automated cross-browser testing via Sauce Labs and Travis CI shows that the JavaScript changes in this pull request are: CONFIRMED

Commit: 64b785b
Build details: https://travis-ci.org/pam/video.js/builds/71989157

(Please note that this is a fully automated comment.)

[heff]

Why are we not trying to provide a complete fallback implementation? Time constraint or something else?

[dmlap]

The complete fallback seems like it would be pretty complicated. If viewers start seeking, we have to keep track of all the time ranges that have been viewed and then figure out whether new timeupdate events should be "merged" with an existing range or create a new one. This implementation allows you to find out if the video has been played at all (providing similar functionality to vjs-has-started at the tech level) which is really useful.

[heff]

Sounds like a good project for a flight. :) I'm fine with merging this in the mean time.

We could probably build it without trying to manage seeking events. Just have a threshold of closeness, e.g. 2s. If a timeupdate happens within 2s of an existing timerange, extend it, otherwise start a new one. Then have a followup task that does any merging needed.