W3C home > Mailing lists > Public > public-media-fragment@w3.org > January 2011

Re: [whatwg] HTML5 video: frame accuracy / SMPTE

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 13 Jan 2011 09:37:41 +0100
Message-ID: <AANLkTi=5jyh58CTfJohaXh4vTH554vGU=MJEXCDi9mYB@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Jack Jansen <Jack.Jansen@cwi.nl>, Raphaël Troncy <raphael.troncy@eurecom.fr>, Media Fragment <public-media-fragment@w3.org>
On Thu, Jan 13, 2011 at 8:33 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Wed, 12 Jan 2011 20:04:52 +0100, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On Wed, Jan 12, 2011 at 1:18 PM, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>> On Wed, 12 Jan 2011 12:29:37 +0100, Raphaël Troncy
>>> <raphael.troncy@eurecom.fr> wrote:
>>>> Dear Silvia,
>>>> Le 10/01/2011 13:05, Jack Jansen a écrit :
>>>>> It's definitely worth it to put a link to our work in that thread. AT
>>>>> THE very least it should get us some reviewers of shag we've edited
>>>>> down on frame accurate addressing...
>>>> Thanks for pointing us this (now long) thread. I have just read it
>>>> completely. For the others, the main point of discussion is about video
>>>> editors and producers who want frame access to video and browsers who
>>>> say
>>>> that container formats such as WebM do not have a fixed frame rate (FPS)
>>>> and
>>>> therefore cannot expose it in the API. No mention of Media Fragments has
>>>> been done yet.
>>>> Silvia, could you please reply that Media Fragments allows to access to
>>>> a
>>>> SMPTE time code? I think the best place is to answer this mail from
>>>> Philip
>>>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029803.html
>>>> who has suggested to add an attribute to the video element exposing the
>>>> (virtual) framerate.
>>> To be clear, I haven't suggested exposing the frame rate, I was arguing
>>> against it.
>>> This is related to our discussion on the SMPTE format in Media Fragments,
>>> which I've stated I don't think we'll ever implement as it doesn't work
>>> with
>>> our most important format, WebM.
>> At the risk of repeating myself from earlier discussions: SMPTE
>> timecodes are just time markers - they do not guarantee that you
>> actually land on a frame boundary.
> Right, and when the media resource isn't also marked up with SMPTE time
> codes, SMPTE provides no technical benefit over a floating point number
> (currentTime).

All time-based addressing is just addressing along its resolution of
that time dimension and hardly ever along a video's frame numbers.
offset in seconds and milliseconds is also just a time marker that has
to be mapped to a the frame that happens to be active at that time.

The point about SMPTE is that people like being able to address frame
"numbers" rather than a floating point time. If the SMPTE code is
given with a framerate, there is a clear mapping between a SMPTE
timecode and a floating point number in seconds, so they are
equivalent. That framerate has nothing to do with the actual framerate
of the video, but it only provides time conversion information.

I am not fussed about making SMPTE addressing available, but I do know
that video editing apps always use SMPTE time codes to display current
time, which is where people are coming from with requests for such
time codes. They can do it themselves in JavaScript though, so there
isn't really an immediate need to implement it in browsers.

Received on Thursday, 13 January 2011 08:38:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:46 UTC