Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Быстрый J2K кодек — это интересно. Любопытно, какую производительность вы ожидаете получить? У меня вот уже довольно давно висит задачка по сжатию потока шестнадцатибитных картинок. Грубо говоря есть самодельная железка (PCI плата), которая подгоняет нам видео в виде потока картинок (технически на каждый фрейм вызывается callback с указателем на буфер), в настоящий момент до 96 MB в секунду (4096x4096/16 bit/3 FPS, либо 1024x1024/16 bit@30FPS — это стало быть 60 мегабайт в секунду). Требуется сжимать это видео с настраиваемой потерей качества и писать в контейнер, который затем можно будет воспроизводить самописным плейером (ну и в плеере само собой зуммирование, останов, интерактивный маппинг 16 бит на 8, либо на 10 бит если монитор поддерживает и т.д.). Вот как бы вы подошли к решению этой задачки (в той перспективе, что железка PCI скоро заменится на PCIe и скорость возрастёт до 320 MB/s)?
Мы тоже считаем, что это очень интересно, хотя скорость на порядок ниже, чем у обычного JPEG. В настоящее время для 24-битных картинок 4К для кодоблока 32х32 и при сжатии в JPEG2000 в 12 раз получена производительность кодирования 1200 МБайт/с на видеокарте GeForce GTX 1080. По запросу в гугле «jpeg2000 benchmarks gpu» можете найти наши графики и таблицы с более подробной информацией по бенчмаркам. К сожалению, декодер JPEG2000 пока не готов. Для решения задач такого типа у нас есть SDK для CUDA, в котором все упомянутые функции есть, в том числе зум (ресайз), луты для маппинга и пр. Статья как раз про решение на базе этого SDK.
Для решения этой проблемы мы всегда делаем ресайз на CUDA по алгоритму Ланцоша
Можно подробней, в инете сразу начинают грузить: «разреженные матрицы… бла-бла… методы итерирования подпространств»…
Почему от АМД отказались? Там же и единая память Mantle и теперь уже SSD прикрутили и по производительности всё довольно неплохо.
Алгоритм Ланцоша даёт более высокое качество ресайза. Визуально гораздо лучше, чем используемый по умолчанию в OpenGL билинейный алгоритм. Все формулы есть в вики.
Мы не отказывались от AMD, мы работаем с видеокартами NVIDIA. А единая память — это проблема для быстрых приложений, потому что при выходе за пределы памяти GPU получаем сильное падение производительности. Карточки у AMD быстрые. Жаль, что нельзя взять и перенести код из CUDA в OpenCL. Можно лишь заново всё переписать, практически с нуля.
Мы не отказывались от AMD, мы работаем с видеокартами NVIDIA. А единая память — это проблема для быстрых приложений, потому что при выходе за пределы памяти GPU получаем сильное падение производительности. Карточки у AMD быстрые. Жаль, что нельзя взять и перенести код из CUDA в OpenCL. Можно лишь заново всё переписать, практически с нуля.
Подскажите, а слой совместимости пригоден для облегчения этих задач?
https://github.com/GPUOpen-ProfessionalCompute-Tools/HIP
За статью спасибо.
Проблема в том, чтобы не просто код запустить на другом GPU. Основная задача — как это сделать оптимально. Для несложных алгоритмов это может быть просто, а для алгоритмов типа нашего дебайера, вейвлетного шумодава или кодека JPEG это, по всей видимости, невозможно.
Например, у NVIDIA и AMD разные по длине вектора. У NVIDIA это warp и он состоит из 32 элементов, а у AMD это wavefront и он состоит из 64 элементов. Это базовое отличие, которое приводит к серьёзным модификациям алгоритмов. Кроме того есть и другие отличия в микроархитектурах (размер разделяемой памяти, количество регистров и т.д.), поэтому сильно оптимизированные алгоритмы, использующие все особенности архитектуры, просто не смогут работать, так что их придётся сильно модифицировать.
Например, у NVIDIA и AMD разные по длине вектора. У NVIDIA это warp и он состоит из 32 элементов, а у AMD это wavefront и он состоит из 64 элементов. Это базовое отличие, которое приводит к серьёзным модификациям алгоритмов. Кроме того есть и другие отличия в микроархитектурах (размер разделяемой памяти, количество регистров и т.д.), поэтому сильно оптимизированные алгоритмы, использующие все особенности архитектуры, просто не смогут работать, так что их придётся сильно модифицировать.
Спасибо за тесты и за комментарии. Действительно, пока при просмотре из Проводника приходится открывать и закрывать приложение, но это поправим в следующей версии. Для сравнения, насколько мы знаем, ни Премьер, ни Давинчи так работать не могут, а это их большой минус при решении задачи по сортировке и отбраковке снятого материала.
Что касается размещения окон для отдельных модулей, то все они настраиваемые, поэтому можно их разместить разными способами. По умолчанию предлагается наш вариант, но он не является обязательным.
Работа по разработке идёт, через пару месяцев будут новые модули и улучшенный интерфейс. Спасибо за замечания.
Мы рассматриваем возможность поддержки формата MLV из Magic Lantern. Возможно, в этом году это решение уже будет готово.
Про опечатки в написании английских слов пожалуйста напишите сюда или в личку.
Что касается размещения окон для отдельных модулей, то все они настраиваемые, поэтому можно их разместить разными способами. По умолчанию предлагается наш вариант, но он не является обязательным.
Работа по разработке идёт, через пару месяцев будут новые модули и улучшенный интерфейс. Спасибо за замечания.
Мы рассматриваем возможность поддержки формата MLV из Magic Lantern. Возможно, в этом году это решение уже будет готово.
Про опечатки в написании английских слов пожалуйста напишите сюда или в личку.
Это очень круто. Аналоги для просмотра dng есть, но если эта программа станет плагином к премьеру или афтеру, она может стать вполне востребованной. Пока что работать с raw материалами с третьего марка не особо удобно. Если честно, не знаю, как обычно просматривают материалы владельцы Blackmagic, запускают ли резолв каждый раз, когда надо просто проверить материалы.
Дебайер ACR действительно крайне хорош и немного выигрывает у резолва, но для риалтайма приходится прогружать таймлайн, а это весьма долго.
Беглый тест — 120-140 fps на 980 Ti (Full HD cdng 16 bit с третьего марка), жесткий диск HGST HUH728060ALE604, примерно 200 МБ/с на чтение.
Выбитые хайлайтсы становятся розовыми. При снижении white level до 32к этот эффект исчезает. (оказалось, не везде)
Такое раньше было с некоторыми программами для дебайера материалов третьего марка, со временем как-то вылечили.
Возможно, не разобрался, но импорт материалов пока что достаточно неудобный. Если загружать папку через контекстное меню в проводнике, открывается новая версия программы, а не добавляется запись в существующую.
Идеальным был бы вариант drag-n-drop'а папки через проводник напрямую в окно project, чтобы для каждого клипа в рамках одного проекта была отдельная строка.
Добавление всех DNG из папки при создании нового проекта почему-то не сработало.
Не очень понятно, почему вкладки Places и File System разделены, если работают в связке — то, что выбрано в Places, появляется в File System. Причем по умолчанию они были отключены при первом запуске. Возможно, лучше убрать иные, более продвинутые опции обработки или метаданных, а вот их оставить, так как загрузка и просмотр материалов все-таки на первом месте.
Из File System хотелось бы более простой импорт папок с их конвертацией в клипы, как это работает в резолве. Пока что приходится выделять все файлы и добавлять их вручную. Ну и огромное количество отдельных файлов в одной папке крайне неудобно. Так как программа все-таки нацелена на видеофайлы, а не на фото, то нужды в списке отдельных кадров нет. Ну и конечно же система работы с таймлайном в данном случае опять же весьма неудобна, так как все файлы при добавлении, скажем, at end, превращаются в одну большую колбасу, где приходится вручную искать начало и конец каждого файла.
Хотелось бы добавить возможность моментально переместиться в выбранную щелчком мыши область таймлайна, а не просто передвижения playhead в эту сторону.
Попробуйте насытить интерфейс теми решениями, которые облегчают работу с мониторингом материалов. Например, при двойном нажатии левой кнопки мыши на картинку она устанавливается на масштаб в 100%, а при следующем двойном нажатии возвращается на пользовательское значение — часто приходится мониторить реальную картинку на предмет шума или banding. Аналогичное решение есть в программе mocha, только через хоткеи.
Достаточно много опечаток в написании английских слов.
Свяжитесь с ребятами из Magic Lantern, если еще не сделали это, конечно. Они всегда запускают публичные обсуждения и тестирование.
Спасибо!
Дебайер ACR действительно крайне хорош и немного выигрывает у резолва, но для риалтайма приходится прогружать таймлайн, а это весьма долго.
Беглый тест — 120-140 fps на 980 Ti (Full HD cdng 16 bit с третьего марка), жесткий диск HGST HUH728060ALE604, примерно 200 МБ/с на чтение.
Выбитые хайлайтсы становятся розовыми. При снижении white level до 32к этот эффект исчезает. (оказалось, не везде)
Такое раньше было с некоторыми программами для дебайера материалов третьего марка, со временем как-то вылечили.
Возможно, не разобрался, но импорт материалов пока что достаточно неудобный. Если загружать папку через контекстное меню в проводнике, открывается новая версия программы, а не добавляется запись в существующую.
Идеальным был бы вариант drag-n-drop'а папки через проводник напрямую в окно project, чтобы для каждого клипа в рамках одного проекта была отдельная строка.
Добавление всех DNG из папки при создании нового проекта почему-то не сработало.
Не очень понятно, почему вкладки Places и File System разделены, если работают в связке — то, что выбрано в Places, появляется в File System. Причем по умолчанию они были отключены при первом запуске. Возможно, лучше убрать иные, более продвинутые опции обработки или метаданных, а вот их оставить, так как загрузка и просмотр материалов все-таки на первом месте.
Из File System хотелось бы более простой импорт папок с их конвертацией в клипы, как это работает в резолве. Пока что приходится выделять все файлы и добавлять их вручную. Ну и огромное количество отдельных файлов в одной папке крайне неудобно. Так как программа все-таки нацелена на видеофайлы, а не на фото, то нужды в списке отдельных кадров нет. Ну и конечно же система работы с таймлайном в данном случае опять же весьма неудобна, так как все файлы при добавлении, скажем, at end, превращаются в одну большую колбасу, где приходится вручную искать начало и конец каждого файла.
Хотелось бы добавить возможность моментально переместиться в выбранную щелчком мыши область таймлайна, а не просто передвижения playhead в эту сторону.
Попробуйте насытить интерфейс теми решениями, которые облегчают работу с мониторингом материалов. Например, при двойном нажатии левой кнопки мыши на картинку она устанавливается на масштаб в 100%, а при следующем двойном нажатии возвращается на пользовательское значение — часто приходится мониторить реальную картинку на предмет шума или banding. Аналогичное решение есть в программе mocha, только через хоткеи.
Достаточно много опечаток в написании английских слов.
Свяжитесь с ребятами из Magic Lantern, если еще не сделали это, конечно. Они всегда запускают публичные обсуждения и тестирование.
Спасибо!
Здравствуйте, я пока не очень разобрался с этой программой, почему то у меня 4к рав от бм4к 9фпс показывает, как и в давинчи, разницы не заметил.видеокарта у меня gtx 680 4gb, двух процессорный по 2 гб… и описании увидел, что можно делать кроп, я так и не нашел эту функцию… и было бы супер.если бы создали группу вконтакте, там удобнее было бы следить за новостями… спасибо.
Чтобы получить 25 к/с на 4К, нужны быстрые SSD, CPU, GPU. Значение 9 фпс может быть из-за того, что это HDD, хотя скорости карточки 680 можеть не хватать. Пожалуйста попробуйте быстрый SSD, если это возможно. Или пришлите пару кадров DNG, мы посмотрим в чём может быть дело. Функции ресайза и кропа на GPU есть, но они пока не выведены наружу, скоро это будет.
Группа вконтакте есть — vk.com/fastcinemadng
Группа вконтакте есть — vk.com/fastcinemadng
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы сделали конвертер и плеер для CinemaDNG на CUDA