Содержание статьи +
- Коротко
- Зачем это нужно
- Вопрос, на который отвечает оболочка
- Что такое выпуклая оболочка простыми словами
- Почему кривые разрешений пересекаются
- Как построить выпуклую оболочку
- Ловушка измерения, которая портит оболочку
- Разобранный пример: читаем лестницу по оболочке
- Почему это именно ВЫПУКЛАЯ оболочка: взгляд rate-distortion
- Оболочка – это математика за per-title encoding
- Оболочка и BD-rate: одна кривая, два применения
- Частые ошибки, портящие выпуклую оболочку
- Стоимость оболочки и как команды её снижают
- Где здесь Фора Софт
- Ключевые выводы
- Что читать дальше
Коротко
Выпуклая оболочка (convex hull) – это ответ на один вопрос: при заданном битрейте какое разрешение даёт лучшую картинку? Поскольку низкое и высокое разрешение меняются местами по мере изменения битрейта – маленький кадр выглядит лучше, когда бит мало, а большой вырывается вперёд, когда их достаточно, – лучший выбор это не одно разрешение, а верхняя граница всех кривых «качество-битрейт» для разных разрешений, сшитая воедино. Эта верхняя граница и есть выпуклая оболочка, и на ней лежит каждая ступень хорошей per-title битрейтной лестницы. Эта статья показывает, что такое оболочка, почему кривые пересекаются, как построить её, не обманув себя на измерении, и как она связана с per-title encoding и с BD-rate.
Зачем это нужно
Если вы строите битрейтные лестницы, выпуклая оболочка – это геометрия, которая решает, какое разрешение поставить на каждую ступень; и сделать это правильно – разница между чистой ступенью 540p и ступенью 1080p, которая рассыпается на блоки при том же битрейте. Эта статья для стриминг- или кодинг-лида, платформенного инженера или QA-инженера, кто слышал «поставь каждую ступень на выпуклую оболочку» и хочет реально понять кривую, построить её по настоящим измерениям и избежать единственной ошибки, которая тихо её портит. Это спутник со стороны измерения для per-title encoding: per-title говорит «зафиксируй цель по качеству и отпусти битрейт», а выпуклая оболочка говорит, какое разрешение использовать, когда битрейт уже известен. Постройте оболочку неправильно – и каждая лестница, построенная по ней, будет неправильной одинаково.
Вопрос, на который отвечает оболочка
Начнём с вопроса, который звучит так, будто у него очевидный ответ, – а его нет. Вы вот-вот закодируете ступень своей битрейтной лестницы, скажем, на 1,5 Мбит/с. Какое разрешение должно быть у этой ступени?
Соблазнительный ответ – «самое высокое, какое можете»: ведь больше пикселей – больше картинки. Настоящий ответ – «зависит от битрейта», и зависимость достаточно сильна, чтобы перевернуть решение. Разрешение – это пиксельная сетка, в которой кодируется кадр: 1920×1080 (1080p), 1280×720 (720p), 960×540 (540p) и так далее. Битрейт – это сколько бит в секунду вы тратите на его передачу. Забывают вот что: эти биты приходится размазывать по всем пикселям, а у 1080p пикселей в четыре раза больше, чем у 540p. На низком битрейте кодирование 1080p пытается описать вчетверо больше деталей теми же горстями бит, поэтому их не хватает, и оно скатывается к грубым приближениям, которые зритель видит как блочность и замыливание. Кодирование 540p, которому нужно прокормить вчетверо меньше пикселей, тратит свои биты спокойно, даёт чистый маленький кадр, а плеер растягивает этот чистый кадр на весь экран. До определённого момента чистый-и-растянутый маленький кадр выглядит лучше, чем изголодавшийся большой.
Так что ответ на вопрос «какое разрешение на 1,5 Мбит/с?» – это измеренный результат, а не догадка. Измерьте качество на нескольких разрешениях в диапазоне битрейтов – и вы обнаружите, что каждое разрешение выигрывает в своей полосе битрейтов и проигрывает вне её. Выпуклая оболочка – это инструмент, который улавливает «какое разрешение сейчас выигрывает» как одну непрерывную линию. Прежде чем строить её, нужно точно понять, что такое выпуклая оболочка, потому что название пришло из геометрии, а не из видео.
Что такое выпуклая оболочка простыми словами
Забудьте на минуту про видео. Возьмите горсть точек, разбросанных на листе, – кнопки, воткнутые в пробковую доску. Натяните резинку вокруг всех них и отпустите. Резинка прижмётся к крайним кнопкам и образует тугую петлю; каждая кнопка окажется либо на петле, либо внутри. Эта петля и есть выпуклая оболочка точек: наименьшая выпуклая фигура, содержащая их все (de Berg et al., Computational Geometry, 3-е изд., 2008).
Её определяют два свойства. Она выпукла – возьмите любые две точки внутри, и прямая между ними останется внутри; граница нигде не прогибается внутрь. И она минимальна – это самая тугая такая фигура; меньшей выпуклой фигуры, содержащей каждую точку, не существует. Картинка с резинкой передаёт оба свойства: натянутая резинка всегда туга (выпуклость) и всегда наименьшая петля, всё ещё держащая каждую кнопку (минимальность).
Для видео нам не нужна вся петля – только её верхний край. Мы строим точки так, что «вверх» означает «лучше качество», поэтому нас интересуют только точки вдоль верхней границы – те, которых ничто не превосходит. Этот верхний край и есть то, что имеют в виду под «выпуклой оболочкой» в кодировании: верхне-левый фронт лучших точек. Точка, лежащая под фронтом, доминируема – какое-то другое кодирование не дороже и не хуже, – а доминируемое кодирование никогда не бывает правильным выбором. Оболочка – это ровно множество кодирований, которые не доминируемы ничем другим. Экономисты называют это фронтом Парето; мир кодирования называет это выпуклой оболочкой. Идея одна: оставляем только варианты, которые ничто строго не превосходит.
Почему кривые разрешений пересекаются
Теперь вернём точки в видео. Для одного фрагмента контента закодируйте его в одном разрешении в диапазоне битрейтов и измерьте качество каждого кодирования. Отложите битрейт по горизонтали, а оценку качества – скажем, VMAF (Video Multi-method Assessment Fusion, перцептивную метрику Netflix с оценкой 0–100, где выше значит ближе к оригиналу для человеческого глаза; см. статью про VMAF) – по вертикали. Получится одна растущая кривая: больше бит – лучше картинка, с выполаживанием наверху по мере того, как кодирование приближается к визуальной прозрачности и лишние биты уже ничего не дают.
Сделайте так для нескольких разрешений – и получите несколько кривых, и они пересекаются. В этом вся суть. На низких битрейтах сверху сидят низкоразрешённые кривые: кадр 540p, закодированный на 800 кбит/с, чист, а чистый-и-растянутый бьёт блочное кодирование 1080p, которое выдают те же 800 кбит/с. На высоких битрейтах верх берут высокоразрешённые кривые: как только у 1080p хватает бит, чтобы отрисовать деталь без артефактов, он показывает больше реальной картинки, чем способен любой растянутый меньший кадр. Где-то посередине кривые пересекаются. Это пересечение – битрейт пересечения (crossover): битрейт, на котором перестаёт быть выгодно оставаться в низком разрешении и становится выгодно подняться выше.
Пересечения реальны и измеримы, а не теоретичны. Fraunhofer FOKUS, воспроизводя метод Netflix на FFmpeg, обнаружил, что около 500 кбит/с кодирования 480p и 720p давали лучший PSNR, чем 1080p того же контента, даже после растягивания для сравнения (Fraunhofer FOKUS Video-Dev, 2019). На другом ролике анализ последовательности «Dolls» поместил пересечение 540p и 1080p примерно на 2,0 Мбит/с: ниже 2,0 Мбит/с 540p набирал более высокий VMAF, выше – выигрывал 1080p (Optimal Transcoding Resolution Prediction, arXiv, 2024). Точный битрейт пересечения целиком зависит от контента – плоский мультфильм и зернистая толпа пересекаются в очень разных местах, – и это и есть причина, по которой оболочку надо измерять под каждый ассет, а не предполагать.
Как построить выпуклую оболочку
Оболочка – это верхняя огибающая этих пересекающихся кривых: на каждом битрейте берём ту кривую разрешения, что выше всех, и ведём эту линию «лучшее из всех разрешений» слева направо. Там, где вы идёте по кривой 360p, затем 540p, затем 720p, затем 1080p, переключения происходят ровно на битрейтах пересечения. Результат – одна кривая, собранная из выигрышных сегментов каждого разрешения, и есть выпуклая оболочка. Каждая точка, которую вы вообще поставили бы на битрейтную лестницу, лежит на этой линии; ничто ниже неё кодировать не стоит.
Вот процедура, которую Netflix описал, вводя per-title encoding в 2015 году, в виде шагов, которые можно выполнить.
Шаг 1 – закодируйте сетку. Выберите набор разрешений и набор настроек качества или битрейта и закодируйте контент во всех комбинациях. Это намеренно «в лоб». Воспроизведение Fraunhofer использовало семь разрешений и двенадцать значений constant-rate-factor – 84 тестовых кодирования для одного фрагмента (Fraunhofer FOKUS, 2019). Собственная per-shot система Netflix кодирует «сотни комбинаций разрешения и битрейта» на источник (Netflix Technology Blog, 2018). Настройка constant-rate-factor (CRF) держит качество примерно постоянным и отпускает битрейт, что естественно растягивает ваши точки вдоль оси битрейта.
Шаг 2 – измерьте каждое кодирование против источника. Оцените каждое кодирование метрикой качества – VMAF или, в исходной демонстрации, PSNR (peak signal-to-noise ratio, число, сравнивающее сжатый кадр с оригиналом попиксельно, в децибелах, где выше значит ближе; см. статью про PSNR). В этом шаге кроется единственная ловушка, которая губит больше оболочек, чем что-либо ещё, так что ей отведён отдельный раздел ниже.
Шаг 3 – выбросьте доминируемые точки и оставьте фронт. Среди всех точек (битрейт, качество) из сетки отбросьте любую точку, которую другая точка превосходит по обеим осям – дешевле и лучше. Что уцелеет – верхний фронт: выпуклая оболочка. На графике это гладкая линия, обнимающая лучшие точки каждого разрешения.
Шаг 4 – считайте разрешение по оболочке. Для любого битрейта, на котором вам нужна ступень, найдите, куда он попадает на оболочку, и используйте это разрешение. Ниже первого пересечения это ваше самое низкое разрешение; за последним пересечением – самое высокое. Оболочка ответила на исходный вопрос – какое разрешение на этом битрейте – сразу для всех битрейтов.
Ловушка измерения, которая портит оболочку
Выпуклая оболочка надёжна ровно настолько, насколько надёжны числа, по которым вы её строите, и есть одна ошибка измерения, которая её тихо отравляет. И PSNR, и VMAF – полноэталонные (full-reference) метрики: они сравнивают искажённый кадр с нетронутым оригиналом, пиксель против пикселя. Это сравнение работает только когда оба кадра одного размера. Но весь смысл оболочки – сравнивать кодирования в разных разрешениях: кодирование 540p против источника 1080p. Кадры не одного размера, поэтому метрику нельзя запустить напрямую.
Исправление – это обязательный шаг, а не опциональный: прежде чем оценивать низкоразрешённое кодирование, растяните декодированный кадр обратно до разрешения источника, а затем сравните растянутый кадр с источником. Это отражает то, что реально происходит дома, – поток 540p декодируется и растягивается на экран 1080p или 4K, – поэтому оценка растянутого кадра измеряет то, что зритель действительно видит (Fraunhofer FOKUS, 2019). Пропустите растягивание – и вы сравниваете маленький кадр с большим, что либо ломает метрику, либо, хуже, выдаёт правдоподобные на вид, но бессмысленные числа. Оболочка, построенная на нерастянутых оценках, – не более слабая оболочка; это неправильная оболочка.
Сам фильтр растягивания – это решение, которое сдвигает оболочку. Netflix рекомендует бикубическое (bicubic) растягивание для этого измерения, оно же – значение по умолчанию в FFmpeg; Lanczos – ещё один частый выбор (Netflix Technology Blog; Fraunhofer FOKUS, 2019). Выбор не косметический: одно исследование поместило пересечение 1080p против более низких разрешений около 320 кбит/с при одном апскейлере и около 1220 кбит/с при другом на том же контенте (анализ кросс-разрешённого VMAF, arXiv, 2024). Другой фильтр сдвигает битрейты пересечения, что сдвигает, какое разрешение выигрывает в полосе, что меняет лестницу. Выберите один апскейлер, запишите его и используйте для каждого кодирования, которое сравниваете, – сравнение «яблоко к яблоку» или никак.
Минимальное современное измерение FFmpeg для кодирования 540p против источника 1080p, с растягиванием сначала, выглядит так:
# Декодируем кодирование 540p, растягиваем до размера источника 1080p бикубикой,
# затем считаем VMAF против оригинала. Называйте модель и апскейлер.
ffmpeg -i encode_540p.mp4 -i source_1080p.y4m \
-lavfi "[0:v]scale=1920:1080:flags=bicubic[up];[up][1:v]libvmaf=model=version=vmaf_v0.6.1" \
-f null -Синтаксис фильтра libvmaf менялся между релизами FFmpeg – сверьтесь с точной формой для своей версии, – но принцип неизменен: растяните меньший кадр до размера источника, назовите модель, затем оцените. Подробный разбор инструментария – в статье измерение качества с FFmpeg и libvmaf.
Разобранный пример: читаем лестницу по оболочке
Числа делают всё конкретным. Допустим, вы измерили один ассет в четырёх разрешениях и, растянув каждое кодирование до источника 1080p и оценив VMAF, получили такие точки (битрейты в кбит/с, VMAF на стандартной модели для 1080p):
| Битрейт (кбит/с) | 360p | 540p | 720p | 1080p | Победитель оболочки |
|---|---|---|---|---|---|
| 400 | 78 | 74 | 68 | 60 | 360p (78) |
| 800 | 86 | 88 | 84 | 76 | 540p (88) |
| 1500 | 90 | 93 | 94 | 90 | 720p (94) |
| 3000 | 92 | 95 | 96.5 | 97 | 1080p (97) |
| 6000 | 92.5 | 96 | 97.5 | 99 | 1080p (99) |
Прочитайте столбец «Победитель оболочки» сверху вниз – и увидите, как оболочка шагает вверх по разрешениям: 360p владеет самой нижней ступенью, 540p – следующей, 720p – средней, а 1080p – двумя верхними. Видны и пересечения: 360p передаёт эстафету 540p где-то между 400 и 800 кбит/с, а 720p передаёт 1080p между 1500 и 3000 кбит/с. Если теперь нужна четырёхступенчатая лестница, вы не выбираете разрешения по привычке, а считываете их по оболочке: 400 кбит/с → 360p, 800 кбит/с → 540p, 1500 кбит/с → 720p, 3000 кбит/с → 1080p. Обратите внимание на ступень 3000 кбит/с: 1080p (97) обходит 720p (96,5) всего на полбалла VMAF, так что на контенте, где жмёт хранилище или вычисления, вы могли бы оставить там 720p и почти ничего не потерять – оболочка показывает компромисс, но не делает выбор за вас.
Спутник этой статьи – плоттер выпуклой оболочки – делает ровно это по вашим измерениям: подайте ему сетку точек (разрешение, битрейт, качество), и он вычислит оболочку, отметит битрейты пересечения, нарисует график «качество-битрейт» с наложенной оболочкой в виде SVG и – для двух оболочек – вычислит BD-rate между ними. Он воспроизводит эту таблицу в режиме --demo.
Почему это именно ВЫПУКЛАЯ оболочка: взгляд rate-distortion
Версии простыми словами выше достаточно, чтобы построить лестницу. Для читателя, которому нужен слой под ней, вот почему выигрышный фронт именно выпуклый, а не любой верхний край, – и почему слово «выпуклая» делает реальную работу.
Сжатие живёт в пространстве rate-distortion (скорость-искажение): каждое кодирование – это компромисс между скоростью (битами) и искажением (насколько результат далёк от оригинала – обратное качеству). Десятилетия теории кодирования формулируют задачу кодировщика как минимизацию совокупной стоимости, записанной J = D + λR – искажение плюс вес λ на скорость (Sullivan and Wiegand, Rate-Distortion Optimization for Video Compression, IEEE Signal Processing Magazine, 1998). Множитель λ (лямбда) задаёт обменный курс между битами и качеством: малая λ говорит «биты дёшевы, гонись за качеством», большая λ – «биты дороги, экономь». Пройдитесь по λ – и вы прочертите рабочие точки, и множество достижимых так точек – это ровно выпуклая оболочка всех достижимых точек (скорость, искажение).
Вот развязка, оправдывающая название: оптимизация стоимости D + λR всегда может привести вас только на выпуклую оболочку – точек, ныряющих под неё (компромисс лучше оболочки), не существует, а точки над ней (доминируемый, расточительный компромисс) никогда не выбираются, потому что какая-то λ даёт строго лучше. Оболочка – это фронт физически возможного. Из этого выпадает полезное следствие: на оптимальной лестнице каждая ступень сидит там, где локальный наклон оболочки совпадает с её λ, так что лучшие ступени делят общую «отдачу на бит». Per-shot оптимизатор Netflix использует ровно это – он выбирает кодирования планов примерно равного наклона в пространстве rate-distortion и сшивает их в кодирование всего видео по решётке (Trellis) (Netflix Technology Blog, Dynamic Optimizer, 2018). Чтобы построить лестницу, исчисление не нужно, но оно объясняет, почему именно оболочка, и только она, – место, где живут хорошие кодирования.
Оболочка – это математика за per-title encoding
Выпуклая оболочка и per-title encoding – одна идея с двух сторон. Per-title encoding говорит: перестаньте использовать одну фиксированную лестницу для каждого видео; дайте каждому тайтлу ту лестницу, которая нужна его контенту. Выпуклая оболочка – это как вы находите эту лестницу. Построение per-title лестницы – это ровно шаги 1–4 выше: закодировать сетку, измерить её, взять оболочку, считать ступени, – выполненные однажды на ассет. Оболочка – это то, откуда берётся «этому тайтлу нужны эти разрешения на этих битрейтах».
Per-shot encoding гонит ту же машинерию на уровень тоньше. Двухчасовой фильм неоднороден по сложности: тёмная диалоговая сцена и взрыв конфетти хотят разных разрешений на одном битрейте. Per-shot encoding вычисляет выпуклую оболочку для каждого плана – каждой серии похожих кадров, – а затем сводит выборы по планам в кодирование всего тайтла, снова используя правило равного наклона, чтобы решить, сколько бит заслуживает каждый план (Netflix Technology Blog, Dynamic Optimizer, 2018). Выигрыш реален: Netflix сообщил о примерно 25% экономии BD-rate для многопланных видео от пошотовой оптимизации и примерно 28% (x264), 34% (x265) и 38% (VP9) экономии битрейта при равном VMAF против кодирования с фиксированным качеством (Katsavounidis and Guo, SPIE, 2018). Цена в том, что per-shot умножает число кодирований на два порядка – вы строите сотни маленьких оболочек вместо одной. Механика со стороны кодека – как эти кодирования производятся и собираются в лестницу – живёт в разделе Video Encoding; эта статья остаётся на стороне измерения: как оболочка находится и считывается.
Оболочка и BD-rate: одна кривая, два применения
Выпуклая оболочка – это ещё и кривая, на которой вычисляется BD-rate, поэтому эта статья и статья про BD-rate – спутники. BD-rate (Bjøntegaard Delta rate) – это стандартный способ сказать «кодеку A нужно на X% меньше битрейта, чем кодеку B, при том же качестве». Он вычисляется так: берут кривую «качество-битрейт» каждого кодека – его выпуклую оболочку, – интерполируют между измеренными точками и измеряют средний горизонтальный зазор между двумя кривыми по диапазону качества (Bjøntegaard, Calculation of average PSNR differences between RD-curves, ITU-T VCEG-M33, 2001). Зазор, выраженный в процентах битрейта, и есть BD-rate.
Отсюда два следствия. Во-первых, BD-rate настолько достоверен, насколько достоверны оболочки, которые он сравнивает: если одна оболочка построена на нерастянутых оценках или с другим апскейлером, BD-rate между ними – выдумка. Во-вторых, BD-rate – это экономия при равном качестве, а не оценка качества; держите его отдельно от VMAF или PSNR, которые суть оценки качества. Выпуклая оболочка – общий фундамент: постройте её правильно один раз, и вы сможете и считать по ней лестницу, и сравнить две из них с помощью BD-rate. Кривая «качество-битрейт», лежащая в основе обоих, разобрана как отдельная тема визуализации в статье визуализация качества.
Частые ошибки, портящие выпуклую оболочку
Оболочка – точный объект, и горстка ошибок тихо её ломает. Назвать их – это разница между лестницей, которой можно доверять, и той, что выглядит принципиальной, но не такова.
Оценка между разрешениями без растягивания. Ловушка из раздела про измерение, повторённая, потому что она самая частая и самая разрушительная. Полноэталонной метрике нужны оба кадра одного размера; сравните кодирование 540p с источником 1080p без растягивания сначала – и числа бессмысленны. Каждая кросс-разрешённая точка на оболочке должна приходить из сравнения «растянуто-до-источника».
Смена апскейлера посреди сетки. Оболочка верна, только если каждая точка измерена одинаково. Смешивание бикубики для одних кодирований и Lanczos для других сдвигает битрейты пересечения между точками, которые должны быть сравнимы. Выберите один фильтр и используйте его везде.
Считать оболочку VMAF и оболочку PSNR взаимозаменяемыми. Форма оболочки зависит от метрики. PSNR награждает попиксельную точность; VMAF награждает воспринимаемое качество; они коронуют разные разрешения на одном битрейте. И оболочка VMAF зависит от того, какую модель VMAF вы взяли – стандартную телевизионную, телефонную, 4K, – все они рисуют разные оболочки, потому что по-разному взвешивают деталь. Называйте метрику и модель при каждой оболочке и подбирайте модель под то, как смотрят контент (см. VMAF в деталях). Помните, что это за метрики: обе – прокси для человеческого глаза, валидированные против субъективных оценок, собранных в контролируемых условиях просмотра (ITU-R BT.500-15, 2023). Выпуклая оболочка – это поэтому модель того, что воспринимают зрители, а не само восприятие; там, где оболочка и аккуратный просмотр расходятся, эталон истины – просмотр, а метрика – прокси, промахнувшийся на этом контенте.
Доверять оболочке, построенной на средних оценках. Каждая точка на оболочке – обычно среднее качество по всем кадрам, а среднее может прятать плохой отрезок. Оболочка, говорящая «540p на 800 кбит/с набирает VMAF 88», может усреднять чистую говорящую голову с замыленным экшен-моментом. Проверяйте нижний перцентиль, а не только среднее, прежде чем фиксировать ступень в лестнице (см. пулинг покадровых оценок).
Забывать, что оболочка – под контент и с датой. Универсальной выпуклой оболочки не существует. Оболочка специфична под этот ассет, этот кодек, эту версию кодировщика и эти настройки; новый релиз кодировщика или другой кодек перерисовывают её. Оболочка – это измерение с прикреплённой датой и конфигурацией, а не константа, – поэтому к каждой её точке применим и более широкий каталог где врут объективные метрики.
Стоимость оболочки и как команды её снижают
Честная слабость выпуклой оболочки – её цена. Построить её «в лоб» означает закодировать тот же контент десятки или сотни раз – каждое разрешение на каждой точке качества, – а затем измерить их все. Для большого каталога, или для per-shot, где счёт умножается снова, это серьёзный счёт за вычисления. Это по карману тайтлу, который посмотрят десятки миллионов раз, и трудно оправдать для длиннохвостого ассета, который посмотрят пару раз; компромисс – вычисления на кодирование сейчас против битрейта, сэкономленного за всю жизнь просмотров тайтла.
Это активная область исследований, и направление ясно: предсказывать оболочку вместо того, чтобы измерять её целиком. Методы машинного обучения оценивают выпуклую оболочку контента по признакам видео, пропуская большинство «лобовых» кодирований с малой потерей в эффективности «качество-битрейт»; обзор 2025 года каталогизирует семейство методов предсказания выпуклой оболочки, используемых сейчас (Telili et al., Convex Hull Prediction Methods for Bitrate Ladder Construction, ACM TOMM, 2025). Более лёгкая версия того же инстинкта без зависимостей – сократить сетку, оставив точки, наиболее вероятно попадающие на оболочку, – это то, к чему продакшн-команды тянутся первым делом. Оболочка остаётся целью; меняется лишь то, сколько кодирования вы тратите, чтобы её найти.
Где здесь Фора Софт
Фора Софт строит видеософт с 2005 года – стриминг и OTT, видеоконференции, e-learning, телемедицину и видеонаблюдение, – и когда проблема клиента в счёте за трафик или в качестве картинки, выпуклая оболочка – одно из первых, что мы измеряем. Мы строим её дисциплинированно: сетка измерений на ассет, каждое низкоразрешённое кодирование растянуто до источника перед оценкой, один названный апскейлер и одна названная модель VMAF держатся постоянными, нижний перцентиль проверяется до того, как ступень попадёт на лестницу. Для каталога OTT или e-learning это превращается в сэкономленный трафик и хранилище; для живого продукта конференций или видеонаблюдения, где нет нетронутого эталона для оценки, та же мысль переходит к безреференсным методам и другой части пайплайна. Наша методология бенчмарков применяет ту же дисциплину «измерь, потом решай» к нашим собственным тестам кодеков, так что лестницы, которые мы рекомендуем, опираются на оболочки, которые мы действительно измерили, – с датой и воспроизводимо.
Ключевые выводы
- Оболочка отвечает «какое разрешение лучше на этом битрейте?» сразу для всех битрейтов.
- Кривые разрешений пересекаются: маленькие кадры выигрывают на низком битрейте, большие – на высоком.
- Оболочка – верхний фронт лучших точек; всё под ним доминируемо и не используется.
- Всегда растягивайте низкоразрешённое кодирование до размера источника перед оценкой – иначе оболочка неверна.
- Держите апскейлер и модель метрики постоянными; оболочка VMAF и оболочка PSNR различаются.
- Оболочка – математика за per-title encoding и кривая, на которой измеряется BD-rate.