- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 21 Oct 2010 08:07:58 +1100
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: public-media-fragment@w3.org
On Thu, Oct 21, 2010 at 1:57 AM, Philip Jägenstedt <philipj@opera.com> wrote: > On Wed, 20 Oct 2010 11:48:15 +0200, Conrad Parker <conrad@metadecks.org> > wrote: > >> On 18 October 2010 17:55, Philip Jägenstedt <philipj@opera.com> wrote: >>> >>> For those of you who were not at FOMS, here's a little FYI: >>> >>> The first native browser implementation of Media Fragments was demoed at >>> FOMS, that is: something I hacked into Opera. This is not ready to ship, >>> so >>> don't expect to see it in desktop Opera just yet. Here's some >>> implementation >>> feedback: >>> >>> About t: >>> >>> * We should consider making the HH component optional. Most clips online >>> are >>> less than an hour, and being able to say #t=9:23 would be useful. >>> >>> * It's not clear to me what to do with the smpte formats. In our >>> underlying >>> media framework (GStreamer) time is expressed in nanoseconds, so it >>> doesn't >>> actually give any great precision that using 9 decimals. For now, I've >>> not >>> added support for the smpte formats at all. Are there any existing >>> implementations or indications that anyone does want to implement it? >>> >>> * The use case for 'clock' syntax is pretty clear, but AFAIK the time in >>> UTC >>> isn't available in Ogg or WebM, so I'm not sure what to do with it. >>> >>> (In short, I've only implemented the npt syntax.) >>> >> >> I was thinking that the smpte formats would be useful for applications >> that need to address specific frames, such as web-based video editors. >> Humans may not find these formats so necessary. It may be the case >> that something like Metavid is already advanced enough to do >> frame-level editing. > > My issue with this syntax is that the actual media frameworks that one > inevitably uses to implement it don't support addressing frames like this, > they simply deal in nanoseconds or similar. (This is true of at least > GStreamer and DirectShow.) If using the SMPTE syntax doesn't, in practice, > give you greater precision than using more decimals, is it worthwhile? > > For video editing in the browser, I think that would best be built using the > JavaScript API, possibly with some additions to allow frame- and > sample-accurate offsets if that turns out to be a problem. It seems > premature to try to solve the problem using MF. I don't remember where it came from, but there were user requests and requirements that asked for SMPTE syntax - we weren't going to do it at first. It may have come from live streaming, TV style applications, video editing, or something else. SMPTE is unfortunately still the standard for much TV-related and professional video stuff, so we shouldn't ignore it. Also, it's actually not that difficult to convert between SMPTE and ms, so just regard SMPTE as a "marker" for certain ms offsets (similar to UTC in fact). I have some functions here that might help: http://svn.annodex.net/libcmml/trunk/src/cmml_time.c . Cheers, Silvia.
Received on Wednesday, 20 October 2010 21:08:47 UTC