W3C home > Mailing lists > Public > public-media-fragment@w3.org > October 2010

Re: Media Fragments in Opera

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Mon, 18 Oct 2010 21:25:27 +1100
Message-ID: <AANLkTi=iCvdThc-COi6dBmD3u3XVFs7S_Q834PV6PuM3@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Media Fragment <public-media-fragment@w3.org>
On Mon, Oct 18, 2010 at 7:55 PM, 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?

It's mostly there because RTP/RTSP uses it, too, IIRC.

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

Ogg Skeleton has the possibility to add a UTC marker and all time
offsets from there can be added onto the UTC time marker. See
http://wiki.xiph.org/Ogg_Skeleton_4 and search for UTC. Not that I've
seen it used yet, but flumotion might need it if/when it's going to do
timed fragment URIs with UTC time.

> (In short, I've only implemented the npt syntax.)

I think that's fair enough! :-)

> About xywh:
> I think this would be useful for cropping away black borders, but I didn't
> have time to implement it for FOMS. It's not clear what 'pixels' means,
> should these be physical pixels of the video frames, or after correcting for
> pixel aspect ratio? Either would be fairly easy to implement, but possibly
> the risk of rounding errors is smaller when applying it to the physical
> pixels. On the other hand, everything else exposed via <video> is in CSS
> pixels after aspect ratio has been corrected for, so it would be a bit odd
> to suddenly use physical pixels here...

I think we referred to CSS pixels, but never really wrote that down.

Received on Monday, 18 October 2010 10:26:24 UTC

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