Содержание статьи +
- Кратко
- Зачем это читать
- Задержка: одна планка для всех приёмов
- Звук важнее видео: защищайте его в первую очередь
- Клиническая планка «достаточно хорошо» по специальностям
- Когда сеть слабеет: детали или движение
- Один поток, много устройств: simulcast и SVC
- Пример: во что обходится «всегда 1080p»
- Частые ошибки
- Где здесь Фора Софт
- Главное
- Что читать дальше
Это инженерные рекомендации, а не юридическая консультация. Детали уточняйте у квалифицированного юриста.
Кратко
Нужное качество видео для телемедицинского приёма определяет клиническая задача, а не самая большая цифра в спецификации. Повторной консультации по ходу лечения хватит чистого звука и узнаваемого лица, а для осмотра раны нужна резкая картинка с точным цветом. Единственный параметр, важный для любого приёма, – задержка: если задержка «рот-ухо» в одну сторону меньше ~150 миллисекунд, разговор ощущается как в кабинете (давняя рекомендация ITU-T G.114). Когда сеть слабеет, звонок должен жертвовать качеством осознанно. Что сохранить – разрешение (для мелких деталей) или частоту кадров (для движения), – вы задаёте настройкой WebRTC degradationPreference. В статье – бюджет задержки, таблица требований к качеству по специальностям, выбор стратегии деградации и simulcast, благодаря которому один поток пациента подходит и телефону, и десктопу.
Зачем это читать
Если вы оцениваете или покупаете телемедицинскую платформу, «HD-видео» кажется требованием, которое надо предъявлять везде. На деле этот рефлекс незаметно съедает деньги и раздражает пациентов со слабой сетью. Спрашивать стоит не о максимальном качестве, а о минимальном, при котором именно этот приём ещё безопасен и эффективен. Если планка выставлена верно, полоса, заряд батареи и силы инженеров уходят туда, где от картинки зависит клиническое решение, и не тратятся там, где не зависит. Статья написана для основателя, продакт-менеджера или руководителя клинической ИТ-службы, которому нужно задать эти цели, а потом проверить у вендора или инженера, достигает ли их платформа. Прочитав её, вы сможете назвать для каждого типа приёма нужные разрешение, частоту кадров и задержку и сказать, что должно происходить, когда сеть не справляется.
Задержка: одна планка для всех приёмов
Начнём с параметра, который важен независимо от специальности. Задержка – это время между событием перед камерой пациента и моментом, когда врач его видит и слышит. Для видео её часто называют задержкой «от стекла до стекла» (glass-to-glass), для звука – «рот-ухо». Измеряют её в миллисекундах (мс, тысячных долях секунды). От задержки зависит, идёт ли разговор естественно или собеседники постоянно перебивают друг друга.
Ориентир пришёл из телефонии и не меняется десятилетиями. Рекомендация ITU-T G.114, международный стандарт времени передачи в одну сторону, считает задержку примерно до 150 мс практически незаметной. При 150–400 мс связь ещё пригодна, но разговор теряет живость: естественный ритм реплик сбивается, люди начинают перебивать друг друга. Больше 400 мс для нормального разговора неприемлемо. На клиническом приёме врач считывает паузы, колебания и эмоции пациента, поэтому цель – нижняя граница этого диапазона.
Задержка накапливается по всему конвейеру: каждый этап добавляет свою долю.
Посчитаем на типичном примере. Захват кадра камерой занимает около 10 мс, кодирование в сжатый видеопоток – примерно 20 мс. Передача по интернету – самая непредсказуемая часть: от 30 мс на хорошем оптоволокне до 150 мс и больше в перегруженной мобильной сети или на длинном маршруте. На стороне получателя работает джиттер-буфер – небольшая очередь, которая выравнивает неравномерно приходящие пакеты. Он сознательно добавляет 20–60 мс: немного задержки в обмен на ровное воспроизведение. Декодирование занимает около 15 мс, отрисовка кадра на экране – ещё 15 мс. Сложим типичные значения: 10 + 20 + 60 + 40 + 15 + 15 = 160 мс в одну сторону, то есть на самой границе «незаметного» диапазона. Поэтому больше всего внимания достаётся сети и джиттер-буферу: именно там бюджет выигрывают или теряют.
Отсюда два практических вывода. Первый: маршрутизация важна. Чем ближе медиасервер к обоим участникам, тем меньше сетевая доля задержки, так что размещение медиасерверов по регионам – реальный инструмент, а не роскошь (к масштабированию и регионам вернёмся в отдельной статье). Второй: джиттер-буфер нужно настраивать. Чем больше буфер, тем ровнее звук, но тем выше задержка, поэтому его подстраивают под разговор, а не выкручивают на максимум. Подробно механика джиттер-буферов разобрана в разделе об аудио; здесь достаточно помнить, что этот этап входит в бюджет задержки. См. джиттер-буфер и NetEQ и маскирование потерь пакетов.
Звук важнее видео: защищайте его в первую очередь
Всё дальнейшее определяет неочевидное правило: почти на любом приёме звук клинически важнее видео. Врач проведёт почти весь разговор об анамнезе и симптомах при чистом звуке и застывшей или нечёткой картинке, но не сможет провести его при резком видео и искажённом звуке. Пациент описывает боль в груди, родитель рассказывает о температуре у ребёнка, врач уточняет схему приёма лекарств – всё это прежде всего разговор, а лицо на экране его лишь дополняет.
Поэтому все дальнейшие решения о качестве жертвуют видео ради звука. Когда сеть проседает, картинка должна уменьшиться, замедлиться или встать на паузу раньше, чем пострадает звук. По той же причине режим «только звук», а в крайнем случае и обычная телефонная линия – полноценный канал связи, а не экран с ошибкой. Обязательные элементы телемедицинской консультации от канала не зависят: участники идентифицируются через ЕСИА, заключение врач подписывает УКЭП (ч. 6–7 ст. 36.2 323-ФЗ). Но допустим ли формат «только голос» для конкретной консультации и как он оплачивается (по ОМС, ДМС или как платная услуга), уточните у юриста и в условиях оплаты, прежде чем на это опираться.
Клиническая планка «достаточно хорошо» по специальностям
Теперь главная мысль. На разных приёмах врач смотрит на разное, поэтому и картинка нужна разная. Передавать 1080p при 30 кадрах в секунду на каждом приёме – всё равно что назначать всем пациентам одну дозу: иногда это верно, часто избыточно, а порой и вредно.
Повторная консультация или контроль лечения – это прежде всего разговор. Врачу нужно узнать пациента и поговорить с ним: 360–480p при 15–24 кадрах в секунду более чем достаточно, основную работу делает звук. Всё, что сверх этого, – лишние расходы.
На приёмах психиатра и психотерапевта разрешения и плавности должно хватать, чтобы оценивать аффект: мимику, контакт глаз, короткие паузы. Практическая планка – примерно 480–720p при 24–30 fps. Плавность здесь важна, потому что аффект проявляется в движении, а не в одном резком кадре.
Первичная и неотложная помощь – посередине: 720p при 24–30 fps позволяют увидеть общие внешние признаки – бледность, отёк, сыпь, которую пациент показывает в камеру, то, как он двигается и дышит. Задача видео здесь – собрать жалобы и помочь врачу решить, нужен ли очный приём: без него диагноз дистанционно не ставится (п. 40 приказа Минздрава 193н), а детальный осмотр обычно переносят на очный визит или заменяют присланным фото.
Дерматология и лечение ран меняют приоритет: детали важнее движения. Один резкий кадр с точным цветом здесь ценнее плавного потока. Часто цитируемые профессиональные стандарты теледерматологии (AAD) рекомендуют снимать с разрешением не ниже 800×600 пикселей, а лучше 1024×768 и выше (около 0,8 мегапикселя). В современных асинхронных консультациях по фотографиям (store-and-forward) обычно используют снимки 2–3 мегапикселя при ровном освещении. Для таких приёмов часто лучше всего работает связка: живое видео плюс кадр высокого разрешения или загруженное фото. Видео даёт контекст и позволяет получить согласие пациента, а снимок несёт диагностически важные детали. Но и у «больше» есть практический предел: чем больше мегапикселей, тем тяжелее файлы и медленнее передача.
Телеинсульт и неврологические осмотры – самый требовательный случай: здесь нужны и детали, и движение. Дистанционная оценка инсульта, например по шкале NIH Stroke Scale (NIHSS, стандартный неврологический осмотр из 15 пунктов), строится на наблюдении за движениями: взглядом, симметрией лица, удержанием конечностей, координацией. Исследования показали, что при достаточно хорошем видео удалённая оценка по NIHSS почти совпадает с очной (корреляция около r = 0,97), а низкоскоростные каналы (ранний 3G) для неё не годились, в отличие от более быстрых. Практическая планка – 720–1080p при стабильных 30 fps и устойчивом соединении: здесь пропущенный кадр может скрыть клинический признак.
Эти цифры не нужно заучивать. Важнее привычка: для каждого типа приёма, который поддерживает ваш продукт, решите, что врач обязан увидеть, и задайте минимальное качество, которое это обеспечивает. Это и есть ваша планка «достаточно хорошо».
Когда сеть слабеет: детали или движение
Реальная сеть не держит нужную полосу стабильно. Когда полоса падает, WebRTC (Web Real-Time Communication – браузерная технология для видеосвязи в реальном времени) не может сохранить и разрешение, и частоту кадров. Чем-то придётся пожертвовать, и главный вопрос – чем именно. WebRTC позволяет задать это напрямую через настройку degradationPreference у отправителя видео.
У неё три значения. maintain-resolution велит кодеру сохранять резкость и снижать частоту кадров: картинка чёткая, но дёрганая. maintain-framerate сохраняет плавность и снижает разрешение: движение плавное, но картинка мягче. balanced (значение по умолчанию) понемногу жертвует и тем и другим. Неподходящее значение по умолчанию может незаметно повлиять на клиническое решение.
Выбор зависит от клинической задачи. Если на приёме важны мелкие детали (очаг на коже, рана, глаз), ставьте maintain-resolution: резкий кадр, который обновляется медленно, лучше плавного размытого изображения. Если важно движение (аффект на приёме психиатра, тремор, походка, симптомы инсульта), ставьте maintain-framerate: плавное движение лучше резкого, но застывающего кадра. Частая ошибка – один раз задать общее значение и больше к нему не возвращаться. В хороших продуктах настройка зависит от типа приёма, а иногда врач может переключить режим прямо во время звонка, когда ему нужно что-то рассмотреть.
Так это выглядит в коде (pc – уже установленный RTCPeerConnection):
// Сохранить детали для дерматологического приёма: резкая картинка, ниже частота кадров.
const sender = pc.getSenders().find((s) => s.track && s.track.kind === "video");
const params = sender.getParameters();
params.degradationPreference = "maintain-resolution"; // или "maintain-framerate" для движения
await sender.setParameters(params);При всём этом звук остаётся защищённым. Лестница деградации клинического звонка жертвует качеством видео по порядку: снижает разрешение или частоту кадров, затем отключает лишние видеослои, затем ставит видео на паузу и оставляет только звук, а в крайнем случае переводит разговор на телефон. Звуком она не жертвует никогда. Эту цепочку мы подробно разбираем в статье о надёжности соединения. С качеством она связана напрямую: плавная деградация позволяет удержать планку «достаточно хорошо», когда сеть подводит.
Один поток, много устройств: simulcast и SVC
На реальном приёме у участников редко бывают одинаковые устройства. Пациент сидит на старом телефоне с мобильным интернетом, врач – за десктопом с проводной сетью, приглашённый специалист подключается с планшета. Если бы платформа отправляла всем одно и то же качество, ей пришлось бы равняться на самое слабое устройство и самую слабую сеть, и врач за десктопом видел бы такую же размытую картинку, как старый телефон.
Эту задачу решают два подхода, и оба опираются на SFU (Selective Forwarding Unit) – медиасервер, который принимает видео каждого участника и пересылает остальным подходящую версию, ничего не смешивая. При simulcast отправитель кодирует видео сразу в нескольких вариантах качества, например 1080p, 720p и 360p, и отправляет все в SFU, а тот пересылает каждому зрителю вариант, который тот потянет. SVC (Scalable Video Coding) даёт похожий результат внутри одного многослойного потока: сервер просто отбрасывает лишние слои. В обоих случаях никого не равняют на самого слабого, а сервер обходится без транскодирования (декодирования и повторного кодирования) каждого потока, которое добавляет нагрузку и задержку.
Если вы не технический специалист, вопрос вендору простой: «Когда в звонке мощное и слабое устройство, каждое получает лучшее качество, которое способно принять, или все опускаются до уровня слабого?» Если второе, платформа не использует simulcast или SVC, и приёмы с разными устройствами (а таких большинство) будут выглядеть хуже, чем могли бы. Как устроены слои и как считается полоса, разобрано в разделе о видеостриминге: см. simulcast, SVC и SFU и оценку полосы в WebRTC. Здесь важен клинический вывод: подстройка качества под каждое устройство и позволяет удержать планку «достаточно хорошо» для всех участников.
Пример: во что обходится «всегда 1080p»
Посчитаем. Пусть поток 1080p требует около 2,5 Мбит/с, а 480p – около 0,6 Мбит/с. Сервис, который проводит 1 000 повторных консультаций в день по 12 минут и всегда держит 1080p, на каждом звонке передаёт 2,5 Мбит/с в течение 12 минут. Это гораздо больше данных, чем нужно такому приёму, причём на устройствах пациентов, у которых часто лимитный мобильный тариф и изношенная батарея. Если перевести такие «разговорные» приёмы на 480p, объём видеоданных на звонок сократится примерно на три четверти, и приём ничего не потеряет: его клиническое содержание и так было разговором. Сэкономленный ресурс можно отдать туда, где он нужен: дерматологическим приёмам и телеинсульту, которым высокое качество действительно требуется. Качество – это бюджет, который распределяют по клиническим задачам, а не ползунок, выкрученный на максимум.
Частые ошибки
Требовать «HD везде». Если считать максимальное разрешение универсальным требованием, полоса и батарея уходят на приёмы, где клиническую ценность несёт звук, а немногим приёмам, которым действительно нужна детализация, ресурса не хватает.
Оставлять degradationPreference по умолчанию. balanced годится как общее значение, но не подходит для дерматологии или оценки инсульта. Если не задать настройку под клиническую задачу, выбор между деталями и движением сделает сеть, а не врач.
Забывать о приоритете звука. Лестница качества, которая ухудшает звук вместе с видео или не предусматривает режим «только звук» и переход на телефон, первой жертвует самой важной для клиники частью звонка.
Не учитывать разнообразие устройств. Платформу тестируют только на одинаковых офисных компьютерах и выпускают без simulcast или SVC, а в реальных звонках с мощным и слабым устройством качество падает до уровня слабого.
Измерять задержку в офисной сети. Цифра, полученная на офисном Wi-Fi, ничего не говорит о реальных приёмах. Естественность разговора определяет задержка в мобильной сети или на старом ADSL у пациента в посёлке – там её и измеряйте.
Где здесь Фора Софт
Задача – провести приём с качеством, достаточным для его клинической цели, в реальной сети пациента. Для этого нужно знать, где проходит планка, и проектировать под неё. Фора Софт разрабатывает видеосвязь реального времени на WebRTC с тех пор, как технология только появилась: телемедицина, видеоконференции, e-learning и стриминг. Именно этим продукт, который «нормально смотрится на демо», отличается от продукта, пригодного для осмотра раны по мобильной сети в посёлке. Мы задаём бюджеты задержки, подбираем degradationPreference и слои simulcast под каждый клинический сценарий, защищаем звук на каждом шаге деградации и до запуска проверяем, хватает ли картинки для каждой специальности. Так качество тратится там, где от него зависит клиническое решение, и экономится там, где не зависит.
Главное
- Держите задержку звука в одну сторону ниже ~150 мс (ITU-T G.114): тогда разговор на приёме идёт естественно.
- Звук клинически важнее видео: защищайте его на каждом шаге деградации.
- Планку качества задаёт клиническая задача: контроль лечения ≠ осмотр раны ≠ оценка инсульта.
- Настройте degradationPreference: maintain-resolution для деталей, maintain-framerate для движения.
- Simulcast и SVC через SFU дают каждому устройству посильное качество без транскодирования.
- «Всегда 1080p» впустую расходует полосу и батарею; распределяйте качество по клиническим задачам.