[Bug 19676] New: timestampOffset accuracy

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676

          Priority: P2
            Bug ID: 19676
                CC: acolwell@chromium.org, mike@w3.org,
                    public-html-media@w3.org
          Assignee: adrianba@microsoft.com
           Summary: timestampOffset accuracy
        QA Contact: public-html-bugzilla@w3.org
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: pal@sandflow.com
          Hardware: All
            Status: NEW
           Version: unspecified
         Component: Media Source Extensions
           Product: HTML WG

Time offsets and durations within media streams, e.g. to specify splice points,
are often expressed in multiples of video frame or audio sample durations.
These durations are therefore typically rational* numbers, e.g. 1/24,
1001/30000, 1/48000, etc. 

As a floating-point double, timestampOffset cannot exactly represent such
rational time offsets. For instance, (double) ((1/24)*17) < 17*1/24 < (double)
(17/24) -- at least in Win32 python.

Accuracy can be important when a splice point needs to fall on a specific frame
boundary or when comparing multiple timestampOffset. For instance, depending on
how it was calculated, (double) (17/24) might actually fall either within the
16th frame or the 17th frame, instead of the boundary between the 16th and 17th
frame.

Potential approaches include:

- specifying rounding and closest frame boundary selection algorithms
- expressing timestampOffset as a rational (the implementation could store this
internally as it wishes)

* Many container formats (ISO BMFF, MXF...) express durations and offsets as
rationals, e.g. as integer multiples of a rational timescale expressed as the
ratio between an integer numerator and an integer denominator.

-- 
You are receiving this mail because:
You are on the CC list for the bug.