Welcome to the network streaming chapter of the NexVDO SDK practical tutorial! In previous chapters, we learned how to capture frames, take snapshots, and save video to a local hard drive. However, in many practical application scenarios (such as security surveillance centers, remote medical surgery live broadcasting, or drone video transmission), we need to "broadcast in real-time" the video to the network so that remote computers or mobile phones can also watch it synchronously.
To solve this need, the NexVDO SDK provides an extremely powerful Broadcast Server Engine. Developers do not need to delve into complex underlying network protocols; with just a few lines of code, your device can instantly transform into a professional RTSP stream server!
💡 Core Concept: Why does streaming require "hardware compression"? (The battle between bandwidth and data volume)
Before we start writing code, there is an important concept to clarify. Many beginners often have a misconception when doing video streaming: "Can I just throw the video captured by the capture card directly onto the network?" The answer is: Absolutely not!
Let's do a simple math problem: An uncompressed raw video (Raw Data) with a 1920x1080 resolution at 60 frames per second (60FPS) will generate a massive data volume of up to about 370 MB/s. However, the bandwidth limit of our common local area networks is generally only around 100 MB/s.
If you try to force a massive 370 MB/s of data into a network cable with only 100 MB/s bandwidth, the result will be an instant network paralysis, and the video viewed remotely will suffer from severe "Frame dropped" or even "Incomplete frame".
This is why we need the "compression" feature of the Broadcast Server Engine! By calling the underlying hardware encoder through the NexVDO SDK, we can compress the original 370 MB/s uncompressed video into a lightweight stream of only 32 MB/s (or even lower) using the H.264 format. In this way, the video can easily and smoothly shuttle through the 100 MB/s network channel, achieving perfect smooth playback.
After understanding this physical limitation, you will understand why setting the video and audio compression format is the most critical step in starting the RTSP server in the upcoming API implementation! Today, we will combine the Callback feeding mechanism we learned earlier to build an RTSP live streaming application that allows all devices in the local area network to connect and watch!
👉 For Callback concepts, you can review: 10-5 Callback and Image Snapshot Example
The logic for establishing an RTSP server is actually very similar to the Share Record feature from the previous chapter: "Create Engine ➔ Set Properties ➔ Start ➔ Feed Data in Callback".
The standard usage sequence is as follows:
QCAP_CREATE_BROADCAST_RTSP_SERVER：Create the RTSP server engine.QCAP_SET_VIDEO_BROADCAST_SERVER_PROPERTY ：Set the video compression properties of the server.QCAP_SET_AUDIO_BROADCAST_SERVER_PROPERTY： Set the audio compression properties of the server.QCAP_START_BROADCAST_SERVER：Start the RTSP server engine.QCAP_SET_VIDEO_BROADCAST_SERVER_UNCOMPRESSION_BUFFER：Continuously feed uncompressed video Buffers in the Callback.