Add live-streaming load-test example + expose RTP timestamp#1177
Draft
cloudwebrtc wants to merge 1 commit into
Draft
Add live-streaming load-test example + expose RTP timestamp#1177cloudwebrtc wants to merge 1 commit into
cloudwebrtc wants to merge 1 commit into
Conversation
New `examples/live_streaming` binary: one publisher publishes a scrolling simulcast H.264 test-pattern track (no camera needed); N subscribers (40 by default) join at random times within a short window and immediately request the highest simulcast layer. Publisher and subscribers run as separate subcommands (`publisher` / `subscriber`) or together (`all`); each subscriber runs on its own OS thread with a dedicated tokio runtime. To let the subscriber report the RTP timestamp of its first frame, add an `rtp_timestamp: u32` field to `VideoFrame`, populated from the received frame in the native video sink (0 on locally-captured frames). Update the other `VideoFrame` construction sites accordingly.
Contributor
No changeset foundThis PR modifies the following packages but doesn't include a changeset: Directly changed:
Click here to create a changeset The link pre-populates a changeset file with If this change doesn't require a version bump, add the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
New
examples/live_streamingbinary: one publisher publishes a scrolling simulcast H.264 test-pattern track (no camera needed); N subscribers (40 by default) join at random times within a short window and immediately request the highest simulcast layer. Publisher and subscribers run as separate subcommands (publisher/subscriber) or together (all); each subscriber runs on its own OS thread with a dedicated tokio runtime.To let the subscriber report the RTP timestamp of its first frame, add an
rtp_timestamp: u32field toVideoFrame, populated from the received frame in the native video sink (0 on locally-captured frames). Update the otherVideoFrameconstruction sites accordingly.Before you submit your PR
Make sure the following is true before submitting your PR:
PR description
Describe the changes in this PR. Explain what the PR is meant to solve and how to reproduce the issue in the first place.
Breaking changes
If this PR introduces breaking changes, list them here and document the rationale for introducing such a change.
MSRV
If the PR modifies the crate's MSRV (Minimum Supported Rust Version), document it here.
Testing
Ideally, unit test the code you add, but ensure you're not repeating existing test cases. Use as many already written scaffolding, utilities as possible; write your own, when needed. If external services, APIs, tokens are required (e.g., running an LK server instance), provide the necessary information. Make sure your tests perform useful, context-aware assertions and do not simply emulate "happy paths".
Async
We want the project to be runtime-agnostic, so please reuse what's already in livekit-runtime and feel free to add anything missing. It's ok to use Tokio directly, when writing unit tests, if necessary. When testing, do not use artificial delays for the state to "catch up"; instead, respect the event flow and subscribe properly using channels or other mechanisms.