Ian Hickson schrieb:
You can jump to a position that's a fraction of the whole clip by setting
'currentTime' to a fractional multiple of 'duration'.
Right, I was thinking of what happens if no duration could be determined
with acceptable effort. However, by now I happen to think that
On Mon, Dec 1, 2008 at 11:28 PM, Ian Hickson [EMAIL PROTECTED] wrote:
For the few servers that don't support seeking, duration is not
available.
Note that that is non-conforming at the moment. You have to have a
duration available (though it can be +Infinity if you think that the
resource is
At 2:06 + 2/12/08, Ian Hickson wrote:
On Tue, 2 Dec 2008, Chris Double wrote:
On Mon, Dec 1, 2008 at 11:28 PM, Ian Hickson [EMAIL PROTECTED] wrote:
For the few servers that don't support seeking, duration is not
available.
Note that that is non-conforming at the moment. You have
On Tue, Dec 2, 2008 at 3:06 PM, Ian Hickson [EMAIL PROTECTED] wrote:
We removed some other features (e.g. bufferedBytes and totalBytes) because
implementors said they would always provide accurate values in the
buffered and duration attributes. If we allow duration to be NaN, then
we'd have to
On Tue, 2 Dec 2008, Chris Double wrote:
It's not possible to always provide accurate values for duration - we've
already discussed that and you suggested estimating. I don't see that as
an accurate value.
The spec does allow for estimations and provides for the estimate being
revised
On Tue, Nov 25, 2008 at 6:58 PM, Maik Merten [EMAIL PROTECTED] wrote:
Dave Singer schrieb:
IF we are to do this, I would have thought it would be by adding units to
the where to seek to argument:
* go to this time in NPT (normal play time, which runs from 0 to media
duration)
* go to this
Relative seeking is always possible: currentTime+=10. Proportional
seeking is possible as long as the duration is known and finite.
I would avoid as far as possible any use of byte positions as this
information isn't exactly trivial to get given all the buffering and
asynchronous decoding
On Nov 24, 2008, at 2:21 PM, Calogero Alex Baldacchino wrote:
Well, the length attribute could be an indication about such limit
and could accept a generic value, such as 'unknown' (or '0', with
the same meaning - just to have only numerical values) to indicate
an endless stream (i.e. a
Eric Carlson ha scritto:
On Nov 24, 2008, at 2:21 PM, Calogero Alex Baldacchino wrote:
Well, the length attribute could be an indication about such limit
and could accept a generic value, such as 'unknown' (or '0', with the
same meaning - just to have only numerical values) to indicate an
Silvia Pfeiffer schrieb:
In any case - if you (and also Chris Double) are satisfied with the
estimates you're getting for file duration/length - I'll stop arguing
for it. It would be nice to hear some experimental evidence about how
well it's doing, e.g. for typical movie trailers, so we can
On Wed, Nov 26, 2008 at 7:22 AM, Maik Merten [EMAIL PROTECTED] wrote:
Silvia Pfeiffer schrieb:
In any case - if you (and also Chris Double) are satisfied with the
estimates you're getting for file duration/length - I'll stop arguing
for it. It would be nice to hear some experimental evidence
On Wed, Nov 26, 2008 at 12:28 AM, Silvia Pfeiffer
[EMAIL PROTECTED] wrote:
In any case - if you (and also Chris Double) are satisfied with the
estimates you're getting for file duration/length - I'll stop arguing
for it. It would be nice to hear some experimental evidence about how
well it's
Silvia Pfeiffer schrieb:
The duration is indeed jumping quite a bit between 8min and 12 min and
even at the end still has a gap of actual end time of 9m54s while the
estimate is still at 10m44s.
Actually that gap means the byte-accounting is still buggy. Hmmm...
Players like YouTube's player
I don't think you mean 'relative' here, which I would take to be go
forward 10 seconds, but 'proportional', please go to 60% of the way
through.
IF we are to do this, I would have thought it would be by adding
units to the where to seek to argument:
* go to this time in NPT (normal play
- Original Message
Da: Eric Carlson lt;[EMAIL PROTECTED]gt;
To: Silvia Pfeiffer lt;[EMAIL PROTECTED]gt;
Cc: WHAT Working Group lt;whatwg@lists.whatwg.orggt;, Maik Merten
lt;[EMAIL PROTECTED]gt;
Oggetto: Re: [whatwg] media elements: Relative seeking
Data: 24/11/08 03:17
nbsp;
- Original Message
Da: Maik Merten lt;[EMAIL PROTECTED]gt;
To: WHATWG Proposals lt;whatwg@lists.whatwg.orggt;
Oggetto: Re: [whatwg] media elements: Relative seeking
Data: 24/11/08 08:45
gt; Eric Carlson schrieb:
gt;gt; QuickTime has used this method
Eric,
On Mon, Nov 24, 2008 at 1:17 PM, Eric Carlson [EMAIL PROTECTED] wrote:
Silvia -
On Nov 23, 2008, at 1:40 PM, Silvia Pfeiffer wrote:
I don't see addition of a duration attribute as much of a problem. We
have width and height for images, and sizes for fonts, too, and web
developers
Dave Singer schrieb:
I don't think you mean 'relative' here, which I would take to be go
forward 10 seconds, but 'proportional', please go to 60% of the way
through.
Right, proportional for sure is the correct word for what I had in
mind. Thanks.
IF we are to do this, I would have thought
Reporting the absolute time of the current sample won't help when
the first sample of the file doesn't have a timestamp of zero. It will
be even more confusing for files with portions removed or added
without fixing time stamps - for example a movie created by
concatenating different
On Nov 23, 2008, at 10:51 AM, Maik Merten wrote:
Eric Carlson schrieb:
Reporting the absolute time of the current sample won't help when
the
first sample of the file doesn't have a timestamp of zero. It will be
even more confusing for files with portions removed or added without
fixing
On Mon, Nov 24, 2008 at 7:17 AM, Eric Carlson [EMAIL PROTECTED] wrote:
On Nov 23, 2008, at 10:51 AM, Maik Merten wrote:
Eric Carlson schrieb:
Reporting the absolute time of the current sample won't help when the
first sample of the file doesn't have a timestamp of zero. It will be
even
Eric Carlson schrieb:
QuickTime has used this method this since it started supporting VBR
mp3 in 2000, and in practice it works quite well. I am sure that there
are degenerate cases where the initial estimate is way off, but
generally it is accurate enough that it isn't a problem. An initial
22 matches
Mail list logo
