Комментарии 123
Отличная статья, спасибо! Теперь буду скептичнее относиться к очередному "убийце джипега"
- Тезис первый: нейросети фантастически удобны для демонстрации произвольных чудес
- Тезис второй: нейросети реально уже порвали целую пачку лучших алгоритмов прошлых лет (и, судя по всему, еще пачку порвут в ближайшие годы)
Эти тезисы не противоречат друг-другу! ) Но они объясняют, почему инвесторы несут хорошие деньги в ИИ-стартапы и почему разных чудес в новостях от них будет в ближайшие годы заведомо много.
сильно помогает открытая реализация и мощная поддержка Google, но сильно мешает более высокая сложность стандарта.И непонятно, станет ли Intel со своими текущими вопросами внедрять аппаратное декодирование ещё одного (пусть и замечательного) кодека в новые процессоры.
Новые кодеки не делают специально медленными
А дальше идут три процесса:
- Оптимизация кодека, при которой он начинает жать с той же силой за гораздо меньшее время (большой и сложный процесс)
- Увеличение производительности железа (в последние годы все медленнее)
- И… совершенствование кодеков старых стандартов, ибо они на новом железе и с новыми оптимизациями тоже начинают жать быстрее и лучше.
И дальше скорости этих процессов определяют, выживет стандарт или нет. MPEG-4, например, относительно не повезло.
А альтернативой тотального апгрейда могли бы стать аппаратные декодеры, но, видимо у индустрии свои заботы.
AV1
![image](https://habrastorage.org/webt/ne/qs/br/neqsbrjfqnj8ur8b97lkk4gqock.png)
Нам пришлось релизить часть отчета 2018 года в 2019 году из-за того, что ждали, когда все досчитается на AV1…
Если конкретно: вы говорите про free view rendering, это большая активно развивающаяся область, но там в общем случае до успеха еще довольно далеко. Хотя для узких спортивных кейсов ее скоро порешают. Забавно, что в MPEG-4 было расширение с поддержкой DIBR (Depth Image-Based Rendering) — эффективное сжатие вольюметрических моделей, 20 лет спустя можно смело прогнозировать ренессанс темы.
![Джоконда](https://habrastorage.org/getpro/habr/comment_images/953/681/e29/953681e2992124327e7d1ecfaad30642.gif)
2. Да, вам нужен конкретный всеядный продукт, тут я не слежу за новинками, увы. Но люди подсказать могут, надеюсь )
Хотите просматривать любое видео из зоопарка однотипно — смотрите с компьютера, используя, например VLC media player. Он справляется почти с любыми комбинациями контейнеров/кодеков. Ничего не нужно пережимать, качество не ухудшится, просто
Хотите избавиться от наследуемых форматов пережав всё и выбросив все исходники?
Жмите в сторону лучшего устройства, т.е. Canon'а. Да, у смартфона может быть выше разрешение, но более шумная матрица и оптика попроще. Full-HD на 40" смотрится всё еще пристойно.
Лучше всё-таки не пережимать — потери будут всегда, а экономия пространства после пережатия быстро съестся очередным гаджетом с 100500 мегапиксельной камерой с очередным модным кодеком.
Если поток хотя бы H.264, то много наиграть не получится, а потери качества точно будут, это правда.
Пример использования — какие-нибудь записи с камер, где много «мертвого» пространства, а еще «перекодирование» какого-нибудь сверхширокого формата в обычный 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Мб, а видимой разницы никакой. А у кого-то таких файлов могут быть залежи.
Тоже все хотел пережать архив, и так и добрался, и хорошо, потому что сейчас весь его размер – это пара видюшек с gopro.
Чем больше итераций пережатия будет, тем хуже будет качество материала.
Более того, по своей сути сжатие с потерями так или иначе основана на выделении значимых и не значимых кусков исходного материала, при этом незначимые куски откидываются или сильно деградируют.
Большая часть преймущества современных кодеков — имено в наилучшем выборе таких кусков, которые можно сильно деградировать/отбросить.
Если же мы на вход подаем материал уже деградированый другим кодеком, то эта эффективность стремительно теряется. Более того, она вносит дополнительную деградацию в те куски которые после первой стадии сжатия оставались «хорошими».
Как результат пережатое видео лучше вообще не пережимать без сильной аргументации на это.
Чтобы смотреть все подряд — лучше использовать кодек паки или всеядные просмотрщики, так хоть что то будет видно на записи снятой старым телефоном :)
По процессору отдельная тема. На рядовом i7 пережатие видео в новомодные форматы может производиться со скоростью, к примеру, 1-2 кадра в секунду (при всех максимальных настройках). А это значит, что ролик в 10 минут, будет пережиматься около 4 часов. Так что при наличии архива записей пары месяцев может не хватить :)
Чтобы смотреть все подряд — лучше использовать кодек паки или всеядные просмотрщикиГолосую за второе. Установка кодек-паков (особенно нескольких, «для верности») чревата наличием в системе нескольких кодеков, условно подходящих для воспроизведения контента. Причём выбран будет не обязательно лучший и не всегда с оптимальными настройками.
Ещё бывает, заканчивается триальный период какого-нибудь платного кодека, но пользователь не получает сообщения об этом или не может понять его смысла.
В итоге, может перестать воспроизводиться определённый тип видеофайлов.
Любое, повторю, ЛЮБОЕ пережатие между форматами с потерями ведет к деградации качества.С оговоркой на MotionJPEG и форматы сжатия с поддержкой режимов сжатия без потерь.
Чем больше итераций пережатия будет, тем хуже будет качество материала.И тоже с оговоркой. Мы в свое время проводили эксперименты с многократным пережатием. Там есть тоже свои нюансы, ибо можно сжимать так, чтобы качество при пережатии почти не деградировало. Это свойство алгоритмов сжатия актуально при редактировании видеоматериала, когда хотелось бы держать материал сжатым, но минимально терять качество при итерациях редактирования. Минимизировать потери возможно, если об этом заботиться.
А в целом — да, лучше пережимать пореже ), согласен совершенно.
Скажу больше — если вообще не пережитьмать, то лет через 20 можно будет с большой вероятностью успешно увеличить разрешение материала (например, сделать HD из старой SD записи). При этом даже одна итерация пережатия кардинально снижает успех этого мероприятия.
При пережатии другим кодеком с потерями качество будет всегда деградировать, т.к. происходит выполнение следующей последовательности:
1) Оригинальное изображение
2) Деградация качества для оптимальной работы кодека (например блочность, или разнесение на слои)
3) При декодировании фильтры воспроизведения «додумывают» картинку, чтобы избавиться от артефактов
4) Это «придуманное» изображение деградирует для оптимальной работы нового кодека (а если установлен режим Constant Quality, то и для такого-же кодека как и в пункте 2 будут выбираться другие зоны для деградации)
5) При воспроизведении декодер опять «додумывает» изображение.
Т.е. чем больше таких итераций, тем больше циклов деградации и «додумывания» (восстановления) будет. А значит оригинальной информации будет все меньше и меньше.
В итоге есть варианты, при которых при определенном устройстве декодера и энкодера возможно в точности «попадать» в старые коэффициенты и всегда одинаково сжимать кусок, если он не изменялся. Да, при этом этом придется отключить часть модных фич, но это возможно.
Тема слабо востребована, но она реализуема в рамках текущих стандартов.
Повторюсь — мал спрос. По факту народ мало парится по поводу потерь, которые не видно на глаз. А то бы давно сделали)
его просто можно запустить в директории с исходными файлами и тогда он переконвертирует все файлы с расширениями из списка (кроме mkv) в HEVC с crf 25 — на мой взгляд получается замечательно. Результирующие файлы будут в контейнере «Матрёшка» (.mkv), он был выбран, помимо прочего, потому, что файл можно просматривать в процессе записи.
Могу сказать две вещи:
1. Сильно не везде в России так, довольно много мест, где реально все еще делом занимаются даже в госконторах.
2. В Китае ситуация с фейковыми публикациями (особенно внутри) хуже чем у нас на порядок (если не сильнее). У нас, как ни странно, по крайней мере технические направления держатся.
НИИ ССК — это звучит гордо.
Никогда не был в Пекине. Видимо, и не поеду туда теперь. В других местах Китая (Чунцин, Чэнду, Ханчжоу, Циндао) было очень чисто и приятно находиться. Но это ещё и особенность Китая: не там чисто, где не мусорят, а там, где постоянно ходит дворник и тут же подбирает мусор.
beamr.com/h264-hevc-video-comparison-player
Причина экспериментов с HandBrake — попалась на глаза на хабре статья от Intel о QuickSync Encoder. Действительно кодирует быстро, но если важно оригинальное качество, то лучше оставить в DV. x264 хоть с ускорением, хоть без, хоть с огромным битрейтом — артефакты сжатия оригинала можно найти.
Каждый кадр бьётся на блоки, и эти блоки (максимально похожие на них) ищутся в предыдущих (примерно 5, но можно и 16) кадрах радиально-недалеко (в 8 разных направлениях, но бывает и в 32) к текущему блоку. Блоки примерно от 4х4 до 64х64 пикселя. Блоки копируются (без афинных преобразований) как есть. Получившаяся разница кодируется дополнительно позже.
Вопрос!
Львиная доля видео в мире, это видео движущейся примерно вперёд камеры. Видеорегистраторы, квадрокоптеры, экшен-камеры. Где очередной кадр сильно похож на предыдущий, только «растянутый» слегка, а также на следующий кадр, только «растянутый» в обратном направлении. Интуитивно кажется, что применив здесь специализированнй подход — чтобы вся серия кадров строилась на однообразном простейшем преобразовании. Щепотки бит буквально достаточно для описания однообразного преобразования. Дополнительная разница с реальным кадром аналогично будет кодироваться позже.
Реализовано ли такое где-то сейчас? Или разница между растянутым кадром и кадром с камеры, сдвинутой в пространстве, слишком велика и потребует сравнимого количества бит и поэтому такой подход не используется?
По факту:
Во-первых, все ощутимо сложнее. Например, есть B-frames, которые и повышают сжатие, и важны, когда идет навигация по файлу (и в которые вектора как с прошлых, так и с будущих кадров).
Во-вторых, если картинка резкая, а не замыленная, то важны субпиксельные сдвиги. И нам важен блок, максимально похожий, например, с четвертьпиксельной точностью. Они находятся и это работает. Это сразу убивает вашу идею.
И, в-третьих, арифметическое сжатие очень эффективно (в доли бита) сжимает вектора, если у вас они смотрят в одну сторону. Т.е. панорамирование (дрон поворачивает) обходится на самом деле достаточно дешево. По крайней мере экономия на более точной компенсации позволяет намного больше потратить на вектора, там нет смысла какой-то один большой вектор сохранять.
Как-то так, если кратко.
И тонкая настройка x264/x265 тоже наврядли лучше placebo (у них же) справится с такими видео?
И тонкая настройка x264/x265 тоже наврядли лучше placebo (у них же) справится с такими видео?Может и лучше.
Пример был в статье:
![image](https://habrastorage.org/getpro/habr/post_images/faa/e6d/5cc/faae6d5cc5349d82c1f963c68c01dd9b.png)
На этом видео звезды так легли, что можно сжать в разы быстрее placebo, причем примерно на треть сильнее при этом. Представление, что placebo обеспечивает максимально возможное сжатие (оно же так долго работает!) — это популярный миф.
Пробовал плацебо на x265 @ FHD — просто невозможно использовать, на 8+8 ядерном компе фпс сильно меньше 1 получался. Кодирую в Constant Quality, CRF=22 чтоли ставил.
Только проверьте качество результата.
На всякий случай спрошу, нет ли у вас готового ответа, на вопрос, какие настройки нужно подкрутить, чтобы квадрокпотерное видео (FHD и 4K) кодировалось быстрее и качественнее (кодеки x264 и x265)? Как на вашей картинке, например)Если бы был какой-то один волшебный пресет — его бы уже прошили в стандартные, т.е. на этот вопрос нет простого ответа.
Вообще возможно стоит на эту тему отдельный пост. Разобрать мифы, обозначить возможности, разобрать сложности. Стоит писать?
К счастью, это не означает, что их нельзя подобрать и улучшить )
Но там масса сложностей, начиная с чисто вычислительной, увы…
Реализовано ли такое где-то сейчас?
В драфте 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 появился в сильных компетиторах. Спасибо за наводку!
Поправка — сцена с движением "blue_sky" https://media.xiph.org/video/derf/
PS: Я делал бенчмарки когда он был еще JEM'ом, но идея вроде как сохранилась
(Ссылка на archive.fo потому что блог, увы, удалён. Вот тут есть сделанная кем-то копия текста, но там убилось форматирование.)
Шикари нам массу предложений по изменению сравнения выкатил, мы многие реализовали. Интересно, что в целом это сделало сравнения совершенно непригодными для широкой публики (слишком много графиков), но профессионалы рады — картина (кто где реально лучше, кто где хуже) яснее.
10 лет назад я писал скринкасты в Microsoft Video 1, в RGB555. 10 минут видео занимало 200-250 мегабайт, но ужималось компрессором до 1.5-2 мегабайт(!). Качество видео было постоянно высоким, и всё выглядело отлично, в т.ч. из-за отсутствия субдискретизации цвета.
Аналогичное видео в VP9 или H.264 получается раза в 3-6 больше по размеру.
Есть ли какой-то рекомендуемый кодек для скринкастов?
Вообще думаем про отдельный пост с разбором оптимизации параметров под контент. Разобрать сложности, обозначить сколько можно наиграть, почему это сложно, как можно действовать на практике и т.д.
Стоит писать? Какие вопросы были бы интересны?
Да, писать однозначно стоит, хотя бы ради вопроса качественных гуи-скринкастов, с динамичной картинкой-то в принципе все те же приемы, что и с живым видео.
Просматривается некая аналогия с жпег против пнг, кстати. :)
тоже остановился на каком-то кодеке, который потом винраром сжимался адскиУжас какой… Где вы такие берете…
Да, писать однозначно стоит, хотя бы ради вопроса качественных гуи-скринкастов,Принято. Еще вопросы в теме, которые интересны, приветствуются.
Что еще было круто, так это возможность установить всего 1 кадр в 30 секунд для предельной экономии места (записывал какую-то динамическую страницу).
Во, вопрос кстати вспомнился в связи со скринкастами: примерно в то же время я нашел какую-то мелкую программу, которая писала скринкасты в файл формата флэша (ну почти как все), но — сжатие, в отличие от других, достигалось невероятное (заметнее всего — на почти статических моментах), и у меня вопрос частично по формату (программу ту я посеял и не смог найти снова с тех пор, о чем жалел не раз) — возможно ли, что та прога делала не просто сжатие картинки, а сперва анализировала геометрию оконного менеджера и, грубо говоря, записывала не тупо покадрово, а делала смещение прямоугольников при движении окон и других объектов по экрану и писала не просто видеопоток, а еще и описания всего? Ну почти как кодеки анализируют предыдущий и следующий кадр для лучшего сжатия. Ведь технически это не должно вызывать большие трудности, верно? :)
Ведь технически это не должно вызывать большие трудности, верно? :)Если с конца начинать, то имейте ввиду, что обычно ответ на этот вопрос «нет» ))), особенно если легкие решения на каждом углу не лежат. Очень часто простые в постановке задачи сложно решаются.
По поводу сжатия такого контента — есть даже отдельное направление — Screen Capture Codec, коих кодеков было создано довольно много (в том числе мы делали). И софта подобного тоже очень много. Там несколько параметров — и собственно их баланс и тюнингуется. Это если кратко. Если подробно — можно большой пост только про алгоритмическую часть написать.
Под Windows это довольно затруднительно, но есть ReactOS, Kolibri.
Также существовали векторные дисплеи, отрисовывавшие вызовы аппаратно. Даже сейчас в драйверах устройств отображения под Windows есть набор флагов, соответствующих наличию реализации различных векторных функций. Если бы развитие подобных дисплеев продолжилось, офисный дисплей можно было бы подключать через com порт, а не hdmi. И, вероятно, офисный компьютер мог бы питаться от солнечной батареи, как калькулятор.
Речь, конечно, только о графическом интерфейсе, офисные приложения без 3d и видео котиков в 4k.
Я помню, для GNOME была утилитка, которая сохраняла скриншоты в SVG подобным образом. В самом деле, всё равно ведь большинство GUI по сути векторные.
Впрочем — судя по тому, что ежегодно успешно патентуется несколько идей вечных двигателей, отучили не всех. Да и в биологии ситуация не волшебна. Впрочем в нейросетях кратно хуже ))) Человеку свойственно верить в чудо.
Инвесторов научили биологии, отучив от элексиров бессмертия, научили химии, отучив от философского камня, научили физике, отучив от вечных двигателей. Теперь вот учат информатике (теории информации), отучая от магии нейросетей. Нейросети оказались скучными статистическими алгоритмами для работы с данными, а не волшебной палочкой, рождающей байты из пустоты.
В отличие от эликсира бессмертия, философского камня и вечных двигателей, нейронные сети — это рабочий инструмент, который успешно применяется на практике. Весь хайп из-за того, что неспециалисты не понимают их возможностей и границ применимости. Ну и название даёт некий налёт фантастичности, что тоже смущает обывателя.
![image](https://habrastorage.org/webt/sh/yu/z9/shyuz9rrtsfqzp-75z9xrshvfky.png)
Слева до обработки, справа после. «Замылевания» нет ни справа ни слева
Полный результат здесь _https://youtu.be/idq4LU_emBE
Иначе вы на ровном месте насобираете минусов в карму.
2. Для доказательства своих доводов была представлена картинка.
3. Для особо пытливых в разглядывании «замыленности» была предоставлена ссылка.
Какая реклама? Любой пост можно рассматривать, как скрытую рекламу своей индивидуальности.
«Замылевания» нет ни справа ни слева
Конечно: нельзя замылить то, чего нет. Реальное разрешение что до обработки, что после очень низкое. Нет высокочастотных деталей, которые можно было бы "замылить".
Впрочем, в местах с быстрым движением, где эти детали (точнее, шум) есть, вполне себе удалось найти различия:
[28:19], кадр REC Fm: 132486.
Вот скриншоты для сравнения:
https://drive.google.com/open?id=1-cQTqGPhKCDQAMm6QyTbknk4isIjhEEp
Конечно: нельзя замылить то, чего нет.+1
И спасибо, что не пожалели времени посмотреть внимательно! )
Уличная магия сравнения кодеков. Раскрываем секреты