Бенчмарки JPEG2000 на процессоре и на видеокарте. OpenJPEG — 15 к/с для 4K, Fastvideo — 616 к/с

Обновлено: 29 сентября 2026

OpenJPEG — открытый кодек JPEG2000 для центрального процессора, два других кодека работают на видеокарте. Здесь все три кодека протестированы на одном компьютере, на одних кадрах и при одинаковом размере сжатого файла. При кодировании кадра 2K с потерями fvJPEG2000 даёт 1914 кадров в секунду (к/с), nvJPEG2000 — 292 к/с, OpenJPEG, занимая весь процессор Ryzen 9 7950X, — 77 к/с. Ниже таблицы для кадров 2K и 4K, предел процессора по числу потоков, занятые ядра и потребление энергии на кадр. Как проводились тесты, написано в методике тестирования кодеков; здесь — только отличия от неё.

Эта статья есть и в виде PDF: Бенчмарки JPEG2000 на процессоре и на видеокарте (технический отчёт) — тот же текст, числа и графики, с оглавлением и номерами страниц, чтобы читать без сети и передавать дальше.

1. Хватит ли процессора для вашей задачи: где проходит граница

Ответ дают результаты тестов, собранные в начале статьи (Главные результаты): все три кодека протестированы на одном компьютере, на одинаковых кадрах и при одинаковом размере сжатого файла.

Граница для процессора проходит здесь: 77 к/с на 2K и 15 к/с на 4K. Это наибольшая скорость, которую удалось получить перебором параметров: больше не получается ни за счёт числа потоков, ни за счёт способа подачи кадров (раздел 7), ни за счёт сборки библиотеки с векторными командами (раздел 4.3).

Поэтому вопрос можно поставить так: можно ли решить конкретную задачу сжатия в JPEG2000 на процессоре? Если требуемая частота кадров ниже границы, задача решается, и остаётся посчитать, насколько при этом будет загружен компьютер. Если выше, никакие параметры кодека не помогут — нужно другое оборудование.

Кроме скорости, важны ещё две величины. Занятые логические ядра: кодек, который занимает весь процессор, не оставляет ресурсов для приёма кадров с камеры, их обработки и записи (раздел 8). Джоули на кадр: для встраиваемой техники и серверной стойки это предел по питанию и по теплу (раздел 9).

OpenJPEG распространяется под открытой лицензией BSD, есть в каждом дистрибутиве Linux и собирается одной командой. Начинают обычно с него, и статья отвечает на один вопрос: когда его стоит использовать?

2. Какие задачи решаются на процессоре, а какие нет

В таблице слева условия задачи, справа — наилучший результат тестов OpenJPEG и ответ, хватает ли процессора. Результаты OpenJPEG взяты из раздела 5 и раздела 6, это его наибольшая скорость при оптимальном наборе параметров: весь процессор занят кодеком, других программ на компьютере не запущено.

«Процессора не хватает» означает, что задача не решается на этом процессоре ни при каких параметрах кодека.

Для одной камеры на 30 к/с граница проходит между кадрами 2K и 4K — это верно для OpenJPEG на этом процессоре, при сжатии с потерями и при той степени сжатия, что в наших тестах. На кадре 2K процессора хватает на такую камеру и с запасом на просмотр; на кадре 4K не хватает и на одну камеру, причём вдвое. На другом процессоре, при другой частоте кадров или другой степени сжатия граница пройдёт в другом месте. Для камеры, подключённой к настольному компьютеру, подходит настольная видеокарта (статья про RTX 4090), для автономной системы регистрации, скорее всего, подойдёт модуль с ограниченным питанием: там, кроме скорости, важно и потребление энергии на кадр.

3. Какие кодеки JPEG2000 сравниваются: nvJPEG2000 и fvJPEG2000 на видеокарте, OpenJPEG на процессоре

fvJPEG2000 — кодек JPEG2000 на CUDA из состава Fastvideo SDK 0.23.1.0, работает на видеокарте.

nvJPEG2000 0.11.0.51 — библиотека NVIDIA, тоже на видеокарте. Бесплатна, поставляется отдельно от CUDA Toolkit.

OpenJPEG 2.5.4 — открытый кодек JPEG2000 для центрального процессора, собран из исходников в конфигурации Release. С ним обычно сравнивают другие кодеки JPEG2000, и его проще всего попробовать.

Все три кодека реализуют один стандарт, ITU-T T.800, и делают одно и то же: сжимают одни и те же кадры с одинаковыми параметрами до одного размера файла. Различается только устройство, на котором идут вычисления.

4. Как измеряли

Измерения сделаны по методике тестирования кодеков JPEG и JPEG2000, редакция 1. Кодеки сравниваются при одинаковом размере сжатого файла. Скорость приводится в двух режимах: в режиме одиночных кадров, когда кадры обрабатываются по одному, и в многопоточном режиме при оптимальном наборе параметров — числе потоков и кадров в пачке, при котором скорость кодека наибольшая; этот набор найден перебором. В многопоточном режиме время считается с момента, когда кадр лежит в оперативной памяти, до момента, когда результат снова в ней, вместе с копированием на видеокарту и обратно; время работы кодека на процессоре учитывается всегда, время чтения и записи файлов не учитывается. Каждое измерение повторялось несколько раз, в таблицах медиана, число повторов указано ниже. При каждом запуске кадр кодируется, декодируется и сравнивается с исходным.

Отличия от методики:

• у OpenJPEG своя сетка параметров — число одновременно обрабатываемых кадров на число потоков внутри кадра, до 64 потоков всего, потому что у библиотеки есть собственный пул потоков (раздел 7.1);
• потребление энергии процессором у кодеков на видеокарте измерено отдельным прогоном 29 сентября 2026 на том же компьютере, потребление видеокарты взято из статьи про RTX 4090 (раздел 9);
• результаты кодеков на видеокарте взяты из статьи про RTX 4090, OpenJPEG протестирован на том же компьютере.

Код и данные лежат в открытом репозитории.

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

4.1. Почему OpenJPEG тестировался не утилитой opj_compress из его состава?

Утилита opj_compress, которая входит в OpenJPEG, при каждом запуске читает один кадр с диска, сжимает его, записывает результат на диск и завершается. Время чтения и записи файла и запуска самой утилиты входит в её результат. Поэтому OpenJPEG тестировался программой Fastvideo — той же, которой тестировался nvJPEG2000 (методика, раздел 10). Она вызывает функции библиотеки OpenJPEG напрямую: читает кадр с диска один раз, а дальше сжимает и декодирует его в оперативной памяти много раз подряд, в одном или нескольких потоках. В самой библиотеке есть функции чтения и записи сжатых данных только для файлов на диске; функции для оперативной памяти написаны в этой программе.

Одна подробность влияет на время обработки кадра. OpenJPEG забирает буферы с изображением себе: после кодирования указатели на данные кадра обнуляются, и повторно эти буферы использовать нельзя. Значит, каждому кадру нужны свои буферы, и так приходится делать любой программе, которая использует OpenJPEG. Выделение буферов вместе с копированием изображения заняло 1,4 % времени обработки кадра 2K в том измерении, результаты которого приведены в таблицах.

4.2. Как проверено, что три кодека делают одну и ту же работу?

По результату, а не по списку ключей: параметры у трёх библиотек называются по-разному и могут означать не совсем одно и то же. Сначала размер файла. У OpenJPEG задаётся коэффициент сжатия, и подбор делением отрезка пополам дал нужный размер с точностью до сотых долей процента.

В режиме без потерь размером управлять нельзя, поэтому совпадение размера само проверяет, что кодеки делают одно и то же. Разница в 39 байт одинакова на обоих кадрах: это заголовок контейнера, а сами сжатые данные совпали по размеру. Декодированный кадр без потерь совпал с исходным байт в байт.

Размер файла nvJPEG2000 получен двумя программами независимо, штатным кодером NVIDIA и программой тестирования Fastvideo, и совпал до байта.

В режиме с потерями одинаковый размер ничего не доказывает, поэтому сравнивается PSNR после полного цикла.

Кадры и заданный размер сжатого файла у трёх кодеков одни и те же; чем больше PSNR, тем ближе результат к исходному кадру.

Разница между крайними кодеками — 0,18 дБ на 2K и 0,27 дБ на 4K, на глаз она не видна. Значит, все результаты скорости ниже получены при одинаковом размере файла и практически одинаковом качестве: ни один кодек не выигрывает в скорости за счёт качества.

4.3. Что даёт сборка OpenJPEG с ключом /arch:AVX2?

Ничего заметного. Библиотеку собрали дважды, обычной сборкой Release и с ключом, разрешающим широкие векторные команды, и протестировали обе подряд при оптимальном наборе параметров. Перед этим проверено, что сборки делают одну работу: файлы совпали по размеру до байта, PSNR совпал, режим без потерь вернул кадр байт в байт.

Разница по восьми задачам от −9,0 до +7,5 %, и знак у неё разный. Это единицы процентов, а кодеки на видеокарте быстрее OpenJPEG в разы и в десятки раз, так что разрыв объясняется не ключами компилятора.

5. Скорость кодирования JPEG2000: сколько кадров в секунду даёт видеокарта и сколько процессор

В таблице скорость каждого кодека при оптимальном наборе параметров, найденном перебором числа потоков и кадров в пачке.

При кодировании fvJPEG2000 быстрее OpenJPEG в 18,6–42,5 раза, nvJPEG2000 — в 3–11 раз. У OpenJPEG на кадре 4K режим сжатия почти не влияет на скорость: 14,5 к/с с потерями и 15,0 к/с без потерь; причина разобрана в разделе 7.3.

5.1. Откуда разница между двумя кодеками на видеокарте?

Главных причин две. Первая — энтропийное кодирование EBCOT Tier-1 с контекстным моделированием. Оно занимает от половины до трёх четвертей времени кадра, и fvJPEG2000 проходит эту стадию в 2–5 раз быстрее nvJPEG2000. Поэтому fvJPEG2000 кодирует быстрее nvJPEG2000 в 1,5–2,5 раза даже в режиме одиночных кадров.

Вторая — загрузка видеокарты. fvJPEG2000 передаёт видеокарте несколько кадров за один запуск. У nvJPEG2000 нет функции, которая принимает несколько кадров сразу, и вычисления запускаются на каждый кадр отдельно, поэтому видеокарта частично простаивает даже при многих потоках процессора. Переход от одиночных кадров к восьми потокам ускоряет fvJPEG2000 в 4,7 раза, nvJPEG2000 — на 3,5 %. При этом fvJPEG2000 занимает 7 логических ядер против 15–30 у nvJPEG2000 (раздел 8).

При декодировании картина обратная: стадия Tier-1 быстрее у nvJPEG2000. Но у fvJPEG2000 скорость сильнее растёт с числом потоков и размером пачки, и при оптимальном наборе параметров скорости двух кодеков почти равны (раздел 6). Разбор по стадиям и данные профилировщика — в разделе 8 статьи про RTX 4090.

6. Скорость декодирования JPEG2000 на видеокарте и на процессоре

Таблица устроена так же: оптимальный набор параметров каждого кодека, те же кадры и режимы.

При декодировании кодеки на видеокарте быстрее OpenJPEG в 5,4–14 раз, а не в десятки раз, как при кодировании. OpenJPEG декодирует быстрее, чем кодирует: 149 к/с против 76,8 к/с на кадре 2K с потерями. Но и эти 149 к/с он даёт, только обрабатывая одновременно 48 кадров и занимая 31,4 логического ядра из 32.

7. Сколько кадров в секунду можно сжать на процессоре и почему больше не получается

В этом разделе проверено, не занижен ли результат OpenJPEG из-за неудачного способа запуска.

7.1. Какими способами можно загрузить процессор и что даёт каждый?

Способов два. Первый — собственный пул потоков OpenJPEG (функция opj_codec_set_threads): кадры идут по очереди, и каждый обрабатывается в нескольких потоках. Второй — несколько кадров обрабатываются одновременно: каждый поток обрабатывает целый кадр своим экземпляром кодека. Восемь кадров по четыре потока дают тридцать два потока. Поэтому тесты шли по общему числу потоков, и при каждом числе проверены все разумные способы поделить потоки между кадрами.

Ускорение считается по отношению к скорости, полученной на одном потоке.

На кадре 2K наибольшая скорость, 76,8 к/с, получена при 32 кадрах одновременно по одному потоку на кадр, и при любом числе потоков быстрее всего обрабатывать каждый кадр в одном потоке. На кадре 4K это перестаёт работать (раздел 7.3).

7.2. Почему собственный пул потоков OpenJPEG отстаёт?

Потому что он не может загрузить все ядра процессора. Вместе со скоростью измерено число занятых логических ядер: оно показывает, работает ли пул медленнее или просто не использует все ядра.

В последнем столбце — скорость в расчёте на одно занятое ядро, то есть отношение двух предыдущих столбцов. Все строки измерены подряд, в одной серии, поэтому результат на тридцати двух потоках здесь ниже, чем в таблице раздела 7.1 (75,0 против 76,8 к/с): та серия измерялась в начале работы, до прогрева компьютера. Сравнивать между собой надо строки внутри одной таблицы.

Пулу задали 32 потока, а занято 8,1 логического ядра из 32. Библиотека работает не медленнее, она не может загрузить все ядра процессора: её потоки ждут друг друга внутри кадра. Это известная особенность OpenJPEG, в списке ошибок проекта на GitHub открыта заявка №952 «Improve scalability of openjpeg multithreading»; здесь она подтверждена измерением.

7.3. Где предел и почему на кадре 4K он наступает раньше?

На кадре 2K скорость почти удваивается на каждое удвоение числа кадров до шестнадцати, то есть до числа физических ядер Ryzen 9 7950X; переход к тридцати двум логическим ядрам увеличивает скорость только в 1,4 раза, а дальше скорость падает. На кадре 4K картина другая.

В последнем столбце — разброс между повторами.

На кадре 4K способ «каждый кадр в своём потоке» перестаёт работать: наибольшая скорость у него при шестнадцати кадрах — 11,3 к/с, а при тридцати двух — только 7,0 к/с, и число занятых ядер при этом не растёт. Быстрее всего работает сочетание двух способов: восемь кадров по четыре потока, 14,5 к/с. При сжатии без потерь наибольшая скорость — 15,0 к/с, при двенадцати кадрах по четыре потока.

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

В первых шести строках потоков поровну — тридцать два; в последних пяти число потоков другое.

При сжатии одного кадра 4K OpenJPEG занимает около 330 МБ оперативной памяти (в таблице выше — 10 ГБ на 32 кадра одновременно), хотя сам кадр в 13 раз меньше — 25 МБ (3840×2160 пикселов, три канала по одному байту). Причина — в устройстве библиотеки OpenJPEG. Изображение хранится в ней в 32-битных целых числах: каждое 8-битное значение пиксела в каждом канале занимает четыре байта вместо одного — в этой библиотеке один формат для данных любой разрядности. Для сжатия она делает рабочую копию кадра того же размера. При сжатии с потерями, как в этой таблице, значения в рабочей копии переводятся в 32-битные числа с плавающей точкой, тоже по четыре байта: в них выполняются цветовое преобразование и вейвлет-преобразование 9/7, результаты которых дробные. При сжатии без потерь (вейвлет-преобразование 5/3) рабочая копия остаётся в целых числах. Две такие копии кадра — уже около 200 МБ, остальное — промежуточные данные сжатия. Чем больше кадров одновременно, тем больше занято памяти, и скорость при этом падает: при тридцати двух кадрах одновременно в памяти 10 ГБ данных, а скорость 7,1 к/с; при восьми кадрах по четыре потока — 2,7 ГБ, а скорость почти вдвое выше. В верхних строках таблицы памяти занято мало, но там скорость ограничивает пул потоков, который не может загрузить все ядра (раздел 7.2). Лучший результат лежит между этими двумя ограничениями.

7.4. Почему на странице бенчмарков кодеков приведён другой результат?

Потому что там тестировался другой режим. На странице бенчмарков кодеков JPEG2000 у OpenJPEG 45 мс на кадр 2K, около 22 к/с: это режим одиночных кадров, где кадры идут по очереди, а внутри кадра работает собственный пул. Тот же режим здесь дал 23,0 к/с (раздел 7.2), расхождение в пределах 5 %, хотя там версия 2.5.2, сжатие около 12:1 и семь уровней разрешения. Значит, 22 и 76,8 к/с — результаты одной и той же библиотеки в двух режимах подачи кадров, а не противоречие двух страниц.

8. Сколько логических ядер процессора занимает каждый кодек JPEG2000

В таблице — занятые ядра процессора вместе со скоростью, которую кодек при этом даёт, при оптимальном наборе параметров каждого кодека; скорость — та же, что в разделах 5 и 6. Всего у процессора этого компьютера 32 логических ядра.

Для кодеков на видеокарте результаты взяты из раздела 11 статьи про RTX 4090, измерены на том же компьютере.

При кодировании fvJPEG2000 обходится 7 логическими ядрами из 32 и оставляет другим задачам почти весь процессор, а OpenJPEG при наибольшей скорости занимает 28,7 ядра при кодировании 2K и 30–31 ядро при декодировании. Сколько ядер занято, зависит от способа запуска, а не только от устройства, на котором работает кодек: nvJPEG2000 при кодировании 2K занимает 29,5 ядра, больше, чем OpenJPEG, потому что его оптимальный набор параметров — 32 потока по два кадра. На кадре 4K OpenJPEG занимает 17,4 ядра, но свободные ядра ему не помогут: скорость уже ограничена объёмом данных в памяти (раздел 7.3).

9. Энергопотребление при сжатии JPEG2000: сколько джоулей на кадр тратят видеокарта и процессор

Чтобы сравнить процессор с видеокартой, нужно учитывать все устройства, которые нагружает кодек. У OpenJPEG видеокарта не работает, и по её счётчику у него получилось бы ноль джоулей. Кодеки на видеокарте тоже нагружают процессор: при кодировании 2K fvJPEG2000 занимает 7 логических ядер из 32 (раздел 8). Поэтому у fvJPEG2000 и nvJPEG2000 измерено потребление и видеокарты, и процессора, а у OpenJPEG — процессора. В статье про RTX 4090 потребление процессора не измерялось.

9.1. Как измерялось потребление энергии процессором?

По правилам методики (раздел 11). Программа AMD uProf примерно каждые 50 мс записывает мощность всего процессора вместе с точным временем записи, а энергия считается как сумма «мощность × время» по этим записям. Каждый тест запускается дважды — на N и на 2N кадрах, — и берётся разность: так из результата уходят затраты на запуск, которые от числа кадров не зависят. Все измерения энергии проведены такой командой:

AMDuProfCLI.exe timechart --event power --interval 50
    -o <папка> <программа> <аргументы>

Три вещи в этой статье проверены отдельно. Интервал опроса 50 мс выбран из четырёх: только при нём отсчёты идут ровно и без пропусков. Сам профилировщик почти не нагружает процессор: при одной и той же вычислительной работе разница с ним и без него — 2,9 %, меньше разброса между повторами (7,8 %). В прогоне 29 сентября запуски с профилировщиком и без него чередовались: с профилировщиком OpenJPEG кодирует на 0,5 % медленнее, fvJPEG2000 — на 0,8 %. И учитывается мощность всего процессора, а не сумма ядер, потому что ядра дают только 79 % потребления под нагрузкой:

9.2. Сколько джоулей уходит на один кадр?

У fvJPEG2000 и nvJPEG2000 в таблице сумма: потребление видеокарты и потребление процессора. У OpenJPEG — потребление процессора. Из чего складывается сумма у кодеков на видеокарте, написано в разделе 9.3.

Последний столбец — потребление OpenJPEG за вычетом простоя: без нагрузки процессор потребляет 20,9 Вт, и эта мощность расходуется всё время работы. У кодеков на видеокарте вычет простоя видеокарты и процессора уменьшает сумму на 8–11 % и ни одного вывода не меняет.

При кодировании fvJPEG2000 тратит на кадр в 8,3–19 раз меньше энергии, чем OpenJPEG, nvJPEG2000 — в 1,2–4,8 раза меньше. При декодировании разница меньше: у fvJPEG2000 в 2,8–5,0 раза, у nvJPEG2000 в 2,4–5,6 раза.

9.3. Сколько энергии тратит процессор у кодеков на видеокарте?

Потребление процессора у fvJPEG2000 и nvJPEG2000 измерено отдельным прогоном 29 сентября 2026 на том же компьютере, при тех же оптимальных наборах параметров и тем же способом, что у OpenJPEG (раздел 9.1). Счётчик видеокарты в этом прогоне работал одновременно с профилировщиком. Потребление видеокарты совпало с прогоном 31 августа в пределах 3 % в 15 случаях из 16, поэтому в таблице оно взято из прогона 31 августа, как в статье про RTX 4090.

У fvJPEG2000 на процессор приходится 31–49 % энергии кадра, у nvJPEG2000 — 21–56 %. Доля процессора следует за числом занятых ядер из раздела 8. Декодер fvJPEG2000 без потерь занимает около 28 ядер, и процессор тратит почти столько же, сколько видеокарта. Кодер nvJPEG2000 на кадре 2K занимает 29–30 ядер, и при сжатии с потерями процессор тратит больше видеокарты: 0,664 Дж против 0,523 Дж.

Два результата nvJPEG2000 повторяются хуже остальных, хотя каждый измерен пятью парами запусков: разброс потребления процессора при кодировании 2K с потерями — 24 %, при кодировании 4K без потерь — 62 %. Суммы в этих строках таблицы известны с меньшей точностью; на выводы раздела это не влияет.

В том же прогоне заново измерено потребление OpenJPEG. Оно отличается от таблицы раздела 9.2 не больше чем на 5,2 %, кроме кодирования 4K без потерь: там на 8,6 % меньше при разбросе повторов 18 %.

10. Выводы: когда для JPEG2000 хватает процессора, а когда нужна видеокарта

Предел процессора. Больше 76,8 к/с на кадре 2K и 14,5 к/с на кадре 4K на этом компьютере не получить ни при каких параметрах кодека: процессор уже занят целиком (раздел 7). Одна RTX 4090 на тех же кадрах даёт с fvJPEG2000 1914 к/с и 616 к/с, с бесплатной nvJPEG2000 — 292 к/с и 160 к/с. Если задаче нужна большая скорость, чем даёт процессор, её решает другое оборудование, а не подбор параметров OpenJPEG.

Когда процессора хватает.

• Декодирование на умеренной частоте кадров: 149 к/с на 2K с потерями и 30,5 к/с на 4K достаточно для просмотра и пакетной обработки.
• Разовое перекодирование архива, где время работы не ограничено и компьютер можно занять целиком.
• Компьютер без видеокарты и без места под неё: в стойке, в защищённом корпусе, на площадке заказчика.

Когда процессора не хватает.

• Кодирование кадров с камеры 4K в реальном времени: OpenJPEG даёт при оптимальном наборе параметров 14,5 к/с, без потерь 15,0 к/с.
• Процессор нужен другим задачам на этом компьютере: OpenJPEG занимает 28,7 логического ядра из 32 при кодировании 2K и 31,4 при декодировании (раздел 8), fvJPEG2000 при кодировании — 7.
• Несколько камер 4K на один компьютер: процессору не хватает скорости даже на одну такую камеру.
• Предел по питанию и по теплу (раздел 9).

Качество при этом практически одинаковое: PSNR у трёх кодеков сходится в пределах 0,27 дБ (раздел 4.2), и ни один кодек не выигрывает в скорости за счёт качества.

Два кодека на видеокарте сравниваются между собой в статье о сравнении fvJPEG2000 и nvJPEG2000 на RTX 4090; что даёт встраиваемый модуль, показано в статье про сжатие без потерь 12-битных кадров на Jetson Orin; о лицензиях и режимах — на странице кодека JPEG2000 на CUDA.

11. Что в этих измерениях не проверялось

Список нужен, чтобы никто не прочитал в таблицах того, чего в них нет.

Что осталось за рамками тестов.

• Kakadu и другие коммерческие кодеки на процессоре. OpenJPEG — самый доступный процессорный кодек, но не самый быстрый.
• Linux. Все тесты проведены на Windows 11.
• Тайлы, декодирование выбранной области, разрядность выше восьми бит, прореживание цветности.
• Метрики качества, кроме PSNR, и визуальное сравнение.
• Разбор по стадиям кодека на процессоре. Для кодеков на видеокарте он сделан в разделе 8 статьи про RTX 4090, для OpenJPEG здесь его нет.

Где точность результатов ограничена.

• Точность отдельных измерений на 4K. Измерения кодирования 4K в этой серии повторяются хуже всего: у сочетания 16×1 разброс 25,5 %, у 8×1 13,5 %, у 12×4 12,2 %, хотя каждое из них повторено пять раз. У оптимального сочетания 8×4 разброс 4,2 %. Выводы опираются на разницу между 14,5 к/с и 7,0 к/с при одном числе потоков, а она больше любого разброса.
• Обращения к памяти. В разделе 7.3 измерен объём памяти, занятой программой, но не счётчики обращений к памяти. Объяснение предела на 4K опирается на объём занятой памяти.
• Порядок запусков при сравнении сборок. Две сборки тестировались подряд при одних и тех же параметрах, и на первую приходится прогрев компьютера; порядок чередуется, но перекос остаётся (медиана разброса 9,5 % у первой сборки в паре против 6,1 % у второй). Поэтому крайние результаты раздела 4.3 сами по себе ничего не доказывают.
• Строка про четыре камеры в разделе 2 построена на допущении: четыре камеры 4K по 10 к/с, сжатие с потерями, 8 бит.
• Сверка счётчиков с потреблением компьютера от сети: прибора, измеряющего мощность на входе компьютера, у нас нет.

12. Как повторить эти измерения у себя

Повторить тесты может любой: OpenJPEG открыт и собирается одной командой, nvJPEG2000 и AMD uProf бесплатны, демонстрационная версия Fastvideo SDK высылается по запросу, а скрипты, программы тестирования и логи лежат в открытом репозитории. Порядок измерений описан в методике, условия этой статьи — в разделе 4. На другой видеокарте и другом процессоре результаты будут другими: повторить можно порядок измерений, а не сами результаты.

13. Что почитать по теме

Откуда взяты результаты и правила этой статьи:

• Методика тестирования кодеков JPEG и JPEG2000 на CPU и GPU — границы отсчёта, одинаковый размер файла, сетка потоков, повторы, энергия. Эта статья сделана по ней, редакция 1.
• Сравнение кодеков JPEG2000 на видеокарте: fvJPEG2000 и nvJPEG2000 на RTX 4090 — оттуда результаты двух кодеков на видеокарте, занятые ядра и потребление видеокарты.
• Открытый репозиторий бенчмарка — программы тестирования, скрипты и логи.
• Как проверить скорость на своих кадрах — демонстрационные программы Fastvideo и порядок проверки.

Тот же кодек в других условиях и в работе:

• JPEG2000 без потерь, 12 бит: кодирование raw на Jetson Orin — встраиваемый модуль вместо настольной видеокарты, с джоулями на кадр.
• JPEG2000 в цифровом кино и телевещании и JPEG2000 в науке и медицине — где этот формат применяется и почему.
• Кодек JPEG2000 на видеокарте и Fastvideo SDK — то, на чём проводились тесты fvJPEG2000.
• Стандарт ITU-T T.800 — сам формат JPEG2000.