Захват экрана — за ценой не постоим
Материал из 0x1.tv
StasFomin (обсуждение | вклад) |
StasFomin (обсуждение | вклад) |
||
---- Если вы крупная телевизионно-транслирующая команда, решение очевидно — несколько камер на зал, стойка скейлеров-сплиттеров-фреймграбберов, все это длинными SDI-кабелями заводится на большой солидный пульт недремлющего режиссера трансляции, который и выбирает, какой из потоков, или какую комбинацию, запрограммированную на кнопках, пустить в эфир, ну и заодно, получить запись. И если вы, читатель, как раз он — умоляю, при трансляции программистких докладов всегда показывать экран, особенно если там идет лайв кодинг. Нет, показа на 5 секунд слайдов при их смене недостаточно — так теряется возможность перематывать запись, искать пропущенное, восстанавливать контекст. Ну а если прервалось живое демо, то это вовсе фейл. И это не извиняет то, что вам захотелось показать киношную картинку пота на лице ботана-спикера, ни красивую девушку зале, ни прикольного бородача в смешной футболке… Ибо в таком случае, как запись обычно всегда публикуется то, что пошло в эфир, часто даже оставляя ненарезанным лежать на каком-нибудь ютубе, т.е. фарш обратно не проворачивается, никто перемонтировать из исходников уже не будет, если произошла ошибка. ---- Что же делать осостальным конференциям, не могущим раскошелится профессиональных видеотрансляторов — пара грузовиков оборудования, взвод профессионалов — дешево быть не может? Понятное дело, экран надо записывать. Самая простой, дешевый, и очевидный подход — запись скринкаста на ноутбуке докладчика. Организаторы обычно предоставляют ноутбуки и иногда десктопы для выступающих, понятное дело, могут поставить любой скринкастер, множество их. Но есть нюансы. Проблемы скринкастинга следующие: * Торможение. Упаковка видео неслабо есть CPU, и соответственно, часто мешает докладчикам. Мало того, что начинают тормозить модные анимации и переходы в могучем поинте, так ведь при лайв демо начинается эффект «уже сейчас видно, что все будет глючить и тормозить» — поэтому «профессиональные евангелисты» как только это заметят, сразу потребуют убрать все это (запись им неважна, они с одной шарманкой выступают тыщи раз, а вот фейла позволить себе нельзя). ** Самое простой воркараунд — запускать скринкастер с самым низким приоритетом. «start /IDLE» или «start /LOW» под Windows, «nice» под Linux и т.п. * Рассинхрон с «истинным временем». Особенно, если скринкастер запустили с низким приоритетом, но даже самый высокий приоритет ни от чего не спасает. Разумеется, если просто тупые слайды, а ноутбук достаточно мощный — это маловероятно. Но вот если лайвдемо, показ видео... начинается временной дрейф и ад для видеомонтажера. ** Для решения этой проблемы, я давным-давно сделал [http://wiki.4intra.net/Screen2Log Screen2Log], так себе конечно поделка, однако активно использовалась мной, и до сих пор используется организаторами известных IT-конференций на пространстве СНГ. * При скринкастинге есть проблема «режима докладчика». Есть докладчики, которым пофиг, можно включать режим «зеркала», то, что запишет скринкастер — то и было на экране. Но есть те, кому нужен режим докладчика — с подсказками что говорить, какой слайд будет следующим и т.п. Иногда это не проблема — если слайды тупы, мелких деталей нет, то тогда да, только надо попыхтеть видеомонтажеру, вырезая «центральный слайд» из общего режима докладчика. [https://events.yandex.ru/lib/talks/2397/] * [[Участник:StasFomin|Стас Фомин]] ([[Обсуждение участника:StasFomin|обсуждение]]) 19:03, 2 ноября 2017 (MSK): [https://www.youtube.com/watch?v=QYrkIfw98H0 Ильдар Мусин, Дмитрий Иванов «Секционирование с pg_pathman»] — как отстойно снял оператор лайвкодинг. в блог. |
Версия 18:52, 2 ноября 2017
- Удивительно, что в 2017 еще кому-то надо объяснять, что в любых видео IT-докладов, после звука, самым важным является экран. Если можно обойтись звуком — это значит, либо технологий там совсем не было (менеджеризмы), либо это мастера техноподкастов, и рассчитывают именно то, что экрана нет, «все говорим словам».
- Но никакие слова не спасут, если идет лайвкодинг.
- Тем более удивляет, что в 2017 еще кто-то вот так снимает видео хардкорных лайвкодингов.
Экран должен быть,
- должен быть читаемым,
- снятым не камерой (блекло, нечетко, дрожжит, мерцает) с экрана проектора или плазмы, а полученный цифровым способом
- нет, вставка слайдов на этапе монтажа слабое утешение
- при сотнях слайдов наверняка что-то перепутает замученный монтажер
- даже в презентациях потеряется анимация, переходы в слайдах и видео
- ну а про лайвкодинг и лайвдемо нет и речи.
Если вы крупная телевизионно-транслирующая команда, решение очевидно — несколько камер на зал, стойка скейлеров-сплиттеров-фреймграбберов, все это длинными SDI-кабелями заводится на большой солидный пульт недремлющего режиссера трансляции, который и выбирает, какой из потоков, или какую комбинацию, запрограммированную на кнопках, пустить в эфир, ну и заодно, получить запись. И если вы, читатель, как раз он — умоляю, при трансляции программистких докладов всегда показывать экран, особенно если там идет лайв кодинг. Нет, показа на 5 секунд слайдов при их смене недостаточно — так теряется возможность перематывать запись, искать пропущенное, восстанавливать контекст. Ну а если прервалось живое демо, то это вовсе фейл. И это не извиняет то, что вам захотелось показать киношную картинку пота на лице ботана-спикера, ни красивую девушку зале, ни прикольного бородача в смешной футболке… Ибо в таком случае, как запись обычно всегда публикуется то, что пошло в эфир, часто даже оставляя ненарезанным лежать на каком-нибудь ютубе, т.е. фарш обратно не проворачивается, никто перемонтировать из исходников уже не будет, если произошла ошибка.
Что же делать остальным конференциям, не могущим раскошелится профессиональных видеотрансляторов — пара грузовиков оборудования, взвод профессионалов — дешево быть не может?
Понятное дело, экран надо записывать.
Самая простой, дешевый, и очевидный подход — запись скринкаста на ноутбуке докладчика. Организаторы обычно предоставляют ноутбуки и иногда десктопы для выступающих, понятное дело, могут поставить любой скринкастер, множество их. Но есть нюансы. Проблемы скринкастинга следующие:
- Торможение. Упаковка видео неслабо есть CPU, и соответственно, часто мешает докладчикам. Мало того, что начинают тормозить модные анимации и переходы в могучем поинте, так ведь при лайв демо начинается эффект «уже сейчас видно, что все будет глючить и тормозить» — поэтому «профессиональные евангелисты» как только это заметят, сразу потребуют убрать все это (запись им неважна, они с одной шарманкой выступают тыщи раз, а вот фейла позволить себе нельзя).
- Самое простой воркараунд — запускать скринкастер с самым низким приоритетом. «start /IDLE» или «start /LOW» под Windows, «nice» под Linux и т.п.
- Рассинхрон с «истинным временем». Особенно, если скринкастер запустили с низким приоритетом, но даже самый высокий приоритет ни от чего не спасает. Разумеется, если просто тупые слайды, а ноутбук достаточно мощный — это маловероятно. Но вот если лайвдемо, показ видео... начинается временной дрейф и ад для видеомонтажера.
- Для решения этой проблемы, я давным-давно сделал Screen2Log, так себе конечно поделка, однако активно использовалась мной, и до сих пор используется организаторами известных IT-конференций на пространстве СНГ.
- При скринкастинге есть проблема «режима докладчика». Есть докладчики, которым пофиг, можно включать режим «зеркала», то, что запишет скринкастер — то и было на экране. Но есть те, кому нужен режим докладчика — с подсказками что говорить, какой слайд будет следующим и т.п. Иногда это не проблема — если слайды тупы, мелких деталей нет, то тогда да, только надо попыхтеть видеомонтажеру, вырезая «центральный слайд» из общего режима докладчика.
- Стас Фомин (обсуждение) 19:03, 2 ноября 2017 (MSK): Ильдар Мусин, Дмитрий Иванов «Секционирование с pg_pathman» — как отстойно снял оператор лайвкодинг. в блог.