Чому підвищення якості призводить до низької якості, або повинні працювати основні функції?

Зроблено, що аналоговий відеоспостереження - це річ минулого: дешеві IP-камери дають картину зіставної якості з дорогим аналогом. Крім того, IP-камери не обмежуються від вершини на будь-який інший, ніж продуктивність рекордера, в той час як аналогові камери вимагають суворого листування приймальної картки, узгодження рівня сигналів передавачів / підсилювачів / ресиверів та інших хаманізмів.
При оформленні системи на основі IP-камер в будь-який час ви можете видалити камеру і замінити її більш якісною - якщо ви зберігаєте IP-адресу і пароль входу, то, швидше за все, ви навіть не зможете змінити налаштування ресивера - просто краще зображення піде до архіву.
З іншого боку, він накладає обмеження на реєстратор – він повинен бути готовий працювати з будь-яким дозволом, будь-яким бітрейтом, будь-яким кодеком та будь-яким протоколом. Або хоча б правильно працювати з якою заявленою.



Існує два способи у світі програмного забезпечення: є Linux-way: це набір невеликих програм, кожен з яких робить одну функцію, але дуже добре; і є вікна-way: це величезні харчові процесори, які можуть зробити все, і трохи більше. Основна проблема з Linux-way є відсутністю інтерфейсу. Щоб отримати всі переваги, вам доведеться курити мансарю (або принаймні читати -допомога), і експериментувати. А також зрозуміти, що і що можна поєднувати і як. Основна проблема з вікнами - це втрата головної функції. Дуже швидко, коли загублена додаткова функція, тести ключової функціональності, і в кінцевому підсумку проблеми навіть з ним починаються. І в той же час починається інерція мислення: «Це основна функція, яку він тестується, вона не може бути помилка, користувач робить щось неправильно. й

Тепер до нашої овець: тепер існує постійне зростання якості IP-камер. Будь-який, хто бачив різницю між камерою FullHD, встановленою в тому ж місці, де навіть надхолодний 700TVL стояв раніше, не хоче повернутися назад (особливо, оскільки ціна зараз про те ж саме). Подальший розвиток означає, що 3MP (2048x1536) і 5MP (2592x1944) камери більше незгодні. Єдина ціна для підвищення якості - це збільшення витрат на зберігання і передавання. Тим не менш, ціна гігабайта на жорсткому диску давно падає (і повністю відновлена від паводка на заводі), і тому не проблема.

На сьогоднішній день з'явилася невелика суперечка з максимальною клаптицею про те, чи виробник програмного забезпечення дає щось користувачеві, після продажу або ні. Так, будь-яке програмне забезпечення продається «як» без будь-яких обіцянок. Таким чином, навіть платити все, ви не обов'язково отримуєте навіть робоче програмне забезпечення. Це тільки якщо програмне забезпечення не працює, і воно відомо – потік клієнтів висихає в одну точку. Хоча вони все ще купують, очевидність виправлення помилок (і ще більше так, реалізація функцій) розглядається.

Давайте закінчити введення, і дивитися невелике, але дуже виявлення відео (можна навіть дивитися - на зупинці. кадр все видно):


Це підручник, який я бачив практично всі програмні продукти, призначені для реєстрації відео. Я бачив його на VideoNet, я бачу його регулярно на Axxon Next, як ви бачите в відео, і це те, що Trasir сказав. Сама kayda навіть у рідній камері глядача. Ви можете відписати всі проблеми на камері. Ви можете написати його. Ви можете покласти високий навантаження на процесор. Електромагнітні втручання. Ви можете консультуватися з перевіркою пам'яті. Ми можемо перевстановити систему. В цілому, способи зробити людину привезти туалет замість пробного ...
Це просто підключення до того ж потоку rtsp через vlc no artifacts і невдач – ні. На одному комп'ютері я запустив колінний тестовий скрипт, який прочитає потік з камери і напишіть на диск - і немає втрат і проблем, і тому тільки один метод працює - для зменшення дозволу камери і зменшення бітрейту.

Це, незважаючи на гнучкість, зазначена підтримка для пучка камер, роботи на ОНВІФ і RTSP. На жаль, ви не можете отримати будь-які переваги від IP відеоспостереження, оскільки програмне забезпечення не було готове до цього.

Основна причина цієї поведінки, не дивно, є IP-мережа, кодеки і каналізація.

Так, для початківців, коротка базова теорія на IP-мережі. Все працює у вигляді сумок онлайн. Кожен пакет має максимальний розмір (МТУ, 1500 на звичайних посиланнях), відправника та ресивера. Пакет відправлений десь по дорозі і в кінцевому підсумку повинен дістатися до одержувача. Не можна дістатися. Можете вирізати себе. Може бути шматок ... Добре, є варіанти. З цих пакетів перекручуються транспортні протоколи: UDP та TCP (з них ми зацікавлені) На UDP нічого не змінюється, тільки з'являються порт відправника і порт ресивера, так що пакети можуть бути загальними; і на TCP багато логіки надходять до того, що «поставка гарантій». Якщо щось не може бути доставлено. Добре, як гарантії ... обіцянки (для обіцянок - не означає маррі;) Будь-який адміністратор неодноразово бачив "гору" з'єднання, на одному мобільний Інтернет, наприклад.

Як працює гарантія TCP? Кожен пакет повинен бути підтверджений. Не існує підтвердження на деякий час - пакет втрачений - відміняє його. Але якщо ви очікуєте підтвердження для кожного пакета, швидкість буде скидати неоднорідно, а більша затримка між точками спілкування. Таким чином, запроваджено поняття «вікно» – ми можемо надсилати максимум пакетів N без підтвердження, а лише потім чекати підтвердження. Але чекаючи підтвердження N також дуже багато – ресивер також отримає і надішле підтвердження не всім, але просто «максимум видимий». Тоді є менше доказів. Підтвердження можна надсилати разом з відправним пакетом, щоб уникнути отримання двічі. В цілому логіка моря, все спрямоване на виконання обіцянки доставки, але при цьому максимальне використання каналу. Розмір вікна є змінним, і обраний системою на основі voodoo магії, налаштувань, погоди на Марсі. Плюс, він змінює процес потоку. Ми зв'яжемося з тим пізніше.

Отже, тепер ми переїжджаємо до нашого овець, H264 на вершині RTSP. ( Насправді, це не важливо, що кодека або що таке транспортний протокол.) Не думаю, що якщо ви використовуєте будь-який з ваших винахідливих протоколів, які набагато простіші, ніж RTSP, це жодна з ваших бізнесів. Потік складається з повторюваних ключових кадрів і потоку змін відносно поточного стану. Підключаючи до відео, потрібно почекати ключову раму, після чого беремо її на поточний стан, а потім беремо дифузори, які ми накладаємо і показуємо. Що означає? Це означає, що один раз в X секунд прибуває багато даних – повний кадр. І чим вище роздільна здатність камери і чим вище бітрейт (хоча, давайте чесним, трохи ефектно впливає на розмір комірки). Отже, тут у нас є час 0 – початок ключової кадри, при якому повна рама прибуває відразу (програш, у нас є камера всіх 3 мегапікселів – це 2048x1536 = 3145728 пікселів). Після стиснення, це патологія ~ 360 кілограмів. В цілому, у нас є 8 мегабітів = 1 мегабайт, один раз на 5 секунд, і FPS = 18. Потім у нас є щось схоже 360k, потім 52k кожні 18 секунд, після 5 секунд знову 360k, потім знову 52k.

Тепер до UDP і TCP. Пакет, який надходить до мережевої картки, складається з буфера мережевої карти, а процесор закріплюється (або перервується), що є дані. Процесор призупиняє виконання всього корисного, витягує пакет з картки, і починає піднімати і розірвати його вниз TCP / IP стека. Цей процес здійснюється на найвищому рівні (для роботи з праскою). Але ми ще не маємо Windows або Linux, а не RTOS, тому немає гарантії, коли саме додаток зможе отримати в цей пакет. І так, один раз система з'ясувала те, що вона з'єднання її належить, пакет намагається вписати в буфер.
На UDP: якщо немає місця в буфері, пакет викидається.
На TCP: Якщо в буфері немає місця, то алгоритм керування потоком переходить - відправник направляється сигнал переливу, вони говорять, поки я не можу тут трохи. Як тільки заявка бере на себе деякі дані з буфера, система надсилає “ОК, далі йде” відправника, повідомлення відновлюється.

Тепер додайте його все і напишіть, як камера отримує дані. Для стартерів це простий випадок, на UDP. Камера читає наступну раму, подрібнює її в компресор, витягує компресовані дані з компресора, нарізає в мішки, додає заголовки і відправляє її одержувачу. Одержувач отримує 260 пакетів UDP, потім пауза, ще 40 пакетів, пауза, ще 40 пакетів і т.д. Перші 260 UDP пакети прибувають миттєво - близько 30 мілісекундів, і вже в 55-му мілісекунді, наступні 40 прибувають (в іншому 4 мілісекунді). Наприклад, вартість буфера 128 кілограмів. Потім вони збивають в 10 мілісекундах. І якщо протягом цього часу буфер програми не порожній в одному відліку імпульсу (і фактично прочитали в часі один пакет ...) – ми втратимо решту основного каркасу. З огляду на те, що у нас немає RTOS, і додаток може бути змушений «збиток» з будь-якої причини (наприклад, при цьому ОС відмітить буфер на диску) один і другий, єдиний спосіб не втратити нічого, щоб мати мережевий буфер більший, ніж ми можемо спати. Це, ідеально, OS буфер повинен бути встановленим до ~2 секунд потоку, в цьому випадку - 2 мегабайти. В іншому випадку гарантовані втрати.



Ми можемо самі зателефонувати одержувачу! Хто гарантує доставку, і просить чекати відправника, якщо все! Давайте переходимо до TCP і подивіться на однакову картину. Додатковий наклад можна нехтувати, просто побачимо, що відбувається. Так ми отримали 360 кілограми даних, що виходять. Понад 100 мегабітних каналів близько 30 мілісекундів. На 10 мілісекундах ресивера переповнена буфером, і камера попросила мовчати. Припустимо, після іншого 20ms додаток читати весь доступний буфер (і фактично читати 4 байти, потім 1400, потім ще 4, ще 1400 ...), і OS попросила камери продовжити. камера надіслала ще одну третину брелоків і знову закриваємо. Після того, як ще 20ms пішов на — але камера видала більше даних, які впали в буфер камери. І ось ми приїжджаємо до слизької точки — що розмір буфера TCP в камеру? Крім того, за рахунок постійного «згорнути» – «продовжити» ефективна пропускна здатність мережі падає катастрофічно – замість 100 мегабітів ми маємо 128 кбайтів в 30 мс = 32 мегабіти максимум. У Windows Server квантовий за замовчуванням - це фіксована 120ms At 120ms, ми маємо обмеження швидкості 8.5mbps. Це, на сервері ОС за допомогою буфера 128 kбайтів, не просто складно приймати потік 8 MB, але архікомплекс. На робочому столі OS простіше, але все ж проблема буде з будь-яким хребтом. Якщо буфер більший, він отримує краще і краще, але все ще, з будь-якою нестійкістю відкликання, проблеми починають це привести, в найпростіший випадок, до руху струменя, в деяких випадках, для розбиття потоку або аналогічної помилки, якщо буфер TCP всередині камери перетікає.

З якого можна зробити тільки один висновок - буфер повинен також ідеально бути з запасом близько 2 секунд потоку, в цьому випадку - 2 мегабайти. В іншому випадку проблеми швидше за все.

Може бути, я неправильний, але якщо додаток, який повинен вибрати і зберігати потокове відео з камер, не може це зробити, це помилка. І ця помилка повинна бути відремонтована, не запропонував зменшити проблему вже вирішеним, знизивши якість на аналогову камеру. Діксі.

Джерело: habrahabr.ru/post/227483/