Comments 123
Отличная статья, спасибо! Теперь буду скептичнее относиться к очередному "убийце джипега"
Старине JPEG-у уже 28 лет, стандарт времен бронзового века по компьютерным меркам. Его замена вполне возможна еще со времен JPEG-2000, а сейчас с нейросетями и подавно. Другое дело, что это вряд ли будет стартап с громкими заявлениями )))
Хм… вы же только что писали, что скептически относитесь к нейросетям?
Внимательно следим за руками! )
Эти тезисы не противоречат друг-другу! ) Но они объясняют, почему инвесторы несут хорошие деньги в ИИ-стартапы и почему разных чудес в новостях от них будет в ближайшие годы заведомо много.
- Тезис первый: нейросети фантастически удобны для демонстрации произвольных чудес
- Тезис второй: нейросети реально уже порвали целую пачку лучших алгоритмов прошлых лет (и, судя по всему, еще пачку порвут в ближайшие годы)
Эти тезисы не противоречат друг-другу! ) Но они объясняют, почему инвесторы несут хорошие деньги в ИИ-стартапы и почему разных чудес в новостях от них будет в ближайшие годы заведомо много.
Очень интересно! Простой вопрос: имеет ли смысл кодировать бытовое видео в h.265 и AV1, или могут быть проблемы с совместимостью и «тормозами» при просмотре у заказчика? Кодирую по старинке в h.264 1280x720
AV1 — точно рано. Там разработка в разгаре. HEVC/H.265 — уже вполне, его декодирование уже несколько лет, как акселерируется аппаратно. Как обычно — вопрос кейса, контента, конкретной ситуации.
Жаль только, что как только аппаратную акселерацию добавляют в процессор, кодек вдруг массово перестают использовать (H.264).
Вопрос к политике лицензионных отчислений соответствующего альянса. Рубят сук.
Вроде же стандарт уже есть. В активной разработке кодеры-декодеры, нет?
Да, есть. Торжественно зафиксирована версия битового потока 1.0.0, что дает возможность производителям работать над своими реализациями, но надо отдавать себе отчет, что его делали стахановскими темпами, учитывая количество багов в процессе, они еще остались. И кодеры-декодеры по опыту предыдущих стандартов доводят до ума примерно за 2-3 года. В этот раз сильно помогает открытая реализация и мощная поддержка Google, но сильно мешает более высокая сложность стандарта.
сильно помогает открытая реализация и мощная поддержка Google, но сильно мешает более высокая сложность стандарта.И непонятно, станет ли Intel со своими текущими вопросами внедрять аппаратное декодирование ещё одного (пусть и замечательного) кодека в новые процессоры.
Ранее они не только для декодирования, но и для кодирования аппаратную акселерацию поддерживали. Сейчас 100% работы над этим идут (благо принципиально похожих моментов много), а дальше класть ли все в железо или оставить софтверные оптимизации — станет виднее.
UFO just landed and posted this here
Почему супер? Накладные расходы на передачу данных на GPU реально мешают очень сильно. Сейчас, понятно, супер-медленное сжатие становится популярно, там влияние передачи невелико, но это ускорение только для медленных кейсов.
UFO just landed and posted this here
Что значит дефолтный медленный? )
Новые кодеки не делают специально медленнымичтобы вы покупали новое железо )))). Основная задача — минимум в 1.5 раза (лучше в два) переплюнуть по сжатию прошлый стандарт, иначе новый стандарт будет внедряться с жутким скрипом. Хрестоматийный пример — JPEG-2000, который несмотря на массу плюсов поторопились выпустить к красивой дате и не додавили сжатие в итоге он до сих пор идет в массы, хромая на все четыре лапы…
А дальше идут три процесса:
И дальше скорости этих процессов определяют, выживет стандарт или нет. MPEG-4, например, относительно не повезло.
Новые кодеки не делают специально медленными
А дальше идут три процесса:
- Оптимизация кодека, при которой он начинает жать с той же силой за гораздо меньшее время (большой и сложный процесс)
- Увеличение производительности железа (в последние годы все медленнее)
- И… совершенствование кодеков старых стандартов, ибо они на новом железе и с новыми оптимизациями тоже начинают жать быстрее и лучше.
И дальше скорости этих процессов определяют, выживет стандарт или нет. MPEG-4, например, относительно не повезло.
Действительно, печально что невозможно обновить поддержку аппаратного кодирования/декодирования новых кодеков обновлением микрокода процессора.
А альтернативой тотального апгрейда могли бы стать аппаратные декодеры, но, видимо у индустрии свои заботы.
А альтернативой тотального апгрейда могли бы стать аппаратные декодеры, но, видимо у индустрии свои заботы.
Ну чипмейкеры на новые части новых кодеков часто ругаются по-черному, ибо они на железо ложатся, бывает, плохо. Но… Приходится работать с тем, что есть.
Имеются в виду баги в стандарте? В формате битового потока, или в реализации кодека?
AV1
Вы в курсе, какая там сейчас скорость? :)
из статьи только о кодеке узнал
Спасибо за цитирование нашего графика! )
Нам пришлось релизить часть отчета 2018 года в 2019 году из-за того, что ждали, когда все досчитается на AV1…
Нам пришлось релизить часть отчета 2018 года в 2019 году из-за того, что ждали, когда все досчитается на AV1…
Это уже устаревшие данные. Сейчас енкодинг AV1уже на порядок быстрее, хоть всё равно непрактично долго для большинства «домашних» сценариев.
На мой дилетантский взгляд кажется, что каждый новый кодек требует все больших вычислительных ресурсов. Экстраполируя в будущее, предполагаю, что возможно кодеки будут делать что-то вроде 3д рендеринга. Например, у персонажа есть 5 костюмов. Кодек сохраняет текстуры этих костюмов в начале ролика и далее рендерит их на персонажа при любом освещении, ракурсе и т.д… Требуются огромные ресурсы у клиента, но вероятно сжатие будет очень высоким. Передавать нужно будет только вертексы объектов и натягивать закешированные текстуры.
Если в общем: Подобные идеи были модными еще почти 20 лет назад при разработке расширений MPEG-4. В итоге получился мертворожденный стандарт (большинство расширений стандарта собирают пыль на полках, так никогда и не уйдя в жизнь). Поскольку мощность железа продолжает расти, попытки ее эффективно задействовать конечно будут, вопрос успешности.
Если конкретно: вы говорите про free view rendering, это большая активно развивающаяся область, но там в общем случае до успеха еще довольно далеко. Хотя для узких спортивных кейсов ее скоро порешают. Забавно, что в MPEG-4 было расширение с поддержкой DIBR (Depth Image-Based Rendering) — эффективное сжатие вольюметрических моделей, 20 лет спустя можно смело прогнозировать ренессанс темы.
Если конкретно: вы говорите про free view rendering, это большая активно развивающаяся область, но там в общем случае до успеха еще довольно далеко. Хотя для узких спортивных кейсов ее скоро порешают. Забавно, что в MPEG-4 было расширение с поддержкой DIBR (Depth Image-Based Rendering) — эффективное сжатие вольюметрических моделей, 20 лет спустя можно смело прогнозировать ренессанс темы.
Если уж речь зашла о ренессансе и экстраполяции видео, здесь просто обязана быть
эта картинка
Блин, вот у меня есть совершенно потребительский вопрос, у меня есть архив видео, снятый разными камерами, старой видеокамерой Sony, Canon 60D, зоопарком телефонов, иногда в слоумо. Я хочу всё пережать и привести в один стандарт. И я ничерта не понимаю какой битрейт мне нужен. И мне условно пофиг сколько времени на пережатие уйдёт, i7 на пару месяцев могу выделить. Но битрейт нужен разный под разные видео. Есть ли инструмент в котором можно было-бы выбрать абстрактное качество видео, и пусть он пережуёт всё что надо? Я знаю про двупроходное кодирование, но оно всё-равно имеет целью заданный средний битрейт, вот его не понятно как выбрать.
1. Вам нужен не фиксированный битрейт, а фиксированное качество (модный сейчас constant quality), чтобы даже если сцена с сильным движением — она все равно смотрелась хорошо. Это отдельная тема сейчас, более сложная чем старое фиксированное квантование.
2. Да, вам нужен конкретный всеядный продукт, тут я не слежу за новинками, увы. Но люди подсказать могут, надеюсь )
2. Да, вам нужен конкретный всеядный продукт, тут я не слежу за новинками, увы. Но люди подсказать могут, надеюсь )
Из бесплатного, всеядного (по заявлениям разработчиков) с опцией constant quality вспоминается HandBrake
Вопрос в цели.
Хотите просматривать любое видео из зоопарка однотипно — смотрите с компьютера, используя, например VLC media player. Он справляется почти с любыми комбинациями контейнеров/кодеков. Ничего не нужно пережимать, качество не ухудшится, простодобавляйте меняйте накопители на более ёмкие, ну и какая-нибудь программа-каталогизатор понадобится, чтобы не заблудиться в зоопарке.
Хотите избавиться от наследуемых форматов пережав всё и выбросив все исходники?
Жмите в сторону лучшего устройства, т.е. Canon'а. Да, у смартфона может быть выше разрешение, но более шумная матрица и оптика попроще. Full-HD на 40" смотрится всё еще пристойно.
Лучше всё-таки не пережимать — потери будут всегда, а экономия пространства после пережатия быстро съестся очередным гаджетом с 100500 мегапиксельной камерой с очередным модным кодеком.
Хотите просматривать любое видео из зоопарка однотипно — смотрите с компьютера, используя, например VLC media player. Он справляется почти с любыми комбинациями контейнеров/кодеков. Ничего не нужно пережимать, качество не ухудшится, просто
Хотите избавиться от наследуемых форматов пережав всё и выбросив все исходники?
Жмите в сторону лучшего устройства, т.е. Canon'а. Да, у смартфона может быть выше разрешение, но более шумная матрица и оптика попроще. Full-HD на 40" смотрится всё еще пристойно.
Лучше всё-таки не пережимать — потери будут всегда, а экономия пространства после пережатия быстро съестся очередным гаджетом с 100500 мегапиксельной камерой с очередным модным кодеком.
Некоторые камеры (особенно старые) по умолчанию генерируют фактически MotionJPEG поток. Оно может быть не в этом стандарте, но внутри поток из одних I-frames. Такие потоки можно пережимать практически без потерь качества с экономией раз в 10.
Если поток хотя бы H.264, то много наиграть не получится, а потери качества точно будут, это правда.
Если поток хотя бы H.264, то много наиграть не получится, а потери качества точно будут, это правда.
Ещё можно без перекодирования видеопотока перебросить в другой контейнер, например, тот же MotionJPEG из .mov в .mkv или в .avi (убавится хотя бы зоопарка расширений, да и медиаплеерам файл станет понятнее). Звук при этом можно сжать, иногда получив заметную экономию.
Еще хочется добавить, что Motion JPEG имеет одно редкое и полезное свойство — его кадры можно обрезать (кропать) без потерь, ну то есть как обычный жпег — по сетке 8 (или 16?) пикселей.
Пример использования — какие-нибудь записи с камер, где много «мертвого» пространства, а еще «перекодирование» какого-нибудь сверхширокого формата в обычный 16:9, а то и 4:3, чтобы справлялось старое железо и картинка без полей была.
Вполне возможно, какой-то более редкий лосслесс кодек тоже это умеет, но я исходил из того, что умел FFMpeg на тот момент. :)
Пример использования — какие-нибудь записи с камер, где много «мертвого» пространства, а еще «перекодирование» какого-нибудь сверхширокого формата в обычный 16:9, а то и 4:3, чтобы справлялось старое железо и картинка без полей была.
Вполне возможно, какой-то более редкий лосслесс кодек тоже это умеет, но я исходил из того, что умел FFMpeg на тот момент. :)
кадры можно обрезать (кропать) без потерь, ну то есть как обычный жпег — по сетке 8 (или 16?) пикселейЕсть такое свойство ).
Сетка зависит от режима прореживания цветовых компонент, все что не 4:4:4 (4:2:0 или 4:2:2 например — можно посмотреть в свойствах файла) — это сетка из 16х16 пикселей. 4:4:4 — это 8x8.
О, спасибо за ликбез. :) И вообще спасибо за сайт, программы сравнения кодеков (хотя не все заработали, уже не помню почему) и проделанную работу — здорово помогло, когда изучал актуальные кодеки и параметры, чтобы выбрать какой-то для конечного формата перекодировки с камеры. Да и для общего развития интересно было почитать. :)
Мне попалось видео со старой камеры. Размытое, но 720p, и формат WMV. Пережал его, уменьшив до 480р, в результате файл уменьшился с 1.2 Гб до 90Мб, а видимой разницы никакой. А у кого-то таких файлов могут быть залежи.
Ужас MJPEG в AVI компенсируется тем, что там разрешение 320x240 и frame_rate в районе 15 :-)
Тоже все хотел пережать архив, и так и добрался, и хорошо, потому что сейчас весь его размер – это пара видюшек с gopro.
Тоже все хотел пережать архив, и так и добрался, и хорошо, потому что сейчас весь его размер – это пара видюшек с gopro.
В большинстве случаев перекодирование не добавит качества. Сжатие с потерями, на то и сжатие с потерями.
Любое, повторю, ЛЮБОЕ пережатие между форматами с потерями ведет к деградации качества.
Чем больше итераций пережатия будет, тем хуже будет качество материала.
Более того, по своей сути сжатие с потерями так или иначе основана на выделении значимых и не значимых кусков исходного материала, при этом незначимые куски откидываются или сильно деградируют.
Большая часть преймущества современных кодеков — имено в наилучшем выборе таких кусков, которые можно сильно деградировать/отбросить.
Если же мы на вход подаем материал уже деградированый другим кодеком, то эта эффективность стремительно теряется. Более того, она вносит дополнительную деградацию в те куски которые после первой стадии сжатия оставались «хорошими».
Как результат пережатое видео лучше вообще не пережимать без сильной аргументации на это.
Чтобы смотреть все подряд — лучше использовать кодек паки или всеядные просмотрщики, так хоть что то будет видно на записи снятой старым телефоном :)
По процессору отдельная тема. На рядовом i7 пережатие видео в новомодные форматы может производиться со скоростью, к примеру, 1-2 кадра в секунду (при всех максимальных настройках). А это значит, что ролик в 10 минут, будет пережиматься около 4 часов. Так что при наличии архива записей пары месяцев может не хватить :)
Чем больше итераций пережатия будет, тем хуже будет качество материала.
Более того, по своей сути сжатие с потерями так или иначе основана на выделении значимых и не значимых кусков исходного материала, при этом незначимые куски откидываются или сильно деградируют.
Большая часть преймущества современных кодеков — имено в наилучшем выборе таких кусков, которые можно сильно деградировать/отбросить.
Если же мы на вход подаем материал уже деградированый другим кодеком, то эта эффективность стремительно теряется. Более того, она вносит дополнительную деградацию в те куски которые после первой стадии сжатия оставались «хорошими».
Как результат пережатое видео лучше вообще не пережимать без сильной аргументации на это.
Чтобы смотреть все подряд — лучше использовать кодек паки или всеядные просмотрщики, так хоть что то будет видно на записи снятой старым телефоном :)
По процессору отдельная тема. На рядовом i7 пережатие видео в новомодные форматы может производиться со скоростью, к примеру, 1-2 кадра в секунду (при всех максимальных настройках). А это значит, что ролик в 10 минут, будет пережиматься около 4 часов. Так что при наличии архива записей пары месяцев может не хватить :)
Чтобы смотреть все подряд — лучше использовать кодек паки или всеядные просмотрщикиГолосую за второе. Установка кодек-паков (особенно нескольких, «для верности») чревата наличием в системе нескольких кодеков, условно подходящих для воспроизведения контента. Причём выбран будет не обязательно лучший и не всегда с оптимальными настройками.
Ещё бывает, заканчивается триальный период какого-нибудь платного кодека, но пользователь не получает сообщения об этом или не может понять его смысла.
В итоге, может перестать воспроизводиться определённый тип видеофайлов.
Любое, повторю, ЛЮБОЕ пережатие между форматами с потерями ведет к деградации качества.С оговоркой на MotionJPEG и форматы сжатия с поддержкой режимов сжатия без потерь.
Чем больше итераций пережатия будет, тем хуже будет качество материала.И тоже с оговоркой. Мы в свое время проводили эксперименты с многократным пережатием. Там есть тоже свои нюансы, ибо можно сжимать так, чтобы качество при пережатии почти не деградировало. Это свойство алгоритмов сжатия актуально при редактировании видеоматериала, когда хотелось бы держать материал сжатым, но минимально терять качество при итерациях редактирования. Минимизировать потери возможно, если об этом заботиться.
А в целом — да, лучше пережимать пореже ), согласен совершенно.
Скажу больше — если вообще не пережитьмать, то лет через 20 можно будет с большой вероятностью успешно увеличить разрешение материала (например, сделать HD из старой SD записи). При этом даже одна итерация пережатия кардинально снижает успех этого мероприятия.
То что это применимо только для алгоритмов с потерями я как раз и написал :)
При пережатии другим кодеком с потерями качество будет всегда деградировать, т.к. происходит выполнение следующей последовательности:
1) Оригинальное изображение
2) Деградация качества для оптимальной работы кодека (например блочность, или разнесение на слои)
3) При декодировании фильтры воспроизведения «додумывают» картинку, чтобы избавиться от артефактов
4) Это «придуманное» изображение деградирует для оптимальной работы нового кодека (а если установлен режим Constant Quality, то и для такого-же кодека как и в пункте 2 будут выбираться другие зоны для деградации)
5) При воспроизведении декодер опять «додумывает» изображение.
Т.е. чем больше таких итераций, тем больше циклов деградации и «додумывания» (восстановления) будет. А значит оригинальной информации будет все меньше и меньше.
При пережатии другим кодеком с потерями качество будет всегда деградировать, т.к. происходит выполнение следующей последовательности:
1) Оригинальное изображение
2) Деградация качества для оптимальной работы кодека (например блочность, или разнесение на слои)
3) При декодировании фильтры воспроизведения «додумывают» картинку, чтобы избавиться от артефактов
4) Это «придуманное» изображение деградирует для оптимальной работы нового кодека (а если установлен режим Constant Quality, то и для такого-же кодека как и в пункте 2 будут выбираться другие зоны для деградации)
5) При воспроизведении декодер опять «додумывает» изображение.
Т.е. чем больше таких итераций, тем больше циклов деградации и «додумывания» (восстановления) будет. А значит оригинальной информации будет все меньше и меньше.
На практике там скучные математические преобразования, а не «додумывание» )
В итоге есть варианты, при которых при определенном устройстве декодера и энкодера возможно в точности «попадать» в старые коэффициенты и всегда одинаково сжимать кусок, если он не изменялся. Да, при этом этом придется отключить часть модных фич, но это возможно.
Тема слабо востребована, но она реализуема в рамках текущих стандартов.
В итоге есть варианты, при которых при определенном устройстве декодера и энкодера возможно в точности «попадать» в старые коэффициенты и всегда одинаково сжимать кусок, если он не изменялся. Да, при этом этом придется отключить часть модных фич, но это возможно.
Тема слабо востребована, но она реализуема в рамках текущих стандартов.
UFO just landed and posted this here
И даже для MotionJPEG есть. А так — не встречал.
Повторюсь — мал спрос. По факту народ мало парится по поводу потерь, которые не видно на глаз. А то бы давно сделали)
Повторюсь — мал спрос. По факту народ мало парится по поводу потерь, которые не видно на глаз. А то бы давно сделали)
Если говорить о «без потерь», то был кодек Huffyuv/Lagarith — что-то вроде сжатия архиватором каждого кадра ru.wikipedia.org/wiki/Huffyuv
Я для схожих нужд состряпал вот такой bash-скрипт для ffmpeg github.com/pust0ta/batch-video-converter
его просто можно запустить в директории с исходными файлами и тогда он переконвертирует все файлы с расширениями из списка (кроме mkv) в HEVC с crf 25 — на мой взгляд получается замечательно. Результирующие файлы будут в контейнере «Матрёшка» (.mkv), он был выбран, помимо прочего, потому, что файл можно просматривать в процессе записи.
его просто можно запустить в директории с исходными файлами и тогда он переконвертирует все файлы с расширениями из списка (кроме mkv) в HEVC с crf 25 — на мой взгляд получается замечательно. Результирующие файлы будут в контейнере «Матрёшка» (.mkv), он был выбран, помимо прочего, потому, что файл можно просматривать в процессе записи.
К сожалению, такой подход (подлога) встречается довольно часто. Работал в одном полу-государственном НИИ, где все достижения на полном серьёзе именно так и презентовались. При этом дополнительно делалась ставка на максимальный охват — как можно больше публикаций, выступлений на конференциях, патентов. Причём, судя по тем же конференциям, такой подход вообще довольно популярен (по крайней мере в России).
Печаль.
Могу сказать две вещи:
1. Сильно не везде в России так, довольно много мест, где реально все еще делом занимаются даже в госконторах.
2. В Китае ситуация с фейковыми публикациями (особенно внутри) хуже чем у нас на порядок (если не сильнее). У нас, как ни странно, по крайней мере технические направления держатся.
Могу сказать две вещи:
1. Сильно не везде в России так, довольно много мест, где реально все еще делом занимаются даже в госконторах.
2. В Китае ситуация с фейковыми публикациями (особенно внутри) хуже чем у нас на порядок (если не сильнее). У нас, как ни странно, по крайней мере технические направления держатся.
2. Зато в Китае уже есть система социального кредита.
НИИ ССК — это звучит гордо.
НИИ ССК — это звучит гордо.
2 недели назад был в Пекине в Запретном городе. Такого количества нахальных самоуверенных громко говорящих колхозников, сколько на посещении Запретного города, я не видел никогда в жизни. Это толпы людей с одной извилиной (интеллект на лице не просматривается вообще), которых срочно надо как-то вводить в какие-то рамки. Коллега ехал на высокоскоростном поезде, был в шоке. Через 2 часа пол был весь в обертках от еды и т.д. Под конец поездки был натуральный свинарник, где все эти люди чувствовали себя крайне комфортно. И это все на скорости 300 км/ч в интерьерах из будущего. Не уверен, что социальный кредит их спасет, но они явно пытаются хоть что-то сделать ) Учитывая скорость роботизации Китая и скорость роста зарплат — это сверхнеобходимость. Возможно запоздавшая )))
Да, тут скорее в консерватории что-то подправить надо…
Никогда не был в Пекине. Видимо, и не поеду туда теперь. В других местах Китая (Чунцин, Чэнду, Ханчжоу, Циндао) было очень чисто и приятно находиться. Но это ещё и особенность Китая: не там чисто, где не мусорят, а там, где постоянно ходит дворник и тут же подбирает мусор.
ошибся веткой.
Существуют ли плееры, позволяющие проигрывать одновременно два видео и имеющий «шторку» посередине, чтобы мышкой перетягивать влево-вправо и сравнивать эти видео?
Примерно похож редактор VirtualDub2, два окна, в одном исходник, в другом после обработки на лету
Могу сильно наврать (давно дело было), но мне кажется, у автора статьи на сайте были как раз такие проги или плагины для плееров, которые позволяли еще и визуально посмотреть различия тестируемого материала :)
Каюсь, есть такое )))
Где он находится на вашем сайте?
тут, в статье в последнем разделе была ссылка
beamr.com/h264-hevc-video-comparison-player
off Пару недель назад развлекался сжиманием в HandBrake файла в DV. У меня этот DV-файл с видеокамеры давно лежит, пережив несколько ПК и HDD, и своего рода образец для измерения производительности ПК при кодировании видеокодеками в менее объемные файлы.
Причина экспериментов с HandBrake — попалась на глаза на хабре статья от Intel о QuickSync Encoder. Действительно кодирует быстро, но если важно оригинальное качество, то лучше оставить в DV. x264 хоть с ускорением, хоть без, хоть с огромным битрейтом — артефакты сжатия оригинала можно найти.
Причина экспериментов с HandBrake — попалась на глаза на хабре статья от Intel о QuickSync Encoder. Действительно кодирует быстро, но если важно оригинальное качество, то лучше оставить в DV. x264 хоть с ускорением, хоть без, хоть с огромным битрейтом — артефакты сжатия оригинала можно найти.
Как я понимаю работу кодеков.
Каждый кадр бьётся на блоки, и эти блоки (максимально похожие на них) ищутся в предыдущих (примерно 5, но можно и 16) кадрах радиально-недалеко (в 8 разных направлениях, но бывает и в 32) к текущему блоку. Блоки примерно от 4х4 до 64х64 пикселя. Блоки копируются (без афинных преобразований) как есть. Получившаяся разница кодируется дополнительно позже.
Вопрос!
Львиная доля видео в мире, это видео движущейся примерно вперёд камеры. Видеорегистраторы, квадрокоптеры, экшен-камеры. Где очередной кадр сильно похож на предыдущий, только «растянутый» слегка, а также на следующий кадр, только «растянутый» в обратном направлении. Интуитивно кажется, что применив здесь специализированнй подход — чтобы вся серия кадров строилась на однообразном простейшем преобразовании. Щепотки бит буквально достаточно для описания однообразного преобразования. Дополнительная разница с реальным кадром аналогично будет кодироваться позже.
Реализовано ли такое где-то сейчас? Или разница между растянутым кадром и кадром с камеры, сдвинутой в пространстве, слишком велика и потребует сравнимого количества бит и поэтому такой подход не используется?
Каждый кадр бьётся на блоки, и эти блоки (максимально похожие на них) ищутся в предыдущих (примерно 5, но можно и 16) кадрах радиально-недалеко (в 8 разных направлениях, но бывает и в 32) к текущему блоку. Блоки примерно от 4х4 до 64х64 пикселя. Блоки копируются (без афинных преобразований) как есть. Получившаяся разница кодируется дополнительно позже.
Вопрос!
Львиная доля видео в мире, это видео движущейся примерно вперёд камеры. Видеорегистраторы, квадрокоптеры, экшен-камеры. Где очередной кадр сильно похож на предыдущий, только «растянутый» слегка, а также на следующий кадр, только «растянутый» в обратном направлении. Интуитивно кажется, что применив здесь специализированнй подход — чтобы вся серия кадров строилась на однообразном простейшем преобразовании. Щепотки бит буквально достаточно для описания однообразного преобразования. Дополнительная разница с реальным кадром аналогично будет кодироваться позже.
Реализовано ли такое где-то сейчас? Или разница между растянутым кадром и кадром с камеры, сдвинутой в пространстве, слишком велика и потребует сравнимого количества бит и поэтому такой подход не используется?
Идея старая. И нерабочая. Глобальное преобразование на практике была попытка применить к кадру еще в расширениях MPEG-4 (которые благополучно умерли).
По факту:
Во-первых, все ощутимо сложнее. Например, есть B-frames, которые и повышают сжатие, и важны, когда идет навигация по файлу (и в которые вектора как с прошлых, так и с будущих кадров).
Во-вторых, если картинка резкая, а не замыленная, то важны субпиксельные сдвиги. И нам важен блок, максимально похожий, например, с четвертьпиксельной точностью. Они находятся и это работает. Это сразу убивает вашу идею.
И, в-третьих, арифметическое сжатие очень эффективно (в доли бита) сжимает вектора, если у вас они смотрят в одну сторону. Т.е. панорамирование (дрон поворачивает) обходится на самом деле достаточно дешево. По крайней мере экономия на более точной компенсации позволяет намного больше потратить на вектора, там нет смысла какой-то один большой вектор сохранять.
Как-то так, если кратко.
По факту:
Во-первых, все ощутимо сложнее. Например, есть B-frames, которые и повышают сжатие, и важны, когда идет навигация по файлу (и в которые вектора как с прошлых, так и с будущих кадров).
Во-вторых, если картинка резкая, а не замыленная, то важны субпиксельные сдвиги. И нам важен блок, максимально похожий, например, с четвертьпиксельной точностью. Они находятся и это работает. Это сразу убивает вашу идею.
И, в-третьих, арифметическое сжатие очень эффективно (в доли бита) сжимает вектора, если у вас они смотрят в одну сторону. Т.е. панорамирование (дрон поворачивает) обходится на самом деле достаточно дешево. По крайней мере экономия на более точной компенсации позволяет намного больше потратить на вектора, там нет смысла какой-то один большой вектор сохранять.
Как-то так, если кратко.
Да, жаль. Стало быть, архив видео с квадрокоптера на 1.44" дискете не получится разместить)
И тонкая настройка x264/x265 тоже наврядли лучше placebo (у них же) справится с такими видео?
И тонкая настройка x264/x265 тоже наврядли лучше placebo (у них же) справится с такими видео?
И тонкая настройка x264/x265 тоже наврядли лучше placebo (у них же) справится с такими видео?Может и лучше.
Пример был в статье:
На этом видео звезды так легли, что можно сжать в разы быстрее placebo, причем примерно на треть сильнее при этом. Представление, что placebo обеспечивает максимально возможное сжатие (оно же так долго работает!) — это популярный миф.
На всякий случай спрошу, нет ли у вас готового ответа, на вопрос, какие настройки нужно подкрутить, чтобы квадрокпотерное видео (FHD и 4K) кодировалось быстрее и качественнее (кодеки x264 и x265)? Как на вашей картинке, например)
Пробовал плацебо на x265 @ FHD — просто невозможно использовать, на 8+8 ядерном компе фпс сильно меньше 1 получался. Кодирую в Constant Quality, CRF=22 чтоли ставил.
Пробовал плацебо на x265 @ FHD — просто невозможно использовать, на 8+8 ядерном компе фпс сильно меньше 1 получался. Кодирую в Constant Quality, CRF=22 чтоли ставил.
попробуйте Intel Quick Sync habr.com/ru/company/intel/blog/311320
Только проверьте качество результата.
Только проверьте качество результата.
На всякий случай спрошу, нет ли у вас готового ответа, на вопрос, какие настройки нужно подкрутить, чтобы квадрокпотерное видео (FHD и 4K) кодировалось быстрее и качественнее (кодеки x264 и x265)? Как на вашей картинке, например)Если бы был какой-то один волшебный пресет — его бы уже прошили в стандартные, т.е. на этот вопрос нет простого ответа.
Вообще возможно стоит на эту тему отдельный пост. Разобрать мифы, обозначить возможности, разобрать сложности. Стоит писать?
Да, было бы очень круто, а то смотришь на эту груду параметров — многие каракули там ни о чём не говорят.
Многие параметры коммерческих кодеков даже нам ничего не говорят (настолько абстрактно их описание в документации)))), а мы параметры кодеков профессионально вертим уже без малого 20 лет.
К счастью, это не означает, что их нельзя подобрать и улучшить )
Но там масса сложностей, начиная с чисто вычислительной, увы…
К счастью, это не означает, что их нельзя подобрать и улучшить )
Но там масса сложностей, начиная с чисто вычислительной, увы…
Реализовано ли такое где-то сейчас?
В драфте VVC есть "affine motion compensation": https://jvet.hhi.fraunhofer.de/
Работает ооочень медленно (енкодер)
На сценах c вращением типа "In to tree" из стандартных тестовых последовательностей
рвет в тряпки все классические блочные кодеры (прирост порядка +40% по BD-Rate)
Посмотрел, кросс-чек Роман Черняк из русского Хуавей (а ранее — из Элекарда) делал, т.е. можно спросить, как оно вблизи и на разных видео выглядит. Ибо с ходу я что-то хорошего анализа что там не нашел. Кстати, предсказание остается блочным. И если я правильно распарсил
www.researchgate.net/publication/328438797_An_Improved_Framework_of_Affine_Motion_Compensation_in_Video_Coding основной выигрыш таки за засчет субпиксельных сдвигов, однако теперь при поворотах )
Вообще ранее от такого подхода отказались, поскольку он был неэффективен по соотношению затраченное время/результат. Посмотрим, что будет в этот раз. У них AV1 появился в сильных компетиторах. Спасибо за наводку!
www.researchgate.net/publication/328438797_An_Improved_Framework_of_Affine_Motion_Compensation_in_Video_Coding основной выигрыш таки за засчет субпиксельных сдвигов, однако теперь при поворотах )
Вообще ранее от такого подхода отказались, поскольку он был неэффективен по соотношению затраченное время/результат. Посмотрим, что будет в этот раз. У них AV1 появился в сильных компетиторах. Спасибо за наводку!
Поправка — сцена с движением "blue_sky" https://media.xiph.org/video/derf/
PS: Я делал бенчмарки когда он был еще JEM'ом, но идея вроде как сохранилась
Про это ещё есть блестящая старая статья Dark Shikari (одного из разработчиков x264 и эксперта по видеокодекам): «How to cheat on video encoder comparisons». Там прямо по косточкам разложено всё.
(Ссылка на archive.fo потому что блог, увы, удалён. Вот тут есть сделанная кем-то копия текста, но там убилось форматирование.)
(Ссылка на archive.fo потому что блог, увы, удалён. Вот тут есть сделанная кем-то копия текста, но там убилось форматирование.)
Да, это отличный текст про следующие (менее увлекательные) уровни читинга при сравнении кодеков. И обратите внимание, как он жестко пишет о том, как компании себя измеряют ) (часто внаглую некорректно измеряя конкурента).
Шикари нам массу предложений по изменению сравнения выкатил, мы многие реализовали. Интересно, что в целом это сделало сравнения совершенно непригодными для широкой публики (слишком много графиков), но профессионалы рады — картина (кто где реально лучше, кто где хуже) яснее.
Шикари нам массу предложений по изменению сравнения выкатил, мы многие реализовали. Интересно, что в целом это сделало сравнения совершенно непригодными для широкой публики (слишком много графиков), но профессионалы рады — картина (кто где реально лучше, кто где хуже) яснее.
3DVideo, может, не совсем подходящая тема для вопроса, но какой кодек использовать для скринкастов?
10 лет назад я писал скринкасты в Microsoft Video 1, в RGB555. 10 минут видео занимало 200-250 мегабайт, но ужималось компрессором до 1.5-2 мегабайт(!). Качество видео было постоянно высоким, и всё выглядело отлично, в т.ч. из-за отсутствия субдискретизации цвета.
Аналогичное видео в VP9 или H.264 получается раза в 3-6 больше по размеру.
Есть ли какой-то рекомендуемый кодек для скринкастов?
10 лет назад я писал скринкасты в Microsoft Video 1, в RGB555. 10 минут видео занимало 200-250 мегабайт, но ужималось компрессором до 1.5-2 мегабайт(!). Качество видео было постоянно высоким, и всё выглядело отлично, в т.ч. из-за отсутствия субдискретизации цвета.
Аналогичное видео в VP9 или H.264 получается раза в 3-6 больше по размеру.
Есть ли какой-то рекомендуемый кодек для скринкастов?
Скринкаст скринкасту рознь. Тьюториал по статическому интерфейсу — одно, прохождение игры-шутера — совсем другое. На этот вопрос нет простого ответа.
Вообще думаем про отдельный пост с разбором оптимизации параметров под контент. Разобрать сложности, обозначить сколько можно наиграть, почему это сложно, как можно действовать на практике и т.д.
Стоит писать? Какие вопросы были бы интересны?
Вообще думаем про отдельный пост с разбором оптимизации параметров под контент. Разобрать сложности, обозначить сколько можно наиграть, почему это сложно, как можно действовать на практике и т.д.
Стоит писать? Какие вопросы были бы интересны?
Страдал точно такой же фигней, как и товарищ выше. :) И тоже остановился на каком-то кодеке, который потом винраром сжимался адски и вызывал поначалу этим легкий шок. :)
Да, писать однозначно стоит, хотя бы ради вопроса качественных гуи-скринкастов, с динамичной картинкой-то в принципе все те же приемы, что и с живым видео.
Просматривается некая аналогия с жпег против пнг, кстати. :)
Да, писать однозначно стоит, хотя бы ради вопроса качественных гуи-скринкастов, с динамичной картинкой-то в принципе все те же приемы, что и с живым видео.
Просматривается некая аналогия с жпег против пнг, кстати. :)
тоже остановился на каком-то кодеке, который потом винраром сжимался адскиУжас какой… Где вы такие берете…
Да, писать однозначно стоит, хотя бы ради вопроса качественных гуи-скринкастов,Принято. Еще вопросы в теме, которые интересны, приветствуются.
Ну где-где… тут вариантов только два: либо это был встроенный в Камтазию кодек, либо один из тех, что идут в мегакодекпаке :)
Что еще было круто, так это возможность установить всего 1 кадр в 30 секунд для предельной экономии места (записывал какую-то динамическую страницу).
Во, вопрос кстати вспомнился в связи со скринкастами: примерно в то же время я нашел какую-то мелкую программу, которая писала скринкасты в файл формата флэша (ну почти как все), но — сжатие, в отличие от других, достигалось невероятное (заметнее всего — на почти статических моментах), и у меня вопрос частично по формату (программу ту я посеял и не смог найти снова с тех пор, о чем жалел не раз) — возможно ли, что та прога делала не просто сжатие картинки, а сперва анализировала геометрию оконного менеджера и, грубо говоря, записывала не тупо покадрово, а делала смещение прямоугольников при движении окон и других объектов по экрану и писала не просто видеопоток, а еще и описания всего? Ну почти как кодеки анализируют предыдущий и следующий кадр для лучшего сжатия. Ведь технически это не должно вызывать большие трудности, верно? :)
Что еще было круто, так это возможность установить всего 1 кадр в 30 секунд для предельной экономии места (записывал какую-то динамическую страницу).
Во, вопрос кстати вспомнился в связи со скринкастами: примерно в то же время я нашел какую-то мелкую программу, которая писала скринкасты в файл формата флэша (ну почти как все), но — сжатие, в отличие от других, достигалось невероятное (заметнее всего — на почти статических моментах), и у меня вопрос частично по формату (программу ту я посеял и не смог найти снова с тех пор, о чем жалел не раз) — возможно ли, что та прога делала не просто сжатие картинки, а сперва анализировала геометрию оконного менеджера и, грубо говоря, записывала не тупо покадрово, а делала смещение прямоугольников при движении окон и других объектов по экрану и писала не просто видеопоток, а еще и описания всего? Ну почти как кодеки анализируют предыдущий и следующий кадр для лучшего сжатия. Ведь технически это не должно вызывать большие трудности, верно? :)
Ведь технически это не должно вызывать большие трудности, верно? :)Если с конца начинать, то имейте ввиду, что обычно ответ на этот вопрос «нет» ))), особенно если легкие решения на каждом углу не лежат. Очень часто простые в постановке задачи сложно решаются.
По поводу сжатия такого контента — есть даже отдельное направление — Screen Capture Codec, коих кодеков было создано довольно много (в том числе мы делали). И софта подобного тоже очень много. Там несколько параметров — и собственно их баланс и тюнингуется. Это если кратко. Если подробно — можно большой пост только про алгоритмическую часть написать.
Анализировать геометрию уже отрисованных примитивов накладно (всякие градиенты, тени, субпиксельные эффекты). Но никто не мешает перехватывать все вызовы GUI, записывать их часть, соответствующую изменениям в зоне интереса, паковать, а при воспроизведении передавать обратно GUI для отрисовки. Плотность будет максимально возможная, нагрузка на cpu/gpu околонулевая, потребление памяти минимальное.
Под Windows это довольно затруднительно, но есть ReactOS, Kolibri.
Также существовали векторные дисплеи, отрисовывавшие вызовы аппаратно. Даже сейчас в драйверах устройств отображения под Windows есть набор флагов, соответствующих наличию реализации различных векторных функций. Если бы развитие подобных дисплеев продолжилось, офисный дисплей можно было бы подключать через com порт, а не hdmi. И, вероятно, офисный компьютер мог бы питаться от солнечной батареи, как калькулятор.
Речь, конечно, только о графическом интерфейсе, офисные приложения без 3d и видео котиков в 4k.
Под Windows это довольно затруднительно, но есть ReactOS, Kolibri.
Также существовали векторные дисплеи, отрисовывавшие вызовы аппаратно. Даже сейчас в драйверах устройств отображения под Windows есть набор флагов, соответствующих наличию реализации различных векторных функций. Если бы развитие подобных дисплеев продолжилось, офисный дисплей можно было бы подключать через com порт, а не hdmi. И, вероятно, офисный компьютер мог бы питаться от солнечной батареи, как калькулятор.
Речь, конечно, только о графическом интерфейсе, офисные приложения без 3d и видео котиков в 4k.
Инвесторов научили биологии, отучив от элексиров бессмертия, научили химии, отучив от философского камня, научили физике, отучив от вечных двигателей. Теперь вот учат информатике (теории информации), отучая от магии нейросетей. Нейросети оказались скучными статистическими алгоритмами для работы с данными, а не волшебной палочкой, рождающей байты из пустоты. Когда же нам уже разрешат инвестировать во что-нибудь нормальное? Телепортацию когда подвезут?
У вас хорошие поэтические аналогии! )
Впрочем — судя по тому, что ежегодно успешно патентуется несколько идей вечных двигателей, отучили не всех. Да и в биологии ситуация не волшебна. Впрочем в нейросетях кратно хуже ))) Человеку свойственно верить в чудо.
Впрочем — судя по тому, что ежегодно успешно патентуется несколько идей вечных двигателей, отучили не всех. Да и в биологии ситуация не волшебна. Впрочем в нейросетях кратно хуже ))) Человеку свойственно верить в чудо.
А что, от нейросетей уже где-то отучают? У меня ощущение, что с каждым днем все только больше и больше хайпа становится. %)
Инвесторов научили биологии, отучив от элексиров бессмертия, научили химии, отучив от философского камня, научили физике, отучив от вечных двигателей. Теперь вот учат информатике (теории информации), отучая от магии нейросетей. Нейросети оказались скучными статистическими алгоритмами для работы с данными, а не волшебной палочкой, рождающей байты из пустоты.
В отличие от эликсира бессмертия, философского камня и вечных двигателей, нейронные сети — это рабочий инструмент, который успешно применяется на практике. Весь хайп из-за того, что неспециалисты не понимают их возможностей и границ применимости. Ну и название даёт некий налёт фантастичности, что тоже смущает обывателя.
Безусловно, для вывода видео качественный выбор кодека необходим и автор убедительно это доказал. Комментарии по поводу «замылевания» картинки на youtube безосновательны. Для примера взял Курсовую работу студентов ВГИКа А.Гордона и А. Тарковского 1959 и попытался загрузить на youtube
Слева до обработки, справа после. «Замылевания» нет ни справа ни слева
Полный результат здесь _https://youtu.be/idq4LU_emBE
Слева до обработки, справа после. «Замылевания» нет ни справа ни слева
Полный результат здесь _https://youtu.be/idq4LU_emBE
Если то, что вы постите может расцениваться как реклама вашего сервиса — нужно быть аккуратнее в формулировках (сейчас вы не доказали безосновательность чужого комментария — фактически просто обвинив его в безосновательности), ссылках (особенно на свою рекламу) и картинках (например, картинки рекомендовано уводить под спойлер).
Иначе вы на ровном месте насобираете минусов в карму.
Иначе вы на ровном месте насобираете минусов в карму.
1. Как Вы словами опишите «замыленность» видео?
2. Для доказательства своих доводов была представлена картинка.
3. Для особо пытливых в разглядывании «замыленности» была предоставлена ссылка.
Какая реклама? Любой пост можно рассматривать, как скрытую рекламу своей индивидуальности.
2. Для доказательства своих доводов была представлена картинка.
3. Для особо пытливых в разглядывании «замыленности» была предоставлена ссылка.
Какая реклама? Любой пост можно рассматривать, как скрытую рекламу своей индивидуальности.
Не буду спорить. У вас есть полное право игнорировать чужие дружеские советы ) Я ведь тоже что-то могу не понимать.
«Замылевания» нет ни справа ни слева
Конечно: нельзя замылить то, чего нет. Реальное разрешение что до обработки, что после очень низкое. Нет высокочастотных деталей, которые можно было бы "замылить".
Впрочем, в местах с быстрым движением, где эти детали (точнее, шум) есть, вполне себе удалось найти различия:
[28:19], кадр REC Fm: 132486.
Вот скриншоты для сравнения:
https://drive.google.com/open?id=1-cQTqGPhKCDQAMm6QyTbknk4isIjhEEp
Полностью с Вами согласен! Была попытка стабилизации ДВД с апскейлом, высокочастотных деталей было взять неоткуда. Не было хороших сканов. Да простит меня Dmitriy Vatolin, что комментарий не по теме кодеков.
Конечно: нельзя замылить то, чего нет.+1
И спасибо, что не пожалели времени посмотреть внимательно! )
Only those users with full accounts are able to leave comments. Log in, please.
Уличная магия сравнения кодеков. Раскрываем секреты