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 ( https://bugs
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 deali
On Tue, Jan 18, 2011 at 7:32 PM, David Singer 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 in precisely
On Wed, Jan 19, 2011 at 1:35 PM, Andy Berkheimer 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.
> We've run into issues th
On Tue, Jan 18, 2011 at 5:11 PM, Zachary Ozer 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 device. Some viewers
On Jan 18, 2011, at 16:16 , Glenn Maynard wrote:
> On Tue, Jan 18, 2011 at 6:54 PM, David Singer 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 6:54 PM, David Singer 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 be surpris
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
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 coup
On Wed, Jan 19, 2011 at 6:11 AM, Zachary Ozer wrote:
> (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 changes to the preload
On Tue, Jan 18, 2011 at 5:00 PM, Boris Zbarsky 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 bandwidth is
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 Sun, Jan 16, 2011 at 2:44 PM, Aryeh Gregor
> 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 functionality gain, even
> accounting for the fact tha
On Tue, Jan 18, 2011 at 8:40 AM, 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 st
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 p
On 1/18/11 2:01 PM, Zachary Ozer wrote:
On Tue, Jan 18, 2011 at 6:46 PM, Boris Zbarsky 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 d
On Tue, Jan 18, 2011 at 6:46 PM, Boris Zbarsky 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
> ga
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
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
applica
On Tue, Jan 18, 2011 at 9:11 AM, Zachary Ozer wrote:
>
> 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
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 p
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
On Mon, Jan 17, 2011 at 5:01 PM, Zachary Ozer wrote:
> > 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?
>
> There are a bunch:
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 prob
2011-01-17 23:32 EEST: Silvia Pfeiffer:
> On Mon, Jan 17, 2011 at 10:15 PM, Chris Pearce 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 than what we re
On Tue, Jan 18, 2011 at 1:30 AM, 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
26 matches
Mail list logo
