Commit 61b3df2
test: feed frames continuously when publishing buffer tracks
`publishManyTracks` captured a single frame before each `publish(videoTrack:)`
and discarded `CVPixelBufferCreate`'s result, so a failed allocation captured
nothing at all. `BufferCapturer` documents both halves of what that breaks:
`capture(_:)` is meant to be called repeatedly, and dimensions must resolve
before publishing or the publish times out — they come only from a real frame,
not from `BufferCaptureOptions(dimensions:)`.
Server logs show the effect: five of six tracks published in 2-6ms each, then
video-2 sat for 10.6s and failed with `Timed out` without any `add_track`
reaching the SFU.
Keep frames flowing until publish returns, matching how
`PublishBufferCapturerTests` drives its buffer track. A fresh buffer per capture
keeps anything non-Sendable out of the feeding task, and `#require` replaces the
discarded allocation result.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>1 parent d443dd8 commit 61b3df2
1 file changed
Lines changed: 22 additions & 6 deletions
Lines changed: 22 additions & 6 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
348 | 348 | | |
349 | 349 | | |
350 | 350 | | |
351 | | - | |
352 | | - | |
353 | | - | |
| 351 | + | |
| 352 | + | |
| 353 | + | |
| 354 | + | |
| 355 | + | |
| 356 | + | |
| 357 | + | |
| 358 | + | |
| 359 | + | |
| 360 | + | |
354 | 361 | | |
355 | | - | |
356 | | - | |
357 | | - | |
| 362 | + | |
| 363 | + | |
358 | 364 | | |
359 | 365 | | |
360 | 366 | | |
| |||
392 | 398 | | |
393 | 399 | | |
394 | 400 | | |
| 401 | + | |
| 402 | + | |
| 403 | + | |
| 404 | + | |
| 405 | + | |
| 406 | + | |
| 407 | + | |
| 408 | + | |
| 409 | + | |
| 410 | + | |
395 | 411 | | |
396 | 412 | | |
397 | 413 | | |
| |||
0 commit comments