Методика тестирования кодеков JPEG и JPEG2000 на CPU и GPU

Редакция 1 · Обновлено: 20 сентября 2026

По этой методике Fastvideo измеряет скорость кодеков JPEG и JPEG2000 на процессорах и на видеокартах NVIDIA, от настольной RTX до модулей Jetson. Сделана она в первую очередь для кодеков на видеокарте, но процессорные кодеки меряются по тем же правилам. Кодеки сравниваются при одинаковом размере сжатого файла, в каждом режиме измерений с явными границами отсчёта, в лучшей точке по числу потоков и размеру пачки, найденной перебором. Каждая точка измеряется трижды, качество восстановленного кадра проверяется при каждом запуске. Статьи с результатами ссылаются на эту страницу и на номер редакции, а отличия от методики называют одной строкой.

1. Для какой задачи написана эта методика?

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

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

Отдельно о задаче, которую часто путают с этой: загрузка изображений для обучения нейросетей. Там декодируют сотни тысяч небольших JPEG, обычно по несколько сотен точек по стороне, разного размера и содержимого, пачками из сотен файлов, и главное число — сколько изображений в секунду уходит в обучение. Время одного кадра и качество сжатия там не важны, а размер пачки подбирают под объём данных, а не под поток с камеры. Под такую задачу устроены очень большие пачки в библиотеках декодирования и специальные библиотеки загрузки данных, например NVIDIA DALI. Это не наша задача. Режимы, выгодные только для неё, мы не подбираем и в сравнение не включаем, а числа, полученные на ней, к нашим задачам не переносятся.

Методика относится к любому кодеку JPEG или JPEG2000 на процессоре или на видеокарте NVIDIA: к кодекам из Fastvideo SDK, к библиотекам NVIDIA nvJPEG и nvJPEG2000, к другим реализациям на CUDA, к процессорным кодекам, например OpenJPEG. Процессорный кодек меряется по тем же правилам и в сравнении с видеокартой показывает, где процессора достаточно, а где нет. Видеокарта может быть любой: настольной, серверной или встраиваемым модулем Jetson. Стенд с RTX 4090 в примерах ниже служит примером, а не условием методики; что меняется от платформы, собрано в разделе 12.

2. На каких изображениях тестируются кодеки?

На открытых фотографических кадрах в несжатом формате PPM, которые можно скачать и проверить у себя. Основной набор — два кадра, 8 бит на канал, три канала:

Формат PPM выбран потому, что это несжатый файл с минимальным заголовком: все кодеки получают на вход одни и те же байты, и чтение исходника ни на что не влияет. Степень сжатия при заданном качестве определяется содержимым кадра, поэтому кадры фотографические, с гладкими областями и мелкой фактурой. Дальше в набор войдут кадры 24 и 65 мегапикселей; каждая статья называет, на каких кадрах она мерила.

Этот набор — наш стандартный вариант, и он намеренно самый простой: два кадра, одни и те же параметры сжатия, одно и то же содержимое от прогона к прогону. Именно поэтому он хорошо подходит для сравнения кодеков между собой и для измерения энергии на кадр, где любая лишняя переменная мешает. Но по этой же методике можно тестировать любые изображения и с любыми параметрами сжатия. Главное правило другое: тест должен соответствовать решаемой задаче. Методика задаёт порядок измерения, а кадры, разрешение, разрядность, качество и режим выбираются под задачу, и статья называет их в таблице условий (раздел 13).

Измерение устроено как «один и тот же кадр N раз», а не «N разных кадров». Это правильно для измерения скорости кодека, но кадр 2K или 4K целиком помещается в кэш процессора, и данные после первого повтора берутся из кэша. Обработка папки с разными файлами устроена иначе, и это одна из задач, для которых нужна своя методика (раздел 1).

Разрядность выше 8 бит, монохромные кадры и кадры с мозаикой Bayer с камеры, кадры с разбиением на тайлы измеряются отдельными сериями со своим набором данных: поведение кодеков на них другое. Кадры разного размера для такой серии вырезаются из одного снимка камеры, а не уменьшаются: уменьшение усредняет соседние пикселы, ослабляет шум и мелкие детали, и такой кадр сжимается легче настоящего.

3. Как задаются параметры сжатия?

Явно и одинаково у всех сторон, по общему знаменателю возможностей. Сравниваются только те параметры, которые доступны каждому кодеку, и каждый из них выставляется в командной строке или в вызове, а не остаётся «по умолчанию»: значения по умолчанию у разных кодеков разные.

Для JPEG2000 в опубликованных сравнениях набор такой:

Для JPEG набор такой:

Что у JPEG проверяется сверх этого, собрано в разделе 14.

Если у одной из сторон нужного параметра нет, он выпадает из сравнения, а причина называется в статье. Если режим есть только у одного кодека, например PCRD у кодера JPEG2000 Fastvideo, он измеряется отдельно и без сравнения: показывать чужой продукт в таблице с режимом, которого у него нет, нельзя.

4. Почему кодеки сравниваются при одинаковом размере файла?

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

Процедура такая. Один кодек кодирует кадр при заданном качестве, и размер его файла становится целью. Остальные подбирают свою настройку делением отрезка пополам: кодируют, смотрят на размер, сдвигают границу и повторяют, пока не попадут в цель точнее 0,1 %. У кодека JPEG2000 Fastvideo настройка — качество q, у nvJPEG2000 — Q-фактор, у OpenJPEG — коэффициент сжатия. Подбор делается для каждого кадра заново: соответствие шкал зависит от содержимого кадра, и найденное на одном кадре значение годится на другом только как первое приближение.

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

Качество у JPEG обычно задаётся целым числом, поэтому попасть в размер точнее 0,1 % удаётся не всегда. Тогда берётся ближайшее значение, а отклонение размера публикуется рядом с результатом. Подбор делается двумя независимыми поисками с разных начальных отрезков: совпали оба, значит найденное значение говорит о шкалах, а не о самом поиске. Так же проверялась шкала JPEG2000, на отрезках от 1 до 100 и от 50 до 99.

В режиме без потерь подбирать нечего: параметра качества там нет, и кодеки обязаны выдать полностью восстановимый файл. Это относится к JPEG2000: у обычного JPEG режима без потерь нет. Совпадение размеров в этом режиме само служит проверкой, что кодеки делают одну работу (раздел 5).

Отсюда следствие для чтения чужих сравнений: «сжатие 20:1» без названия кадра ничего не значит. Одно и то же значение параметра на другом кадре даст другой коэффициент сжатия.

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

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

• Без потерь — побитное совпадение декодированного кадра с исходным у каждого кодека на каждом кадре. Без этого совпадения речь уже не о сжатии без потерь. Проверка есть только у JPEG2000: у обычного JPEG сжатия без потерь нет.
• С потерями — PSNR по всему кадру, по трём компонентам сразу, шкала 0–255, при одинаковом размере файла. Разница в десятые доли децибела означает сопоставимое качество. Структурные метрики SSIM и MS-SSIM считаются там, где качество ниже и PSNR перестаёт различать кодеки.
• Перекрёстное декодирование — каждый декодер разбирает и файлы чужого кодера. Так проверяется, что сравнение декодеров не превратилось в сравнение того, что выдали кодеры.
• Размер без потерь — у кодеков с одинаковыми параметрами совпадает до байта или отличается на постоянную величину заголовка контейнера.

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

Демонстрационные сборки кодеков наносят на кадр водяной знак, и прямое сравнение с исходником измеряло бы знак, а не кодек. Поэтому программа сначала проверяет, есть ли знак. Если он есть, эталоном для PSNR берётся кадр, вернувшийся через полный цикл без потерь на той же сборке: знак наносится до кодирования, а режим без потерь сохраняет всё побитно. Условие проверяется отдельно: два независимых цикла без потерь обязаны совпасть байт в байт. Так проверка качества воспроизводится и на демонстрационной версии.

6. В каких режимах измеряется скорость?

В двух основных режимах, и каждое число публикуется вместе со своим режимом. Скорость в кадрах в секунду без режима не имеет смысла: на одной видеокарте один кодек даёт разные числа, и все они верные. У кодера JPEG2000 Fastvideo на кадре 2K с потерями одиночные кадры дают 381 кадр в секунду, а лучшее сочетание потоков и пачки — 1914.

Латентность и пропускная способность — разные величины, а не разная точность для одной задачи. В многопоточном режиме время каждого отдельного кадра больше, чем в одиночном, и это плата за общую скорость. Для задачи с жёстким сроком на кадр главная величина — латентность, для потока с камеры или пакетной обработки — пропускная способность.

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

Если у библиотеки есть собственная пачка или аппаратный блок, они измеряются как отдельные способы запуска, рядом с сеткой потоков. Так у nvJPEG: декодирование пачкой (nvjpegDecodeBatched) меряется на CUDA и, если он есть, на аппаратном декодере. Размер пачки берётся того же порядка, что число кадров в работе в сетке потоков (раздел 8), то есть единицы и десятки крупных кадров, как в потоке от камер. Пачки из сотен кадров нужны для загрузки данных при обучении нейросетей и в сравнение не входят (раздел 1). В сравнение идёт лучший из способов, которые даёт сама библиотека в этих пределах. Кодирования пачкой у nvJPEG нет, там применяется та же схема, что у nvJPEG2000.

Несколько видеокарт в одной машине эта методика не рассматривает: речь о производительности одной карты.

7. Что входит в измеряемое время?

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

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

Работа на процессоре входит в отсчёт у всех сторон. У JPEG2000 это свойство алгоритма: разбор и сборка сжатого потока (Tier-2) плохо распараллеливаются; у кодека Fastvideo они идут на процессоре и при кодировании, и при декодировании, у декодера nvJPEG2000 тоже, это сказано в его документации. Вынести эту часть за скобки у одного кодека и оставить у другого значило бы сравнивать разные вещи.

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

8. Как находится лучшее сочетание потоков и пачки?

Перебором по сетке, а не назначением. Сетка записывается как «число потоков × размер пачки»; в опубликованных сравнениях на RTX 4090 это 8×1, 8×2, 16×2, 8×4, 32×1 и 32×2. Точки, где потоков столько же, сколько логических ядер процессора, отвечают на прямой вопрос: не хватит ли библиотеке просто большего числа потоков.

Лучшее сочетание зависит от кодека, от размера кадра и от режима сжатия, поэтому публикуется вся сетка, а не только победившая точка: воспроизводится процедура, а не итоговое число. На кадре 2K у кодера JPEG2000 Fastvideo пачка помогает, на кадре 4K не даёт ничего, потому что крупный кадр и без неё загружает видеокарту.

Перед каждой точкой проверяется, поместится ли она в память. Каждый кадр, находящийся в работе, занимает место в памяти видеокарты, и точка, которой памяти не хватит, не запускается. В таблице на её месте стоит прочерк, и это результат, а не пропуск: например, 32 потока по 2 кадра на 4K потребовали бы кодеру около 37 ГБ при 22 ГБ свободной памяти на RTX 4090.

Если две точки или два кодека отличаются меньше, чем расходятся повторы одной точки, результат называется словом «вровень», и победитель не назначается.

9. Сколько раз повторяется измерение?

Трижды, в таблицы идёт медиана. Точка, у которой повторы разошлись больше чем на 7 %, домеряется ещё двумя запусками, и медиана берётся по всем пяти. Если разброс остаётся большим и после этого, точка называется в статье поимённо, вместе с разбросом.

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

Числа публикуются с двумя-тремя значащими разрядами: при разбросе повторов в проценты четвёртый разряд не измерен. Отношения «во сколько раз» считаются по напечатанным числам, чтобы читатель, поделив одно на другое, получил то же, что стоит в тексте.

10. Как проверяется сама программа измерений?

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

1. Одна и та же работа. Штатная программа и программа измерений Fastvideo кодируют кадр с одинаковыми параметрами, и сжатые файлы должны совпасть по размеру до байта.
2. Одна и та же подача кадров. Обе программы подают кадры по одному. Результаты должны сойтись в пределах нескольких процентов; для nvJPEG2000 на RTX 4090 расхождение составило 1–3 %.
3. Границы отсчёта по исходникам. Что входит в отсчёт штатной программы, проверяется по её коду, а не по описанию. В примере декодирования nvJPEG2000 время разбора потока переводится в целые секунды и поэтому всегда равно нулю; без этой поправки его числа и числа нашей программы ставить рядом нельзя.
4. Только потом та же библиотека запускается в многопоточном режиме, и прирост относится к схеме запуска, а не к разнице программ.

У JPEG штатные программы NVIDIA — кодер nvJPEG_encoder и декодер nvJPEG из набора cuda-samples и декодер nvjpegDecoder из набора CUDALibrarySamples. Первые два есть в cuda-samples до версии v13.2 и удалены в v13.3, поэтому берутся из v13.2. Декодированный кадр они оставляют в памяти видеокарты, и сверка с ними идёт в их границе отсчёта, как в режиме одиночных кадров.

Разбор времени кадра по стадиям делается двумя способами: изнутри, по выводу самого кодека в режиме одиночных кадров, и снаружи, профилировщиком NVIDIA Nsight Systems. Разбор изнутри включает разовые расходы и читается как порядок величины. Профилировщик показывает время работы вычислительных ядер видеокарты, простои между ними и загрузку шины у обоих кодеков одинаково, но сам замедляет тест, поэтому скорость под ним не публикуется.

11. Как измеряются энергия, загрузка процессора и память?

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

Разностный способ. Счётчик читается до и после запуска, поэтому в показание попадают постоянные расходы: запуск процесса, подготовка буферов, выход карты на режим. Чтобы их убрать, каждая точка измеряется дважды, на N кадрах и на 2N, и энергия кадра берётся как разность, делённая на N. Если программа читает счётчик сама, внутри цикла и после прогрева, разность не нужна; статья называет, каким способом получены её числа.

Простой измеряется отдельно, после того как мощность перестала меняться. Для процессора и для модуля Jetson в таблице стоят оба числа: полное и за вычетом простоя. Полное нужно для расчёта питания системы, за вычетом простоя — для сравнения кодеков между собой.

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

Загрузка процессора показывается в логических ядрах, а не в процентах: 7 логических ядер из 32 читаются сразу, а «22 %» требуют пересчёта. В ватты она не переводится, потому что одно ядро на разной работе потребляет разную мощность. Там, где энергия процессора не измерена, статья говорит, в чью пользу это сдвигает вывод.

Память видеокарты на Windows по процессам не отдаётся, поэтому числа верны для всей карты и при условии, что на ней не работало ничего постороннего.

12. Что меняется на Jetson и на других видеокартах?

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

• Энергия. Джоули модуля Jetson и джоули настольной видеокарты — разные величины: первые включают процессор и память, вторые только карту. Сравнивать их напрямую нельзя, и статьи этого не делают.
• Режим питания. Режим считается применённым, только если изменилось то, что он меняет: частота графической части, число включённых ядер процессора и строка nvpmodel -q. Часть режимов включается только после перезагрузки, и если отвечать на вопрос о перезагрузке некому, команда завершается без ошибки, а модуль остаётся в прежнем режиме. Включён ли jetson_clocks, который закрепляет частоты на максимуме текущего режима, записывается в условия.
• Нагрев и снижение частот. Короткая серия и долгая работа дают разные числа. Длительный прогон идёт 10 минут в лучшей точке, в таблице медиана первой и последней минуты, рядом температура и частота. Способ охлаждения называется: штатный вентилятор и пассивный корпус — разные условия.
• Общая память. «Память видеокарты» на Jetson означает общую память модуля. Сетка потоков и пачки строится по доступной памяти каждого модуля: кодек сообщает, сколько памяти доступно и сколько он запросил, и точка запускается, только если запрос помещается.
• Загрузка по tegrastats. Процент у графической части показывает долю времени, когда на ней была работа, а не долю её ширины. 99 % не значит «запаса нет»: при тех же 99 % скорость ещё может вырасти от другого сочетания потоков и пачки. Запас измеряется пробой нагрузкой: рядом запускается ещё один кодер и смотрится, выросла ли суммарная скорость и выдерживается ли время кадра.
• Модуль и ревизия. Orin NX и Orin AGX — разные машины с разным числом ядер, частотами и полосой памяти. В условиях называется точная модель с объёмом памяти, версии JetPack, L4T и CUDA.
• Наличие кодеков. Есть ли на платформе нужная библиотека NVIDIA (например nvJPEG2000 под aarch64) и аппаратный блок JPEG, проверяется на каждой платформе, а не переносится с другой.

На серверных и профессиональных картах добавляются свои условия: режим работы драйвера, заданный предел мощности, соседние задачи на той же карте. Они записываются в условия так же, как режим питания на Jetson.

13. Какие условия публикуются рядом с результатом?

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

Если число цитируется отдельно от статьи, рядом с ним должны стоять хотя бы стенд, кадр, режим и дата: например, «1914 кадров в секунду, кодирование JPEG2000 кадра 2K с потерями, RTX 4090, лучшее сочетание потоков и пачки, 31.08.2026».

Каждая статья с результатами начинается с короткого раздела «Как мерили» по единой заготовке: абзац со ссылкой на эту страницу и номер редакции, таблица условий и строка «Отличие от методики». Строка обязательна, и если отличий нет, в ней так и написано: «нет».

14. Чем тесты JPEG отличаются от тестов JPEG2000?

Порядок измерений у двух форматов общий, отличаются настройки качества и то, что приходится проверять отдельно.

У библиотек бывают пороги, на которых меняется путь выполнения. В заголовочном файле nvJPEG сказано, что в режиме GPU hybrid декодирование Хаффмана уходит на видеокарту, только когда в пачке больше 50 кадров; при меньшей пачке оно идёт на процессоре. Такие пачки нужны загрузке данных для нейросетей, а не потоку крупных кадров (раздел 1), поэтому сетка под порог не подгоняется. У каждой точки записывается, где шло декодирование Хаффмана, и это входит в отсчёт как работа кодека на процессоре. Правило общее: если путь выполнения зависит от размера задачи, это называется в статье, а сетка строится по нашей задаче.

14.1. Как проверяется аппаратный декодер JPEG?

Четырьмя независимыми способами на самой видеокарте, потому что документация отвечает не на каждую карту. У nvJPEG она называет поколения, а не модели: аппаратный декодер есть у «Ampere (A100, A30), Hopper, Ada, Blackwell», и из поколения Ampere названы только две серверные модели. Кроме того, библиотека может без предупреждения перейти с аппаратного блока на CUDA, и такую работу легко принять за работу блока.

Тем же порядком проверяется аппаратный кодер JPEG: в заголовочном файле nvJPEG он объявлен (NVJPEG_ENC_BACKEND_HARDWARE), и есть ли он на конкретной карте, выясняется только на ней. На модулях Jetson аппаратный блок JPEG свой (в выводе tegrastats это поле NVJPG), и проверяется он так же.

14.2. Как делится на стадии декодирование JPEG?

У nvJPEG декодирование разбито на три стадии самой библиотекой: разбор файла и декодирование Хаффмана на процессоре, пересылка данных на видеокарту и обратное преобразование на видеокарте. Каждая стадия измеряется отдельно. Доли показывают, куда уходит время одного кадра, но складывать их во время кадра нельзя: между стадиями стоят синхронизации, которых в обычной работе нет. У кодеков Fastvideo стадии печатает сам кодек, как у JPEG2000 (раздел 10).

14.3. Что у JPEG измеряется отдельными сериями?

Прогрессивный JPEG, 12 бит и сжатие кадров с мозаикой Bayer. У кодека JPEG из Fastvideo SDK эти режимы есть, но у других кодеков их может не быть, а поведение на них другое. Каждый такой режим измеряется своей серией по тем же правилам, и в статье он называется в строке «Отличие от методики» или в названии серии.

15. Чего эта методика не измеряет?

Того, что лежит за пределами задачи из раздела 1, и того, что требует отдельного набора данных:

• изображения, которые не помещаются в память видеокарты и обрабатываются по частям;
• обработку архивов с диска, где в отсчёт входят чтение и запись файлов и кадры разного содержимого;
• загрузку множества небольших изображений для обучения нейросетей и пачки из сотен кадров;
• несколько видеокарт в одной машине;
• декодирование выбранной области и работу с тайлами;
• разрядность выше 8 бит и монохромные кадры — это отдельные серии со своими кадрами;
• визуальную оценку качества глазами.

В каждой статье есть раздел «Что не проверено». Утверждение, которое не подтверждено измерением, стоит только там, а не по тексту, и читатель видит, где вывод опирается на измерение, а где на рассуждение.

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

Взять открытый код и запустить его на своей видеокарте и своих кадрах. Результаты на другой машине будут другими; воспроизводится процедура, а не наши числа.

• Скрипт прогона, программы измерений для библиотек NVIDIA и сырые логи каждой серии лежат в открытом репозитории github.com/fastvideo/jpeg2000-benchmark. Данные серии сохранены в архиве Zenodo с постоянным идентификатором; DOI называет статья, к которой относится серия.
• Скорость кодеков Fastvideo воспроизводится на демонстрационной версии SDK, проверка качества тоже (раздел 5). Сборка без водяного знака выдаётся по запросу.
• nvJPEG входит в CUDA Toolkit, nvJPEG2000 бесплатно скачивается с сайта NVIDIA, OpenJPEG открыт, AMD uProf бесплатна.
• Скрипт сам подбирает размер файла, число кадров на точку и печатает сетку, так что лучшее сочетание потоков и пачки для своей машины находится тем же перебором. Брать чужой оптимум готовым не стоит.

Как быстро проверить скорость отдельного модуля Fastvideo на своей видеокарте демо-программой, описано на странице «Как проверить производительность Fastvideo на своём оборудовании». Замечания к методике принимаются в разделе issues репозитория.

17. Редакции методики и статьи, которые на неё ссылаются

Методика меняется редакциями. Статья ссылается на редакцию, по которой получены её числа, поэтому новая редакция не меняет смысла старых результатов.

Статьи, в которых методика была разобрана впервые и которые теперь на неё ссылаются:

• Сравнение кодеков JPEG2000 на видеокарте: fvJPEG2000 и nvJPEG2000 на RTX 4090 — сравнение двух кодеков на одной видеокарте, 31 августа 2026.

Права на этот материал

Текст методики распространяется по лицензии CC BY 4.0: его можно перепечатывать, пересказывать, переводить и применять в своих измерениях, в том числе в коммерческих, со ссылкой на источник. Ссылка выглядит так: Fastvideo, «Методика тестирования кодеков JPEG и JPEG2000», редакция 1, https://www.fastvideo.ru/benchmarks/codec-benchmark-methodology.htm. Номер редакции нужен обязательно: по нему видно, по каким правилам получены числа. Если вы меняли методику, скажите, что именно.

Об авторе

Фёдор Серженко, к.ф.-м.н. — основатель и генеральный директор Фаствидео. Кандидатскую защитил в МФТИ в 1993 году. С 2009 года ведёт разработку кодеков и модулей обработки изображений на видеокартах, включая Fastvideo SDK. Профиль в LinkedIn.

Почему этим результатам можно верить

Фаствидео делает обработку изображений на видеокартах с 2009 года. Кодеки соответствуют стандартам, которые реализуют — JPEG (ITU-T T.81 / ISO IEC 10918) и JPEG2000 (ITU-T T.800 / ISO IEC 15444). Любой опубликованный результат воспроизводим: скрипты измерений и сырые логи лежат в открытом репозитории, демонстрационные версии — в разделе загрузок.