Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[feature] Add Stream API for capturing video frames from WebRTC MediaStreamTrack

Open
#670 5 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
dart, flutter

Research direction

Start by reading the existing Timer-based captureFrame() usage and the RemoteRehabilitationRoomState reference in the issue, then investigate how this SDK exposes native WebRTC frame callbacks on each platform. Define what the stream emits and how frames are managed across platforms; done means a stream delivers frames at the native rate without Timer polling. The issue names no test files.

Written by the indexing model from the issue text.

Description

Is your feature request related to a problem? Please describe.
Currently, when trying to analyze video frames from WebRTC MediaStreamTrack in real-time (e.g., for ML processing), we need to use Timer to periodically capture frames using captureFrame(). This approach has several issues:

  • High CPU/Memory usage
  • UI stuttering
  • Potential frame drops
  • Inconsistent frame rate
    Describe the solution you'd like
    Add a new Stream-based API to capture video frames from MediaStreamTrack that:
  1. Provides frames as a Stream at the native frame rate
  2. Integrates directly with the native WebRTC frame callback system
  3. Has an API similar to:
Stream<VideoFrame> getVideoFrameStream() async {
// Implementation that hooks into native frame callbacks
}

This would allow more efficient frame processing without Timer polling.
Describe alternatives you've considered

  1. Current Timer-based approach with captureFrame()
  2. Custom native implementation per platform
  3. Using platform channels with event streams

The Stream API would be the most elegant and performant solution.

Additional context
Looking at the current implementation in the codebase:

  1. The current implementation uses Timer-based approach:
  captureImageTimer = Timer.periodic(
   const Duration(milliseconds: 200),
  () async {
    if (!mounted) return;
    await caputureImage(videoTrack);
   },
);

  Future<Image> captureImage({
    required VideoTrack videoTrack,
  }) async {
    try {
      final mediaStreamTrack = videoTrack.mediaStreamTrack;

      final imageByteBuffer = await mediaStreamTrack.captureFrame();

      final imageBytes = imageByteBuffer.asUint8List();

      final image = await compute(
        decodeImage,
        imageBytes,
      );
      return image;
  }
  1. The proposed Stream API could be integrated with the existing RemoteRehabilitationRoomState class, replacing the current Timer implementation:
Stream<VideoFrame> getVideoFrameStream() async {
// Implementation using native frame callbacks
}
  1. Benefits of this approach:
  • More efficient resource usage
  • Better frame timing accuracy
  • Native integration with WebRTC frame callbacks
  • Reduced CPU/Memory overhead
  • Smoother integration with ML processing pipeline

/cc @cloudwebrtc

Dominant language
Dart
Stars
421
Forks
260
Avg merge
3d 9h
Merged PRs (30d)
11

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from livekit/client-sdk-flutter

All issues in livekit/client-sdk-flutter

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.