- From: David Singer <singer@apple.com>
- Date: Mon, 18 Jan 2010 10:38:16 +0900
- To: Jack Jansen <Jack.Jansen@cwi.nl>
- Cc: Davy Van Deursen <davy.vandeursen@ugent.be>, "'Bailer, Werner'" <werner.bailer@joanneum.at>, public-media-fragment@w3.org, 'Richard Wright-ARCHIVES' <richard.wright@bbc.co.uk>
On Jan 18, 2010, at 8:06 , Jack Jansen wrote: > > On 16 jan 2010, at 10:25, Davy Van Deursen wrote: >> >> Temporal fragments should indeed take into account embedded time stamps. 'may', I think, surely. It depends on whether the fragment time is expressed in NPT, or (say) SMPTE time-codes. NPT starts at 0; to resolve a fragment here, you're fine without inspecting the media. SMPTE time-codes, OTOH, need to be found. They might not even be continuous in the media. >> Note that this is already stated in the specification [1]. >> >> Best regards, >> >> Davy >> >> [1] http://www.w3.org/TR/media-frags/#processing-overview-interpretation > > > Thanks for finding this one! > > But: this means that we have to look through the protocol description with this in mind. > > If I have a video http://www.example.com/example.mp4, which has 10 seconds worth of video, with timestamps 01:00:00:00 through 01:00:10:00, and a UA sends a request > with > Range: t:smpte=01:00:05:00-01:00:06:00 > what does it get back in the Content-Range header? > I would assume the timestamps are as expected, but what is the duration returned? > -- > 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 > > > > David Singer Multimedia and Software Standards, Apple Inc.
Received on Monday, 18 January 2010 01:38:50 UTC