In a previous blog (address here), we did the encoding of the collected camera data to H.264, next to how to send H.264, receive decoding and playback. Like the previous encoded blog, we also call ffmpeg.exe and ffplay.exe files, and internal specific operations require tossing.
Transmission
UDP is a connectionless transport layer protocol that does not guarantee the reliability of the transfer packet, suitable for one-time transmission of small amounts of data.
We add instructions on the basis of encoding instructions to encapsulate the encoded H.264 into UDP and send it to the multicast address.
FFMPEG -F VFWCAP -I 0 -VCODEC libx264 encoded.h264 -f h264 udp: //127.0.0.1: 6666 I am sending, testing on my computer with my own computer, so address must be: 127.0.0.1 . The following 6666 is the port number, which is set, as long as the receiving end is consistent.
Considering improving the coding speed, you can add -Preset: v UltrafAs and -Tune: V Zerolatency two options. As follows:
FFMPEG - F VFWCAP - I 0 - vcodec libx264 encoded.h264 -preset: v Ultrafast -Tune: V zerolatency -f h264 udp: //127.0.0.1: 6666 High resolution, UDP transmission will packet loss . In order to avoid this, you can add parameters-S (EG: -S 320x240) to adjust the resolution.
Similarly, the H.264 can be encapsulated into RTP and sent to the multicast address:
FFMPEG -F VFWCAP -I 0 -VCODEC libx264 encoded.h264 -preset: v Ultrafast -Tune: V zerolatency -f rtp: //127.0.0.1: 6666 >Test.sdp can also send H.264 to RTMP server:
FFMPEG - F VFWCAP - I 0 - vcodec libx264 encoded.h264 -preset: v Ultrafast -Tune: V zerolatency -f flv rtmp: // localhost / oflademo / livestream
Be
At this point, all the code of the origin is as follows:
#include
# include int main () {char * encoded = "ffmpeg -f vfwcap -i 0 -vcodec libx264 encoded.h264 -f h264 UDP: //127.0.0.1:6666 "; WINEXEC (Encoded, SW_SHOW); return 0;}
2. Receive
The function that the receiving end to be implemented is decoded and played. Here, we only need to open the transferred H.264 file in FFPlay. In the open process, the FFPlay.exe file will automatically play the H.264 decoding. As long as the ports of the UDP are consistent.
The command is as follows:
Ffplay -f h264 -analyzeduration 100000 -MAX_DELAY 100000 -FFLAGS NOBUFFER UDP: //127.0.0.1: 6666
All code in the VS engineering:
#include # include int main () {char * play = "ffplay -f h264 -analyzedure 100000 -MAX_DELAY 100000 -FFLAGS Nobuffer udp: //127.0 .0.1: 6666 "; WINEXEC (Play, SW_SHOW); Return 0;}
3. Test
First run the code:
As shown in the figure above, it is displayed in encoding. Real-time buffer XX% Full! Frame Dropped! This prompt is normal because we are real-time encoding, and it is not sure when the encoding ends. Here is a problem, that is, in the process of encoding, it is impossible to display the camera, increasing a thread is also a failure, I think it may be because the camera is actually open, so it has been occupied, so it is no longer displayed.
After running the hairpin code, run the closing code in another engineering:
Be
In the engineering directory of the originated, we find the local H.264 file, play with VLC Media Player, can be compared to the video played with the receiver.
Here, use FFMPEG to call the camera, encoding, sending, decoding, and playing all the processes of playback, and the specific code flow inside has slowed down later.
Our other product:
