前言
在当今的音视频处理领域，FFmpeg无疑是一个强大的工具，它能够实现各种复杂的音视频编解码、转码、流媒体处理等功能。然而，在实际应用中我发现在某些场景下，使用FFmpeg进行推流工作并不是最佳选择。相反，我更倾向于使用socket来实现推流工作。在这篇博客中，我将详细介绍为什么我会选择socket而不是FFmpeg来进行推流工作，以及如何利用socket实现高效的推流方案。希望这篇文章能为广大音视频开发者提供一些有益的参考和启示。
ffmpeg&socket简介
FFmpeg获取原始音视频数据并封装成数据包，然后进行编码转换等工作，最后通过特定协议（如RTMP）推送到服务器。由于ffmpeg过于成熟，在网上对于ffmpeg的介绍也比较多因此这里就不过多的对它进行介绍。
socket库是一种用于实现网络通信的模块。它基于BSD Sockets API，并提供了高级的接口以供程序员使用。套接字，或称为Socket，是计算机网络中用于数据交换的数据结构。在网络通信开始之前，需要创建套接字来实现数据的发送和接收。套接字可以被看作是电话插孔，没有它将无法进行通信。
使用比对
在python中我们使用opencv读取视频流或者摄像头然后调用ffmpeg进行推流工作往往需要借助其他工具进行开端口，例如使用EasyDarWin、ffmpeg-server和nginx等进行开启rtsp或rtmp端口，这里我们势必会增加消耗。 使用socket的话则不必借助其他工具进行开端口，socket库自身即可设定tcp端口(未被占用)通过下面这段代码可输出一个可用的端口号便于后续使用。
scss
复制代码
import socket def get_random_tcp_port(): with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s: s.bind(("", 0)) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) return s.getsockname()[1] random_tcp_port = get_random_tcp_port() print("随机选择的TCP端口是：", random_tcp_port)
数据比对
在这里我们对于同一图像进行数据传输，这里采取了调用ffmpeg与socket库进行比对:
| 方法 | 数据型 | 数据量 | 协议 |
| opencv+ffmpeg | bytes | 451584 | rtsp\rtmp |
| opencv+socket | bytes | 69366 | tcp |
| opencv+encode+socket | bytes | 18304 | tcp |
相对于FFmpeg，使用socket实现推流工作有以下几点优势：
- 低延迟：基于socket的推流方式能实现较低的延迟，对于实时性要求较高的应用场景非常有利。
- 稳定性高：socket方式传输的数据包较小，因此在网络状况不佳的情况下，也能保证推流的稳定性。
- 协议灵活：socket方式允许我们自定义协议，这使得我们能够更好地满足特定需求，而FFmpeg虽然支持多种流媒体协议如RTSP、HLS、RTMP等，但其协议是固定的。
- 兼容性好：socket方式可以在不同平台和设备上进行推流，具有良好的通用性和兼容性。
- 控制能力强：通过socket，我们可以更好地控制数据传输的过程，例如可以方便地实现循环推流。
总结：
由于测试的画面不便于上传，这里请原谅我没有放比对的图像（192010803的图像延迟在0.5秒左右）。因此在实际需求来选择合适的技术方案。在某些特定场景下，如实时性要求较高、对协议有特殊需求或需要跨平台兼容等情况下，使用socket实现推流工作可能是一个更好的选择。
