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
Hey, Emiliano! I'm going to snip your actual questions, as they're rather long.
1) The specification does not define any mechanism for an application
using the microdata to deal with possible misuses of data
vocabularies.
The spec completely specifies how to extract the data. What
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
Am 18.01.2011 18:11 schrieb Zachary Ozer:
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 that some browsers don't respect the
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 Sun, Jan 16, 2011 at 2:44 PM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
If we just have a boolean, it's unambiguous: the properties are all
logically separate. We don't want to emulate the DOM selection API,
IMO -- it's ridiculously complex for minimal
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
Thank you for the reply, it took some time going through the algorithm
and I should have looked there first. But, It still does not explain
what an implementation should do with the results already found before
encountering the loop and failing. I'll take it that this is up to the
application
I'm really happy to see that Chromium has landed a fix for frame-accurate
seeking, making SMPTE timecode compliant operations with HTML5 video
possible.
The fix for Firefox is underway (
https://bugzilla.mozilla.org/show_bug.cgi?id=626273 ) and I have filed bugs
at both Webkit/Safari (
26 matches
Mail list logo
