DEV Community: Nisha Goswami

Cross-Platform Live Video App Development: Architecture, Tech Stack, Challenges, and Best Practices

Nisha Goswami — Tue, 30 Jun 2026 13:32:02 +0000

What Is Cross-Platform Live Video App Development?

Cross-Platform Live Video App Development helps to build one real-time video experience for Android, iOS, web, and desktop without maintaining fully separate native apps.

Instead of creating separate apps for iOS, Android, web, and desktop, you can use frameworks like Flutter, React Native, Kotlin Multiplatform, or .NET MAUI.

The goal is to reuse code where it makes sense, reduce development time, and still provide a smooth user experience on every supported platform.

A modern cross-platform live video app can include video calls, live streaming, webinars, screen sharing, chat, reactions, recording, user roles, analytics, and moderation.

This guide explains the architecture, tech stack, development process, challenges, security practices, differences, cost factors, and best practices so that you can make the best production-ready live video app.

Native vs Cross-Platform Development

Native development uses platform-specific tools like Swift for iOS and Kotlin for Android. It gives strong control over performance, device APIs, and platform behaviour.

Cross-platform development allows teams to share UI, business logic, API calls, and product flows. This helps small teams ship faster and maintain features more easily.

For live video, the best choice depends on product complexity, native media needs, team skills, device coverage, and the video SDK or WebRTC stack.

Common Use Cases

Cross-platform live video apps are used in many product categories where real-time human interaction improves the user experience.

Video conferencing apps
Online education platforms
Telemedicine apps
Fitness and coaching apps
Social live streaming platforms
Gaming and esports communities
Creator economy apps
Customer support tools
Enterprise collaboration platforms
Virtual events and webinars

Any business that wants users to connect live across devices can benefit from a strong cross-platform video architecture.

Choosing the Right Cross-Platform Framework

The framework you choose affects development speed, UI quality, native integration, SDK compatibility, performance, and long-term maintenance.

Flutter

Flutter is an open-source UI toolkit developed by Google that allows developers to build natively compiled applications for mobile, web, and desktop from a single codebase.
Flutter is a strong choice when one want consistent UI across Android, iOS, web, and desktop. It is popular for polished product experiences.
For live video apps, Flutter works well when the selected video SDK provides stable Flutter support and handles native media features properly.

React Native

React Native is a framework for building mobile apps using JavaScript and React.
For video apps, the main consideration is native module quality, SDK support, performance during rendering, and device permission handling.

Kotlin Multiplatform

Kotlin Multiplatform allows teams to share business logic while keeping native UI on Android and iOS. This gives better native control.
It works well for teams that want platform-specific UI quality but still want to avoid duplicating networking, models, and business logic.

.NET MAUI

.NET MAUI is useful for enterprise teams working in the Microsoft ecosystem. It supports building apps for Android, iOS, macOS, and Windows.
It may fit internal collaboration tools, enterprise communication systems, and products where C# and Microsoft infrastructure are already common.

Framework Comparison Table

Framework	Best For	Strengths	Considerations
Flutter	Consumer apps, startups, polished UI	Consistent UI, fast iteration, strong design control	Needs stable video SDK support
React Native	JavaScript teams, fast product development	Large ecosystem, easier hiring, reusable components	Native modules can add complexity
Kotlin Multiplatform	Native-first mobile apps	Shared logic with native UI	Smaller ecosystem than React Native
.NET MAUI	Enterprise apps	C# support, Microsoft ecosystem	Not ideal for every consumer product

The right choice depends on the product goal, performance needs, platform coverage, development timeline, and the video SDK or media stack being used.

Technology Stack for Cross-Platform Live Video Apps

A live video app needs multiple layers working together. These layers include frontend, backend, signaling, media servers, cloud infrastructure, databases, and observability.

Frontend Layer

The frontend handles camera access, microphone access, video rendering, speaker controls, participant list, chat, reactions, screen sharing, and room navigation.

Common frontend choices include Flutter, React Native, web apps using React or Vue, and native modules where deeper platform control is needed.

Backend Layer

The backend manages users, authentication, room creation, permissions, session records, payment logic, webhooks, notifications, and admin workflows.

Common backend technologies include Node.js, Go, Java, .NET, and Python. The best choice depends on your team's skill and scaling needs.

Real-Time Communication Layer

For interactive video calls, WebRTC is commonly used because it supports real-time audio, video, and data communication between clients.

For broadcast-style streaming, RTMP can be used for ingest, while HLS is commonly used for large-scale playback with higher latency.

Protocol	Best For	Latency Profile	Notes
WebRTC	Video calls, classrooms, telehealth, gaming	Very low	Best for interactive sessions
RTMP	Stream ingest, creator broadcasting	Medium	Often used before transcoding
HLS	Large-scale playback and recorded video	Higher	Reliable for one-to-many viewing
SRT	Reliable contribution streaming	Low to medium	Useful for unstable networks

Media Server Layer

Media servers route, forward, mix, or process audio and video streams. They are critical when moving beyond small peer-to-peer calls.

Common media server options include SFU-based systems, Janus, mediasoup, Jitsi, LiveKit, or managed videoSDK infrastructure.

Cloud Infrastructure

Cloud infrastructure provides compute, networking, storage, global regions, deployment automation, monitoring, and scaling capacity.

AWS, Google Cloud, and Azure are common choices. For live video, region selection matters because physical distance affects latency.

For broadcast and recorded playback, CDN planning is important. A CDN helps deliver video content to viewers across regions with less buffering.

Database and Cache

PostgreSQL can store structured user, room, and billing data. MongoDB can store flexible session metadata. Redis works well for presence and caching.

Most production apps use more than one storage technology because session state, recordings, analytics, and user data have different needs.

Live Video App Architecture Explained

A production-grade cross-platform live video app usually includes client apps, authentication, signaling, media routing, storage, CDN, analytics, and monitoring.

Client Layer

The client layer includes mobile apps, web apps, and desktop apps. It handles capture, rendering, controls, permissions, and user interactions.

The client should gracefully handle weak networks, permission denial, camera switching, background mode, reconnection, and audio output changes.

Authentication Service

The authentication service verifies user identity and issues secure tokens. It decides who can join, publish, subscribe, record, or moderate.

Tokens should be short-lived and role-based. A viewer should not have the same access as a host or moderator.

Signaling Server

The signaling server helps clients exchange information required to establish a media connection. It manages room state, participant events, and connection metadata.

Signaling does not usually carry actual audio or video. It helps clients and media servers connect correctly.

Media Server

The media server receives audio and video streams and forwards them to other participants. In group calls, an SFU is commonly used.

This reduces bandwidth and CPU pressure compared to full mesh peer-to-peer calls where every participant sends streams to every other participant.

Storage and CDN

Storage is used for recordings, thumbnails, chat history, logs, and compliance data. CDN integration improves playback for recorded videos and large broadcasts.

CDNs are more useful for one-to-many streaming and recorded playback than for fully interactive video calls.

Monitoring and Analytics

Monitoring tracks packet loss, jitter, latency, bitrate, dropped frames, join failure, crashes, and server health.

A live video platform without monitoring is difficult to improve because users may report quality issues without clear technical evidence.
This approach helps developers avoid building WebRTC signaling, room management, participant events, and media handling from scratch. VideoSDK already provides SDKs for platforms like Flutter, React Native, JavaScript, Android, and iOS.

How to Build a Cross-Platform Live Video App Using VideoSDK

The easiest way to build a cross-platform live video app is to use VideoSDK’s implementation flow: create a developer account, generate an auth token, create a room, join the room from your app, render participants, and add meeting controls.

This approach helps developers avoid building WebRTC signaling, room management, participant events, and media handling from scratch. VideoSDK already provides SDKs for platforms like Flutter, React Native, JavaScript, Android, and iOS.

If you are still exploring the best approach or want to understand how the implementation works, this quickstart is a good place to start. It helps you test the flow quickly and see how everything connects in practice.

Key Development Challenges and Solutions

Live video apps face different challenges from normal mobile or web apps. The app must handle real-time media, unpredictable networks, and device differences.

Network Instability

Users may join from mobile data, weak Wi-Fi, office networks, shared hostels, or public hotspots. Network quality can change during the session.

Solution: Use adaptive bitrate, reconnection, network indicators, audio-only fallback, and graceful UI messages when quality drops.

Low Latency Requirements

Interactive video needs low delay. High latency makes conversations awkward and can break use cases like support, teaching, gaming, and healthcare.

Solution: Use WebRTC for real-time sessions, nearby media servers, efficient signaling, and avoid unnecessary transcoding.

Scalability

A two-person call is simple compared to a virtual event with thousands of viewers or a classroom platform with many parallel sessions.

Solution: Use SFU architecture, distributed media servers, autoscaling, load balancing, and CDN playback for large broadcast audiences.

Device Compatibility

Different devices handle camera permissions, microphone routing, Bluetooth devices, codecs, background mode, and screen sharing differently.

Solution: Test on real devices, track device-specific failures, and choose SDKs with proven cross-platform support.

Battery Consumption

Live video uses camera, microphone, CPU, GPU, and network continuously. Poor optimization can drain mobile battery quickly.

Solution: Use hardware acceleration, efficient codecs, background handling, lower resolution when needed, and avoid unnecessary local rendering.

Audio and Video Sync

Audio-video sync issues make sessions feel unprofessional. They can happen because of buffering, jitter, processing delay, or device performance.

Solution: Use stable media pipelines, monitor jitter, avoid unnecessary media processing, and test across devices and network conditions.

Bandwidth Optimization

Group video calls can consume high bandwidth. This creates cost issues for the business and quality issues for users.

Solution: Use simulcast, adaptive bitrate, selective subscriptions, audio-only fallback, and sensible default video quality.

Cost Factors in Cross-Platform Live Video Development

The cost of building a cross-platform live video app depends less on the framework and more on how the app handles real-time media, scale, storage, and reliability.

A simple one-to-one video calling MVP can be built faster with a managed video SDK. But a large live streaming platform with recording, moderation, analytics, multi-region support, and compliance needs a bigger budget.

Key Cost Drivers

Cost Factor	What It Includes	Why It Matters
App Complexity	Video calls, live streaming, chat, screen sharing, recording, reactions, and moderation	More features increase development, testing, and maintenance effort
Platform Coverage	Android, iOS, web, desktop, tablets, and different browser versions	More platforms mean more compatibility testing and edge cases
Video Usage	Number of participants, session duration, video quality, and active rooms	Live video consumes bandwidth continuously, so usage directly affects cost
Infrastructure	Media servers, TURN servers, SFU, CDN, storage, monitoring, and scaling	Real-time video needs infrastructure built for low latency and reliability
Recording and Playback	Cloud recording, file storage, thumbnails, transcripts, and playback delivery	Storage and CDN costs grow as recorded content increases
Security and Compliance	Token access, encryption, audit logs, data retention, GDPR, HIPAA, or SOC 2 needs	Regulated apps need stronger controls and more engineering review
Maintenance	Bug fixes, SDK updates, device testing, analytics, monitoring, and support	Live video apps need ongoing optimization after launch

Startup vs Enterprise Cost Difference

Factor	Startup MVP	Enterprise-Grade App
Main Goal	Launch quickly and validate the idea	Build for reliability, scale, and compliance
Best Approach	Use a video SDK and managed infrastructure	Use SDK or custom architecture with strict controls
Feature Set	Calling, basic chat, recording, simple roles	Advanced roles, analytics, compliance, moderation, multi-region support
Testing Needs	Core device and browser testing	Wider device, network, security, and load testing
Cost Risk	Bandwidth and product changes	Compliance, uptime, security, and scale

For most developers, students, builders, and startups, the smarter approach is to avoid building the complete video infrastructure from scratch. A video SDK reduces backend complexity and helps you focus on the product experience.

For CTOs and larger teams, the cost discussion should include long-term reliability, observability, compliance, scaling, support, and vendor flexibility. The cheapest option at the beginning is not always the most cost-effective option at scale.

Build vs Buy: Should You Use a Video SDK?

One of the biggest decisions in Cross-Platform Live Video App Development is whether to build media infrastructure or use a video SDK.

When to Build From Scratch

Building from scratch may make sense if video infrastructure is your core product differentiator and your team has strong WebRTC and media engineering experience.

You should also have budget for signaling, SFU, TURN, recording, observability, scaling, security, SDK maintenance, and long-term infrastructure support.

When to Use a Video SDK

Using a video SDK is better when your team wants to launch faster, reduce infrastructure work, and focus on product experience.

A good SDK provides cross-platform support, real-time communication APIs, recording, screen sharing, analytics, webhooks, security controls, and global infrastructure.

For VideoSDK.live users, this approach helps developers add video calls, live streaming, chat, recording, and interactive features without building the media layer alone.

Video SDK Evaluation Checklist

	Criteria	What to Check
✅	Platform Support	Flutter, React Native, web, Android, iOS
✅	Latency	Real-time performance for target regions
✅	Features	Calls, streaming, recording, chat, screen share
✅	Scalability	Group calls, webinars, large sessions
✅	Security	Tokens, roles, encryption, compliance support
✅	Documentation	Quickstarts, examples, API clarity
✅	Analytics	Call quality, logs, webhooks, debugging
✅	Pricing	Bandwidth, recording, participant minutes
✅	Support	SLA, response time, migration help

The best SDK is not the one with the longest feature list. It is the one that matches your product, team, budget, and scaling plan.

Conclusion

Cross-Platform Live Video App Development is a practical approach for teams that want to deliver real-time communication across Android, iOS, web, and desktop.

The success of a live video app depends on more than choosing Flutter or React Native. Teams need the right media architecture, security model, scaling plan, and monitoring.

For most startups and product teams, using a reliable video SDK is the fastest way to launch without owning the full complexity of WebRTC infrastructure.

For enterprises, the focus should be reliability, compliance, access control, analytics, and long-term scalability across regions and devices.

If your team is planning a live video product, start with the use case, define the required features, choose the right stack, and design for real-world network conditions.

FAQs

1. What is cross-platform live video app development?

Cross-platform live video app development means building real-time video applications that work across Android, iOS, web, and desktop using shared code or reusable logic.

2. Is Flutter good for live video apps?

Yes, Flutter can work well for live video apps when the selected video SDK has stable Flutter support and handles native media performance properly.

3. Is React Native good for video calling apps?

React Native is a good choice for teams using JavaScript or TypeScript. The key is choosing reliable native modules or a strong video SDK.

4. Which protocol is best for low-latency video?

WebRTC is usually best for interactive low-latency video calls. HLS is better for large-scale playback where a few seconds of delay is acceptable.

5. How is WebRTC different from RTMP and HLS?

WebRTC is designed for real-time communication. RTMP is often used for stream ingest, while HLS is commonly used for scalable video playback.

6. What are the biggest challenges in live video app development?

The biggest challenges include network instability, latency, device compatibility, scalability, bandwidth cost, security, recording, and monitoring.

7. How can developers reduce video latency?

Developers can reduce latency by using WebRTC, nearby media servers, efficient signaling, adaptive bitrate, and avoiding unnecessary media processing.

8. Should startups build video infrastructure from scratch?

Most startups should use a videoSDK because it reduces development time, infrastructure complexity, and maintenance cost.

9. How much does it cost to build a cross-platform live video app?

The cost depends on features, platforms, team size, video infrastructure, bandwidth, recording, security, and compliance requirements.

10. Which industries benefit most from live video apps?

Healthcare, education, fitness, gaming, social media, customer support, events, creator platforms, and enterprise collaboration benefit strongly from live video.

How to Choose a Real-Time Communication API for a WebRTC App

Nisha Goswami — Fri, 26 Jun 2026 13:40:45 +0000

If you are building a WebRTC app, you are not just choosing a video SDK, You are choosing the infrastructure that will affect call quality, latency, recording, transcription, live streaming, mobile support, developer speed, and long-term scaling.

Most teams evaluate platforms like VideoSDK, Agora, Twilio, and LiveKit when building real-time video or audio features. However, the right choice depends on what your product needs beyond a basic video call.

Here are the key factors that help in choosing the right real-time communication API for a WebRTC app:

1. Cross-platform SDK support

A good RTC API should work across the platforms your users already use.
For most WebRTC products, that means support for:

JavaScript
React
React Native
Android
iOS
Flutter
Backend or REST APIs

This is one area where VideoSDK is useful because it provides SDKs across web, mobile, and backend environments. If your product roadmap includes web today and mobile later, choosing an API with strong cross-platform support helps avoid rebuilding the communication layer again.

2. Managed infrastructure instead of WebRTC complexity

WebRTC is powerful, but production WebRTC is not simple.
You need to think about:

Media routing
SFU architecture
Participant events
Network changes
Device permissions
Browser behavior
Call quality
Recording
Scaling

A managed RTC API like VideoSDK helps teams focus on the product experience instead of operating the full media infrastructure themselves. This is especially useful if your team wants to build custom video calls, in-app voice, customer support video chat, live streaming, or video collaboration without spending months on infrastructure.

3. Built-in production features

A basic video SDK may help you start a call. A production-ready RTC API should support the full workflow around that call.
Look for features like:

Group video calls
Screen sharing
Recording
Transcription
HLS streaming
RTMP streaming
End-to-end encryption
Participant controls
Webhooks
Monitoring and debugging

VideoSDK fits well here because it is not limited to simple audio/video calling. It also supports recording, transcription, HLS, RTMP, E2EE, SIP Connect, and real-time communication workflows that developers usually need after the first version of the app is live.

4. Developer experience and quickstart quality

The best real-time communication API for live video apps should be easy to test quickly.
Before choosing any platform, consider:

How easily you can create a room
How quickly you can join a meeting
Whether mic and camera controls are straightforward
How participants are rendered
The clarity of documentation
Availability of working examples

VideoSDK’s React quickstart is useful because it follows a simple flow that makes it easy for developers to move from evaluation to implementation.

5. Pricing and scaling clarity

When evaluating pricing for real-time video APIs, it is important to look beyond the base video minute cost.
A real WebRTC app may also involve:

Recording usage
Transcription
Storage
Streaming (HLS or RTMP)
TURN usage
Analytics
Mobile SDK support
Enterprise-level features

The right API is not always the cheapest one on paper. It is the one that provides predictable costs aligned with your actual product usage and growth.

Implementing a WebRTC call with the VideoSDK React Quickstart

Once you know what to look for in a real-time communication API, the next step is to test how fast you can actually build with it.

App Architecture

Prerequisites

Before proceeding, ensure that your development environment meets the following requirements:

VideoSDK Developer Account (If you don’t have one, create it from the VideoSDK Dashboard)
Basic understanding of React
Familiarity with React VideoSDK
Node.js and NPM installed on your device
Basic understanding of React Hooks (useState, useRef, useEffect)
React Context API (optional)

Token Generation

Token is used to create and validate a meeting using API and also initialise a meeting.

Important: One should have a VideoSDK account to generate a token. Visit the VideoSDK dashboard to generate your token.

VideoSDK’s React quickstart follows a simple flow:

Create a React app
Install the VideoSDK React SDK
Create an API.js file for room creation
Add MeetingProvider
Create a join screen
Add meeting controls
Render participants

Let’s walk through the same quickstart flow.

Step 1: Create a React app

 npx create-react-app videosdk-rtc-react-app
cd videosdk-rtc-react-app

Step 2: Install VideoSDK

Install the VideoSDK React package.

npm install "@videosdk.live/react-sdk"

For participant video rendering, also install react-player.

npm install "react-player"

Your basic project structure will look like this:

root
├── node_modules
├── public
├── src
│   ├── API.js
│   ├── App.js
│   ├── index.js

Step 3: Create API.js

Create a file named API.js inside the src folder.

This file will handle the API call for creating a new VideoSDK room.

// API.js

//This is the Auth token, you will use it to generate a meeting and connect to it
export const authToken = "<Generated-from-dashbaord>";
// API call to create a meeting
export const createMeeting = async ({ token }) => {
const res = await fetch(`https://api.videosdk.live/v2/rooms`, {
method: "POST",
headers: {
authorization: `${authToken}`,
"Content-Type": "application/json",
},
body: JSON.stringify({}),
});
//Destructuring the roomId from the response
const { roomId } = await res.json();
return roomId;
};

For production, do not expose the auth token directly in the frontend. Generate the token from your backend or use a backend endpoint to create rooms securely.

Step 4: Wire App.js with VideoSDK components

In App.js, import the VideoSDK React SDK components and hooks.

You will use:

MeetingProvider
useMeeting
useParticipant
VideoPlayer

// App.js

import "./App.css";
import React, { useEffect, useMemo, useRef, useState } from "react";
import {
  MeetingProvider,
  MeetingConsumer,
  useMeeting,
  useParticipant,
  VideoPlayer,
} from "@videosdk.live/react-sdk";
import { authToken, createMeeting } from "./API";

function JoinScreen({ getMeetingAndToken }) {
  return null;
}

function ParticipantView(props) {
  return null;
}

function Controls(props) {
  return null;
}

function MeetingView(props) {
  return null;
}

function App() {
  const [meetingId, setMeetingId] = useState(null);

  //Getting the meeting id by calling the api we just wrote
  const getMeetingAndToken = async (id) => {
    const meetingId =
      id == null ? await createMeeting({ token: authToken }) : id;
    setMeetingId(meetingId);
  };

  //This will set Meeting Id to null when meeting is left or ended
  const onMeetingLeave = () => {
    setMeetingId(null);
  };

  return authToken && meetingId ? (
    <MeetingProvider
      config={{
        meetingId,
        micEnabled: true,
        webcamEnabled: true,
        name: "C.V. Raman",
      }}
      token={authToken}
    >
      <MeetingView meetingId={meetingId} onMeetingLeave={onMeetingLeave} />
    </MeetingProvider>
  ) : (
    <JoinScreen getMeetingAndToken={getMeetingAndToken} />
  );
}

export default App;

MeetingProvider gives the child components access to meeting state, participant data, and meeting controls.

Step 5: Create the JoinScreen component

The join screen lets a user create a new meeting or join an existing meeting ID.

function JoinScreen({ getMeetingAndToken }) {
  const [meetingId, setMeetingId] = useState(null);
  const onClick = async () => {
    await getMeetingAndToken(meetingId);
  };
  return (
    <div>
      <input
        type="text"
        placeholder="Enter Meeting Id"
        onChange={(e) => {
          setMeetingId(e.target.value);
        }}
      />
      <button onClick={onClick}>Join</button>
      {" or "}
      <button onClick={onClick}>Create Meeting</button>
    </div>
  );
}

Output

If the input is empty, a new meeting is created. If a meeting ID is entered, the user joins that meeting.

Step 6: Create MeetingView and Controls

MeetingView handles the meeting state. It lets the user join the meeting and renders the participants once the meeting is joined.

function MeetingView(props) {
  const [joined, setJoined] = useState(null);
  //Get the method which will be used to join the meeting.
  //We will also get the participants list to display all participants
  const { join, participants } = useMeeting({
    //callback for when meeting is joined successfully
    onMeetingJoined: () => {
      setJoined("JOINED");
    },
    //callback for when meeting is left
    onMeetingLeft: () => {
      props.onMeetingLeave();
    },
  });
  const joinMeeting = () => {
    setJoined("JOINING");
    join();
  };

  return (
    <div className="container">
      <h3>Meeting Id: {props.meetingId}</h3>
      {joined && joined == "JOINED" ? (
        <div>
          <Controls />
          //For rendering all the participants in the meeting
          {[...participants.keys()].map((participantId) => (
            <ParticipantView
              participantId={participantId}
              key={participantId}
            />
          ))}
        </div>
      ) : joined && joined == "JOINING" ? (
        <p>Joining the meeting...</p>
      ) : (
        <button onClick={joinMeeting}>Join</button>
      )}
    </div>
  );
}

Now add the meeting controls.

function Controls() {
  const { leave, toggleMic, toggleWebcam } = useMeeting();
  return (
    <div>
      <button onClick={() => leave()}>Leave</button>
      <button onClick={() => toggleMic()}>toggleMic</button>
      <button onClick={() => toggleWebcam()}>toggleWebcam</button>
    </div>
  );
}

Output of Controls Component

With this, the user can join, leave, mute/unmute the mic, and turn the webcam on/off.

Step 7: Implement Participant View

Before implementing the participant view, you need to understand a couple of concepts.

Forwarding Ref for mic

The useRef hook is responsible for referencing the audio component. It will be used to play and stop the audio of the participant.

const micRef = useRef(null);

useParticipant Hook

The useParticipant hook is responsible for handling all the properties and events of one particular participant joined in the meeting. It will take participantId as argument.

const { micStream, webcamOn, micOn } = useParticipant(props.participantId);

MediaStream API

The MediaStream API is beneficial for adding a MediaTrack to the audio tag, enabling the playback of audio.

const micRef = useRef(null);
const mediaStream = new MediaStream();
mediaStream.addTrack(micStream.track);

micRef.current.srcObject = mediaStream;
micRef.current
  .play()
  .catch((error) => console.error("micElem.current.play() failed", error));

Note: Only use the MediaStream API for microphone access. The VideoPlayer component in VideoSDK automatically handles the video stream.

Now you can use both of the hooks and the API to create ParticipantView.

function ParticipantView(props) {
  const micRef = useRef(null);
  const {micStream, webcamOn, micOn, isLocal, displayName } =
    useParticipant(props.participantId);

  useEffect(() => {
    if (micRef.current) {
      if (micOn && micStream) {
        const mediaStream = new MediaStream();
        mediaStream.addTrack(micStream.track);

        micRef.current.srcObject = mediaStream;
        micRef.current
          .play()
          .catch((error) =>
            console.error("videoElem.current.play() failed", error)
          );
      } else {
        micRef.current.srcObject = null;
      }
    }
  }, [micStream, micOn]);

  return (
    <div>
      <p>
        Participant: {displayName} | Webcam: {webcamOn ? "ON" : "OFF"} | Mic:{" "}
        {micOn ? "ON" : "OFF"}
      </p>
      <audio ref={micRef} autoPlay playsInline muted={isLocal} />
      {webcamOn && (
        <VideoPlayer
          participantId={props.participantId} // Required
          type="video"
          containerStyle={{
            height: "300px",
            width: "300px",
          }}
          className="h-full"
          classNameVideo="h-full"
          videoStyle={{}}
        />
      )}
    </div>
  );
}

Step 8: Run the project

Start the React app.

npm start

Now you can:

Create a meeting
Join a meeting using a meeting ID
Toggle mic
Toggle webcam
Leave the meeting
Render participants in the call

This gives developers a practical way to evaluate VideoSDK before building a full production WebRTC app.
You can checkout the complete quick start example here.