[eugene-mux]

Description

Fix two correctness issues found during HEVC/4K acceptance testing: a captured Pixel HLG video fell back before tone mapping, and a true 60 fps source could be unnecessarily converted to 30 fps.

Changes

• Support one leading empty edit followed by one media edit, retaining the A/V gap and requiring one consistent extractor timestamp convention. Complex edit sequences remain unsupported.
• Calculate measured frame rate from container precision before rounding timestamps to microseconds.
• Add three regression tests for edit-list handling, inconsistent timestamps, and frame-rate boundaries.

Validation

• 304 debug and 304 release unit tests passed; SDK/sample release builds and release lint passed.
• Sauce Labs checks on Pixel 8 Pro, Galaxy S23, and Galaxy A02, plus Android 6.0 virtual runtime. The corrected Pixel HLG recording converts, and Pixel/S23 4K60 outputs retain all 300 frames at 60 fps.
• 21 real Mux acceptance journeys reached ready, including pause/resume and process-death restoration. Mux network tests ran on an emulator, including byte-verified outputs generated on physical phones.

---

Note

Medium Risk
Changes core ISO timeline proofing and frame-rate measurement that drive convert-vs-upload decisions; scope is bounded by stricter edit rules and new tests, but misclassification could still affect real device captures.

Overview
Fixes two upload-planning correctness bugs from HEVC/4K acceptance: sources with a leading empty edit (common A/V gap on phone recordings) were treated as unsupported, and true 60/120 fps streams could measure slightly above policy and trigger unnecessary downconversion.

ISO edit-list handling now proves exactly one optional empty edit followed by one unit-rate media edit. The reader shifts timelines by the movie-time gap, preserves audio/video start offset, and extends PlatformTimestampMatcher with a per-track rounded-gap convention so extractors that snap the gap to the nearest media tick still pass a full-sample consistency check. Other edit patterns (multiple media edits, repeated empties) stay explicitly unproven.

Measured frame rate in VideoSampleFactsReader uses the effective presentation span in container seconds instead of a span derived from microsecond-rounded PTS endpoints, avoiding boundary drift (e.g. 60 → 60.000004 fps) that failed frame-rate compliance and forced 30 fps output.

Regression tests cover leading empty audio edits, rejected complex edit lists, and 60/120/60.01 fps planning at 4K.

^{Reviewed by Cursor Bugbot for commit a8675ed. Bugbot is set up for automated code reviews on this repo. Configure here.}