Использование сжатия при глобальном хранении и распространении видеоконтента уже давно стало повсеместным.
Сжатие значительно уменьшает размеры видеофайлов при хранении на серверах или на носителях, таких как DVD и диски Blu-ray™, а также снижает требования к пропускной способности для трансляции, включая цифровое эфирное телевидение, кабельные, спутниковые и потоковые сервисы. В последние годы сжатие стало стандартом и в профессиональном видео, где применяются мезонинные (промежуточные) методы на этапах захвата и пост-продакшена. Оно также становится все более распространенным на конечной стадии передачи сигнала по мере роста требований к пропускной способности между источником и устройством отображения, находя применение в самых разных областях, включая медицину, профессиональный аудиовизуал, промышленность, коммерческий и жилой секторы.
С момента появления технологии HDBaseT в 2010 году пропагандировалась передача несжатого сигнала для передачи высококачественных AV-сигналов на большие расстояния. Этот подход согласуется с решениями для соединений на короткие расстояния, а именно с технологиями DisplayPort™ и HDMI®. Причины просты — максимальное качество изображения, совместимость устройств и отсутствие задержки. В отличие от этого, сжатие может негативно сказаться на любом или всех этих параметрах.
Однако использование сжатия стало неизбежным и даже необходимым в некоторых приложениях, где требования к пропускной способности превышают исходные возможности канала связи. Альянс HDBaseT ратифицировал метод легкого сжатия в качестве промежуточного решения для поддержки эквивалента HDMI-сигнала с пропускной способностью 18 Гбит/с с использованием HDBaseT версии 2.0. Тем не менее, в некоторых случаях это может осложнить обеспечение совместимости между устройствами.
HDBaseT 3.0 решает эту проблему, обеспечивая эквивалент несжатого сигнала 18 Гбит/с для максимальной производительности при совместимости и обратной совместимости устройств. В будущем же сочетание HDBaseT 3.0 с легким сжатием может позволить передавать сигнал с пропускной способностью до 48 Гбит/с для приложений с разрешением 8K или высокой частотой кадров.
Растущее количество вариантов ставит перед проектировщиками и интеграторами систем вопрос: «Использование компрессии канала — это хорошо, плохо или нейтрально, и что мне следует применять?». Чтобы ответить на него, полезно сначала разобраться, что такое сжатие и каковы его различные типы.
Сжатие видео — это процесс кодирования цифрового видеосигнала, направленный на уменьшение его битрейта. Существует множество способов достичь этого, и они в разной степени влияют на качество изображения и производительность системы. Наиболее распространенными методами являются субдискретизация цветности — которую часто не считают сжатием, хотя технически это так — и алгоритмы на основе кодеков и файловых контейнеров.
Зрительная система человека воспринимает цвет и градации серого совершенно по-разному. Фоторецепторы в сетчатке нашего глаза называются «палочками»; они обеспечивают монохромное зрение и насчитывают около 120 миллионов клеток. Для сравнения, «колбочек», обеспечивающих цветовое зрение, всего около 6 миллионов клеток, и для их активации требуется более высокий уровень освещенности. Кроме того, существует три типа колбочек, чувствительных к трем основным цветам: красному, зеленому и синему (RGB). В целом, наше зрение значительно менее чувствительно к разрешению цвета, чем к разрешению яркости (контрасту).
Видеосистемы изначально основаны на модели RGB. Видеостандарты определяют координаты основных цветов RGB, датчики изображения в камерах захватывают сцену в RGB, и все технологии отображения — как аналоговые, так и цифровые — воспроизводят изображение в RGB. Однако RGB непрактичен для хранения и передачи из-за необходимости использования трёх полноразрядных каналов.
Несколько десятилетий назад, с появлением цветного телевидения, возникла двойная проблема: парк телевизоров состоял преимущественно из чёрно-белых (Ч/Б) моделей, а пропускная способность каналов передачи была ограничена. Решение предоставила ранняя форма аналогового компонентного видео под названием Y'UV:
Y'UV формировала Ч/Б изображение по одному сигналу яркости (luminance), в то время как информация о цвете передавалась по отдельным, параллельным сигналам. Цветные телевизоры использовали оба типа сигналов, а Ч/Б телевизоры — только сигнал яркости.
Эта система кодирования цвета с двумя каналами позволяла уменьшить цветовое разрешение — учитывая меньшую чувствительность нашего зрения к цвету — при сохранении полного разрешения по яркости. Это экономило полосу пропускания без заметного ухудшения качества изображения.
Много лет спустя появился вариант Y'UV более высокого качества, обозначаемый как Y'PbPr. Описываемый как компонентное видео с "цветоразностными" сигналами, его обычно можно узнать по трём аналоговым RCA-разъёмам на устаревших источниках сигнала, таких как DVD-плееры.
Y'CbCr — это цифровой, пиксельный эквивалент аналогового Y'PbPr, использующий субдискретизацию цветности. Этот метод работает с блоком пикселей, обычно размером четыре пикселя в ширину и два в высоту. Каждый пиксель в этом блоке является элементом выборки (subsample). Информация о цвете (Chroma) может быть удалена из некоторых пикселей в блоке для сокращения количества битов. Когда дисплей получает такой сигнал, он распространяет сохранённую цветовую информацию на соседние пиксели для формирования полноцветного изображения. Метод обозначается тремя числами, разделёнными двоеточием, и существует несколько его вариантов. Наиболее распространённые в профессиональном и потребительском видео — это 4:4:4, 4:2:2 и 4:2:0.
4:4:4 — это режим полной пропускной способности, математически эквивалентный RGB.
Преобразование сигнала из RGB в 4:4:4 и обратно является полностью безлопастным. Значение каждого числа следующее:
Первое число в 4:4:4 представляет ширину выборки в пикселях: 4.
Второе число — количество цветовых компонентов в первой строке выборки (имея в виду, что компоненты Cb и Cr вместе считаются как одна, взаимозависимая единица): 4.
Третье число — количество цветовых компонентов во второй строке: 4.
Размер выборки не изменился, поэтому первое число остаётся 4. Однако на каждой строке удаляется половина цветовых компонентов: в первой строке остаётся 2, и во второй строке также остаётся 2. Отсюда и обозначение — 4:2:2. В результате для всего изображения это приводит к снижению горизонтального цветового разрешения вдвое (цветовая информация сохраняется только для каждого второго столбца пикселей), в то время как полное вертикальное цветовое разрешение сохраняется (для каждой строки). Для большинства людей ухудшение качества изображения является практически незаметным.
4:2:0 сохраняет тот же размер выборки, равный 4, и оставляет 2 цветовых компонента в верхней строке. Однако он полностью удаляет оставшуюся цветовую информацию из второй строки, что отражается третьим числом — 0.
Большое преимущество 4:2:0 заключается в том, что он сокращает требуемую пропускную способность вдвое по сравнению с 4:4:4. Если посчитать на простом примере:
4:4:4: блок 4x2 пикселя содержит 24 компонента (по 8 для Y, Cb и Cr).
4:2:0: тот же блок 4x2 пикселя содержит только 12 компонентов (8 для Y, но всего по 2 для Cb и Cr).
Обратной стороной является то, что 4:2:0 снижает цветовое разрешение вдвое как по горизонтали, так и по вертикали. Цветовая информация от одного пикселя затем "распространяется" на три соседних пикселя, образуя один большой блок цвета размером 2x2 пикселя. Это может вызывать следующие артефакты:
"Ступенчатость" ("jaggies") на диагональных линиях и границах объектов в пределах кадра.
Снижение резкости и контраста, поскольку область пересечения белых и черных пикселей может усредняться до серого цвета, а различные цвета — смешиваться в совершенно новый оттенок.
Однако хорошая новость состоит в том, что в подавляющем большинстве случаев при просмотре динамического видео человеческий глаз не воспринимает этих негативных эффектов. Это особенно справедливо для современных видеоформатов благодаря двум факторам:
Более высоким разрешениям изображения: поскольку каждый блок дискретизации занимает пропорционально меньшую площадь на экране.
Улучшенным алгоритмам обработки видео, которые интеллектуально компенсируют потенциальные артефакты.
Хранимые и распространяемые медиафайлы неизбежно подвергаются сжатию на основе кодеков. Термин «кодек» является сокращением от «кодер-декодер» и обозначает использование алгоритмического процесса для уменьшения количества битов в видеофайле. Стоит отметить, что сжатие на основе кодеков и субдискретизация цветности не являются взаимоисключающими; напротив, они часто используются вместе, поскольку сжатые медиафайлы — особенно на потребительском уровне — обычно содержат видео с форматом 4:2:0. Эти два метода применяются в комплексе для достижения максимального снижения битрейта. Однако в любой момент времени может использоваться только один тип сжатия на основе кодеков.
Видеокодеки можно разделить на два основных типа: внутрикадровое (Intra-frame) и межкадровое (Inter-frame) сжатие:
Внутрикадровое сжатие работает с одним кадром за раз, завершая обработку текущего перед переходом к следующему. Это делает его относительно быстрым, но менее эффективным с точки степени сжатия. Коэффициенты сжатия варьируются от незначительных 1,3:1 до обычно достижимых 20:1. Например, такой метод может уменьшить битрейт потока 4K UHD 24 кадра/с, 24 бит/пиксель с 7,128 Гбит/с до примерно 350 Мбит/с для передачи по сети 1GbE.
Межкадровое сжатие анализирует несколько последующих кадров, что занимает больше времени, но приводит к значительно большему уменьшению размера файла и битрейта передачи. Это позволяет достигать коэффициентов сжатия 300:1 и выше. Тот же пример с 4K UHD можно сократить с исходного битрейта 7,128 Гбит/с до менее чем 24 Мбит/с для передачи через интернет-соединение.
Важным аспектом является влияние сжатия на качество изображения. Его можно классифицировать как безлопастное (lossless) или с потерями (lossy):
Безлопастное сжатие, как следует из названия, не вызывает математических потерь в процессе, и изображение после сжатия идентично исходному. Это достигается только при очень низких коэффициентах сжатия, обычно 2:1 или меньше.
Сжатие с потерями создает приблизительную аппроксимацию оригинала, что приводит к безвозвратной потере части данных. То, насколько эти потери допустимы, зависит от конкретного приложения и ожиданий пользователя. Большинство современных решений обычно характеризуются как «визуально безлопастные» (visually lossless).
Термин «визуально безлопастный» является highly субъективным. Для некоторых он может означать, что видео выглядит приемлемо при просмотре в другой комнате и на экране меньшего размера и худшего качества, чем оригинал. Очевидно, что такой подход не является идеальным. Общепринятое ожидание заключается в том, что «визуально безлопастный» должен означать, что пользователь не может отличить исходный контент от сжатого при просмотре в сопоставимых условиях или даже при сравнении бок о бок. В некоторых случаях это может быть критически важно или даже вопросом безопасности. В связи с этим, Инициатива по разработке руководящих принципов оцифровки для федеральных агентств (FADGI) — совместный проект нескольких правительственных учреждений США — официально определила «визуально безлопастное» сжатие следующим образом:
Визуально безлопастное сжатие — это форма или способ сжатия с потерями, при котором данные, утраченные после сжатия и последующего распаковывания файла, не обнаруживаются визуально; сжатые данные выглядят идентично несжатым данным.
В медицинских приложениях требования формулируются как «Диагностически приемлемое необратимое сжатие» (Diagnostically Acceptable Irreversible Compression, DIAC). Это означает, что сжатие никоим образом не должно влиять на изображение так, чтобы это могло повлиять на результат диагностики.
Тот факт, что сжатие является необратимым (с потерями), сам по себе не имеет значения, если его цель и ожидаемый результат четко определены и достигнуты. Альтернативой в условиях ограниченной доступной пропускной способности может быть использование значительно более низкого разрешения, что способно нанести качеству изображения еще больший ущерб, чем само сжатие.
Существует множество различных кодеков сжатия, и в каждом из них — еще больше вариаций и уровней производительности. Здесь мы сосредоточимся на двух внутрикадровых кодеках — JPEG 2000 и DSC, а также на двух межкадровых — H.264 и H.265 — для сравнения.
JPEG 2000 (JP2) — это внутрикадровый кодек, разработанный объединенной группой экспертов по фотографии (Joint Picture Experts Group) в качестве замены оригинальному кодеку сжатия фотографий JPEG. Он был выпущен в 2000 году, отсюда и его название. Однако в контексте видео под JPEG 2000 обычно подразумевается Motion JPEG 2000 (MJ2). Если оригинальный Motion JPEG (MJPEG) передавал каждый кадр как отдельное изображение JPEG с добавлением аудио, то каждый кадр MJ2 кодируется независимо с использованием JP2.
Процесс MJ2 довольно сложен: он способен разбивать кадр на макроблоки любого размера — от 8x8 (как оригинальный JPEG) до целого изображения. Многие распространенные приложения используют блоки 16x16. Качество изображения может быть превосходным, при этом задержка обычно составляет порядка 30 мс, или примерно один кадр видео (в зависимости от частоты обновления, конечно).
использует совершенно другой внутрикадровый подход. Разработанный VESA и первоначально выпущенный в 2014 году, DSC является формой строчного кодирования (line code compression), поскольку он разбивает каждый кадр по горизонтали, работая с небольшими группами строк за раз. Это очень легкий кодек, достигающий коэффициентов сжатия до 3.75:1, что делает его чрезвычайно быстрым (задержка измеряется в микросекундах) при сохранении исключительно высокого качества изображения. Версия 1.1 была разработана для работы с RGB-видео глубиной до 12 бит на цвет. Выпуск DSC 1.2a в 2017 году добавил поддержку субдискретизации цветности 4:2:2 и 4:2:0, а также глубины цвета до 16 бит в RGB.
H.264, также известный как Advanced Video Codec (AVC), — это межкадровый кодек, разработанный ITU-T на основе стандарта MPEG, часть 10. Это повсеместно распространенный стандарт глубокого сжатия для вещания и потоковых медиа, а также для носителей, таких как диски Blu-Ray™.
Частью того, что делает этот формат столь эффективным, является его способность «заглядывать вперед» для оптимизации сжатия в группах кадров. Однако это также неизбежно увеличивает задержку: иногда она составляет всего 100 мс, но часто достигает 200-500 мс. Это плата за достижение значительно более низкого битрейта при сохранении отличного качества изображения.
H.264 работает, разделяя последовательность кадров на три типа:
I-кадр (Intra-frame). Это ключевые кадры, которые кодируются полностью и используются как опорные для следующих типов кадров.
P-кадр (Predicted frame). Эти дельта-кадры кодируют только изменения, произошедшие между текущим и предыдущим кадром.
B-кадр (Bidirectional predicted frame). Эти кадры кодируют различия между текущим кадром, предыдущим и последующим кадрами для оптимизации качества и степени сжатия.
H.265 — это кодек следующего поколения после H.264. Известный как High Efficiency Video Coding (HEVC), он обеспечивает сопоставимое с H.264 качество изображения, но при значительно более низком битрейте, позволяя экономить до 50%.
Такое значительное улучшение стало возможным благодаря обработке информации с помощью единиц кодирующего дерева (Coding Tree Units, CTUs), а не макроблоков. Размер CTU может варьироваться от 4x4 до 64x64. Изображение может разделяться на структуры переменного размера, что позволяет гораздо эффективнее кодировать большие области с малыми изменениями, используя меньшие блоки для участков с большей детализацией и движением.
Внедрение H.265 быстро растет, но H.264 по-прежнему доминирует в таких приложениях, как телевещание и потоковые медиа. ITU-T опубликовал H.266 в 2020 году как следующее поколение кодеков для поддержки быстро развивающегося медиапространства.
Как правило, при сжатии требуется баланс между тремя ключевыми параметрами:
Качество изображения
Битрейт
Задержка (Latency)
Достижение комбинации высокого качества изображения, низкого битрейта и малой задержки возможно, но требует значительной вычислительной мощности, что обычно означает более высокую стоимость. В зависимости от конкретного приложения, прагматичный подход предполагает поиск определенной степени компромисса между этими параметрами.
Как упоминалось ранее, большая часть потребительского медиаконтента сильно сжимается для доставки на исходное устройство пользователя и передается в несжатом виде только через выход HDMI, в то время как компьютерные и игровые источники изначально несжатые. Качество видео на выходе источника не является темой данного документа; здесь важно то, как сохранить производительность исходного медиа при передаче по каналу связи на дисплей, и каково влияние сжатия. Две ключевые уязвимые области включают:
Динамический диапазон — Появление глубокого цвета и HDR-видео требует сквозного поддержания как минимум 10 бит на компонент throughout всего сигнального тракта. Это может быть несовместимо с некоторыми системами сжатия, что приводит к ухудшению уровня черного и цветового охвата.
Читаемость текста — При передаче сигналов с компьютера, например, содержащих электронные таблицы, важна читаемость текста. Блочные кодеки сжатия, такие как JPEG, могут вызывать артефакты «кольцевания» вокруг текста и ступенчатость границ, что приводит к потере контрастности и резкости. Кодеки, которые работают построчно, а не с блоками, гораздо лучше сохраняют края символов без артефактов. Например, PNG для статических изображений или DSC для видео. Разумеется, полное отсутствие сжатия по-прежнему остается лучшим вариантом для оптимальной производительности графики и четкого текста!
Основной компромисс при видеосжатии обычно заключается между битрейтом и задержкой. Эти параметры обычно находятся в обратной пропорциональности: для достижения более низкого относительного битрейта требуются более высокие коэффициенты сжатия и большая вычислительная обработка, что, в свою очередь, увеличивает задержку, и наоборот.
Задержка видео может негативно влиять на пользовательский опыт: запаздывание реакции на нажатия клавиатуры и мыши во время презентаций в переговорной комнате, задержки визуального отклика при использовании пульта ДУ для навигации по экранным меню или возникновение рассинхронизации аудио и видео (lipsync error), если звук воспроизводится отдельно до передачи сжатого видео на дисплей.
Исследования показали, что человек способен воспринимать зрительные стимулы длительностью всего 13 мс и, фактически, обрабатывать целые изображения с такой скоростью. Поэтому задержка на этом уровне или ниже идеальна для восприятия как «реального времени».
Некоторые производители могут указывать задержку в кадрах в секунду. Это, конечно, зависит от частоты кадров в конкретном приложении, но обычно расчет основывается на 30 кадрах/с, где задержка в один кадр равна 33 мс. Некоторые продукты могут заявлять об «отсутствии задержки», даже когда она объективно присутствует; как правило, это маркетинговое решение, основанное на прагматичном взгляде или, возможно, округлении. Как бы то ни было, разработчикам систем рекомендуется определять максимально допустимую задержку в своих AV-системах и тщательно исследовать продукты на предмет их соответствия требованиям.
При определении необходимости и степени сжатия, совместимость играет ключевую роль в обеспечении предсказуемой и надежной работы развернутых систем. В первую очередь, это означает, что как передатчик (Tx), так и приемник (Rx) должны поддерживать один и тот же метод. Другим важным фактором является наличие в AV-сигнале встроенных метаданных от источника, которые могут быть несовместимы со сжатием. В таких случаях метаданные извлекаться из сигнала для отдельной передачи и повторного встраивания на другой стороне.
Метаданные можно описать как «данные о данных». Они содержат информацию о том, как дисплей должен использовать видеопоток. Например, информация о том, является ли сигнал цветовым пространством RGB или Y'CbCr. Это особенно важно для HDR-видео, где метаданные содержат инструкции по тональному отображению для дисплея; некорректные или отсутствующие метаданные могут привести к ошибкам, таким как искаженные цвета, сжатый динамический диапазон или общее излишне темное изображение.
Надежная совместимость лучше всего достигается за счет следования стандартам. Однако иногда даже этого может быть недостаточно; могут возникать вариации, различия в интерпретации и конфликты между чипсетами и т.д. Проектировщикам и интеграторам систем настоятельно рекомендуется обращать внимание не только на соответствие стандартам и поддержку функций в системах передачи видео, но и, предпочтительно, на тестирование и сертификацию совместимости.
При разработке любой системы передачи видео необходимость сжатия определяется простым сравнением требуемой пропускной способности с исходной пропускной способностью канала связи. Затем выбираются тип и степень сжатия (коэффициент) для достижения желаемого баланса и производительности.
В течение десятилетия собственных возможностей пропускной способности HDBaseT было достаточно для поддержки подавляющего большинства требований к передаче аудио- и видеосигналов. Появление видео 4K Ultra HD само по себе не вызвало необходимости в увеличении пропускной способности HDBaseT. В конце концов, 4K был представлен со спецификацией HDMI 1.4 в 2009 году, то есть до появления HDBaseT. Это включало контент с частотой до 30 Гц, который и по сей день продолжает доминировать, например, фильмы с частотой 24 кадра/с. Даже выпуск спецификации HDMI 2.0 в 2013 году с поддержкой 4K/60 был ориентирован на 8-битный цвет 4:2:0, что сохраняло совместимость с 10 Гбит/с для отображения на скорости линии связи HDBaseT 8 Гбит/с (поскольку HDBaseT удаляет 20% избыточности кодирования TMDS из HDMI-сигнала).
Факторы, которые в конечном итоге выводят требования к пропускной способности за пределы возможностей несжатой передачи в HDBaseT версий 1.0 и 2.0, включают любую комбинацию по крайней мере двух из следующих параметров:
Источники с нативным выводом RGB/4:4:4, такие как графический процессор (GPU) компьютера или игровой консоли, или устройство-источник, преобразующее контент 4:2:0 в вывод 4:4:4.
Наличие HDR-видео и необходимость поддерживать как минимум 10 бит на субпиксель.
Увеличение частоты кадров/обновления сверх 30 Гц.
По большей части эти комбинации укладываются в возможности спецификации HDMI 2.0b. Её исходная емкость 18 Гбит/с фактически несет полезную нагрузку до 14,25 Гбит/с, снова за вычетом избыточности TMDS (максимальный сигнал 17,82 Гбит/с × 8/10 TMDS). Это означает, что для поддержки этих форматов в HDBaseT требуется эффективный коэффициент сжатия не более 2:1.
Очень низкий требуемый коэффициент сжатия для передачи сигналов 4K/60 4:4:4 или 4K/60 HDR 4:2:2 по линиям HDBaseT 1.0 или 2.0 исключил необходимость использования сжатия H.264/265 или даже JPEG 2000 (MJ2). В конце концов, эти кодеки предназначены для достижения гораздо более высоких коэффициентов сжатия, чем требуется в данном случае, и привели бы к заметной задержке. Абсолютным приоритетом Альянса HDBaseT является сохранение незаметной задержки, что привело к выбору DSC в качестве наилучшего кандидата для производителей, желающих опционально реализовать визуально безлопастное сжатие в продуктах HDBaseT. Задержка при этом измеряется всего лишь десятками микросекунд — на порядки ниже порога восприятия человека!
HDBaseT — не единственный стандарт, поддерживающий DSC в качестве предпочтительного мощного метода легкого сжатия для передачи AV-сигналов:
DSC является частью спецификации DisplayPort 1.4 для обеспечения передачи видео 8K/60 по каналу HBR3 32.4 Гбит/с.
DSC присутствует в спецификации HDMI 2.1 для поддержки форматов, превышающих нативную скорость канала 48 Гбит/с, или для снижения нагрузки на кабели в линиях связи ниже 48 Гбит/с.
Как DisplayPort, так и HDMI технологии имеют собственные строгие системы контроля для обеспечения совместимости между поддерживающими устройствами; то же самое относится и к реализации DSC в HDBaseT. Альянс HDBaseT также утвердил требования и методы, которые производители должны использовать для достижения максимальной производительности и совместимости своих продуктов HDBaseT с поддержкой DSC.
Стоит отметить, что хотя эти три интерфейса — HDBaseT, DisplayPort и HDMI — по отдельности используют опциональное DSC, сжатый сигнал не может передаваться с одного типа интерфейса на другой без промежуточной распаковки.
Использование любых методов сжатия в HDBaseT, кроме DSC, не утверждено Альянсом HDBaseT. Однако, как и применение других методов сжатия, оно является опциональным и не может быть запрещено — производители свободны в своих разработках. Важное предостережение: использование любого неутвержденного метода приведет к снижению согласованного разрешения между двумя продуктами до 4K60 4:2:0 или 4K30 4:4:4.
В качестве предупреждения стоит отметить, что некоторые производители могут применять субдискретизацию цветности и уменьшение разрядности цвета для достижения желаемого снижения общего битрейта. Например, сигнал 4K/60 10-бит HDR 4:2:2, требующий 17.82 Гбит/с через HDMI, может быть преобразован до 4:2:0, а 10-битный сигнал — уменьшен до 8 бит. Вместе это позволяет снизить общий битрейт ниже порога несжатой передачи HDBaseT 1.0 или 2.0 (эквивалентно 8.91 Гбит/с в HDMI). Затем сигнал может быть повторно повышен для эмуляции исходного 10-битного 4:2:2 на приемной стороне, но после того, как половина цветовой информации и три четверти динамического диапазона были отброшены, вернуть их невозможно!
Такие решения могут позиционироваться как «несжатые» на том основании, что в них не применяются алгоритмы сжатия на основе кодеков, однако влияние на качество изображения может быть хуже, чем при использовании сжатия на основе кодеков — в зависимости от контента. Это может быть приемлемо в некоторых инсталляционных сценариях, при условии что все участники проекта осведомлены и согласны с компромиссами.
HDBaseT 3.0 представляет собой значительный шаг вперед в обеспечении беспрепятственной совместимости. Сохраняя обратную совместимость с предыдущими поколениями, новая версия стандарта обеспечивает передачу несжатого видео с пропускной способностью, эквивалентной 18 Гбит/с HDMI, что достаточно для форматов 4K/60 4:4:4 HDR. Это устраняет необходимость в сжатии для большинства современных приложений, упрощая интеграцию и гарантируя максимальное качество изображения без задержек.
Ключевые особенности HDBaseT 3.0 включают:
Единый стандарт передачи без необходимости выбора методов сжатия
Сохранение всех метаданных и цветовых пространств без модификации
Автоматическое определение возможностей подключенных устройств
Улучшенные механизмы проверки handshake между оборудованием
Благодаря стандартизированному подходу HDBaseT 3.0 обеспечивает предсказуемую работу в гетерогенных средах, где используются продукты разных производителей. Это особенно важно для критически важных приложений, где надежность и совместимость являются первостепенными требованиями.
Альянс HDBaseT на протяжении длительного времени поддерживает строгую программу тестирования и сертификации для обеспечения соответствия стандартам и совместимости продуктов с поддержкой HDBaseT. Это относится к версиям HDBaseT 1.0 и 2.0 — как в несжатом виде, так и с визуально безлопастным сжатием (DSC), — а также к новейшим продуктам, использующим HDBaseT 3.0.
Что касается сжатия видео, существуют простые руководящие принципы для сертификации продуктов HDBaseT:
Любой продукт, сертифицированный для поддержки 4K/30 4:4:4, подразумевает использование 8-битного видео, что эквивалентно по пропускной способности форматам 4K/30 до 12-бит 4:2:2 для HDR и 4K/60 8-бит 4:2:0. Можно предположить, что в таких случаях сжатие не используется.
Любой продукт, использующий неутвержденный метод сжатия, может быть сертифицирован только по своим возможностям работы без сжатия. Например, расширитель HDBaseT, заявляющий о поддержке 4K/60 4:4:4, но не использующий DSC утвержденным методом, может быть протестирован и сертифицирован только для режима 4K/30 4:4:4 при условии соответствия соответствующим критериям производительности.
Любой продукт, использующий HDBaseT 3.0, может быть протестирован и сертифицирован для работы в режиме 4K/60 4:4:4 без сжатия и обладает обратной совместимостью с предыдущими версиями HDBaseT, как упоминалось ранее.
С появлением видео 8K и увеличением пропускной способности HDMI и DisplayPort до 48 Гбит/с (HDMI 2.1) и 80 Гбит/с (DisplayPort 2.0) соответственно, легко представить, что может возникнуть спрос на передачу более 18 Гбит/с через HDBaseT. Совмещение технологии DSC и архитектуры HDBaseT 3.0 может сделать это реальностью.
Флагманские форматы, передаваемые без сжатия через HDMI 2.1 — это 8K/30 12-бит 4:4:4 и 8K/60 12-бит 4:2:0, каждый из которых передается на скорости 48 Гбит/с. Применение коэффициента сжатия 3:1 снижает требуемую пропускную способность до 16 Гбит/с, что идеально соответствует нативной скорости HDBaseT 3.0. И это без учета избыточности кодирования HDMI (что уменьшит ее еще больше)! Этого также было бы более чем достаточно для некоторых премиальных графических форматов, таких как Apple 6K, чья исходная скорость данных составляет порядка 40 Гбит/с при 10-бит RGB.
Теоретически, при соответствующей обработке сигнала, HDBaseT 3.0 с максимальными возможностями DSC (сжатие 3.75:1) мог бы поддерживать эквивалент до 67.5 Гбит/с в HDMI FRL, что позволило бы передавать сигналы 8K/60 12-бит 4:2:2 или 8K/60 8-бит 4:4:4.