Closed Bug 1916305 Opened 6 months ago Closed 3 months ago

sample appended after truncation to zero-duration with appendWindowEnd

Categories

(Core :: Audio/Video: Playback, defect)

defect

Tracking

()

RESOLVED FIXED
134 Branch
Tracking Status
firefox134 --- fixed

People

(Reporter: karlt, Assigned: karlt)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

https://pernos.co/debug/jm31IX8m_dYmE21IFNorXA/index.html records a case where a sample is appended even though truncated to zero-duration by appendWindowEnd.
This happens because the (microsecond resolution) append window end is converted to the sample time base after intersection.

Arguably, the zero-duration sample might be a better approximation of the behavior expected by the client, but mAppendWindow is rounded to microseconds and so does not provide a true indication of what the client is requesting.

The spec allows dropping such a truncated frame:

If frame end timestamp is greater than appendWindowEnd, then set the need random access point flag to true, drop the coded frame, and jump to the top of the loop to start processing the next coded frame.
Some implementations MAY choose to collect coded frames with presentation timestamp less than appendWindowEnd and frame end timestamp greater than appendWindowEnd and use them to generate a splice across the portion of the collected coded frames within the append window at time of collection, and the beginning portion of later processed frames which only partially overlap the end of the collected coded frames. Supporting this requires multiple decoders or faster than real-time decoding so for now this behavior will not be a normative requirement. In conjunction with collecting coded frames that span appendWindowStart, implementations MAY thus support gapless audio splicing.

Blocks: 1849216

Whether a sample is fully contained is calculated using double precision
representations as specified, which uses the append window values precisely as
provided.

The optional inclusion of a truncated frame overlapping the append window is
determined based on the timescale of the frame, so as to skip the frame if the
intersection duration would be zero.

FromSeconds() rounds to nearest and so the end time of the truncated frame is
now rounded to the nearest point at timescale resolution.
ToBase<RoundingPolicy> defaulted to TruncatePolicy and so would truncate even
when the double precision appendWindowEnd was intended align with the frame
end.

Summary: zero-duration sample with appendWindowEnd → sample appended after truncation to zero-duration with appendWindowEnd
Pushed by ktomlinson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e52256bac205 Remove microsecond rounding of appendWindowStart and appendWindowEnd r=alwu
Pushed by ktomlinson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/bd77c1032a62 Test appendWindowEnd and frame end timestamp rounding r=alwu
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/49324 for changes under testing/web-platform/tests
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 134 Branch
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: