为什么生长引起的增加质量nekachestva，或是否工作的主要功能 Bashny.Net

愚蠢的争论与模拟过去的央视事情的事实：廉价的IP摄像头提供昂贵的模拟图像质量相媲美。此外，IP摄像机是通过无界任何东西，除了性能的注册，而模拟摄像机需要严格遵守的接收卡，匹配的信号发射器/放大器/接收器和其他萨满教的水平。
设计一个系统的基础上，随时可将相机中删除，并通过更好的替代IP摄像机 - 如果仍然保留IP地址和登录密码，你可能甚至没有改变接收器的设置 - 只要到归档更好的画面< BR /> 在另一方面，它规定了接待员的限制 - 他必须准备工作在任何决议，任何比特率，任何编解码器和任何协议......好吧，或者至少与声明的正常工作
。


在软件世界里，有两种方式 - 有Linux的方式：小程序的集合，其中每个使得一个功能，但它是很好的;并有Windows的方式：这是一个巨大的食品加工，可以做一切，多一点。主要的问题Linux的方式 - 是缺乏界面。为了让吸烟的所有好处都法力（或至少读--help），和实验。而刚刚弄清楚是什么，可以结合什么，以及如何。的窗口程的主要问题 - 为主要功能的丧失。很快就污染dop.funktsionalom失去了关键的功能测试，最终的问题，甚至开始和他一起。并由此开始的惯性思维，“这是主要的功能，它是广泛的测试，最重要的是，不能有一个bug，用户做错事»。

现在去我们的羊：现在有在IP相机的质量稳步提高。任何人谁看到安装在同一个地方的不同的FullHD摄像机前的地方甚至出现了ultrakrutaya 700TVL，不会想回去（更何况现在是差不多的价格）。进一步的发展导致了一个事实，即在相机3MP（2048×1536）和5MP（2592×1944）的情况并不少见。唯一的价格更好的质量 - 存储和传输成本上升。然而，其价格GB的硬盘驱动器具有长瀑布（和从洪水相当回收在工厂），因此，是没有问题的。

就在今天，有一个与 maxlapshin 的话题小小的争执软件制造商的任何用户，售后与否。是的，任何软件出售“原样”没有任何承诺。因此，即使付出很多东西，你没有得到的事实，即使是工作软件。这是只有当软件无法正常工作，并且它被称为 - 客户的流量将用完的一天。虽然是买来的，bug修复的证据（甚至更多的话，功能的实​​现）下的大问题。

完成录入，看到一个小，但非常显著的视频（你甚至不能收看 - 在stop.kadre看到的一切）：


这本教科书的毛刺，我看几乎所有的软件设计的视频录制。我看到这个在VideoNet，经常看到轴心自控接下来，你可以看到在视频 - 这跟我打招呼Trassir。同样的独木舟，甚至在自己的相机取景器。这将有可能注销所有问题和相机。可以归因于该网络。可在CPU上的高负载。可能的电磁干扰。它可能是可取的检查存储器。您可以重装系统。在一般情况下，该方法的程序，而不是使一个人<一href="http://pikabu.ru/story/idet_muzhik_po_ulitse_smotrit_novyiy_magazin_day_dumaet_zaydu_91793">принести厕所 ...
这里只是连接到相同的流过VLC RTSP没有文物和毛刺 - 没有。在同一计算机上运行余nakolenny测试脚本读取从流和相机写入磁盘 - 和无损耗和无问题，因此是唯一的一种方法 - 以降低照相机的分辨率和比特率缩减

也就是说，尽管灵活性，声称它是相机对ONVIF和RTSP工作堆...无论如何，你不能接受，因为还没有准备好为它的IP监视软件的任何优势。

主要的原因行为，奇怪的是，在IP网络中，编解码器和...... 污水。

这样，以开始，简要基本理论在一个IP网络。在所有运行在网络中袋的形式。每个包具有最大大小（MTU，1500常规LINC），发送者和接收者。袋一旦沿途并在端转发到到达收件人。无法达成。可能导致伤害。一块可以来...在一般情况下，可能的选择。这些袋缠绕在传输协议顶部：UDP和TCP（我们感兴趣）。 UDP的没有什么变化，但是有发送方和目的地端口以允许数据包彼此共享的端口;和TCP拧一堆逻辑，即“保证交货。”更确切地说 - 保证交付或产生错误，如果事情无法传送。嗯...承诺保证（承诺 - 不结婚;）任何管理员多次看到“挂起”连接在同一移动互联网上，例如）
。
由于TCP保证交付？一个简单的 - 每个数据包必须被确认。没有证据一段时间 - 包丢失 - 这，转载。但是，如果每个分组等待确认 - 速度下降可怕，而且越，较高通信点之间的延迟。因此引入了“窗口”的概念 - 我们可以不经确认发送最多N个数据包，然后等待确认。别急，太多的证据N - 接收器也将发送和接收的每个没有确认，只是“最大的愿景”。然后证据是以下。并确认可以一起发送的数据包被发送，因此没有得到两次了。在一般情况 - 海的逻辑，所有这些都是为了交付承诺的履行，但信道的最大利用率。窗口大小 - 摇摆不定，并通过基于巫术，设置，天气在火星上的系统选择。加，改变了工艺物流。后来触及这一点。

所以，现在让我们看一下我们的羊 - H264在RTSP。 （事实上​​，它几乎没有关系 - 什么是编解码器是什么，传输协议，不要以为，如果你使用的任何协议的天才，有时更容易RTSP，这不关你的事。）。进料组成的周期性重复的关键帧，并从当前状态的流量变化。通过连接到视频要等待一个关键帧，然后我们把它的当前状态，然后采取diff文件，并突出显示。这是什么意思？这意味着，每X秒苍蝇大量的数据 - 全画幅。和相机的更多，更高的分辨率和更高的比特率（虽然说实话，比特率对关键帧的大小影响不大）。所以，在这里我们有时间0 - 在这一次到达全画幅起始关键帧（例如，我们有相机中的所有3 megapiselya - 是2048×1536 = 3145728个像素后压缩是可怜〜360 KB）。总流量我们有8兆位= 1兆字节，关键帧，每5秒钟，FPS = 18。然后，我们将有类似360K，52K，然后每隔1/18秒，5秒钟后再次360K，然后再次在52K。

现在再次回到UDP和TCP。谁来到网卡袋折叠到缓冲区网卡和处理器把标志（或中断）有数据。处理器暂停执行一切有用的，从一个地图包翻出，并开始上升，他脱衣服的TCP / IP堆栈。在最高优先级的处理（用于与铁工作）这一过程。但是，我们仍然是Windows或Linux，或任何不是RTOS，所以不能保证何时能拿到这个包的应用程序。因此，只要系统计算出什么样的包，向其中的连接是，包试图满足缓冲器。
在UDP：如果在缓冲区没有空间，则数据包将被丢弃
。 对TCP：如果在缓冲区没有空间，流量控制算法包括 - 发送者发出一个信号溢出，他们说闭嘴，而我没有动摇自己一点点。一旦应用程序需要一些数据从缓存，系统会发送“OK，开车更多»发送通讯恢复。

现在，让我们把一切写出来的相机数据如何接待。对于一个开始 - 一个简单的案例UDP。摄像头读取下一帧，将其放在逼尿肌括约肌得到的裁员压缩数据包，添加标题和发送接收方。收件人收到的第260 UDP数据包，然后暂停，另外40包，暂停，另外40包，等等。第260 UDP数据包到达瞬间 - 地方30毫秒;并已经在55Y到达下一个40毫秒（另外4毫秒）。假设我们有缓冲器128千字节。然后，他们将比分为10毫秒。如果在那个时候，应用程序将不会清空缓冲器中的单个脉冲串校对所有的（实际读取一次在一个封装...） - 我们将失去的关键帧的其余部分。既然我们没有RTOS，应用程序可以强制“休眠”以任何理由（如OS复位中buffer to disk），在同一时刻，只有这样，不要失去任何东西 - 你需要有一个网络缓冲区大小大于我们所能睡眠。也就是说，理想情况下，应安装的OS缓冲等于流的约2秒，在这种情况下 - 2兆字节。否则损失保障。



好，但我们也有TCP！这保证交货，并要求发送方如果等待！让我们切换到TCP，并期待在同一张图片。额外的开销可以忽略不计，就让我们看看会发生什么。因此，我们有苍蝇360千字节的数据。他们将在30毫秒发送到100Mbps的连接的地方。某处10毫秒接收缓冲区已满，相机并要求安静。假设，一个20ms的进一步应用之后读取的所有可用缓冲器（实际上是 - 读4个字节，那么1400，然后再如图4所示，1400仍...），并要求在相机继续工作。摄像头已经派出另外三分之一的关键帧，然后再次闭上了嘴。又经过20毫秒开车上 - 但相机仍然生产，所形成的相机本身的缓冲区中的数据。在这里，我们就来湿滑的时刻 - 而在室内什么尺寸的TCP缓冲区？由于不断此外，“闭嘴” - “保持”的有效带宽急剧下降 - 而不是为100Mbps，我们128kbayt在30毫秒=最大32兆比特。 In在Windows Server中，默认的量子是一个固定的120毫秒。当我们为120ms限速将8.5mbit。也就是说，使用128kbayt缓冲服务器操作系统需要8mbitny流将不只是困难，但令人望而生畏。在桌面操作系统更容易，但仍是问题将在任何chihe。如果缓冲区更多 - 越来越好，但仍 - 在任何不稳定减法的问题开始这一结果在最简单的情况下颠簸地来回移动，在某些情况下，到的类似于流或错误的损害，如果该室内部的缓冲器溢出的TCP。

在这里你可以得出结论只有一个 - 缓冲区为好，理想情况下，应该是流动的大约2秒的保证金，在这种情况下 - 2兆字节。否则，问题是可能的。

也许我是错的，但如果应用程序的任务是接受并保持相机无法做到这一点的流量 - 这是一个错误。这应该修正错误，并没有提出减少的问题已经解决了降低质量的模拟摄像机。迪西。

来源： habrahabr.ru/post/227483/