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

On  12-Jan-2011, at 21:56 , Raphaël Troncy wrote:

> Hi Silvia,
> 
>> 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...
> 
> Yes, I think you use the good wording. I'm curious to hear what Jack thinks about all this, since he has knock his head with SMPTE a lot during the elaboration of SMIL.


Oops, I hadn't answered this one yet.

There is only one case that is really important (and I mean REALLY F***ING IMPORTANT:-) and that's when all of the client-side agent, the server and the media file involved understand SMPTE timecodes, and the media uses the same SMPTE variation that is specified on the fragment. In this case, the frame must be exactly matched. As someone (Dave Singer?) said in this group earlier: think of it as content-based addressing.

Getting this right enables things like web-based frame-accurate non-linear video editing and such.

In all other cases it would be good if something reasonable happened, but this is non-essential. I'm going back-and-forth on what "something reasonable" is, though, maybe Chris is right and just ignoring it is the best option. I did the thought-experiment of implementing an NLE in Javascript on top of an HTML5 implementation that didn't know about SMPTE but I don't think it can be done. If the <video> element would expose per-frame metadata (such as the SMPTE code for the current frame) or I could probably hide the frames. If there was a way to inspect the HTTP reply and then instruct the video renderer to not render the first N frames: ditto. However, none of these hooks are available, so I guess an NLE in Javascript will have to wait for HTML6.
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman

Received on Tuesday, 18 January 2011 23:09:11 UTC