Как правя streaming-а и записите: Difference between revisions
No edit summary |
|||
(10 intermediate revisions by the same user not shown) | |||
Line 6: | Line 6: | ||
=== Видео източник (камера) === | === Видео източник (камера) === | ||
По принцип използвам видео камера с firewire изход. Предимствата са, че е сравнително стандартно, има поддръжка в linux, windows и какво ли не още, работи стабилно (т.е. използва се) и може да вкарва лесно и звука и картината в синхронизиран файл. Първо ползвах една Sony DCR-TRV33E (720x576), сега ползваме Cannon Legria | По принцип използвам видео камера с firewire изход. Предимствата са, че е сравнително стандартно, има поддръжка в linux, windows и какво ли не още, работи стабилно (т.е. използва се) и може да вкарва лесно и звука и картината в синхронизиран файл. Първо ползвах една Sony DCR-TRV33E (720x576), сега ползваме Cannon Legria HV40, която може да прави 1080p (FullHD) записи. Двете камери вадят еднакви по размер файлове, като втората използва mpeg2/aac като кодеци. | ||
* Legria-та по принцип има автоматичен gain control на входа за звук, който трябва да се спре и нивото на микрофона да се настрои на ръка, понеже иначе усилва всякакви минимални шумове. | |||
Може да се използва и нормална usb камера през v4l2 интерфейса (или каквото-е-там под windows), отбелязал съм по-долу къде би трябвало да има разлики. | Може да се използва и нормална usb камера през v4l2 интерфейса (или каквото-е-там под windows), отбелязал съм по-долу къде би трябвало да има разлики. | ||
Line 12: | Line 14: | ||
Камерата има нужда от статив или някакъв друг начин, по който да се стабилизира. | Камерата има нужда от статив или някакъв друг начин, по който да се стабилизира. | ||
=== | === Encoder/streamer === | ||
Един добър лаптоп с интерфейс към камерата (ако не е firewire, и към звука), който да може да смята достатъчно бързо video/audio codec-ите (за streaming) и диск, на който да може да прави записите (за записа). "Некомпресираното" видео от DV/HDV камера, което идва по firewire е около 24mbps, съответно час и половина са 19GB (целият запис от VarnaConf например беше 100GB, един ден и около 8-9 часа). Също така за stream-ване силно препоръчвам да се ползва жичен ethernet, вместо wireless, поради буферните проблеми, които wireless-а може да направи. | Един добър лаптоп с интерфейс към камерата (ако не е firewire, и към звука), който да може да смята достатъчно бързо video/audio codec-ите (за streaming) и диск, на който да може да прави записите (за записа). "Некомпресираното" видео от DV/HDV камера, което идва по firewire е около 24mbps, съответно час и половина са 19GB (целият запис от VarnaConf например беше 100GB, един ден и около 8-9 часа). Също така за stream-ване силно препоръчвам да се ползва жичен ethernet, вместо wireless, поради буферните проблеми, които wireless-а може да направи. | ||
=== | === Звук === | ||
==== | ==== Микрофони ==== | ||
По принцип за конференциите са нужни два типа микрофони - "брошки" (такива, които се закачат на лектора) и "нормални", които или да стоят стационарно, или да са безжични и да се разнасят из публиката. Аз лично препоръчвам всички да са безжични, понеже се спестяват много кабелни проблеми. От друга страна, при безжичните микрофони трябва да се внимава какви канали се използват и да не се получи колизия с друго такова оборудване наблизо. | По принцип за конференциите са нужни два типа микрофони - "брошки" (такива, които се закачат на лектора) и "нормални", които или да стоят стационарно, или да са безжични и да се разнасят из публиката. Аз лично препоръчвам всички да са безжични, понеже се спестяват много кабелни проблеми. От друга страна, при безжичните микрофони трябва да се внимава какви канали се използват и да не се получи колизия с друго такова оборудване наблизо. | ||
Line 26: | Line 28: | ||
Поне част от местата, в които които се провеждат разни събития имат някакво количество такова оборудване. | Поне част от местата, в които които се провеждат разни събития имат някакво количество такова оборудване. | ||
==== | Аз използвам един AKG WMS 40 FLEXX за брошка и HED Audio WMS-35DUAL за преносими микрофони. | ||
==== Пулт/миксер ==== | |||
Всичкият звук има нужда да се събере на едно място, за да се изпрати към камерата и към озвучаването на залата. В общи линии всякакъв миксер с нужния брой входове, изходи и възможности за настройка върши работа (аз се справям с един Behringer Xenyx 802). Често се случва мястото, на което е събитието да има подобен пулт, към който са закачени техните audio неща. | Всичкият звук има нужда да се събере на едно място, за да се изпрати към камерата и към озвучаването на залата. В общи линии всякакъв миксер с нужния брой входове, изходи и възможности за настройка върши работа (аз се справям с един Behringer Xenyx 802). Често се случва мястото, на което е събитието да има подобен пулт, към който са закачени техните audio неща. | ||
==== | ==== Озвучаване ==== | ||
По принцип за да може да се чува добре какво се говори е добра идея това, което лекторите и т.н. казват да се усилва и чува от допълнителни източници. Почти всичко, което има усилвател и колони може да свърши тая работа, като повечето зали имат нещо подобно. В случаите, в които нямат съм открил, че кубе от бас (моето Fender Bass Rumble 15) вади добър звук като за човешки глас и има достатъчна мощност да озвучи зала за 100-200 човека (зала 200 на ФМИ на СУ). По същия начин сме използвали усилвател и две колони в ТУ-София за курса по linux (нямам спомен какви точно бяха, мисля, че се водеха 50-100W). Тестове може да се провеждат лесно и да се види колко добре се получава звукът. | По принцип за да може да се чува добре какво се говори е добра идея това, което лекторите и т.н. казват да се усилва и чува от допълнителни източници. Почти всичко, което има усилвател и колони може да свърши тая работа, като повечето зали имат нещо подобно. В случаите, в които нямат съм открил, че кубе от бас (моето Fender Bass Rumble 15) вади добър звук като за човешки глас и има достатъчна мощност да озвучи зала за 100-200 човека (зала 200 на ФМИ на СУ). По същия начин сме използвали усилвател и две колони в ТУ-София за курса по linux (нямам спомен какви точно бяха, мисля, че се водеха 50-100W). Тестове може да се провеждат лесно и да се види колко добре се получава звукът. | ||
(не препоръчвам да се ползват китарни кубета, понеже при тях кривенето на звука е feature) | (не препоръчвам да се ползват китарни кубета, понеже при тях кривенето на звука е feature) | ||
==== Източник на звук, музика за паузите ==== | |||
Полезно е да има някакъв източник на звук, от който да се пуска (тихо) музика в паузите. Най-лесно става с лаптоп, но и телефон (който няма да звънне) или mp3 player биха свършили работа. | |||
Музиката, която се пуска трябва да е под свободен лиценз или поне да имате по някакъв начин право да я пускате (за да не си създадете безсмислени проблеми за в бъдеще). Мога да дам няколко варианта: | |||
* Първите три албума на Falik, които са под creative commons. | |||
* Скоро записаното dvd на MusOpen: [http://archive.org/details/musopen-lossless-dvd] | |||
* Колекцията записи на wikipedia (изпълненията не са от най-добрите): [https://en.wikipedia.org/wiki/Wikipedia:Sound/list] | |||
* Creative commons поддържат списък сайтове, който могат да се погледнат: [https://creativecommons.org/music-communities] | |||
=== Разни === | === Разни === | ||
Line 46: | Line 60: | ||
** например всички безжични микрофони | ** например всички безжични микрофони | ||
* Стойки за микрофони (ако са нужни и няма на място) | * Стойки за микрофони (ако са нужни и няма на място) | ||
== Софтуер == | == Софтуер == | ||
Line 162: | Line 175: | ||
rm -f "$name" x264_2pass.log* | rm -f "$name" x264_2pass.log* | ||
ffmpeg -analyzeduration 50000000 -v verbose -y -i "$input" | 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 | -vcodec libx264 -s $res -b $rate -qmin 10 -qmax 51 -qdiff 4 -filter:v yadif $name | ||
ffmpeg -analyzeduration 50000000 -v verbose -y -i "$input" | 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 | -vcodec libx264 -s $res -b $rate -qmin 10 -qmax 51 -qdiff 4 -filter:v yadif $name | ||
Line 225: | Line 238: | ||
<nowiki> | <nowiki> | ||
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 | 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 | ||
</nowiki> | |||
Има вариант под windows, който сме тествали, с ffmpeg, само за streaming на екрана и звук: | |||
<nowiki> | |||
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 | |||
</nowiki> | </nowiki> | ||
Line 240: | Line 258: | ||
</nowiki> | </nowiki> | ||
която ще създаде един голям файл, който вече може да се обработва. Без --size 0 ще направи отделни файлове по 1GB, който после първо ще трябва да се лепят, после да се режат, което не е особено удобно. | която ще създаде един голям файл, който вече може да се обработва. Без --size 0 ще направи отделни файлове по 1GB, който после първо ще трябва да се лепят, после да се режат, което не е особено удобно. | ||
* В някои случаи изглежда по-удобно да се направят отделни файлове по 1GB (които са по около 5 минути) и после да се налепят, но съм имал различни проблеми със софтуера, който прави слепването (най-вече разсинхронизация на звука) и за това не го препоръчвам. | |||
==== Работа с камерата ==== | ==== Работа с камерата ==== | ||
Line 316: | Line 336: | ||
=== initlab === | === initlab === | ||
В initlab изходът на звука е свързан към озвучаването на голямата стая, а сървърчето там (cassie.ludost.net) е закачено към | В initlab изходът на звука е свързан към озвучаването на голямата стая, а сървърчето там (cassie.ludost.net) е закачено към миксера, съответно може да се пуска музика в паузите и може да се чува добре в стаята. Камерата стои отзад (до библиотеката) заедно с цялата техника, и има в общи линии нужда само от микрофон за лектора и понякога някой от другите преносими за задаване на въпроси. Звукът се получаваше сравнително добре и като се записваше директно от микрофона на камерата. | ||
==== Пускане/спиране ==== | |||
След като се включи камерата и се провери звука на микрофоните, се включва лаптопа, влиза се с user/pass initlab. В един терминал се пуска | |||
<nowiki> | |||
while /bin/true; do sync; sleep 2; date; done | |||
</nowiki> | |||
в два други се прави chroot и su: | |||
<nowiki> | |||
sudo chroot /home/encoder /bin/bash | |||
su - vasil | |||
</nowiki> | |||
(на su може да даде нещо като грешка, няма значение) | |||
В единия от двата chroot терминала се пуска | |||
<nowiki> | |||
dvgrab --format raw - | ./ttee av.m2t log.`date +%H%M`.dv | |||
</nowiki> | |||
а в другия | |||
<nowiki> | |||
bash -x stream.sh | |||
</nowiki> | |||
(трябва да се пуснат бързо едно след друго, командите ги има в history-то). | |||
Stream-а е достъпен на http://stream4.initlab.org:8787/lab.ts , може да се гледа с vlc. | |||
Спирането става с ctrl-c в двата терминала с chroot-овете. След това се обаждате на крокодила да преточи raw видеото и да го обработи, или си взимате файла (log.xxxx.dv) и го обработвате вие с някои от по-горните инструкции. | |||
=== varnaconf === | === varnaconf === |
Latest revision as of 16:32, 5 December 2013
Първия път, когато писах подобно нещо, беше преди 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 там, та с това нямаше проблем.