Media elements should support a rational time value for seek()

Using floating point time values when seeking is inherently imprecise. Specifically, authors attempting to precisely seek to the beginning of a specific video frame will often find that they have seeked to the end of the previous video frame. This is due to rounding errors when converting from double-width floating point values used by JavaScript to the rational integer values used by media file formats.

Double-width floating point values can accurately represent integers up to 2^52. So a rational integer time value can be represented by two JavaScript numbers so long as those numbers are both smaller than 2^52.

Building off of @foolip's work in issue #553, rational time seeking could be supported by adding an optional timeScale parameter to the SeekOptions, which defaults to 1 if absent.

An author with a 29.97 fps video file could then accurately seek to the 30th frame by issuing:

video.seek(30 * 1001, { mode: "precise", timeScale: 30000 });

Left unspecced for now is how the author would determine the correct time scale for the movie or track. For the current proposal, the time scale could be provided out of band.

Start by reading issue #553 and the existing SeekOptions and media seeking specification text. The proposal centers on an optional timeScale for precise seeking, while determining the correct movie or track time scale remains unresolved. Done means the behavior and time-scale handling are specified clearly enough to implement.