W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2011

[Bug 14260] <track> "text tracks ready" and HTMLMediaElement.readyState

From: <bugzilla@jessica.w3.org>
Date: Mon, 03 Oct 2011 08:05:18 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RAdWY-0007Yj-Vd@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14260

--- Comment #9 from Simon Pieters <simonp@opera.com> 2011-10-03 08:05:16 UTC ---
(In reply to comment #8)
> The idea here is that it would be as bad to start playback without the enabled
> tracks loaded as it would be to start playback without the audio or video track
> loaded. With audio and video, we can do incremental loading, which is good.
> With the text tracks, we can't, but they're small, so it's not a big deal.

Right.

> Maybe the solution is to prevent <video> from getting to HAVE_CURRENT_DATA at
> any time there are outstanding loads? (But then we'd need a way to load
> metadata them in the background without blocking.)

That's not much better than the status quo (you wouldn't render the first
frame).

> There'd still be a race if
> the parser stalled after <video> and before <track> for long enough for the
> video itself to load, but then as soon as a subtitle track was enabled the
> video would pause again while it loaded.
> 
> I'd like to avoid depending on </video>, but we do have precedent for that
> (with </object>). So it's not the end of the world if we do it.

Indeed, I think we need to wait for </video>. I also prefer Philip's suggestion
to let the "got video end tag" flag and the tracks' readyState influence the
autoplaying flag instead of influencing the video's readyState.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 3 October 2011 08:05:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:05 UTC