Как правя streaming-а и записите

Първия път, когато писах подобно нещо, беше преди 8 години, от тогава много неща се промениха.

Хардуер

Видео източник (камера)

По принцип използвам видео камера с firewire изход. Предимствата са, че е сравнително стандартно, има поддръжка в linux, windows и какво ли не още, работи стабилно (т.е. използва се) и може да вкарва лесно и звука и картината в синхронизиран файл. Първо ползвах една Sony DCR-TRV33E (720x576), сега ползваме Cannon Legria ..., която може да прави 1080p (FullHD) записи. Двете камери вадят еднакви по размер файлове, като втората използва mpeg2/aac като кодеци.

Може да се използва и нормална usb камера през v4l2 интерфейса (или каквото-е-там под windows), отбелязал съм по-долу къде би трябвало да има разлики.

Камерата има нужда от статив или някакъв друг начин, по който да се стабилизира.

encoder/streamer

Един добър лаптоп с интерфейс към камерата (ако не е firewire, и към звука), който да може да смята достатъчно бързо video/audio codec-ите (за streaming) и диск, на който да може да прави записите (за записа). "Некомпресираното" видео от DV/HDV камера, което идва по firewire е около 24mbps, съответно час и половина са 19GB (целият запис от VarnaConf например беше 100GB, един ден и около 8-9 часа). Също така за stream-ване силно препоръчвам да се ползва жичен ethernet, вместо wireless, поради буферните проблеми, които wireless-а може да направи.

звук

микрофони

По принцип за конференциите са нужни два типа микрофони - "брошки" (такива, които се закачат на лектора) и "нормални", които или да стоят стационарно, или да са безжични и да се разнасят из публиката. Аз лично препоръчвам всички да са безжични, понеже се спестяват много кабелни проблеми. От друга страна, при безжичните микрофони трябва да се внимава какви канали се използват и да не се получи колизия с друго такова оборудване наблизо. (историята познава доста такива случаи, например как на openfest 2011 единия ден се чуваше нещо от събирането на някаква църква наблизо)

Поне част от местата, в които които се провеждат разни събития имат някакво количество такова оборудване.

пулт/миксер

Всичкият звук има нужда да се събере на едно място, за да се изпрати към камерата и към озвучаването на залата. В общи линии всякакъв миксер с нужния брой входове, изходи и възможности за настройка върши работа (аз се справям с един Behringer Xenyx 802). Често се случва мястото, на което е събитието да има подобен пулт, към който са закачени техните audio неща.

озвучаване

По принцип за да може да се чува добре какво се говори е добра идея това, което лекторите и т.н. казват да се усилва и чува от допълнителни източници. Почти всичко, което има усилвател и колони може да свърши тая работа, като повечето зали имат нещо подобно. В случаите, в които нямат съм открил, че кубе от бас (моето Fender Bass Rumble 15) вади добър звук като за човешки глас и има достатъчна мощност да озвучи зала за 100-200 човека (зала 200 на ФМИ на СУ). По същия начин сме използвали усилвател и две колони в ТУ-София за курса по linux (нямам спомен какви точно бяха, мисля, че се водеха 50-100W). Тестове може да се провеждат лесно и да се види колко добре се получава звукът. (не препоръчвам да се ползват китарни кубета, понеже при тях кривенето на звука е feature)

Разни

• Всички нужни кабели и малко резервни
• Разклонители (и поне един с прекъсната маса)
• Мултицет (понякога трябва)
• Тиксо
• Слушалки
  • Много са важни при тестването и наблюдаването на системата, понеже наоколо почти винаги ще е шумно
• Резервни батерии за всичко, което иска батерии
  • например всички безжични микрофони
• Стойки за микрофони (ако са нужни и няма на място)

Софтуер

Софтуерният процес изглежда по следният начин:

• dvgrab взима записа от камерата и го подава на ttee;
• ttee го пише в един named pipe (към vlc) и в един файл (за запис);
• vlc го чете от named pipe-а, encode-ва го и го праща до restreamer сървъра;
• restreamer сървъра поема потока пак с vlc и го дава на всеки, който си иска по http.

Възможно е да се каже на vlc да прави запис на потока (още при encoder-а), което вероятно и ще е вариантът, ако не ползваме firewire камера, dvgrab и ttee, но по принцип stream-вания поток трудно може да е с толкова добро качество, колкото записите.

За комуникация м/у encoder-а и restreamer-а използвам UDP протокола на vlc. Това създава малко security проблеми (т.е. някой друг може да бълва данни и да ми се меси в оригиналния поток, ако налучка няколко неща) и планирам да направя нещо по въпроса (RTP или подобен протокол, в краен случай VPN).

Решението ми е ограничено до един restreamer и съответно броят възможни клиенти е ограничен от неговата свързаност. Аз досега не съм минал 1gbps, в момента, в който това се случи и измисля решение, ще го добавя.

Подробности за streaming-а с vlc могат да се намерят на [[1]].

Сървър

Използвам vlc за restreamer, командата изглежда по следния начин:

/usr/bin/vlc -I dummy --udp-caching 16000 udp://:UDPPORT --sout '#standard{access=http,{dst=:HTTPPORT/lab.ts}}'

Където:

• 16000 е 16 секунди буфер на получения по udp поток. Много много добра идея, иначе клиентите се шашкат, като трябва да чакат да се съберат данни, а така директно получават 16 секунди и могат веднага да започнат да показват нещо.
• UDPPORT е UDP порта, на който слушаме за входящия поток. Може да слушаме и на определен ip адрес.
• HTTPPORT е порта, на който слушаме за клиентски връзки.
• /lab.ts е url-то, което клиентите трябва да заявят.
  • По принцип използвам MPEG-PS за контейнер на данните, за да мога да stream-вам и да да не реенкапсулирам накрая. Ако искаме да може да се гледа stream-а през някакъв (мизерен) flash, можем в сървъра да пипнем данните и да ги обърнем в mp4 контейнер.

Понеже не ми се занимаваше да пиша странния команден ред на vlc за слушане на специален адрес, на v4 и на v6, използвам socat за да пренасочвам към този порт нормалния порт 80:

socat -d -d -lmlocal2 TCP4-LISTEN:80,bind=62.44.127.178,su=nobody,fork,reuseaddr TCP4:62.44.127.178:8787,bind=62.44.127.178
socat -d -d -lmlocal2 'TCP6-LISTEN:80,bind=[2001:67c:20d0:b0::3],su=nobody,fork,reuseaddr' TCP4:62.44.127.178:8787,bind=62.44.127.178

(не съм изтрил оригиналните адреси, но мисля, че лесно ще се ориентирате)

При мен streamer-а има едно име, което сочи и към ipv4 и към ipv6 адреса. Поради калпавостта на голяма част от ipv6 свързаността, бих препоръчал (и вероятно и аз ще го направя) да има още две отделни имена, само по v6 и само по v4, за удобство на клиентите и по-лесно debug-ване.

encoder/streamer

Това е малко по-криво.

Използвам за codec-и h264 за видео и aac за аудио. Може дълго да се спори колко е лошо или колко е хубаво, моите причини са следните:

• h264 е най-новия и добре разработен codec.
• поддържа се от почти всичко (вкл. телефони).
• може да кодира добре голямо видео (720p) на 2mbps и дори на 1mbps.
• има свястна и много добре разработена реализация (x264) на encoder.

Понеже имах проблеми с оригиналната версия си компилирах наново x264 и vlc. Версията на x264 е x264-snapshot-20120710-2245 и е компилиран само с --enable-pic, версията на vlc е 2.0.2 и няма някакви специални опции. Направил съм си един отделен chroot, за да не пречи на системата и при заявка мога да го кача някъде и други хора да го ползват.

Поради липса на подходящ инструмент си написах сам ttee.

dvgrab е стандартен инструмент и трябва да го има във всички дистрибуции.

Предварително съм изпълнил

mknod av.m2t p

По принцип използвам два терминала. В единия пускам:

dvgrab --format raw - | ./ttee av.m2t log.`date +%H%M`.dv

а в другия stream.sh, в който има

cvlc av.m2t --sout='#transcode{vcodec=h264,vb=2000,scale=0.6,acodec=mp4a,ab=128,channels=2,2amplerate=48000,threads=2,deinterlace}:std{access=udp{ttl=32},mux=ts,dst=RESTREAMER:UDPPORT}' --sout-keep --sout-x264-profile baseline --no-sout-x264-non-deterministic --sout-x264-preset ultrafast -v 1

• RESTREAMER и UDPPORT трябва да си ги попълните
• vb=2000 значи 2mbps stream, което се оказва добре на задачата
• scale=0.6 прави от 1920x1080 (1080p) 1280x720 (720p)
• сложил съм deinterlace, понеже оригинално това, което идва от камерата е interlaced и се получава грозно
• ttl=32 е задължително, default-а е 1, което никаква работа не върши
• --sout-x264-preset ultrafast е нужно, за да може моя лаптоп (който е core i7) да се справи със сметката

processing

Записите обработвам с ffmpeg и малко скриптове. Имам компилиран x264 само с

./configure --enable-pic  --use-ffmpeg=no

и ffmpeg, взет от git repo-то им на 14ти август 2012, компилиран с

./configure --enable-gpl  --enable-libx264 --enable-pic --enable-pthreads --enable-libfaac --enable-nonfree --enable-avfilter --enable-postproc --enable-shared

Имам скрипт за нарязване на файл, който работи с два файла - списък от начална и крайна секунда на всяко парче, и видео файл. Скриптът се казва split.sh и изглежда по следния начин:

#!/bin/bash

if [ -z "$2" ]; then
        echo Usage: $0 tsfile avifile
        exit 3
fi

n=0
input="$2"

(while read beg end; do 
        let n=$n+1
        let sz=$end-$beg

        name=$input.$n.split.avi
        echo ffmpeg -analyzeduration 50000000 -v verbose -y -i "$input" -acodec copy -ss $beg -t $sz -threads 6 -vcodec copy $name

done) < $1

За encode-ване ползвам следният скрипт:

#!/bin/sh

if [ -z "$4" ]; then
        echo Usage: $0 input output resolution rate
        exit 2
fi
set -x
set -e

#output
name="$2"
#output file bitrate
rate="$4"
#output file resolution
res="$3"
#input file name
input="$1"

rm -f "$name" x264_2pass.log*

ffmpeg -analyzeduration 50000000 -v verbose -y -i "$input" -ss 42 -an -pass 1 -acodec libfaac  -ar 48000 -ab 128 -threads 6 \
-vcodec libx264 -s $res -b $rate -qmin 10 -qmax 51 -qdiff 4 -filter:v yadif $name

ffmpeg -analyzeduration 50000000 -v verbose -y -i "$input" -ss 42 -pass 2 -acodec libfaac  -ar 48000 -ab 128k -threads 6 \
-vcodec libx264 -s $res -b $rate  -qmin 10 -qmax 51 -qdiff 4 -filter:v yadif $name

exit 0

Процес

инсталация/закачане

Това е твърде зависимо от залата, така че просто ще дам базовите идеи:

• Камерата се поставя така, че да вижда спокойно лектора и презентацията му, и доколкото е възможно без да хваща публиката.
• Пултът и "майките" на безжичните микрофони се поставят на място, което е най-удобно за окабеляването на залата.
  • Колкото по-малко кабели газят хората, толкова по-добре.
• Звукът от пулта се извежда до озвучаването на залата и до камерата (по възможност).
  • Възможно е да се кара на микрофонът на камерата, който да записва звука, който се чува в залата, но резултатите не са особено добри - шум от климатици и т.н. (който може да се филтрира), има шум от публиката (който е почти невъзможен за филтриране), разни ехота в залата се усещат, като цяло е неприятно.
  • Не винаги може да се пусне кабел от пулта до камерата, за което планирам да взема нещо като Amphony L1500, което да пренася лесно звука.
• Правят се тестове да се види доколко се получава микрофония от лекторите, къде трябва да стоят и колко да бъдат усилени
• Правят се същите тестове за говоренето от публиката при задаване на въпроси (освен ако не се прави със стационарни микрофони на няколко места в залата).
• Прави се тест с камерата и колко добре се чува звука

• !!! Много често срещан проблем е да има шум от около 50hz, силен и дразнещ, който да изчезне, когато например захранването на лаптопа, който е закачен към камерата, се изключи. Това се решава чрез ground lift, който най-лесно се реализира като се залепи тиксо на масата на разклонителя.
  • Понеже аз нищо не разбирам от ток, препоръчвам да не ме слушате и да имате с вас един човек, който да знае какво да прави в такива ситуации.

• Encoder/streamer-а (т.е. лаптопа) се закача към камерата и към мрежата.
  • съответно encoder-а трябва да стои до камерата.
  • мрежата се тества за загуби и bandwidth.
  • добре е да има някакъв вариант да се погледне от друга машина как върви излъчването.

опериране

• При повече от един лектор за всеки се налага да се види колко силно говори и да се намали/усили микрофона му съответно.
  • Обмислям да направя скала за оценка на силата на гласа на лектора, която започва от Радослав Борисов и Борис Филипов, минава през Стефан Кънев и свършва със Светлин Наков и Атанас Бъчваров.

• Добре е да се наблюдава stream-а и да се преслушват/преглеждат части от записите, за да се следи качеството.
  • По принцип хората, които ще гледат събитието през stream-а се оплакват на разни места, намерете начин да ги следите. Например на varnaconf няколко човека ми предаваха какво се казва в twitter.

събиране/съхранение

Има много сайтове, които обясняват как се съхранява техника, как правилно се навиват кабели и т.н. - неща, които не съм чел и въпреки многото обясняване вероятно не съм схванал правилно. Базовите ми правила са:

• Кабелите трябва да са навити и вързани така, че да не се оплитат.
• Техниката трябва да може да преживее сътресения на кашона или каквото-там-се-ползва, в което се носи.
• Трябва да има в какво да се носи техниката, а не всеки компонент да се мъкне отделно.
• Много добра идея е да има списък на техниката, по който да се провери какво е забравено.
  • Моята е достатъчно малко за да си мисля, че мога да помня всичко.