Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Код? Примеры сжатых видео? Скорость сжатия?
А что будет, если люди будут вашим кодеком перекодировать уже сжатые другими кодеками видео (ибо кто видео будет без сжатия хранить чтоб скормить его вашему кодеку)? Там в каждом фрагменте каждого кадра будут шумы после сжатия мелкие или большие (в зависимости от испорченности кадров предыдущим кодеком). Поэтому идеализированное
вроде бы никогда работать не будет. Все фрагменты всех кадров фильма будут разные постоянно.
Да и наверняка все эти фичи «разложим-ка кадр на мелкие изображения или возьмем целиком как изображение, а потом посчитаем разности/превратим изображения в спектры и посчитаем их разности/попляшем с бубном, возведем все в квадрат и извлечем корень пятой степени» уже были проработаны ведущими специалистами/авторами видеокодеков и не подошли:
— в силу идеализированности и несрабатываемости в реальных видео («представим что в кадрах без сглаживания двигается облачко, а все остальное не меняется»),
— в силу медленной скорости обработки (будем назначать индексы разным кускам, сортировать, уплотнять, тасовать, раскладывать в деревья, чайку попьем),
— в силу небольшой выгоды по степени сжатия в условиях потери слишком большого времени на компрессию/декомпрессию.
На сколько превышает. На полпроцента? Или на 20 процентов? Это вот на этом графике оно превышает?
«вместо 48 нулевых разностей в уплотнённой базе будет только одна запись»
вроде бы никогда работать не будет. Все фрагменты всех кадров фильма будут разные постоянно.
Да и наверняка все эти фичи «разложим-ка кадр на мелкие изображения или возьмем целиком как изображение, а потом посчитаем разности/превратим изображения в спектры и посчитаем их разности/попляшем с бубном, возведем все в квадрат и извлечем корень пятой степени» уже были проработаны ведущими специалистами/авторами видеокодеков и не подошли:
— в силу идеализированности и несрабатываемости в реальных видео («представим что в кадрах без сглаживания двигается облачко, а все остальное не меняется»),
— в силу медленной скорости обработки (будем назначать индексы разным кускам, сортировать, уплотнять, тасовать, раскладывать в деревья, чайку попьем),
— в силу небольшой выгоды по степени сжатия в условиях потери слишком большого времени на компрессию/декомпрессию.
При достаточной длительности видеопотока (от 5000 кадров) средний коэффициент сжатия метода фрагментарного сжатия составляет 3,38, что превышает коэффициенты сжатия лучших из рассмотренных методов.
На сколько превышает. На полпроцента? Или на 20 процентов? Это вот на этом графике оно превышает?
Я не спорю, что у метода достаточно узкая область применения, но в той сфере, где он используется (медицинские записи) он показывает большую эффективность. И выигрыш в степени сжатия в несколько процентов на практике превращается в сотни мегабайт, что на установках с ограниченными ресурсами очень важно.
А разве нельзя копить до определенного предела, а потом скидывать на внешний носитель/отправлять по сетке на другой комп и т.д.? Стоит ли овчинка выделки?
На графике высота столбца вашего кодека 307 пикселей, а высота Yuls(Max) 301 пиксель. Получаем, что если ваш кодек жмет 3,38, то Yuls(Max) 3,314.
Выгода в сжатии почти 2 процента (чуть меньше). Т.е. так юзеры-доктора могли сохранить 100 видео, а теперь смогут сохранить на два видео больше. Сомнительная выгода. Как разница между возможностью сохранить 100 или 102 видеоролика (если б у меня, например, был один фотоаппарат с записью 100 фотографий, а второй с записью 102 фотографий — я бы брал любой, один хрен когда останется возможность записать 2 фотки — там уже лучше все скинуть куда нибудь и освободить место, чтоб была возможность снова записать 102 фотки, чем фотографировать оставшиеся две и потом уткнуться в ту же границу).
А если еще и сохранение 102 видео будет занимать в два раза больше времени (т.к. кодек тормозит), то я бы использовал тот который жмет 100, зато быстро.
На графике высота столбца вашего кодека 307 пикселей, а высота Yuls(Max) 301 пиксель. Получаем, что если ваш кодек жмет 3,38, то Yuls(Max) 3,314.
Выгода в сжатии почти 2 процента (чуть меньше). Т.е. так юзеры-доктора могли сохранить 100 видео, а теперь смогут сохранить на два видео больше. Сомнительная выгода. Как разница между возможностью сохранить 100 или 102 видеоролика (если б у меня, например, был один фотоаппарат с записью 100 фотографий, а второй с записью 102 фотографий — я бы брал любой, один хрен когда останется возможность записать 2 фотки — там уже лучше все скинуть куда нибудь и освободить место, чтоб была возможность снова записать 102 фотки, чем фотографировать оставшиеся две и потом уткнуться в ту же границу).
А если еще и сохранение 102 видео будет занимать в два раза больше времени (т.к. кодек тормозит), то я бы использовал тот который жмет 100, зато быстро.
Конечно можно и так поступать. Возможно многие так и делают, но разве это повод не изобретать что-то новое и более эффективное? Кроме того Yuls(Max) использует преобразование цветовых пространств, что привносит ошибки. Если разрешить преобразование цветовых пространств для МФС коэффициент сжатия станет >5, а это уже выигрыш не на 2%, а как минимум на 40%.
В конце разработки хорошо бы привести сравнительные графики и таблицы с коэффициентами сжатия (пока только график в статье), со скоростью обработки, и с коэффициентами сжатия, умноженными на скорость обработки. И по последним из этих графиков тогда будет понятно реально ли описанное является «более эффективным» по сравнению с известными на сегодня методами сжатия видео.
Но статья интересная, спасибо)
Но статья интересная, спасибо)
p.s. имелось ввиду «уже были проработаны ведущими специалистами/авторами видеокодеков и были использованы в существующих кодеках либо не подошли по следующим причинам»
Я даже могу предположить, что это за причина: энтропийные префиксные кодировщики только в теории выглядят красиво, на практике реализовать их весьма тяжело (из-за ошибок с округлением или переполнением), кроме того процесс кодирования условно сводится к поиску соответствующего элемента среди всех листьев дерева и восстановлению траектории по дереву. Если листьев несколько сот миллионов это довольно тяжело.
Основная «фишка» данного метода — использование деревьев секущих, что позволяет строить префиксе деревья и кодировать на их основе почти в реальном времени.
Основная «фишка» данного метода — использование деревьев секущих, что позволяет строить префиксе деревья и кодировать на их основе почти в реальном времени.
Спасибо за статью! Всегда интересно почитать про новые алгоритмы. Я или прочитал невнимательно, или в вашем алгоритме действительно нет компенсации движения? Такого, когда картинка во всем кадре смещается или вращается.
Алгоритм разрабатывался преимущественно для статичных сцен?
Алгоритм разрабатывался преимущественно для статичных сцен?
Занимательная статья, спасибо. Я просмотрел внимательно все графики, но в упор не вижу сравнения с x264. Если я правильно понял выводы, то ваш метод не уступает по степени сжатия лучшим видеокодекам (в lossless mode разумеется). Если это так и вы ничего не упустили из виду, то это очень хорошо. И поменьше слушайте критикующих 2% выгоды. В данной области это достойный результат.
просто если выгода 10-20% — это уже сногсшибательный успех несмотря на скорость запаковки/распаковки (хотя конечно такие цифры это фантастика), а если 2% — то надо посмотреть на скорость: если выгода по скорости жутко отрицательная (к примеру, кодирование идет в 2 раза дольше чем у аналогичных кодеков), а прирост сжатия 2% (который еще надо проверить на большом количестве больших видеофайлов, т.к. врядли гиганты рынка видеокодеков не перепробовали уже по три раза все описанное в статье, тогда это просто ошибка из-за малого количества тестов, или из-за специально подготовленных видеоданных для тестов и т.д.) — то это негативный результат.
Я бы с азартом подискутировал, но пока не вижу доказательства превосходства над x264 хотя бы на 2% даже без учета времени кодирования. Возможно автор забыл протестировать x264 и, следовательно, спорить здесь не о чем.
Исходя из собственного практического опыта, могу сказать, что на сегодняшний день x264 является самым эффективным видеокодеком для большинства видео. Там еще подтягиваются x265 и гугловский vp9, но о существенном превосходстве над x264 речь пока не идет. Поэтому в идеале сравнивать нужно в первую очередь с x264, потом со свежей версией x265, и только тогда говорить об улучшениях.
Исходя из собственного практического опыта, могу сказать, что на сегодняшний день x264 является самым эффективным видеокодеком для большинства видео. Там еще подтягиваются x265 и гугловский vp9, но о существенном превосходстве над x264 речь пока не идет. Поэтому в идеале сравнивать нужно в первую очередь с x264, потом со свежей версией x265, и только тогда говорить об улучшениях.
Если бы сжатие в реалтайме, как HuffYUV например, тянул… Попробуйте скормить кодеку VHS. Интересны результаты.
А на чем писали? Использовали ли AVX/AVX2, или специфика оборудования не позволяет?
В моем случае с RAW переход, например, с чистого C -O3 на AVX позволил сделать альфа-наложение YUVA420P FullHD-картинок (не инвертированных с подготовкой, а исходных, с перемножением обеих на альфу) за 1.5мс вместо 11мс. На AVX2 будет и того быстрее, но пока не тестил. Одно понятно — овчинка стоит выделки.
Соответственно, при ваших скоростях сжатия алгоритм имеет весьма ограниченное применение, но если реально хотя бы в теории ускорить его хотя бы до реалтайм-сжатия 4K@30fps, то тут уже реально говорить о применении в передаче 4K по гигабитному каналу, что несомненно круто с запасом в 20-30%, насколько я помню, когда тестил, ни один из кодеков не справляелся или со скоростью или с каналом.
В моем случае с RAW переход, например, с чистого C -O3 на AVX позволил сделать альфа-наложение YUVA420P FullHD-картинок (не инвертированных с подготовкой, а исходных, с перемножением обеих на альфу) за 1.5мс вместо 11мс. На AVX2 будет и того быстрее, но пока не тестил. Одно понятно — овчинка стоит выделки.
Соответственно, при ваших скоростях сжатия алгоритм имеет весьма ограниченное применение, но если реально хотя бы в теории ускорить его хотя бы до реалтайм-сжатия 4K@30fps, то тут уже реально говорить о применении в передаче 4K по гигабитному каналу, что несомненно круто с запасом в 20-30%, насколько я помню, когда тестил, ни один из кодеков не справляелся или со скоростью или с каналом.
За сколько продали алгоритм? :)
Странный тест.
Зачем сравнивать кодеки 20-летней давности (HuffYuv не обновлялся с 2002-го) с их аналогами (Lagarith), уже понимающими несколько CPU? Сразу надо было и XVId c DivX-ом подтягивать. Особенно в режиме мультиков — там сжатие и за 11 перевалит. Сам лет 10 кодировал (Видеотека была тысяч на 10 фильмов — бросил, все в Инете есть). И В-кадры вспоминать, и перестановку ключевых…
Зачем сравнивать кодеки 20-летней давности (HuffYuv не обновлялся с 2002-го) с их аналогами (Lagarith), уже понимающими несколько CPU? Сразу надо было и XVId c DivX-ом подтягивать. Особенно в режиме мультиков — там сжатие и за 11 перевалит. Сам лет 10 кодировал (Видеотека была тысяч на 10 фильмов — бросил, все в Инете есть). И В-кадры вспоминать, и перестановку ключевых…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Метод фрагментарного сжатия видеопотока