Демонстрация экрана и показ материалов для преподавания

Кратко

Демонстрация экрана на занятии – не то же самое, что показ экрана в обычном видеозвонке. На занятии показывают слайды, код и живые демо, которые учащиеся должны читать, и это требование к читаемости меняет все инженерные решения. Главный приём – передавать показываемый контент отдельным видеотреком рядом с камерой преподавателя, а не выключать камеру на время показа. Затем этот трек настраивают на чёткость, а не на плавность, двумя стандартными браузерными параметрами: подсказкой контента detail или text и предпочтением деградации maintain-resolution. Если всё сделать правильно, слайды остаются чёткими на любом канале, а лицо преподавателя – плавным. Если нет, класс читает мутный текст, демо дёргается или преподаватель пропадает с экрана в момент показа. Статья простым языком объясняет, как работает захват экрана в браузере, как выбирать между чёткостью и плавностью для слайдов и демо, сколько полосы нужно двум трекам, как располагать контент и преподавателя на экране, что делать со звуком, приватностью и доступностью и когда своя разработка выгоднее покупки.

Зачем это читать

Если вы строите или покупаете виртуальный класс, учтите: демонстрацией экрана преподаватели пользуются почти на каждом занятии, и именно её чаще всего делают «для галочки», не замечая, что требования здесь выше, чем у деловой встречи. На созвоне слегка размытый экран простителен; на занятии нечитаемый код или слайд, который учащийся не может разобрать, срывает урок. Хорошую учебную демонстрацию от обычной отличает не бюджет, а несколько осознанных решений о треках, подсказках кодеру и раскладке, которые большинство готовых интеграций оставляют по умолчанию. Статья даёт словарь и архитектуру, чтобы вы точно ставили задачу инженерам, оценивали демонстрацию у вендора по меркам преподавания и решали, где хватит готовой платформы, а где окупится своя разработка.

Что такое демонстрация экрана в браузере

Современные виртуальные классы работают в браузере на стандарте реального времени WebRTC (о нём – статья WebRTC для живого обучения). Чтобы показать экран, браузер преподавателя вызывает одну стандартную функцию – getDisplayMedia() из спецификации W3C Screen Capture (W3C Working Draft, Screen Capture). Браузер открывает системный диалог, преподаватель выбирает, что показать, и функция возвращает медиапоток – такой же объект, как у веб-камеры, только кадры берутся с экрана.

Из этого следует главное. Технически демонстрация экрана – просто ещё один видеотрек: поток кадров, который система кодирует и отправляет так же, как изображение с камеры. В этом её противоположность общей доске из статьи интерактивная доска и общий холст: доска синхронизирует крошечное описание фигур, которое отрисовывает каждый браузер, а демонстрация экрана передаёт сами пиксели, в одну сторону и только для просмотра. Пиксели тяжелее и при сжатии теряют чёткость, поэтому дальше речь пойдёт о том, как эту чёткость сохранить.

В диалоге можно выбрать один из трёх видов источника, которые спецификация называет поверхностями показа (display surface): весь экран monitor, окно приложения window или вкладку браузера browser (W3C, Screen Capture, перечисление DisplayCaptureSurfaceType). Этот выбор важен и для педагогики, и для приватности; к нему мы ещё вернёмся.

Первое правило: контент – второй трек, а не замена камере

Есть ошибка, по которой сразу видна «дешёвая» демонстрация. Когда преподаватель нажимает «Показать экран», ленивая реализация подменяет трек камеры потоком экрана: класс видит слайды, а преподаватель пропадает. На демо это выглядит нормально. Но на занятии учащиеся теряют живого человека: жесты, взгляд, «посмотрите на меня, это важно» – всё, на чём держится живое обучение.

Правильный подход – считать контент отдельным, дополнительным треком. Камера преподавателя идёт своим треком, экран – вторым, и оба одновременно приходят каждому учащемуся. Медиасервер, который раздаёт их классу (Selective Forwarding Unit, или SFU, из статьи масштабирование живого класса), просто пересылает два трека вместо одного. Архитектура этому не мешает, нужно лишь сознательно так спроектировать. Отдельный трек открывает все дальнейшие возможности: треки можно по-разному настроить, по-разному разместить на экране, записать раздельно и вывести один крупно, не теряя другой.

Нажмите, чтобы увеличить

Главный компромисс: чёткость или плавность

Теперь решение, которое отличает хорошую учебную демонстрацию от обычной. При ограниченной полосе любой видеокодер стоит перед выбором: держать высокое разрешение и снижать частоту кадров (меньше картинок в секунду, но чётких) или держать частоту кадров и снижать разрешение (больше картинок, но мутных). На узком канале одновременно и то и другое не получится.

Для «говорящей головы» важнее плавность: лицо на 30 кадрах в секунду выглядит живым, а пиксели никто не разглядывает. Для слайда с текстом или экрана с кодом намного важнее чёткость: статичный слайд, который обновляется дважды в секунду, – это нормально, а текст, превратившийся в кашу, останавливает занятие. Как сформулировала команда, переделавшая демонстрацию экрана в своём продукте, в приложении для показа экрана пользователи ценят читаемость выше анимации, а в видеозвонке – плавность выше разрешения (Multi, Making Illegible, Slow WebRTC Screenshare Legible and Fast, инженерный блог). Двум трекам нужны противоположные настройки – ещё одна причина, почему треков должно быть два.

Для этого в браузере есть две стандартные настройки.

Первая – подсказка контента (content hint). У каждого медиатрека есть свойство contentHint, определённое W3C; для видеотрека оно принимает значения motion, detail или text (W3C, MediaStreamTrack Content Hints). Оно сообщает кодеру, что за контент в треке, чтобы тот выбрал правильную стратегию: motion – для камеры (веб-камера, видео), detail или text – для показываемого экрана, где, по словам спецификации, «детали видео особенно важны» и часто встречаются «резкие края и области однородного цвета». Это точное описание слайдов и кода. На треке контента настройка занимает одну строку:

// contentTrack получен из getDisplayMedia(); cameraTrack – из getUserMedia()
contentTrack.contentHint = "text";   // резкие края, плоский цвет: слайды и код
cameraTrack.contentHint  = "motion"; // плавное движение: говорящая голова

Вторая – предпочтение деградации (degradation preference). У WebRTC-отправителя, который передаёт трек, есть параметр degradationPreference с тремя значениями: maintain-framerate, maintain-resolution и balanced (WebRTC 1.0, W3C Recommendation; параметры RTCRtpSender). Он говорит кодеру, чем жертвовать, когда не хватает полосы. Для трека контента ставят maintain-resolution: при сужении канала слайд остаётся чётким и просто обновляется реже. Для камеры – maintain-framerate: движение лица сохраняется за счёт разрешения. Это не мелочь: браузеры исторически по умолчанию агрессивно снижали разрешение демонстрации экрана, превращая текст в кашу, и maintain-resolution нужен именно для того, чтобы переопределить это поведение (Mozilla Bugzilla, WebRTC downgrades screen sharing resolution).

Нажмите, чтобы увеличить

Частота кадров и разрешение: выбирайте числа осознанно

Две подсказки определяют, чем кодер жертвует в первую очередь, но конкретные значения всё равно выбираете вы. Частоту кадров запрашивают как ограничение при захвате экрана:

const content = await navigator.mediaDevices.getDisplayMedia({
  video: { frameRate: { ideal: 5, max: 30 } }   // см. примечание ниже
});

На практике ориентируйтесь на такие значения. Статичные слайды и документы меняются несколько раз в минуту, поэтому низкой частоты, скажем 1–5 кадров в секунду, более чем достаточно, а освободившаяся полоса уйдёт на разрешение. Живому демо ПО (клики в приложении, прокрутка кода, движение курсора) нужна частота повыше, около 15 кадров в секунду, иначе оно выглядит заторможенным. Видео внутри показа или динамичной анимации нужны полные 30 кадров в секунду; в этот момент трек контента фактически становится треком движения, и его нужно пометить как motion. Поэтому не делайте одну настройку частоты на всю демонстрацию экрана. Привяжите её к тому, что показывает преподаватель, или дайте простой переключатель «слайды / демо / видео», который меняет подсказки.

Разрешение должно соответствовать источнику, а не заниженной догадке. Экран 1080p захватывайте в 1080p; не давайте конвейеру незаметно ужать его до 720p, чтобы потом учащийся разбирал код 10-м кеглем. Именно от этого и защищает maintain-resolution.

Сколько полосы нужно двум трекам

Два трека дороже одного, и продуктовой команде лучше узнать цифру до того, как она станет сюрпризом на лекции на 200 мест. Посчитаем в расчёте на одного учащегося, который принимает потоки.

Камера 720p при 30 кадрах в секунду, настроенная на движение, – примерно 1,2 Мбит/с. Трек контента со слайдами 1080p при низкой частоте, настроенный на детали, неравномерен: пока слайд стоит, почти ноль, при смене – всплеск. В среднем закладывайте на него около 1,0 Мбит/с. Складываем:

камера (720p30, motion)   ≈ 1,2 Мбит/с
контент (1080p, detail)   ≈ 1,0 Мбит/с
-------------------------------------
приём на учащегося        ≈ 2,2 Мбит/с

Теперь масштаб. Преподаватель отправляет каждый трек один раз, а раздаёт их SFU, поэтому для класса из 50 человек исходящий трафик сервера – около 50 × 2,2 = 110 Мбит/с, а каждый учащийся принимает всего 2,2 Мбит/с. Это спокойно укладывается в обычный домашний интернет – хорошая новость. Плохая касается слабых сетей: у учащегося с мобильным каналом 3 Мбит/с запаса почти нет, и здесь maintain-resolution себя оправдывает: слайд остаётся читаемым, а частота кадров незаметно падает, вместо того чтобы расплылся текст. Подробнее о топологии и масштабировании – в статье масштабирование живого класса; выбор кодеков, который уменьшает эти цифры, разобран в разделе Video Streaming.

Нажмите, чтобы увеличить

Раскладка: контент на главную сцену

Два трека полезны, только если на экране учащегося они расположены удобно для учёбы. Обычно показываемый контент закрепляют на главной сцене (в ВКС этот режим называют закреплением или spotlight), а камера преподавателя сжимается до миниатюры в углу – «картинка в картинке». Это решение о раскладке на стороне клиента, а не о медиа: SFU по-прежнему пересылает оба трека, а приложение решает, какого размера рисовать каждый. Раз контент приходит отдельным треком, слайд можно показать крупно и чётко, а преподавателя оставить на экране в маленьком окне. Именно такую раскладку поддерживают исследования.

Согласно когнитивной теории мультимедийного обучения, учащиеся понимают больше, когда связанные слова и изображения находятся рядом, а преподаватель выделяет главное, и меньше – когда внимание разрывается между несвязанными источниками (Mayer, Cognitive Theory of Multimedia Learning; принципы пространственной смежности и сигнализации). Крупный читаемый слайд и лицо преподавателя рядом (он жестикулирует, указывает, расставляет акценты) удерживают рассказ и изображение вместе. Слайд на весь экран без преподавателя или огромная камера с крошечным слайдом одинаково рассеивают внимание. Вывод для продукта (подробнее – в статье педагогика видео): раскладка по умолчанию должна отдавать главное место контенту и при этом оставлять преподавателя на экране, а не заставлять выбирать одно из двух.

Нажмите, чтобы увеличить

Звук: класс должен слышать то, что вы показываете

Демо часто идёт со звуком. Если преподаватель запускает в показе обучающее видео, до класса должен дойти звук этого видео, а не только микрофон. Стандарт захвата экрана позволяет вместе с изображением захватывать звук, в частности звук вкладки или окна, – достаточно запросить его в том же вызове (W3C, Screen Capture; захват аудио поверхности показа). Здесь важны две практические детали.

Во-первых, звук показываемой вкладки захватывается отдельно от микрофона преподавателя, поэтому класс слышит и рассказ, и видео – именно то, что нужно, если громкость сведена сбалансированно. Во-вторых, есть риск обратной связи: если динамики преподавателя воспроизводят этот звук при открытом микрофоне, возникает эхо. Браузер даёт настройку suppressLocalAudioPlayback: захваченный звук не воспроизводится ещё и в локальных динамиках, и один частый источник эха исчезает (MDN, suppressLocalAudioPlayback). Более глубокая работа со звуком – подавление эха, шумоподавление, синхронизация – относится к аудиоконвейеру, которому посвящён раздел Audio for Video. Здесь же главное – заранее запланировать звук показа, а не обнаружить на релизе, что класс не слышит демо.

Доступность показанного контента

Требования к самому контенту при показе экрана никуда не деваются. Текст на слайде должен соответствовать минимальному контрасту (WCAG 2.1, критерий 1.4.3); изображения текста по возможности заменяют настоящим текстом – например, прикладывают файл презентации к материалам занятия (критерий 1.4.5); у звука видео, проигрываемого в показе, должны быть субтитры, а в прямом эфире – живые субтитры (критерий 1.2.4). В России на WCAG 2.1 построен ГОСТ Р 52872-2019; стандарт добровольный, но заказчик вправе вписать его в техническое задание, а для учащихся с ОВЗ ст. 79 273-ФЗ требует специальных условий обучения, включая услуги сурдопереводчика. Вывод для раскладки: если на занятии работает сурдопереводчик, его видео должно оставаться на экране рядом с контентом, как и миниатюра преподавателя, и не пропадать, когда контент закрепляют крупно.

Приватность: показывайте вкладку или окно, а не весь экран

Выбор поверхности показа из начала статьи – ещё и вопрос безопасности. При показе всего экрана (monitor) класс видит всё, что на нём всплывает: уведомление о личном сообщении, превью случайного письма, не ту вкладку браузера. Учебный продукт должен по умолчанию подталкивать преподавателя показывать отдельное окно (window) или вкладку (browser), чтобы класс видел только нужное, и делать этот путь самым простым в интерфейсе. Спецификация захвата экрана прямо предупреждает, что у функции «значительные последствия для безопасности»: приложение может получить доступ к конфиденциальной информации из других источников (W3C, Screen Capture, Introduction). Относитесь к выбору поверхности как к настройке приватности: по умолчанию предлагайте самую узкую поверхность, которой достаточно для задачи, и до начала показа напоминайте преподавателю, что увидит класс. Если занятие записывается, всё, что мелькнуло на экране, останется в записи, включая чужие персональные данные: ведомость с ФИО и оценками, переписку с учащимся. Такая запись становится документом с ПДн, который придётся хранить и защищать по 152-ФЗ, поэтому узкая поверхность по умолчанию обходится дешевле, чем последующая чистка записей.

Строить или покупать: где находятся нужные настройки

Захват экрана даёт браузер, а SFU с нуля большинству продуктов писать не нужно. Настоящий вопрос – насколько платформа открывает настройки, важные для преподавания; многие не открывают их вовсе. В таблице роль столбца стандартов из других статей раздела играют управление треком контента и пригодность к трекингу.

Разумный вариант по умолчанию: учебный продукт, для которого демонстрация важна, начинает с открытого SFU в российском облаке или с CPaaS, который позволяет задавать подсказку контента и предпочтение деградации для каждого трека и собирать сцену, где главное место у контента. К полностью своей медиасборке переходите, когда нужен жёсткий контроль над кодированием двух треков, особые раскладки для занятий, поведение в каждом зале, привязанное к состоянию сессионных залов, или полноценный трекинг. Обычный конференц-софт как есть годится, только если «достаточно хорошо» действительно достаточно. Для школ, колледжей и вузов есть ещё один фильтр: по п. 21 Правил применения ЭО и ДОТ (ПП № 1678 в ред. ПП № 517) ПО видео-конференц-связи в составе дистанционных технологий должно создаваться и использоваться по законодательству РФ и (или) входить в единый реестр российского ПО, а к государственным заказчикам эту норму на практике применяют жёстко.

Трекинг показа для аналитики

Если вы хотите знать, кто смотрел демо и сколько (это полезно для аналитики прохождения и вовлечённости), описывайте показ как учебные события, а не вытаскивайте данные из медиаслоя. Стандартный способ записать «преподаватель начал показ слайдов» или «Мария смотрела демо 6 минут» – xAPI-утверждение, как в статье трекинг видео через xAPI Video Profile. Если начало и конец показа и время просмотра каждым учащимся записываются как утверждения, аналитика говорит на том же языке, что и остальные учебные данные, и не превращается в разрозненный лог, который никто не свяжет с записью учащегося.

Частая ошибка, которая на демо выглядит нормально

Соблазнительный путь – оставить всё по умолчанию: одна кнопка показа экрана, камера подменяется, подсказки контента нет, предпочтения деградации нет, показывается весь экран. В тихом офисе на быстром канале с одним слайдом всё работает прекрасно. Потом приходит настоящий класс. Учащийся в поезде с мобильным интернетом пытается читать расплывающийся код: браузер снизил разрешение, сохраняя частоту кадров, которая здесь никому не нужна. У другого преподавателя во время показа всплывает личное уведомление. Третий запускает обучающее видео, а класс слышит тишину, потому что звук вкладки так и не запросили. И на каждом занятии в момент показа преподаватель пропадает с экрана. Ни одна из этих проблем не баг в обычном смысле – это непроверенные настройки по умолчанию. Решение – всё, о чём эта статья: контент отдельным треком с пометкой о деталях и maintain-resolution, показ окна, а не всего экрана, заранее продуманный звук и преподаватель, который остаётся на экране.

Где здесь Фора Софт

Учебная демонстрация экрана – задача медиаинженерии, спрятанная за кнопкой в один клик: несколько по-разному настроенных треков, которые раздаёт SFU и которые нужно правильно расположить на экране. Это как раз наша работа. Фора Софт с 2005 года делает видеосвязь, системы видеоконференций и виртуальные классы, поэтому одна команда разбирается и в API захвата, и в подсказках кодеру, и в SFU, который пересылает треки, и в раскладке, выводящей контент на главную сцену без потери преподавателя. Мы подключаемся, когда учебному продукту нужна демонстрация, которая остаётся читаемой на слабых сетях, показывает контент и спикера вместе, передаёт звук демо и подключена к трекингу. И честно говорим, если CPaaS или готовая ВКС с нужными настройками уже закрывает задачу и своя разработка не окупится. Во всех наших направлениях – онлайн-обучении, видеоконференциях, телемедицине и стриминге – в основе одна и та же медиаинфраструктура реального времени.

Главное

• Показывайте контент отдельным треком рядом с камерой; не выключайте камеру на время показа.
• Настройте трек контента на чёткость: подсказка detail или text, деградация maintain-resolution.
• Подбирайте частоту под контент: 1–5 fps для слайдов, ~15 для демо, 30 для видео.
• Закладывайте два трека на учащегося (≈2,2 Мбит/с); maintain-resolution сохраняет читаемость на слабом канале.
• Выводите контент на главную сцену, а преподавателя – в «картинку в картинке», не заставляя выбирать одно из двух.
• По умолчанию показывайте окно или вкладку, а не весь экран: всё лишнее попадёт и в запись, вместе с чужими ПДн.
• Планируйте звук показа, субтитры и место для сурдопереводчика на экране.

Что читать дальше

• Виртуальный класс: что это и чем он отличается от встречи
• Масштабирование живого класса: SFU, simulcast и лекция на 200 мест
• Интерактивная доска и общий холст