Публикация была переведена автоматически. Исходный язык: Русский
В мире видеонаблюдения сложилась парадоксальная ситуация. Мы научились эффективно упаковывать данные, но застряли в бесконечном цикле их перепаковки.
Конфликт поколений: HEVC против Legacy
Проблема не в том, что H.265 «плохой». Проблема в инерции. Да, современные браузеры начинают дружить с WebCodecs, а Safari давно крутит HEVC. Но реальность систем видеонаблюдения — это не только свежий Chrome. Это тысячи веб-плееров на старых JS-библиотеках, корпоративные софтовые клиенты и мобильные приложения, которые всё еще требуют «старый добрый» H.264.
Когда у вас сотни современных камер пишут в H.265 ради экономии места на дисках, но клиенты требуют поток в AVC — вы попадаете в «транскодинговый ад».
Традиционный путь — это сжигание денег
Стандартный подход к транскодированию выглядит как попытка перевезти груз из одного грузовика в другой, полностью его распаковывая:
- Декодируем H.265 в «сырые» пиксели.
- Снова кодируем эти пиксели в H.264.
Для одной 4K-камеры при 60 fps этот процесс «съедает» целое ядро CPU. Если у вас облачный сервис на 1000 камер, ваша серверная превращается в обогреватель, который просто перекладывает цифры из кармана в карман.
Я смотрел на загрузку процессоров и задавал один вопрос: «Если информация в обоих кодеках почти идентична, зачем мы вообще касаемся пикселей?»
Призрак Шеннона и математическая хирургия
В 1948 году Клод Шеннон доказал: информация и её упаковка (контейнер) — вещи разделимые. И H.264, и H.265 используют схожую математику: дискретное косинусное преобразование (DCT), векторы движения и энтропийное кодирование. Они говорят на разных диалектах, но описывают одни и те же объекты.
Так появился проект. Идея безумная: трансформировать битовый поток напрямую, работая с коэффициентами DCT, а не с картинкой.
Как это работает (без маркетинговой шелухи):
- Butterfly-операции: Вместо того чтобы делать обратное преобразование в пиксели (O(n3)), я вывел формулу прямой конвертации коэффициентов H.265 в H.264. Сложность упала до O(nlogn).
- Групповой Bypass в CABAC: Потоковое энтропийное декодирование обычно идет «бит за битом». Я реализовал пакетную обработку bypass-бинов группами по 4, что дало кратный прирост пропускной способности.
- Умный пропуск (JND): Используя модель Just Noticeable Difference, алгоритм находит в потоке данные, которые человеческий глаз не заметит, и просто отбрасывает их при перепаковке. Это экономит еще 40–60% ресурсов CPU.
Всё это написано на C с жесткой оптимизацией под AVX2 SIMD.
Результаты: Когда 1 ядро заменяет 8
Бенчмарки заставили меня перепроверить код трижды. Там, где стандартный стек FFmpeg (с полным циклом декодирования/кодирования) требовал мощную многоядерную систему для 4K@60fps, мой подход забирает всего 15-20% от одного ядра.
Это значит, что один сервер средней руки теперь может «переваривать» сотни потоков, для которых раньше требовалась целая стойка.
Почему это важно сегодня?
Да, индустрия движется к WebCodecs. Да, H.265 постепенно становится стандартом. Но пока в мире существуют тысячи программ, требующих H.264 для аналитики или стриминга, мы будем платить «налог на транскодирование».
Моя разработка доказывает: самая эффективная оптимизация — это не покупка нового железа, а отказ от вычислений, которые на самом деле не нужны. Мы не меняем информацию. Мы просто меняем её обертку, не вскрывая посылку.
В мире видеонаблюдения сложилась парадоксальная ситуация. Мы научились эффективно упаковывать данные, но застряли в бесконечном цикле их перепаковки.
Конфликт поколений: HEVC против Legacy
Проблема не в том, что H.265 «плохой». Проблема в инерции. Да, современные браузеры начинают дружить с WebCodecs, а Safari давно крутит HEVC. Но реальность систем видеонаблюдения — это не только свежий Chrome. Это тысячи веб-плееров на старых JS-библиотеках, корпоративные софтовые клиенты и мобильные приложения, которые всё еще требуют «старый добрый» H.264.
Когда у вас сотни современных камер пишут в H.265 ради экономии места на дисках, но клиенты требуют поток в AVC — вы попадаете в «транскодинговый ад».
Традиционный путь — это сжигание денег
Стандартный подход к транскодированию выглядит как попытка перевезти груз из одного грузовика в другой, полностью его распаковывая:
- Декодируем H.265 в «сырые» пиксели.
- Снова кодируем эти пиксели в H.264.
Для одной 4K-камеры при 60 fps этот процесс «съедает» целое ядро CPU. Если у вас облачный сервис на 1000 камер, ваша серверная превращается в обогреватель, который просто перекладывает цифры из кармана в карман.
Я смотрел на загрузку процессоров и задавал один вопрос: «Если информация в обоих кодеках почти идентична, зачем мы вообще касаемся пикселей?»
Призрак Шеннона и математическая хирургия
В 1948 году Клод Шеннон доказал: информация и её упаковка (контейнер) — вещи разделимые. И H.264, и H.265 используют схожую математику: дискретное косинусное преобразование (DCT), векторы движения и энтропийное кодирование. Они говорят на разных диалектах, но описывают одни и те же объекты.
Так появился проект. Идея безумная: трансформировать битовый поток напрямую, работая с коэффициентами DCT, а не с картинкой.
Как это работает (без маркетинговой шелухи):
- Butterfly-операции: Вместо того чтобы делать обратное преобразование в пиксели (O(n3)), я вывел формулу прямой конвертации коэффициентов H.265 в H.264. Сложность упала до O(nlogn).
- Групповой Bypass в CABAC: Потоковое энтропийное декодирование обычно идет «бит за битом». Я реализовал пакетную обработку bypass-бинов группами по 4, что дало кратный прирост пропускной способности.
- Умный пропуск (JND): Используя модель Just Noticeable Difference, алгоритм находит в потоке данные, которые человеческий глаз не заметит, и просто отбрасывает их при перепаковке. Это экономит еще 40–60% ресурсов CPU.
Всё это написано на C с жесткой оптимизацией под AVX2 SIMD.
Результаты: Когда 1 ядро заменяет 8
Бенчмарки заставили меня перепроверить код трижды. Там, где стандартный стек FFmpeg (с полным циклом декодирования/кодирования) требовал мощную многоядерную систему для 4K@60fps, мой подход забирает всего 15-20% от одного ядра.
Это значит, что один сервер средней руки теперь может «переваривать» сотни потоков, для которых раньше требовалась целая стойка.
Почему это важно сегодня?
Да, индустрия движется к WebCodecs. Да, H.265 постепенно становится стандартом. Но пока в мире существуют тысячи программ, требующих H.264 для аналитики или стриминга, мы будем платить «налог на транскодирование».
Моя разработка доказывает: самая эффективная оптимизация — это не покупка нового железа, а отказ от вычислений, которые на самом деле не нужны. Мы не меняем информацию. Мы просто меняем её обертку, не вскрывая посылку.
Поделиться
