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

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).

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Thursday, 13 January 2011 07:35:10 UTC