On Sun, 23 Jan 2011 00:06:30 +0100, Glenn Maynard gl...@zewt.org wrote:
On Sat, Jan 22, 2011 at 5:57 AM, Philip Jägenstedt phil...@opera.com
wrote:
I agree that there must exist a buffering strategy between
strategy=metadata
and strategy=auto, but it's not clear that this must be exposed as
On Sun, Jan 23, 2011 at 5:24 AM, Philip Jägenstedt phil...@opera.com
wrote:
I do think that in the basic case of a user pressing play on a video
player, it's good to be able to make that respond instantly rather
than waiting for a round-trip to begin playing.
Have you found this to be an
On Sun, 23 Jan 2011 12:13:15 +0100, Glenn Maynard gl...@zewt.org wrote:
On Sun, Jan 23, 2011 at 5:24 AM, Philip Jägenstedt phil...@opera.com
wrote:
I do think that in the basic case of a user pressing play on a video
player, it's good to be able to make that respond instantly rather
than
On Sun, Jan 23, 2011 at 6:32 AM, Philip Jägenstedt phil...@opera.comwrote:
But presumably you want some kind of guarantee that the video will be able
to keep playing without waiting for the network, right? So if you don't use
preload=auto, you'll at least need preload=playthrough or similar.
On 24/01/2011 12:32 a.m., Philip Jägenstedt wrote:
Hmm. To get this effect without preload=buffer, you could set
preload=auto,
watch the buffered attribute to see when some data is actually
downloaded,
then set it to preload=metadata to stop autoloading. That's a minor
hack,
and would
On Jan 23, 2011, at 21:40 , Glenn Maynard wrote:
The most important unresolved use case is: how to allow limiting the amount
of prebuffered data, while also having a mechanism to disable that limit
when there isn't enough bandwidth.
The problem isn't so much the lack of bandwidth, as the
On Thu, 20 Jan 2011 19:16:21 +0100, Zachary Ozer z...@longtailvideo.com
wrote:
On Thu, Jan 20, 2011 at 3:14 AM, Philip Jägenstedt
phil...@opera.comwrote:
* effective state can only increase to higher states, never go from e.g.
metadata to none (it makes no sense)
What if my bandwidth
On 22/01/2011 11:57 p.m., Philip Jägenstedt wrote:
I agree that there must exist a buffering strategy between
strategy=metadata and strategy=auto, but it's not clear that this must
be exposed as a preload state. The only difference between
preload=metadata and preload=state3 would be that
On Sat, Jan 22, 2011 at 5:57 AM, Philip Jägenstedt phil...@opera.com wrote:
I agree that there must exist a buffering strategy between strategy=metadata
and strategy=auto, but it's not clear that this must be exposed as a preload
state. The only difference between preload=metadata and
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
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 Thu, 20 Jan 2011 01:14:12 +0100, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jan 19, 2011 at 8:22 AM, Philip Jägenstedt
phil...@opera.comwrote:
If the available bandwidth exceeds the bandwidth of the resource, some
kind
of throttling must eventually be used. There are mainly 2 options
On Jan 20, 2011, at 9:14 AM, Philip Jägenstedt wrote:
(Since there is some overhead with each HTTP request, one must make sure
that they are not unreasonably small.)
When HTTP byte ranges are used to achieve bandwidth management, it's hard
to talk about a single downloadBufferTarget that
On Thu, Jan 20, 2011 at 3:14 AM, Philip Jägenstedt phil...@opera.comwrote:
However, it'd be great if all implementors could agree on the same
interpretation of states. Specifically, this isn't required by the spec but
would still be helpful to have consistency in:
* effective state can only
On Thu, Jan 20, 2011 at 3:14 AM, Philip Jägenstedt phil...@opera.comwrote:
* effective state can only increase to higher states, never go from e.g.
metadata to none (it makes no sense)
What if my bandwidth situation improves (moving from 3g to WiFi, for example)?
At that point, perhaps I should
On 2011-01-20 19:16, Zachary Ozer wrote:
== New Proposal ==
I like this. It seems you laid out everything to ensure a balanced
buffer, kinda like a moving window buffer which I pointed out earlier.
So as far as I can see, your proposal looks pretty solid, unless there
are any implementation
We never make any promises about when we'll get something into an
official release, but I think we'd start playing around with it in our
development version once a reference implementation was publicly
available.
--
Zachary Ozer
Developer, LongTail Video
w: longtailvideo.com • e:
On Thu, Jan 20, 2011 at 1:16 PM, Zachary Ozer z...@longtailvideo.com wrote:
On Thu, Jan 20, 2011 at 4:19 AM, Glenn Maynard gl...@zewt.org wrote:
I think that pausing shouldn't affect read-ahead buffering behavior. I'd
suggest another preload value, preload=buffer, sitting between metadata
and
On Mon, 17 Jan 2011 22:41:17 +0100, Robert O'Callahan
rob...@ocallahan.org wrote:
One solution that could work here is to honour dynamic changes to
'preload',
so switching preload to 'none' would stop buffering. Then a script could
do
that, for example, after the user has paused the video
On Mon, Jan 17, 2011 at 6:41 PM, Jeroen Wijering
jer...@longtailvideo.com wrote:
We are getting some questions from JW Player users that HTML5 video is quite
wasteful on bandwidth for longer videos (think 10min+). This because browsers
download the entire movie once playback starts,
On Wed, 19 Jan 2011 10:42:01 +0100, Aryeh Gregor
simetrical+...@gmail.com wrote:
On Mon, Jan 17, 2011 at 6:41 PM, Jeroen Wijering
jer...@longtailvideo.com wrote:
We are getting some questions from JW Player users that HTML5 video is
quite wasteful on bandwidth for longer videos (think
Two ideas just struck me:
== Network API calls ==
What if, instead of trying to solve this problem, we leave it up to
the publishers. The current behavior would be unchanged, but we could
add explicit bandwidth management API calls, ie startBuffer() and
stopBuffer(). This would let developers /
On Wed, 19 Jan 2011 17:14:23 +0100, Zachary Ozer z...@longtailvideo.com
wrote:
Two ideas just struck me:
== Network API calls ==
What if, instead of trying to solve this problem, we leave it up to
the publishers. The current behavior would be unchanged, but we could
add explicit bandwidth
On Wed, Jan 19, 2011 at 11:14 AM, Zachary Ozer z...@longtailvideo.comwrote:
Two ideas just struck me:
== Network API calls ==
What if, instead of trying to solve this problem, we leave it up to
the publishers. The current behavior would be unchanged, but we could
add explicit bandwidth
On Tue, Jan 18, 2011 at 1:30 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/17/11 6:04 PM, Boris Zbarsky wrote:
From a user's perspective (which is what I'm speaking as here), it
doesn't matter what the technology is. The point is that there is
prevalent UI out there right now where pausing
2011-01-17 23:32 EEST: Silvia Pfeiffer:
On Mon, Jan 17, 2011 at 10:15 PM, Chris Pearce ch...@pearce.org.nz wrote:
Perhaps we should only honour the downloadBufferTarget (or whatever measure
we use) when the media is in readyState HAVE_ENOUGH_DATA, i.e. if we're
downloading at a rate greater
On Tue, Jan 18, 2011 at 5:46 AM, Mikko Rantalainen
mikko.rantalai...@peda.net wrote:
This way the UA would (slowly?) converge to correct downloadBufferTarget
for any site for any given network connection. If the full length of the
video clip is known, then downloadBufferTarget should probably
On Mon, Jan 17, 2011 at 5:01 PM, Zachary Ozer z...@longtailvideo.comwrote:
I assume you're comparing to the bandwidth usage of flash? Does flash
allow
developers to control how the media is downloaded on the client? What
mechanisms does it provide? Maybe we can do something similar?
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
fluctuations, either you have the bandwidth to stream the video or you
don't; the length of the video doesn't enter
I've heard from some people that they're a bit lost, so I wanted to
take a moment to summarize.
We have two competing interests here:
* Viewers want a smooth playback experience regardless of their
bandwidth or device. Some viewers may also want to limit the amount
they download because they're
On Tue, Jan 18, 2011 at 9:11 AM, Zachary Ozer z...@longtailvideo.comwrote:
Currently, there's no way to stop / limit the browser from buffering -
once you hit play, you start downloading and don't stop until the
resource is completely loaded. This is largely the same as Flash, save
the fact
On 1/18/11 12:11 PM, Zachary Ozer wrote:
(Side
note: I also haven't found a browser that stops loading the resource
even if you destroy the video tag.)
destroy in what sense? You verified in a debugger that it had been
garbage collected?
-Boris
On Tue, Jan 18, 2011 at 6:46 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/18/11 12:11 PM, Zachary Ozer wrote:
(Side
note: I also haven't found a browser that stops loading the resource
even if you destroy the video tag.)
destroy in what sense? You verified in a debugger that it had been
On 1/18/11 2:01 PM, Zachary Ozer wrote:
On Tue, Jan 18, 2011 at 6:46 PM, Boris Zbarskybzbar...@mit.edu wrote:
On 1/18/11 12:11 PM, Zachary Ozer wrote:
(Side
note: I also haven't found a browser that stops loading the resource
even if you destroy the video tag.)
destroy in what sense? You
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
fluctuations, either you have the
On 1/18/11 4:37 PM, Glenn Maynard wrote:
If you don't have enough bandwidth, then the necessary buffer size is
effectively the entire video[1]
No, it's really not. Your footnote is, of course, correct.
If my bandwidth is such that I can download the video in 2 hours, and
it's one hour long,
On Tue, Jan 18, 2011 at 5:00 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/18/11 4:37 PM, Glenn Maynard wrote:
If you don't have enough bandwidth, then the necessary buffer size is
effectively the entire video[1]
No, it's really not. Your footnote is, of course, correct.
If my
On Wed, Jan 19, 2011 at 6:11 AM, Zachary Ozer z...@longtailvideo.comwrote:
(Side note: I also haven't found a browser that stops loading the resource
even if you destroy the video tag.)
Setting the source URI to should stop the download.
Personally I think having browsers honor dynamic
I feel like we are asking this question at the wrong protocol level.
If you use the HTML5 video tag, you indicate the resource and the protocol used
to get it, in a URL.
If you indicate a download protocol, you can hardly be surprised if, well,
download happens.
If you want a more tightly
On Jan 18, 2011, at 5:40 , Boris Zbarsky 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
fluctuations, either you have the bandwidth to stream the video
On Tue, Jan 18, 2011 at 6:54 PM, David Singer sin...@apple.com wrote:
I feel like we are asking this question at the wrong protocol level.
If you use the HTML5 video tag, you indicate the resource and the protocol
used to get it, in a URL.
If you indicate a download protocol, you can hardly
On Jan 18, 2011, at 16:16 , Glenn Maynard wrote:
On Tue, Jan 18, 2011 at 6:54 PM, David Singer sin...@apple.com wrote:
I feel like we are asking this question at the wrong protocol level.
If you use the HTML5 video tag, you indicate the resource and the protocol
used to get it, in a URL.
On Tue, Jan 18, 2011 at 5:11 PM, Zachary Ozer z...@longtailvideo.com wrote:
I've heard from some people that they're a bit lost, so I wanted to
take a moment to summarize.
We have two competing interests here:
* Viewers want a smooth playback experience regardless of their
bandwidth or
On Wed, Jan 19, 2011 at 1:35 PM, Andy Berkheimer andyberkhei...@youtube.com
wrote:
As an example, I believe Chrome's current implementation _does_ stall
the HTTP connection (stop reading from the socket interface but keep
it open) after some amount of readahead - a magic hardcoded constant.
On Tue, Jan 18, 2011 at 7:32 PM, David Singer sin...@apple.com wrote:
I'm sorry, perhaps that was a shorthand.
In RTSP-controlled RTP, there is a tight relationship between the play
point, and play state, the protocol state (delivering data or paused) and
the data delivered (it is delivered
Hello all,
We are getting some questions from JW Player users that HTML5 video is quite
wasteful on bandwidth for longer videos (think 10min+). This because browsers
download the entire movie once playback starts, regardless of whether a user
pauses the player. If throttling is used, it seems
downloadBufferTarget in seconds is not that good. Think about a movie
that takes more to load than to see. Depending on the settings the
developer done, you might have to pause the video at some point to load
the rest of the movie.
On Mon, 17 Jan 2011 17:41:13 +0100, Jeroen Wijering wrote:
On 1/17/11 11:41 AM, Jeroen Wijering wrote:
This because browsers download the entire movie once playback starts,
regardless of whether a user pauses the player.
Interesting. Isn't that what Flash does as well? I know that I will
often start playing a Flash movie, then pause it and go do
Am 17.01.2011 17:41 schrieb Jeroen Wijering:
Hello all,
We are getting some questions from JW Player users that HTML5 video is quite
wasteful on bandwidth for longer videos (think 10min+). This because browsers
download the entire movie once playback starts, regardless of whether a user
On 2011-01-17 18:36, Markus Ernst wrote:
Am 17.01.2011 17:41 schrieb Jeroen Wijering:
We are getting some questions from JW Player users that HTML5 video
is quite wasteful on bandwidth for longer videos (think 10min+). This
because browsers download the entire movie once playback starts,
What no one has mentioned so far is that the real issue isn't the
network utilization or the memory capacity of the devices, it's
bandwidth cost.
The big issue for publishers is that they're incurring higher costs
when using the video tag, which is a disincentive for adoption.
Since there are
On Mon, Jan 17, 2011 at 7:19 PM, Roger Hågensen resca...@emsai.net wrote:
On 2011-01-17 18:36, Markus Ernst wrote:
Am 17.01.2011 17:41 schrieb Jeroen Wijering:
We are getting some questions from JW Player users that HTML5 video is
quite wasteful on bandwidth for longer videos (think 10min+).
On 18/01/2011 8:05 a.m., Zachary Ozer wrote:
What no one has mentioned so far is that the real issue isn't the
network utilization or the memory capacity of the devices, it's
bandwidth cost.
The big issue for publishers is that they're incurring higher costs
when using thevideo tag, which is a
On 1/17/11 4:05 PM, Silvia Pfeiffer wrote:
Assuming a browser is able to play back video in realtime, i.e. their
CPU and download bandwidth are sufficient to download video data at or
above the speed it is required in to provide continuous playback
... and that both conditions will continue
On Mon, Jan 17, 2011 at 10:15 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/17/11 4:05 PM, Silvia Pfeiffer wrote:
Assuming a browser is able to play back video in realtime, i.e. their
CPU and download bandwidth are sufficient to download video data at or
above the speed it is required in to
On Mon, Jan 17, 2011 at 4:15 PM, Boris Zbarsky bzbar...@mit.edu wrote:
If nothing else, I'm thinking things like I would like to buffer up this
3-hour-long-video so I can watch it on the plane, where my network bandwidth
will be precisely 0. Definitely as use case I've had.
That's an
On Mon, Jan 17, 2011 at 10:15 PM, Chris Pearce ch...@pearce.org.nz wrote:
On 18/01/2011 10:05 a.m., Silvia Pfeiffer wrote:
If instead the bandwidth is the limiting factor, we do want to allow
buffering ahead a fair bit such that we don't end up in a buffering
state for the user too often. In
On Mon, Jan 17, 2011 at 1:25 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Jan 17, 2011 at 4:15 PM, Boris Zbarsky bzbar...@mit.edu wrote:
If nothing else, I'm thinking things like I would like to buffer up this
3-hour-long-video so I can watch it on the plane, where my network
bandwidth
On Tue, Jan 18, 2011 at 10:08 AM, Chris Pearce ch...@pearce.org.nz wrote:
Can this not be implemented on the server side? If you know the media has
an average playback rate of X KB/s, can the server reliably throttle its
transmission at 1.5X?
Yes, it seems to me that if you simply throttle
One solution that could work here is to honour dynamic changes to 'preload',
so switching preload to 'none' would stop buffering. Then a script could do
that, for example, after the user has paused the video for ten seconds. The
script could also look at 'buffered' to make its decision.
Rob
--
On Mon, Jan 17, 2011 at 4:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jan 17, 2011 at 1:25 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Jan 17, 2011 at 4:15 PM, Boris Zbarsky bzbar...@mit.edu wrote:
If nothing else, I'm thinking things like I would like to buffer up
this
On Mon, Jan 17, 2011 at 9:08 PM, Chris Pearce ch...@pearce.org.nz wrote:
On 18/01/2011 8:05 a.m., Zachary Ozer wrote:
What no one has mentioned so far is that the real issue isn't the
network utilization or the memory capacity of the devices, it's
bandwidth cost.
The big issue for
On 1/17/11 4:25 PM, Glenn Maynard wrote:
That's an important use case, but it feels like a very different one.
From a user's point of view it's really not.
If you want to download hours of video for playing offline, you don't
want to store that in a transient read-ahead buffer--you want to
On 1/17/11 6:04 PM, Boris Zbarsky wrote:
From a user's perspective (which is what I'm speaking as here), it
doesn't matter what the technology is. The point is that there is
prevalent UI out there right now where pausing a moving will keep
buffering it up and then you can watch it later. This
On 2011-01-18 01:30, Boris Zbarsky wrote:
On 1/17/11 6:04 PM, Boris Zbarsky wrote:
From a user's perspective (which is what I'm speaking as here), it
doesn't matter what the technology is. The point is that there is
prevalent UI out there right now where pausing a moving will keep
buffering it
On 18/01/2011 4:59 p.m., Roger Hågensen wrote:
Unbuffering:
It may sound odd but in low storage space situations, it may be
necessary to unbuffer what has been played. Is this supported at all
currently?
Firefox caches media data locally on disk, and will evict data which is
unlikely to be
66 matches
Mail list logo
