Would something like this tie in to the device work that's being done
maybe?
-- Forwarded message --
From: Adam Malcontenti-Wilson adman@gmail.com
Date: Fri, Jan 21, 2011 at 6:21 AM
Subject: [chromium-html5] File API Streaming Blobs
To: Chromium HTML5
2011-01-18 23:37 EEST: Glenn Maynard:
On Tue, Jan 18, 2011 at 8:40 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/18/11 6:09 AM, Glenn Maynard wrote:
I'm confused--how is the required buffer size a function of the length of
the video? Once the buffer is large enough to smooth out network
On Fri, 21 Jan 2011 00:51:41 +0100, Alexey Proskuryakov a...@webkit.org
wrote:
There seems to be no provision in the spec for a behavior Firefox and IE
(and now WebKit-based browsers, too) have. If window.print() is called
during page load, then its action is delayed until loading is
Based on the discussion on the WebKit bug [1] I wanted to quickly make sure
we're all on the same page with respect to seeking.
My fix for Chromium was rounding up/down to the nearest frame however I
agree that seeking should always land within the duration of a frame as
opposed to rounding.
On 01/13/2011 01:44 AM, Philip Jägenstedt wrote:
Changing the default at this point wouldn't really hurt since not all
browsers are doing exact seeking anyway, right? I think that keyframe
seeking is more often what you want and it'd be better to let the few
who want frame-exact seeking jump
On Fri, Jan 21, 2011 at 1:12 PM, Michael Dale d...@ucsc.edu wrote:
On 01/13/2011 01:44 AM, Philip Jägenstedt wrote:
Changing the default at this point wouldn't really hurt since not all
browsers are doing exact seeking anyway, right? I think that keyframe
seeking is more often what you want
I still want the API to support seeks to exact frames.
eg when I build some GUI that allows the user to click on a button that says
explosion shot 1 at 00:31:02.15 then I want the player to seek to
00:31:02.15 exactly and not to say, 00:31:02.01 simply b/c that's where a
keyframe happens to be.
Doesn't the current XHR2 spec address this use case?
Browsers don't seem to implement it yet, but shouldn't something like
this work for the original poster?
x = new XMLHttpRequest()
x.open(GET, http://my-media-file;);
x.responseType = blob;
x.send();
On Fri, Jan 21, 2011 at 1:38 PM, Rob Coenen coenen@gmail.com wrote:
I still want the API to support seeks to exact frames.
eg when I build some GUI that allows the user to click on a button that says
explosion shot 1 at 00:31:02.15 then I want the player to seek to
00:31:02.15 exactly and
XHR2 is one part of the APIs required for my use case as that is the
easiest way to download for example a music file. However, while
downloading, there's no way to pipe the download(ing) blob to the
HTML5 Audio element as to play Audio it requires an object URL, and an
object URL can (currently)
I don't think any rounding should be done, at least not in a way that is
then observable through currentTime. Each frame has a start time, so if
the seeked time falls right between two frames, I'd expect the first of
them to show for half of its duration before the second one shows.
My
On Fri, Jan 21, 2011 at 1:55 PM, David Flanagan da...@davidflanagan.com wrote:
Doesn't the current XHR2 spec address this use case?
Browsers don't seem to implement it yet, but shouldn't something like this
work for the original poster?
x = new XMLHttpRequest()
x.open(GET,
On Fri, 21 Jan 2011 20:11:30 +0100, Gregory Maxwell gmaxw...@gmail.com
wrote:
On Fri, Jan 21, 2011 at 1:38 PM, Rob Coenen coenen@gmail.com wrote:
I still want the API to support seeks to exact frames.
eg when I build some GUI that allows the user to click on a button that
says
On Fri, Jan 21, 2011 at 4:04 PM, Philip Jägenstedt phil...@opera.com wrote:
Since, as you say, the behavior is currently inconsistent, there is still
time to agree on something that makes sense and have everyone implement
that. I think the best default is keyframe seeking and haven't seen any
On Fri, 21 Jan 2011 22:15:43 +0100, Gregory Maxwell gmaxw...@gmail.com
wrote:
On Fri, Jan 21, 2011 at 4:04 PM, Philip Jägenstedt phil...@opera.com
wrote:
Since, as you say, the behavior is currently inconsistent, there is
still
time to agree on something that makes sense and have everyone
On 2011-01-21 22:15, Gregory Maxwell wrote:
I don't like keyframe seeking as the default. Keyframe seeking
assumes things about the container, codec, and encoding which may not
be constants or even applicable to all formats. For example a file
with rolling intra may have no keyframes, and yet
On Sat, Jan 22, 2011 at 8:04 AM, Philip Jägenstedt phil...@opera.com wrote:
On Fri, 21 Jan 2011 20:11:30 +0100, Gregory Maxwell gmaxw...@gmail.com
wrote:
On Fri, Jan 21, 2011 at 1:38 PM, Rob Coenen coenen@gmail.com wrote:
I still want the API to support seeks to exact frames.
eg when I
On 2011-01-21 22:04, Philip Jägenstedt wrote:
Concretely: Add seek(time, flags) where flags defaults to nothing.
Accurate seeking would be done via seek(time, accurate) or some
such. Setting currentTime is left as is and doesn't set any flags.
Hmm. I think the default (nothing) should be
On Sat, Jan 22, 2011 at 8:50 AM, Roger Hågensen resca...@emsai.net wrote:
On 2011-01-21 22:04, Philip Jägenstedt wrote:
Concretely: Add seek(time, flags) where flags defaults to nothing.
Accurate seeking would be done via seek(time, accurate) or some such.
Setting currentTime is left as is
On 2011-01-21 21:50, Glenn Maynard wrote:
On Fri, Jan 21, 2011 at 1:55 PM, David Flanaganda...@davidflanagan.com wrote:
Doesn't the current XHR2 spec address this use case?
Browsers don't seem to implement it yet, but shouldn't something like this
work for the original poster?
He wants to be
On Fri, Jan 21, 2011 at 4:42 PM, Roger Hågensen resca...@emsai.net wrote:
Accurate seeking also assumes things about the codec/container/encoding.
If a format does not have keyframes then it does have something
equivalent.
Formats without keyframes can probably (I might be wrong there) seek
On Fri, Jan 21, 2011 at 4:40 PM, Philip Jägenstedt phil...@opera.com wrote:
I'm fine with any terminology, as long as it allows implementations to seek
to some other time than currentTime if it's (much) faster to do so.
GStreamer has the flags GST_SEEK_FLAG_ACCURATE and GST_SEEK_FLAG_KEY_UNIT,
On 2011-01-21 22:57, Silvia Pfeiffer wrote:
On Sat, Jan 22, 2011 at 8:50 AM, Roger Hågensenresca...@emsai.net wrote:
On 2011-01-21 22:04, Philip Jägenstedt wrote:
Concretely: Add seek(time, flags) where flags defaults to nothing.
Accurate seeking would be done via seek(time, accurate) or some
On Fri, Jan 21, 2011 at 5:11 PM, Glenn Maynard gl...@zewt.org wrote:
Should there be any consistency requirements for fast seeking?
[snip]
This could have unexpected side-effects. Should this be allowed? I'd
suggest that fast seeking should always be consistent with itself, at
least for a
On Sat, Jan 22, 2011 at 9:05 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Fri, Jan 21, 2011 at 4:57 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
* the default is best effort
I fear that the best effort language is misleading. You can always
do exact on a stream that you can seek
On Fri, Jan 21, 2011 at 4:59 PM, Roger Hågensen resca...@emsai.net wrote:
Hmm! And I guess it's very difficult to create a abstract in/out interface
that can handle any protocol/stream.
Although an abstract in/out would be ideal as that would let new protocols
to be supported without needing
On Fri, Jan 21, 2011 at 5:25 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
The language I'd prefer is fast. Fast may be exact, or it might
just be to the nearest keyframe, or something in between. It might
just start you over at the beginning of the stream.
That is putting a
On Fri, Jan 21, 2011 at 5:19 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
It would, but it also results in some pretty perplexing and unfriendly
behavior... where the user hits the 5-seconds forward button and ends
up going 4-seconds backwards, only to press the button again and
repeatedly
On 2011-01-21 23:48, Gregory Maxwell wrote:
It seems surprising to me that we'd want to expose something so deeply
internal while the API fails to expose things like chapters and other
metadata which can actually be used to reliably map times to
meaningful high level information about the
On Sat, Jan 22, 2011 at 9:48 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Fri, Jan 21, 2011 at 5:25 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
The language I'd prefer is fast. Fast may be exact, or it might
just be to the nearest keyframe, or something in between. It might
just
On 2011-01-22 01:27, Silvia Pfeiffer wrote:
It seems surprising to me that we'd want to expose something so deeply
internal while the API fails to expose things like chapters and other
metadata which can actually be used to reliably map times to
meaningful high level information about the
When the HTML5 states were first proposed, I went through a careful exercise to
make sure that they were reasonably delivery-technology neutral, i.e. that they
applied equally well if say RTSP/RTP was used, some kind of dynamic streaming,
simple HTTP, and so on.
I am concerned that we all tend
On Fri, Jan 21, 2011 at 7:27 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Sat, Jan 22, 2011 at 9:48 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Fri, Jan 21, 2011 at 5:25 PM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
The language I'd prefer is fast. Fast may be exact, or
On 22/01/2011 7:31 a.m., Gregory Maxwell wrote:
It's usually the decoding, not the file access that kill you. Firefox
seeking on low resolution clips is very snappy index or not. But try a
1080p clip encoded with a 10 second maximum keyframe interval...
This is true. If you want fast frame
Regarding whether to use fast or accurate seeks by default, it
seems like a balance between the frequency of use cases for each, the
likelihood of either default being wrong, principle of least surprise,
and consistency with other APIs. Looking at various seek use cases:
Seek bars should use
On 22/01/2011 3:23 p.m., Gregory Maxwell wrote:
On Fri, Jan 21, 2011 at 8:19 PM, Chris Pearcech...@pearce.org.nz wrote:
On 22/01/2011 7:31 a.m., Gregory Maxwell wrote:
It's usually the decoding, not the file access that kill you. Firefox
seeking on low resolution clips is very snappy index
36 matches
Mail list logo
