On Fri, 1 May 2009, Silvia Pfeiffer wrote:
On Fri, May 1, 2009 at 3:00 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 30 Apr 2009, David Singer wrote:
At 16:45 + 30/04/09, Ian Hickson wrote:
On Thu, 30 Apr 2009, David Singer wrote:
If the resource is 'seekable' then time is
On Thu, Apr 30, 2009 at 1:04 PM, Ian Hickson i...@hixie.ch wrote:
I have left the spec as is (except for adding startTime), which means that
currentTime can be greater than duration if startTime is not zero.
I think it would be safer to have the invariant that 0 = currentTime =
duration. Most
On Thu, 30 Apr 2009, Robert O'Callahan wrote:
On Thu, Apr 30, 2009 at 1:04 PM, Ian Hickson i...@hixie.ch wrote:
I have left the spec as is (except for adding startTime), which means
that currentTime can be greater than duration if startTime is not
zero.
I think it would be safer to
On Thu, Apr 30, 2009 at 6:21 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 30 Apr 2009, Robert O'Callahan wrote:
On Thu, Apr 30, 2009 at 1:04 PM, Ian Hickson i...@hixie.ch wrote:
I have left the spec as is (except for adding startTime), which means
that currentTime can be greater than
On Thu, 30 Apr 2009, Robert O'Callahan wrote:
So I think a safer design would be to interpret currentTime as
relative to the startTime, perhaps renaming startTime to
'timeOffset' instead?
I considered that, but it seems that in the streaming video
(DVR-like) case, in the
At 6:21 + 30/04/09, Ian Hickson wrote:
On Thu, 30 Apr 2009, Robert O'Callahan wrote:
On Thu, Apr 30, 2009 at 1:04 PM, Ian Hickson i...@hixie.ch wrote:
I have left the spec as is (except for adding startTime), which means
that currentTime can be greater than duration if startTime is
On Thu, 30 Apr 2009, David Singer wrote:
If the resource is 'seekable' then time is relevant, and I agree that
time should be a normal play time and run from 0 to duration.
That wouldn't address the use case of files that were split with non-zero
start times, though, where the author wants
At 16:45 + 30/04/09, Ian Hickson wrote:
On Thu, 30 Apr 2009, David Singer wrote:
If the resource is 'seekable' then time is relevant, and I agree that
time should be a normal play time and run from 0 to duration.
That wouldn't address the use case of files that were split with
On Thu, 30 Apr 2009, David Singer wrote:
At 16:45 + 30/04/09, Ian Hickson wrote:
On Thu, 30 Apr 2009, David Singer wrote:
If the resource is 'seekable' then time is relevant, and I agree
that time should be a normal play time and run from 0 to duration.
That wouldn't
On Fri, May 1, 2009 at 3:00 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 30 Apr 2009, David Singer wrote:
At 16:45 + 30/04/09, Ian Hickson wrote:
On Thu, 30 Apr 2009, David Singer wrote:
If the resource is 'seekable' then time is relevant, and I agree
that time should be a normal
On Thu, Apr 30, 2009 at 12:00 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 30 Apr 2009, Robert O'Callahan wrote:
So I think a safer design would be to interpret currentTime as
relative to the startTime, perhaps renaming startTime to
'timeOffset' instead?
I considered that,
On Mon, 6 Apr 2009, Chris Double wrote:
Ogg based media resources can start from a time position that is not
zero. Examples of files that do this are those generated by the program
oggz-chop. For example:
On Wed, 8 Apr 2009, Silvia Pfeiffer wrote:
Note that in the Media Fragment working group even the specification of
http://www.example.com/t.mov#time=10s-20s; may mean that only the
requested 10s clip is delivered, especially if all the involved
instances in the exchange understand media
On Thu, Apr 9, 2009 at 4:46 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 8 Apr 2009, David Singer wrote:
Navigation outside the indicated range could be done in several ways -
it does not have to be through indicating the full length of the
resource in the timeline.
surely. but which
At 22:30 +1000 9/04/09, Silvia Pfeiffer wrote:
On Thu, Apr 9, 2009 at 4:46 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 8 Apr 2009, David Singer wrote:
Navigation outside the indicated range could be done in several ways -
it does not have to be through indicating the full length of
On Thu, Apr 9, 2009 at 5:30 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Thu, Apr 9, 2009 at 4:46 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 8 Apr 2009, David Singer wrote:
Navigation outside the indicated range could be done in several ways -
it does not have to be through
On Fri, Apr 10, 2009 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote:
http://example.com/video.ogg#t=5s
displaying the selected frame, but displaying a timeline for the full
video and allowing the user to directly go to any position.
For this to work with custom user interfaces in
2009/4/10 Chris Double chris.dou...@double.co.nz:
On Fri, Apr 10, 2009 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote:
http://example.com/video.ogg#t=5s
displaying the selected frame, but displaying a timeline for the full
video and allowing the user to directly go to any position.
For
On Tue, 07 Apr 2009 06:11:51 +0200, Chris Double
chris.dou...@double.co.nz wrote:
On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson eric.carl...@apple.com
wrote:
Media time values are expressed in normal play time (NPT), the
absolute
position relative to the beginning of the presentation.
2009/4/7 Philip Jägenstedt phil...@opera.com:
On Tue, 07 Apr 2009 06:11:51 +0200, Chris Double chris.dou...@double.co.nz
wrote:
On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson eric.carl...@apple.com
wrote:
Media time values are expressed in normal play time (NPT), the absolute
position
On Tue, Apr 7, 2009 at 5:12 PM, Philip Jägenstedt phil...@opera.com wrote:
On Tue, 07 Apr 2009 06:11:51 +0200, Chris Double chris.dou...@double.co.nz
wrote:
On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson eric.carl...@apple.com
wrote:
Media time values are expressed in normal play time (NPT),
On Tue, 07 Apr 2009 10:26:15 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Tue, Apr 7, 2009 at 5:12 PM, Philip Jägenstedt phil...@opera.com
wrote:
On Tue, 07 Apr 2009 06:11:51 +0200, Chris Double
chris.dou...@double.co.nz
wrote:
On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson
On Tue, Apr 7, 2009 at 1:26 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
For example, take a video that is a subpart of a larger video and has
been delivered through a media fragment URI
(http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/).
When a user watches both,
On Apr 6, 2009, at 9:11 PM, Chris Double wrote:
On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson
eric.carl...@apple.com wrote:
Media time values are expressed in normal play time (NPT), the
absolute
position relative to the beginning of the presentation.
I don't see mention of this in the
I think that there is a very real difference between the
zero-to-duration 'seek bar' that the UI presents, and which users
understand, from the 'represented time' of the content. That might
be a section of a movie, or indeed might be a section of real
time-of-day (think of one of the millions
OTOH, if the media player scroll bar has zoom function, the problem of
navigation deficiency in a short interval disappears. When the browser
displays a fragment, it can just zoom the scroll bar to the fragment
displayed.
IMHO,
Chris
At 19:20 +0200 7/04/09, KÞitof Îelechovski wrote:
OTOH, if the media player scroll bar has zoom function, the problem of
navigation deficiency in a short interval disappears. When the browser
displays a fragment, it can just zoom the scroll bar to the fragment
displayed.
IMHO,
Chris
That's
2009/4/8 Křištof Želechovski giecr...@stegny.2a.pl:
OTOH, if the media player scroll bar has zoom function, the problem of
navigation deficiency in a short interval disappears. When the browser
displays a fragment, it can just zoom the scroll bar to the fragment
displayed.
When the video
On Wed, Apr 8, 2009 at 12:26 AM, Ralph Giles gi...@xiph.org wrote:
On Tue, Apr 7, 2009 at 1:26 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
For example, take a video that is a subpart of a larger video and has
been delivered through a media fragment URI
On Wed, Apr 8, 2009 at 3:30 AM, David Singer sin...@apple.com wrote:
At 19:20 +0200 7/04/09, KÞi”tof Îelechovski wrote:
OTOH, if the media player scroll bar has zoom function, the problem of
navigation deficiency in a short interval disappears. When the browser
displays a fragment, it can
At 8:02 +1000 8/04/09, Silvia Pfeiffer wrote:
Note that in the Media Fragment working group even the specification
of http://www.example.com/t.mov#time=10s-20s; may mean that only the
requested 10s clip is delivered, especially if all the involved
instances in the exchange understand media
On Wed, Apr 8, 2009 at 8:21 AM, David Singer sin...@apple.com wrote:
At 8:02 +1000 8/04/09, Silvia Pfeiffer wrote:
Note that in the Media Fragment working group even the specification
of http://www.example.com/t.mov#time=10s-20s; may mean that only the
requested 10s clip is delivered,
At 8:29 +1000 8/04/09, Silvia Pfeiffer wrote:
My mental analogy was HTML, where an acnhor takes you to that part of the
page as a convenience, but nothing stops you from navigating away. And in
the case where the UA optimizes for showing that section (by suitable
handshakes/translations
On 8/4/09 00:29, Silvia Pfeiffer wrote:
The media fragment WG decided that fragment addressing should be done
with # and be able to just deliver the actual fragment.
Interesting! Do you have a reference for this? I can't understand how
this is possible if these are URI references, unless
2009/4/8 Dan Brickley dan...@danbri.org:
On 8/4/09 00:29, Silvia Pfeiffer wrote:
The media fragment WG decided that fragment addressing should be done
with # and be able to just deliver the actual fragment.
Interesting! Do you have a reference for this? I can't understand how this
is
Silvia Pfeiffer wrote:
Note that in the Media Fragment working group even the specification
of http://www.example.com/t.mov#time=10s-20s; may mean that only the
requested 10s clip is delivered
Since the part starting with '#' isn't sent as part of the HTTP GET
request, I'm not sure how this
On Tue, 7 Apr 2009, Boris Zbarsky wrote:
Silvia Pfeiffer wrote:
Note that in the Media Fragment working group even the specification
of http://www.example.com/t.mov#time=10s-20s; may mean that only the
requested 10s clip is delivered
Since the part starting with '#' isn't sent as part of
On Wed, Apr 8, 2009 at 8:37 AM, David Singer sin...@apple.com wrote:
At 8:29 +1000 8/04/09, Silvia Pfeiffer wrote:
My mental analogy was HTML, where an acnhor takes you to that part of
the
page as a convenience, but nothing stops you from navigating away. And
in
the case where the UA
On Wed, Apr 8, 2009 at 10:49 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Silvia Pfeiffer wrote:
Note that in the Media Fragment working group even the specification
of http://www.example.com/t.mov#time=10s-20s; may mean that only the
requested 10s clip is delivered
Since the part starting
On Wed, Apr 8, 2009 at 11:21 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 7 Apr 2009, Boris Zbarsky wrote:
Silvia Pfeiffer wrote:
Note that in the Media Fragment working group even the specification
of http://www.example.com/t.mov#time=10s-20s; may mean that only the
requested 10s clip is
On Mon, Apr 6, 2009 at 9:40 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
If we want to display that there
is some more context around the video, we should display the offset
time. I personally would prefer the latter option, since it relates
directly with the original resource.
This
I guess I would prefer a DOM property to retrieve the declared start time of
embedded media to an explicit attribute. It would me more consistent and
tamper-proof.
Chris
On Mon, Apr 6, 2009 at 7:38 PM, Chris Double chris.dou...@double.co.nz wrote:
On Mon, Apr 6, 2009 at 9:40 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
If we want to display that there
is some more context around the video, we should display the offset
time. I personally would prefer
On Apr 6, 2009, at 3:08 AM, Silvia Pfeiffer wrote:
On Mon, Apr 6, 2009 at 7:38 PM, Chris Double chris.dou...@double.co.nz
wrote:
On Mon, Apr 6, 2009 at 9:40 PM, Silvia Pfeiffer
I doubt though we need another attribute on the element - the
information is stored in the src URL, so should be
On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson eric.carl...@apple.com wrote:
A media file with a non-zero initial time stamp is not new to
oggz-chopped files (eg. an MPEG stream initial PTS can have any value, SMPTE
time-codes do not necessarily start at zero, etc) , but I disagree that we
On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson eric.carl...@apple.com wrote:
Media time values are expressed in normal play time (NPT), the absolute
position relative to the beginning of the presentation.
I don't see mention of this in the spec which is one of the reasons I
raised the question.
On Mon, Apr 6, 2009 at 7:21 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson eric.carl...@apple.com wrote:
A media file with a non-zero initial time stamp is not new to
oggz-chopped files (eg. an MPEG stream initial PTS can have any value, SMPTE
47 matches
Mail list logo
