高价求做一个wifi摄像头模块

工作量主要体现在软件开发上，开发ios端和wifi模块上的代码。wifi摄像头模块，我看淘宝上很多卖的。

总体延时控制在50ms还是比较有难度的 【 在 February09 的大作中提到: 】 : 要求： : 摄像头通过wifi向IOS系统的手机实时传递视频流，延时最好控制在50ms内，像素可以最低降低到480 * 480 ， 以降低延时。至少30FPS。整个wifi + 摄像头的模块尽可能便宜，控制在150元以内。 : : ...................

像素可以最低降低到480 * 480，手机与wifi模块、路由器之间距离不超过5米。 这样行吗？ 【 在 bupt1986 的大作中提到: 】 : 总体延时控制在50ms还是比较有难度的

50ms追求的是网络端的时延吧？工业和医用领域整体理想时延在130-150ms，某些特定领域理论整体时延也超过85-100ms，50ms的时延....传输协议了解一下，网络压缩了解一下，视频编解码了解一下，一般200-400ms的整体时延是正常的 1.首先一般民用视频格式里不会出现480×480这种分辨率，可以了解一下视频的基本发展过程，跟成像芯片的切割有关，就按照D1格式640×480来理解吧，假设买了一款30万像素640×480的摄像头（除了扫二维码真不觉得这种分辨率还能干什么），买高分辨率的摄像头也行，但是成像、压缩两方面会多出一些时延，根据具体视频需求领域自行选吧。 时延有： 1、成像时延一般一帧10-30ms吧，这时候光信号转换成了电信号；基本的视频处理一般都会有，一般就是白平衡之类，一般都是成像器件厂商的集成方案，也有时延，具体不清楚，就按10ms来预估吧，还有视频编码时延，基本就当等待一帧成像的时候可以涵盖了吧，咱们就按照30万像素摄像头60帧来评估，这样就不用考虑图像压缩过程的时延了，30万像素也是为了降低成像的时延毕竟1080P或者720P分辨率成像器件60帧的要极大超出楼主硬件预算，成像加编码的总体时延这就估计要到40ms了，理论上30万像素60帧率的成像延时可以控制在30ms内，但实际上要40ms之外了，起码测出来是这样，问为什么就是实际测过 2.网络延时，这个比较难说，因为没有研究过wifi的延时，只能按照固网类推，就按照理论值比固网的延时多上wifi6空分复用的理论值10ms吧。从来源上说基本就是传输协议导致的延时，再加上一帧视频封包导致的延时，毕竟一帧视频要封很多包理论上就简单按1ms吧，按tcpip来说ping一下最少还得2ms更何况还有数据传输，物流给分成小包了，整体接收还得给拼接还原一下，整体给40ms不过分吧，给wifi6传输理论上再加10ms，实际走wifi5的话150ms内都挺正常，这部分其实是时延最多的部分，理论上网络传输时延应该可以50ms，但是一言难尽，反正150ms内的话正常是很难查觉。 3.视频解码时延，p帧i帧了解一下，简单说网络中就是基本传的都是关键帧信息，要是每帧都传的话会发现时延积累的越来越多过一段时间时延可能会积累一两个小时，早期干视频的很多人都见过，所以节省带宽降低食盐，这事编解码来解决累计时延我不怕，编码会解决啊，只要两张关键帧之间的问题都可以处理，理论上30万像素视频给100ms延时足够了。 4.成像延时，这个是显卡的锅，视频解码后渲染显示的问题，估计不会太多吧。 综上整体来说200-400ms是正常的，一般视频监控低于400ms不影响观感，需要快速视频分析的再多上50-200ms，需要实施分析的给客户解释帧间关系挺麻烦的，所以尽量少追帧，不然客户一般都是你就是慢，不要解释，解释就是掩饰，掩饰就是编故事，不听不听王八念经，你就是做的不好。这也是深度学习应用在视频分析领域为啥YOLO这么受业界欢迎的主要原因之一，因为项目经理面对客户少挨骂啊，哈哈哈哈哈 需要低时延的就别走移动网络了，wifi6和5G不知道效果，起码wifi5、微波传输或者4G都能被用户喷成狗，最好是专网，走公网那数据量一旦多起来，客户又炸毛。没试过蓝牙，离得近的话比wifi更可控，楼主有需要可以尝试。 以上分析并不严谨，理论上和实践上大抵是这样，有需要还是系统的把网络和视频编解码的内容去详细看一下吧。

然而老黄的gamestream protocol在LAN中的e2e latency(甚至算上了客户端解码时延)只有十几ms，人家那还是1080p的分辨率。姑且不说成像和网络，单encoding这块您100ms的预估高了至少一个数量级。 【 在 qingyuan86 的大作中提到: 】 : 50ms追求的是网络端的时延吧？工业和医用领域整体理想时延在130-150ms，某些特定领域理论整体时延也超过85-100ms，50ms的时延....传输协议了解一下，网络压缩了解一下，视频编解码了解一下，一般200-400ms的整体时延是正常的 : 1.首先一般民用视频格式里不会出现480×480这种分辨率，可以了解一下视频的基本发展过程，跟成像芯片的切割有关，就按照D1格式640×480来理解吧，假设买了一款30万像素640×480的摄像头（除了扫二维码真不觉得这种分辨率还能干什么），买高分辨率的摄像头也行，但是成像、压缩两方面会多出一些时延，根据具体视频需求领域自行选吧。 : 时延有： : ...................

游戏流的成像和视频成像应该是有差异的，并且我是简单以H.264的通用格式为例来说，老黄的编码格式不清楚你可以自己搜一下，绝对不止100ms，我在计算100ms的时候是简单暴力的把系统内部与网络相关实验都进行了计算，包括解码、内存等一系列步骤，有兴趣的话楼上可以对串流游戏的视频流缓冲进行一下分析，实际游戏体验其实是感觉不到延时的，因为没有延时的对比，因为实时视频的延时有场景对比，游戏那边完全是缓存之后的体验，没有可对照性 【 在 Zelda 的大作中提到: 】 : 然而老黄的gamestream protocol在LAN中的e2e latency(甚至算上了客户端解码时延)只有十几ms，人家那还是1080p的分辨率。姑且不说成像和网络，单encoding这块您100ms的预估高了至少一个数量级。 :

另外同学你可能没仔细看内容，编码这款时延在我计算中基本是忽略了的，因为帧间成像有时延所以编码这块基本不存在时延，视频解码需要在得到两个关键帧数据之后进行，而游戏是由缓存时间的，所以对游戏体验来说因为缓存万全体验不到，但对实时视频来说100ms的预估是确实存在的，尤其是有视频和实际场景对照的情况下确实存在，1080P解码的时延在400ms内都属于正常，2K的时延基本要求700ms左右了，跟设备cpu和内存的频率和编码规则都有有关系的 【 在 Zelda 的大作中提到: 】 : 然而老黄的gamestream protocol在LAN中的e2e latency(甚至算上了客户端解码时延)只有十几ms，人家那还是1080p的分辨率。姑且不说成像和网络，单encoding这块您100ms的预估高了至少一个数量级。 :

游戏中你看到的那个时延值是显示系统的时延，简单来说就是你计算机端渲染图像的值 【 在 Zelda 的大作中提到: 】 : 然而老黄的gamestream protocol在LAN中的e2e latency(甚至算上了客户端解码时延)只有十几ms，人家那还是1080p的分辨率。姑且不说成像和网络，单encoding这块您100ms的预估高了至少一个数量级。 :

https://new.qq.com/rain/a/20221024A03CUH00 找到一篇介绍串流游戏理论时延的资料，但是理论和实际一言难尽，换句话说在带宽足够不考虑网络时延的情况下1080P的串流游戏理论时延也就100ms，如果这么算的话其实视频成像的整体理论时延可以到50-80ms，但实际在这个行业干了十年的表示一言难尽