(мислех да oпиша първо как правим записите и stream-а в малките зали на Interpred, но там ще трябва да чертая схеми и ще ги оставя за по-нататък)
За да можем да гледаме събитието локално и по Internet, тази година направихме следния restream setup:
Навън (в delta.bg) имахме сложена една машина, наречена grendel, която имаше 10gbps порт и достатъчно свързаност, че да може да ни бута трафика (още ме е яд, че не минахме 1gbps, догодина може нарочно да пуснем fullhd 1080p stream само за това). На него имаше пуснат nginx с nginx-rtmp модула, който приемаше stream-а и пускаше на потребителите rtmp и HLS. Имахме също страничка, която можеше да показва видеото директно в browser-а и я показвахме в iframe на сайта на OpenFest.
Графика на трафика на restreamer-а.
Същият restreamer с nginx имахме и на router-а в самия Interpred, и там препращахме потребителите, които искаха да гледат локално (и overflow телевизорите/лаптопите). Препращането ставаше чрез split DNS, т.е. за stream.openfest.org връщах локалният ip адрес вместо този на grendel.
Нямам графика на тоя трафик отделно, в общи линии би трябвало да е разликата между външния интерфейс и вътрешния интерфейс на router-а.
На restreamer-ите нямаше ipv6, понеже така и не успях да накарам някой от моите клиенти да работи по v6 за rtmp и мисля, че щеше само да създаде странни проблеми.
В настройките на nginx-а няма нищо, което да го няма в default-ната конфигурация, та ще ги пропусна. Единственият по-куц момент е, че явно модула не е дописан и на повече от един worker нещата се чупят, т.е. реално трябва да се праща по един stream на всеки worker, което не е ясно как може да се направи, или да се допише така, че м/у worker-ите да може да се дели един stream (което значи да му се добави shared memory и да се пише внимателно).
Самите потоци с видео влизаха на eagle, и от там биваха пуснати до двата сървъра. От по-малките зали пращахме директно по UDP raw HDV потоците, а от зала София, поради възможностите на restreamer-а – RTMP.
Причината за UDP-то (което беше една много добра идея на Петко) е, че така се получава decouple-ване на софтуера, който изпраща и записва от този, който приема, т.е. ако умре restreamer-а в който и да е момент, записващата част няма да има проблем, и ако restreamer-а се върне, ще може директно да продължи да чете потока от мрежата.
За encode-ването използвахме ffmpeg, ето как (с някои дребни промени по url-тата):
ffmpeg -re -i 'udp://@10.3.0.1:2600?overrun_nonfatal=1&buffer_size=81921024&fifo_size=178481' \
-c:v libx264 -s 1280x720 -profile:v high -level 4.2 -preset ultrafast -filter:v yadif -g 60 \
-b:v 2000k -acodec aac -ar 44100 -ac 2 -bsf:a aac_adtstoasc \
-flags +global_header -strict -2 -threads 2 \
-f tee -map 0:v -map 0:a "[f=flv]rtmp://localhost/of/g1|[f=flv]rtmp://1.2.3.4/of/g1" \
-c:v libx264 -s 854x480 -profile:v high -level 4.2 -preset ultrafast -filter:v yadif -g 60 \
-b:v 500k -acodec aac -ar 44100 -ac 2 -bsf:a aac_adtstoasc \
-flags +global_header -strict -2 -threads 2 \
-f tee -map 0:v -map 0:a "[f=flv]rtmp://1.2.3.4/of/g1-low|[f=flv]rtmp://localhost/of/g1-low"
Тук има няколко интересни неща:
– Вдигнали сме буферите на UDP-то за приемане на пакети (и имаме същото нещо от другата страна, за изпращане). В първоначалните тестове (по време на setup-а YAPC::EU 2014) открихме, че UDP е наистина unreliable на default-ните буфери (около 256к) за толкова много трафик и губи достатъчно пакети, че картината да се намазва почти постоянно. Съответно след като с тестове се видя, че при TCP проблемът го няма, лесно се стигна до правилния извод и от тогава тия неща ни работят като слънце.
(интересното е, че на VarnaConf правихме тоя setup без да вдигаме буферите и работеше, и едното съмнение беше, че щото е бил прав кабела м/у двете машини и без никакви switch-ове нещата са били ок. По-вероятно ми се вижда просто някой буфер да е бил по default по-голям на тогавашния ни encoder (един лаптоп на Петко), но няма как да го проверим).
(тази опция изисква и да се пипнат едни sysctl-та по kernel-а, имайте го предвид)
– ffmpeg-а може да създава няколко потока от един вход, и да ги пуска на няколко различни места. Така от един поток можехме да пуснем low и high quality потоци и към двата restreamer-а, без да се налага да се слага нещо по пътя, което да копира пакети или потоци. Наложи се да компилирам една последна версия, че да работи добре, но не беше особен проблем.
– „-g 60“ е keyframe интервала, което в общи линии определя колко бързо ще се покаже нещо при потребителя, след като събере някакви данни.
– „-flags +global_header“ се налагаше, за да може да бълва rtmp като цяло през тия разчеквания. Не помня как го намерих 🙂
Като цяло, всичкото това ми отне около два-три часа четене.
За зала София се наложи да направим малка добавка – понеже ffmpeg-а не можеше да слуша на rtmp (т.е. за половин час с Guru не можахме да го накараме), засилихме потока от залата директно в локалния restreamer, и с ffmpeg си го взимах от там и го пращах нататък. Така вкарвахме още 20-тина секунди латентност в излъчването, но пък си решихме доста приятно проблема.
Като цяло този setup не направи никакви проблеми и си работи двата дни като слънце, eдинствено в overflow залите в началото пускахме големия stream от зала София (1080p на 5mbps) и това създаваше малко проблеми на декодерите.
