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

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. For that to happen, you do indeed
need an exact framerate and that is simply not available in modern
formats.

Instead, you should consider the suggestions that Jeroen is making:
use the SMPTE timecode to do seeking to the exact equivalent time
offset in seconds. Then, a step() function can help to get to exact
frame boundaries of that is indeed required.

Such a SMPTE timecode seeking function - while typically in use by
video editors - doesn't normally mean much any more in digital video
editors. It's more that people have a better grasp on frame numbers
through SMPTE than on time offsets in seconds, which is why these time
codes are still somewhat relevant.

I'm not too sure I want to muddy the discussion further with SMPTE
time codes on media fragments. I might mention that the possibility
exists and that these are just time markers and may also not map to an
exact frame broundary, but that they are at least available. I'll
sleep over it...

Cheers,
Silvia.

Received on Wednesday, 12 January 2011 19:05:48 UTC