Skip to content

CI: run the H.264 video_sender E2E on Windows too#48

Merged
nus merged 1 commit into
mainfrom
topic/windows-e2e-h264
Jun 10, 2026
Merged

CI: run the H.264 video_sender E2E on Windows too#48
nus merged 1 commit into
mainfrom
topic/windows-e2e-h264

Conversation

@nus

@nus nus commented Jun 10, 2026

Copy link
Copy Markdown
Owner

Summary

  • The Windows E2E job filtered video_sender_test to vp8 video frames, leaving the H.264 variant Linux-only.
  • video_sender is a unidirectional harness (Dart sends, the browser only decodes — no bidirectional ICE), so it is not affected by the cross-interface DTLS-direction flakiness that keeps the webdartc-as-offerer scenarios (1/2/3, packet-loss) off Windows.
  • Broaden the selector vp8 video framesvideo frames so it matches both the VP8 and H.264 video_sender tests, and correct the stale comment that lumped this H.264 sender in with the flaky bidirectional scenarios.

Why it's safe on Windows

  • OpenH264 is bundled (fetched by the build hook) and Chrome for Testing ships an H.264 decoder.
  • Verified locally on Windows: the H.264 video_sender variant passes 10/10.
  • The webdartc-as-offerer scenarios remain excluded — they still fail consistently on Windows (ICE reaches connected, then cross-interface UDP sends fail with errno 1214/1231 and the DTLS direction is dropped). Those need a transport-layer fix, tracked separately.

Test plan

  • dart test test/e2e/video_sender_test.dart -n "h264 video frames" ×10 on Windows — 10/10 pass.
  • CI Windows E2E job runs both vp8 and h264 video_sender and stays green.

🤖 Generated with Claude Code

The Windows E2E job filtered video_sender to `vp8 video frames`, leaving
the H.264 variant Linux-only. video_sender is a unidirectional harness
(Dart sends, the browser only decodes — no bidirectional ICE), so it
isn't affected by the cross-interface DTLS-direction flakiness that
keeps the webdartc-as-offerer scenarios off Windows. Verified locally:
the H.264 variant passes 10/10 on Windows (OpenH264 is bundled and
Chrome for Testing ships an H.264 decoder).

Broaden the selector to `video frames` so it matches both the vp8 and
h264 video_sender tests, and correct the stale comment that lumped this
H.264 sender in with the flaky bidirectional scenarios.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@nus nus merged commit be68491 into main Jun 10, 2026
15 checks passed
@nus nus deleted the topic/windows-e2e-h264 branch June 10, 2026 14:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant