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

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

Хардуер

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

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

• Legria-та по принцип има автоматичен gain control на входа за звук, който трябва да се спре и нивото на микрофона да се настрои на ръка, понеже иначе усилва всякакви минимални шумове.

Може да се използва и нормална 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 единия ден се чуваше нещо от събирането на някаква църква наблизо)

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

Аз използвам един AKG WMS 40 FLEXX за брошка и HED Audio WMS-35DUAL за преносими микрофони.

Пулт/миксер

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

Озвучаване

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

Източник на звук, музика за паузите

Полезно е да има някакъв източник на звук, от който да се пуска (тихо) музика в паузите. Най-лесно става с лаптоп, но и телефон (който няма да звънне) или mp3 player биха свършили работа.

Музиката, която се пуска трябва да е под свободен лиценз или поне да имате по някакъв начин право да я пускате (за да не си създадете безсмислени проблеми за в бъдеще). Мога да дам няколко варианта:

• Първите три албума на Falik, които са под creative commons.
• Скоро записаното dvd на MusOpen: [1]
• Колекцията записи на wikipedia (изпълненията не са от най-добрите): [2]
• Creative commons поддържат списък сайтове, който могат да се погледнат: [3]

Разни

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

Софтуер

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

• 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 могат да се намерят на [[4]].

Сървър

Използвам 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 е стандартен инструмент и трябва да го има във всички дистрибуции.

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" -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" -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.

• Микрофоните "брошка" е добре да се слагат колкото се може по-високо (под брадата на лектора), така че да няма шум от силно вдишване/издишване
  • особено ако пак изгубим ветробрана на микрофона

пускане на stream-а

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

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

Има вариант под windows, който сме тествали, с ffmpeg, само за streaming на екрана и звук:

ffmpeg -loglevel panic  -f dshow -i video="screen-capture-recorder" -f dshow -i audio="Microphone (High Definition Aud" -vcodec libx264 -pix_fmt yuv420p  -preset ultrafast -vsync vfr -acodec libmp3lame -f flv - | ffmpeg -f flv -i - -c copy -bsf h264_mp4toannexb  -f mpegts udp://RESTREAMER:UDPPORT

• 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) да се справи със сметката

Ако не се прави streaming, само за запис командата е

dvgrab --format raw --size 0

която ще създаде един голям файл, който вече може да се обработва. Без --size 0 ще направи отделни файлове по 1GB, който после първо ще трябва да се лепят, после да се режат, което не е особено удобно.

• В някои случаи изглежда по-удобно да се направят отделни файлове по 1GB (които са по около 5 минути) и после да се налепят, но съм имал различни проблеми със софтуера, който прави слепването (най-вече разсинхронизация на звука) и за това не го препоръчвам.

Работа с камерата

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

• особено неприятно е ако се следи някой лектор, който има навика да ходи постоянно от единия до другия край на сцената и на моменти трябва да се фокусира на slide-овете му.
  • историята познава хора, от които е имало оплаквания че от ходенето им напред-назад зрителите хващали морска болест

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

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

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

Обработка

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

Първото действие е да се изгледа записа и да се отбележи от къде до къде трябва да се изреже. Форматът, който приема script-а е многоредов файл с по две числа на ред - начална и крайна секунда на парчето. Секундите са абсолютни спрямо началото на файла (с файловете, генерирани от dvgrab по принцип показвания timestamp е от моментът на пускане на камерата, не от началото на файла и трябва да се види с колко секунди трябва да се коригира). Примерен файл изглежда така:

1146 1265
1265 3002
3858 5763
6943 9713
10228 13598
13598 13692

След това се пуска split.sh, който да нареже файла (което отнема някакво време). В момента скриптът има проблем с return code и изяждане на stdin, поради това генерирам команди (с echo), които после да се пуснат. Пример:

vasil@lain:/home2/encoder/home/vasil/varnaconf$ bash split.sh split.1022 log.1022.dv
ffmpeg -analyzeduration 50000000 -v verbose -y -i log.1022.dv -acodec copy -ss 670 -t 1890 -threads 6 -vcodec copy log.1022.dv.1.split.avi
ffmpeg -analyzeduration 50000000 -v verbose -y -i log.1022.dv -acodec copy -ss 3306 -t 1999 -threads 6 -vcodec copy log.1022.dv.2.split.avi
ffmpeg -analyzeduration 50000000 -v verbose -y -i log.1022.dv -acodec copy -ss 6010 -t 1860 -threads 6 -vcodec copy log.1022.dv.3.split.avi
ffmpeg -analyzeduration 50000000 -v verbose -y -i log.1022.dv -acodec copy -ss 8864 -t 2684 -threads 6 -vcodec copy log.1022.dv.4.split.avi
ffmpeg -analyzeduration 50000000 -v verbose -y -i log.1022.dv -acodec copy -ss 12525 -t 2375 -threads 6 -vcodec copy log.1022.dv.5.split.avi
ffmpeg -analyzeduration 50000000 -v verbose -y -i log.1022.dv -acodec copy -ss 14900 -t 350 -threads 6 -vcodec copy log.1022.dv.6.split.avi

След това с fenc.sh може да се encode-нат до нужния формат:

bash fenc.sh log.1022.dv.1.split.avi finished_log.1022.dv.1.split.avi 1280x720 2000k

Ако се наложи да се обработва звука, той първо може да се извади от файла с

ffmpeg -i FILE.avi -vn out.wav

, след това да се обработи out.wav и да се mux-не обратно с

ffmpeg -i tmp2.wav -i INPUT.avi -acodec libfaac -ar 48000 -ab 128k  -vcodec copy OUTPUT.avi -map 0.0 -map 1.0

(INPUT.avi приемаме, че вече е encode-нато до h264 и няма нужда да му се пипа видеото)

Документация за ffmpeg може да се намери на страницата на проекта, и е препоръчително да се прегледа. Проектът е ужасен, но няма заместител.

Обработка на звук

(това па изобщо не го разбирам)

Използвам audacity, за да махна шума, да нормализирам/усиля звука, ако е нужно, и да го направя същия на двата канала (ако по някаква причина записът е само на единия канал, което се случва, ако например не ползвам миксер, а микрофон директно в камерата).

• Махането на шума става просто - намира се отрязък от време (кратък), който е само шум, select-ва се, дава се на noise removal-а да профилира, след което се select-ва целия звук (или там, откъдето искаме да изчистим шума) и му се дава noise removal.
• Останалото става още по-лесно с малко четене в google.

Няколко setup-а

Това са няколко различни setup-а, които съм правил:

initlab

В initlab изходът на звука е свързан към озвучаването на голямата стая, а сървърчето там (cassie.ludost.net) е закачено към миксера, съответно може да се пуска музика в паузите и може да се чува добре в стаята. Камерата стои отзад (до библиотеката) заедно с цялата техника, и има в общи линии нужда само от микрофон за лектора и понякога някой от другите преносими за задаване на въпроси. Звукът се получаваше сравнително добре и като се записваше директно от микрофона на камерата.

Пускане/спиране

След като се включи камерата и се провери звука на микрофоните, се включва лаптопа, влиза се с user/pass initlab. В един терминал се пуска

while /bin/true; do sync; sleep 2; date; done

в два други се прави chroot и su:

sudo chroot /home/encoder /bin/bash
su - vasil

(на su може да даде нещо като грешка, няма значение)

В единия от двата chroot терминала се пуска

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

а в другия

bash -x stream.sh

(трябва да се пуснат бързо едно след друго, командите ги има в history-то).

Stream-а е достъпен на http://stream4.initlab.org:8787/lab.ts , може да се гледа с vlc.

Спирането става с ctrl-c в двата терминала с chroot-овете. След това се обаждате на крокодила да преточи raw видеото и да го обработи, или си взимате файла (log.xxxx.dv) и го обработвате вие с някои от по-горните инструкции.

varnaconf

В залата имаше една JBL колона, която по принцип беше директно вързана към микрофона на катедрата. Свързахме и двете към пулта, след което в пулта включихме и нашите микрофони. Камерата се намираше отзад и записваше с нейния микрофон, което доведе до много шум и проблемен звук, който после едвам докарахме до поносимо ниво. Мрежовата свързаност излизаше точно при камерата и беше независима от публичния wireless там, та с това нямаше проблем.