Bug 22678 - <video>: expose the frame rate and specific frames of the media resource
Summary: <video>: expose the frame rate and specific frames of the media resource
Status: NEW
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 enhancement
Target Milestone: Needs Impl Interest
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
Depends on:
Blocks: 23493
  Show dependency treegraph
Reported: 2013-07-15 23:25 UTC by Ian 'Hixie' Hickson
Modified: 2013-10-22 19:45 UTC (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ian 'Hixie' Hickson 2013-07-15 23:25:07 UTC
On Tue, 1 May 2012, Hugh Guiney wrote:
> Use case for exposing frame rate of <video>: Web-based non-linear
> editors. This software already exists—YouTube has one:
> http://www.youtube.com/editor, Mozilla has one:
> http://mozillapopcorn.org/popcorn-maker/, and there are/have been
> several independent efforts as well
> (http://lifehacker.com/5629683/jaycut-is-a-pretty-awesome-web+based-video-editor,
> http://www.spacebarstudios411.com/easyclip/, etc).
> Right now all of this software is alpha-stage, but the kinds of
> problems they attempt to solve involve: pop-up annotations,
> synchronized slide shows, clickable video areas, etc. Essentially,
> they will allow users to author rich multimedia experiences that
> aren't achievable with a traditional desktop NLE. Even if desktop
> NLEs were to offer this functionality with an HTML export like Adobe
> is doing with Flash CS6, it is advantageous to work in the
> destination medium rather than one fundamentally different; a
> similar trend is happening right now as web designers are moving
> away from Photoshop and beginning to design in the browser directly,
> and I can only imagine the same will happen with moving images,
> technology permitting.
> As it stands, frame rate awareness is a feature of NLEs that you
> would have to try very hard NOT to find. It is quite common for
> modern camcorders to offer an array of different available frame
> rates, for instance Panasonic's prosumer models (HVX200, HPX170
> etc.) offer at least 20 different fps options: 12, 15, 18, 20, 21,
> 22, 24, 25, 26, 27, 28, 30, 32, 34, 36, 40, 44, 48, 54, and 60. One
> of the primary purposes these options is to allow the user to
> achieve time distortion effects; if your main timeline is 24fps, you
> could shoot at 12fps and play it back for fast-motion; alternatively
> 48fps for slow-motion. These are called "undercranking" and
> "overcranking" respectively and have been in use since the dawn of
> film.
> A ubiquitous UI paradigm in modern video editing is to have a
> timeline with a set frame rate, that videos of alternate frame rates
> can be dragged into to change their effective playback speed. Not
> only is this useful for artistic time distortion effects, but also
> pragmatic time distortion, such as mixing 24fps (US film) and 30fps
> (US broadcast), 24fps with 25fps (European film), etc. with a
> non-variable output frame rate.
> Other use cases:
> - Categorizing/filtering a video catalog by frame rate, such as on a
> stock videography or film archive site, to only see those match the
> user's interest.
> - Video player UI displaying the frame rate so that users can tell
> if it is worthwhile to attempt playback on a slow connection, or
> device with limited playback capabilities. For instance such a user
> might discern that watching a 1080p60 video on a mobile device would
> take up too much bandwidth BEFORE pressing play and having the video
> stutter or play too slowly. Similarly, devices could detect this on
> their own and report to the user.
> - Frame-accurate subtitle authoring; timing the display of text with
> a character's lip movements is a precise art and if it is off by
> even a few seconds, it is distracting to the audience.
> - NLE that ingests Edit Decision List (EDL) XML files, which denote
> cuts, transitions, etc. in SMPTE timecode, so editors can work on
> projects that were originally cut in another NLE. This would be
> especially useful for desktop-to-web migration.
> Ian Hickson wrote:
> > If you have fixed frame rates, it's trivial to do the conversion
> > to and from SMTPE timecode in JavaScript; you don't need any
> > direct support from the media element API.
> Yes, but we currently have no way of knowing what fixed frame rate
> we are working with, making this kind of conversion impossible
> except through pure guesswork. If frame rate is exposed we don't
> need SMPTE internally.