Post Syndicated from original https://vasil.ludost.net/blog/?p=3465

Тия дни от Дневник ме разпитваха някакви неща за видео streaming-а (“видеонаблюдението”) на изборите и решиш да доразкажа някакви подробности, ако на някой му е интересно.

Моят опит с тези неща идва от няколко места – генералното ми занимаване със сервиране на файлове и видеа, streaming-а на конференции (OpenFest и най-вече FOSDEM), и накрая – инфраструктурата и схемата, която сглобявах за tibroish.bg за излъчване на предишните избори.
(предишните видео-наблюдения бяха саботирани там, където вероятно ще бъдат и тези, на ниво секция, и на практика имаше твърде малко stream-ващи, може би около 1%. Съответно, цялостната схема не е минала пълен тест в production, но не успявам да намеря причина да не работи.)

(код на всичкото на tibroish)

Според мен, подобна система може да се реализира с почти подръчни средства. В нея няма нито един много специализиран, сложен или невиждан досега компонент. От друга страна, точно това не е правено особено много и има много интеграционна и тестова работа, която не намалява с идването на изборите, та най-големият проблем всъщност са сроковете.

Ще тръгна по потока на данните и ще обясня моето виждане (и как в общи линии работеше системата за streaming в tibroish, която за тези избори е спряна).

Самото заснемане се прави с телефон.
– Хардуерът на модерните телефони е доста добър, и като качество на картината, и като звук;
– в тях има хардуерен encoder за видео, който може да го сдъвче доста добре на хубаво качество;
– два варианта за свързаност (мобилна мрежа и wifi, като в този случай само мобилната мрежа вероятно ще се ползва);
– място за събиране на записи – на повечето телефони 6-часовия, 2.7GiB запис на 1mbps ще се събере във вътрешната памет и няма да има нужда от SD карта;
– самия телефон си има поддържаща операционна система и готови библиотеки;
– вграден UPS;
– ако трябва да се осигурят 12000 устройства за нещо и да се изпрограмират, телефоните нямат равни, понеже като цяло имат подобно производство.

Конкретно в tibroish нямахме особен избор, и задачата беше допълнително затруднена от това, че трябваше да поддържаме random телефони, което ако някоя фирма прави цялостното решение, няма да е проблем.

Приложението на tibroish има в себе си и video streaming, и е open-source, съответно може да се използва тази му част като основа.

Първата задача на приложението е да се оторизира пред зададен централен сървър и да разбере къде да си изпраща видео потока. Подобни системи и схеми има в най-различни видове и са нещо, което почти всеки е правил. Това е услуга с малко натоварване, свястна база данни и сравнително защитена от атаки (по темата сигурност ще пиша отделно).

След като получи информацията, приложението започва да записва и ако може, да stream-ва. Ако може, понеже в някакво количество секции internet няма и няма достатъчно мобилно покритие, за да излъчи 1Mbps видео.

Стойността 1Mbps идва от някакъв опит и проби/грешки, за повечето нужди в 1Mbps на 1280×720 (720p) може да се смести картина с четим текст и като цяло всичко да е добре различимо, при подходящ H.264 профил. Не съм успявал да докарам поносимо видео на по-малка разделителна способност, а 2Mbps ще е доста сложно за мобилната мрежа. Като опция, вероятно може да се записва на различен bitrate, но това ще увеличи доста натоварването на телефона.

Stream-ването го бяхме реализирали по RTMP. В момента опциите за подобно нещо са:
– WebRTC базирано – генерира UDP/RTP трафик и като цяло губи пакети, понеже е ориентирано за комуникация с ниска латентност. Голямото му предимство е сериозната поддръжка в телефоните и като цяло, понеже се използва много, но е доста по-сложно и като цяло неподходящо.
– Нещо файлово-базирано – например да генерира на телефона HLS фрагменти и да ги качва директно един по един – това би било страхотно решение и изисква най-малко от инфраструктурата, но не съм виждал такова.
– RTMP(S) – стандартен протокол в/у TCP, от ерата на Flash-а. Все още стандартът за stream-ване (всичките платформи като twitch, youtube и facebook май само него поддържат) и има добра open-source поддръжка. Аз все още ползвам nginx-rtmp за повечето streaming и стига да не се подава странно видео, работи добре.

Тук задачата в крайна сметка е да има видео и да изглежда добре, латентност от 5-10-30 секунди е поносима.

Този поток от данни с всички останали се праща до приемащ сървър. Сметките всеки може да си ги направи, при 1Mbps на поток и като цяло 12Gbps, ако се раздели на 50 виртуалки (както аз го бях направил), натоварването става поносимо и се издържа от и събира на почти всякаква машина в някаква cloud услуга. Единият път за tibroish използвах Hetzner, но има и други, които могат да свършат работа. За конкретния случай дори комбинация от няколко български доставчика ще свърши работа, и вероятно дори самите мобилни оператори могат да предоставят подобна мижава инфраструктура.
(по моя опит, нужната инфраструктура за това не стига размерите дори на среден cloud provider, може би е като един малък такъв. 12 Gbps и 30 TiB данни за записите би трябвало да не са нещо особено за когото и да било)

От гледна точка на сигурност, адресът на приемащия сървър се дава на приложението от централния, малко преди да е започнал streaming-а. Това се прави да се ограничи периодът, в който ще може да се подготви и засили DDoS атака, понеже такава ще има, както всяка година има спрямо сайта на ЦИК. Доколкото знам, ИО са отработили система за защита, и поне според мен може да се направи уговорка с мобилните оператори точно този трафик да не излиза никъде от мрежите им и да върви по трасета, които няма как да се DDoS-нат отвън.

След като трафикът стигне на приемните машини, от там те могат да генерират HLS потоци (за които няма нужда от reencode-ване, т.е. просто се препакетира трафика, което не яде почти никакъв процесор, от моите експерименти – бях пускал няколко-стотин потока към един сървър, докато сгъне) и може да се гледа. Като цяло гледането ще е по-малката част от трафика, и HLS се проксира доста лесно, та в tibroish просто ползвахме CloudFlare за proxy/филтър пред гледането. Мисля, че това е опция и за всеки друг, който го прави.

И на последно място, някъде трябва да има една красива страница, от която да се вижда къде има работещ stream и да може да се избере/гледа stream. Това се сглабя сравнително лесно (и пак го има в tibroish), като цяло начини да показваш видео – бол…

Няколко проблема, които не съм споменал горе:

– Цялото нещо има нужда минимум от DDoS защита. Може да се очаква да бъде блъскано усилено, ако се намери къде е, за това аз бих разчитал на елемента на изненадата (да не се вижда къде е докато не започне събитието), random имена на сървърите (и всичко в dns зоната, което не е тези сървъри, сочи към някакви blackhole-нати адреси, да затруднява допълнително), подходяща DDoS защита с подходящ капацитет и почистване на трафика, и различни, големи доставчици за проксиране, които да могат да издържат.

– Не сме правили запис, и не мога да кажа какви мотики може да се ударят там. Според мен и сметка на салфетка вътрешния storage на телефоните ще се справи, за удобство може да се пише И на SD карта, там е основно въпрос на логистика. Проблемът на SD картата е, че доста по-лесно изчезва…

– ЦИК има изискването да могат да се четат номерата на бюлетините. Това изисква най-вече добро осветление и поставяне на камерата, което не е от най-простите неща за обясняване (камерата има почти второстепенна роля). Според мен 1Mbps ще се справи със задачата.

– Не е ясно дали може да се записва звук или не. В tibroish го бяхме спрели директно, понеже юристите не можаха да се произнесат, според мен би бил страхотна идея да се записва и stream-ва, колкото и да е зле.

Та, технически може да стане. Практически – времето е малко и ще е сложно, и както обикновено, ще бъде саботирано в секциите. Ако няма конкретни глоби и наказания за липса на видео-наблюдение, може да се очаква поне 20% от него да не работи и да няма запис. Честно казано, ако видя да се случи от 50% от секциите, ще го броя за чудо.

Приемам всякакви идеи и корекции, че това ми е brain dump от една ранна сутрин 🙂