W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2012

[Bug 18400] New: Define and document timestamp heuristics

From: <bugzilla@jessica.w3.org>
Date: Wed, 25 Jul 2012 15:32:21 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-18400-2486@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18400

           Summary: Define and document timestamp heuristics
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Media Source Extensions
        AssignedTo: adrianba@microsoft.com
        ReportedBy: acolwell@chromium.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org


There are several situations where heuristics are needed to resolve issues with
the timestamps in media segments. The following list indicates issues the
Chrome team has encountered so far :

1. How close does the end of one media segment need to be to the beginning of
another to be considered a gapless splice? Media segments can't always align
exactly, especially in adaptive content, and they may be close but don't
overlap.

2. How far apart do track ranges need to be for the UA to consider media data
to be missing? For example:  audio [5-10) video [5.033-10) and I seek to 5.
Technically I don't have video @ t=5, but the UA should likely allow the seek
to complete because 5.033 is "close enough".

3. How close do timestamps need to be to 0 to be equivalent to t=0? Content may
not always start at exactly 0 so how much room do we want to allow here, if
any? This may be related to #2, but I wanted to call it out just in case we
wanted to handle the start time slightly differently.

4. How should the UA estimate the duration of a media segment if the last frame
in the segment doesn't have duration information? (ie WebM clusters aren't
required to have an explicit cluster duration. It's possible, but not required
currently)

5. How should SourceBuffer.buffered values be merged into a single
HTMLMediaElement.buffered? Simple range intersection? Should heuristic values
like estimated duration (#4) or "close enough" values (#2) be applied before
computing the intersection?


Text needs to be added to the spec to address these questions.

-- 
Configure bugmail: https://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 Wednesday, 25 July 2012 15:32:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 July 2012 15:32:28 GMT