В этом году исполняется юбилей — 16 лет, как был запущен сайт compression.ru, на котором автор и сотоварищи организуют сравнения видеокодеков и кодеров изображений. За это время были проведены десятки сравнений с отчетами от 23 до 550+ страниц, количество графиков в последнем сравнении перевалило за 7000, а количество разных феерических случаев за это время окончательно превысило все разумные пределы. Поскольку следующая круглая дата (32 года) наступит еще нескоро, есть желание рассказать в честь юбилея малую толику феерического.
Если говорить про кодеки, то не секрет, что большинство сравнений и графиков, которые видит почтеннейшая публика — это продукт отдела маркетинга. В лучшем случае — графики грамотно делали инженеры, а маркетинг только давал добро на публикацию. В худшем случае инженеры вообще не участвовали в их подготовке.
При этом тема сжатия весьма популярна. В сериале «?Кремниевая долина»? стартап главного героя разработал гениальный алгоритм, который в последней серии первого сезона показал невероятное сжатие 3D видео и в итоге теперь миллионы стартаперов (и инвесторов) мира знают, что главное — это чтобы коэффициент Вайсмана был побольше и ещё гения надо найти, а остальное — фигня-вопрос. Чудо будет! Это естественным образом увеличивает ожидание чудес и, конечно (КОНЕЧНО!) эти чудеса радостно демонстрируются компаниями! В том числе с использованием последних достижений уличной магии.
DISCLAIMER: Любые совпадения имен и названий компаний ниже с реальными именами и названиями абсолютно случайны.
Усаживайтесь поудобнее! Обещаем, что к концу рассказа вы сможете показывать подобные фокусы сами, как, впрочем, и раскрывать многие из них. Поехали!
Level 1, фокусы для начинающих
Начнем с самого простого, ибо, как ни странно, эти методы вполне в современной (не сериальной, а настоящей!) Кремниевой долине прокатывают.
Итак, почтеннейшая публика, фокусы с демонстрацией сверхсильного сжатия начинаются!
Наверняка многие видели подобные динамические сравнения
Сказано — сделано!
Компания заявляет на 30% лучшее сжатие (все совпадения случайны!). А картинки выглядят совершенно одинаково! Даже профессионально наметанный взгляд не находит различий. Возникает желание посмотреть детальнее. Лезем в код страницы и видим, что слайдер для первой и второй картинки берет данные из одного файла! Получаем преимущества сразу по нескольким параметрам — во-первых, идеально демонстрируется лучший результат, во-вторых, не отвлекали инженера от работы, и, наконец, это место страницы сайта грузится вдвое быстрее. Сплошной profit!!!
Случай, не поверите, реальный. Теперь вы знаете, куда стоит посмотреть!
В другом месте — тоже слайдер и опять замечательный результат. Заглядываем в код слайдера — грузятся разные файлы. Наученные горьким опытом скачиваем их — они не просто до байта одного размера, они совпадают побитно! В общем — все плюсы предыдущего способа, но фокус раскрывается чуть сложнее, правда за счет замедления загрузки страницы (за все приходится чем-то платить...). И, главное, не нужно привлекать дорогих специалистов в сжатии.
Впрочем, более продвинутые маркетологи этого уровня идут еще дальше. Выкладывается слайдер — смотришь — картинки отличаются, но качество о-о-очень похоже. Ну ок. Дальше больше! Демонстрируется фантастическая открытость — есть даже линки на видеофайлы. Скачиваешь — очень неплохое преимущество у их метода, даже непонятно, как они это сделали. Выручает то, что мы же тут все поголовно русские хакеры (уже бренд на западе). Смотрим битовый поток и видим чудную картину:
То есть даже многие эксперты, если не будут глубоко копать и перепроверять, подтвердят, что действительно у людей отличный результат примерно вдвое превосходящий по размеру сегодняшнего лидера при сравнимом качестве. Вы не поверите, подобные методы вполне себе используются и даже в некоторых случаях позволяют получить десятки миллионов долларов инвестиций.
Вспоминается встреча с русским стартапом 6 лет назад. Их директор прямо с порога сказал: «?Вы должны нам все сделать на совесть. У нас инвесторы из «?Северстали»?, и, если что, к вам выедут спортивные бритые ребята с паяльниками.»? Как вы понимаете, в таких суровых условиях качество исследовательской работы волшебным образом возрастает, а количество фокусов разного уровня — падает… При работе с такими кейсами у нас, на родине слонов, возникает непреодолимое чувство жалости к западным инвесторам. Правда не все наши инвесторы такие чисто конкретные, и свои фокусники и в наших палестинах тоже находятся. Причем регулярно. Но про это в другой раз...
Level 7, резонансный
Эта история не про видеокодек, а про сжатие картинок, но в ней многое было по всем законам жанра «?честных фокусов»?.
Как-то довольно известная компания М решила, что им к своим форматам Windows Media Video (WMV) и Windows Media Audio (WMA) нужно добавить Windows Media Photo (WMP). Чисто для комплекта, как вы понимаете.
Молодой человек на галёрке! Ну не надо так громко кричать, не вас одного осенило! Культурные люди (посмотрите на первый ряд) максимум — понимающе усмехнулись в усы…
Сказано — сделано!
Далее внимательно следим за руками:
Т.е. у WMP больше деталей, чем у JPEG и JPEG 2000 при том же уровне сжатия (мягко уравниваются JPEG и JPEG 2000 и задается уровень 24 раза), а в следующем абзаце:
Т.е. обычно только в 6 раз сжимают, а было 24. Вау, пахнет тремя разами! И вообще мы лучше в 2 раза точно. СМИ понесли благую весть в массы (некоторые написали, что в 2 раза лучше JPEG 2000), даже на Хабре повторили эту новость.
Чуть позднее появился график из этой презентации:
По вертикали обычно идет качество (какая-то из метрик в зависимости от моды в этот момент времени), по горизонтали — так или иначе — размер. Обычно с увеличением размера качество растет (хотя на практике всякое бывает). По линии одинакового качества (красная горизонтальная) можно прикинуть, что «?пурпурный»? кодек примерно в 2 раза проигрывает по размеру «?синему»? при том же качестве на этом диапазоне битрейтов.
Преимущество по сравнению с JPEG 2000 было небольшим, при том, что они, очевидно, отобрали лучшую картинку с чудным мальчиком и дельфинами. Мы с большим нетерпением ждали возможности поиграться с этим кодером. Примерно через полгода утилиту для сжатия таки выложили.
У нас к тому моменту как раз было годичной давности сравнение 9 реализаций JPEG 2000
Да-да-да! Как не все йогурты одинаково полезны, так и не все реализации стандарта жмут одинаково хорошо. Стандарт оговаривает только битовый поток, положить в который данные (и, кстати, вынуть!) можно сильно по-разному, это порождает отдельный рынок кодеков со своей жесткой конкуренцией по доброму десятку параметров. Простой пипл этого, как правило, не знает, что позволяет безнаказанно ездить ему по ушам практически на бульдозере («?Наш видеорегистратор поддерживает новейший H.265/HEVC, больше его ни у кого нет!»?). И никто (никто!) КРАЙНЕ вероятной подставы не замечает.
Мы радостно вставили в предыдущий отчет 3 линии для WMP. Получилось как-то так:
Видно, что линии реализаций JPEG 2000 идут довольно кучно и у жирной синей (лучшая реализация WMP) результаты где-то посередине, т.е. ПРОИГРЫВАЕТ JPEG 2000. Если взять JASPER за ноль и все по вертикали относительно него показать, то видно, что WMP с худшим параметром проигрывает почти всем, кроме двух последних (одна из них KDU, запомним это), а с лучшим — лежит где-то по центру, проигрывая многим реализациям:
Поскольку сравнение было выложено публично и наделало шуму в узких кругах, то разработчик даже ответил на него в официальном блоге. Заметка была вежливая: похвалили, покритиковали, а дальше, если продраться сквозь текст, человек чистосердечно признался, что они использовали самую худшую реализацию JPEG 2000 нашего сравнения (опубликованного за полгода до того) в своем сравнении, правда «?совершенно случайно»?. Мы, конечно, им поверим. Компания уважаемая и все такое.
Дальше название технологии было изменено с WMP на HD Photo, впрочем в сети остался такой вердикт:
В качестве вишенки на торт. Наши коллеги пошли дальше: взяли больше картинок и показали, что HD Photo проигрывает не только JPEG 2000, но и хорошей реализации JPEG (в 7 случаях из 14). И проигрывает конкретно. Есть основания полагать, что они подбирали картинки, но они откровенно закопали HDPhoto, ибо кому нужен формат, который в половине случаев проигрывает древнему JPEG — непонятно:
Итого, секреты этого фокуса:
- Берем худшую реализацию основного конкурента, сравниваем с ней.
- Создаем рекламную шумиху (в стиле «?мы всех сильно обогнали»?).
- Когда шумиха отходит на второй план, делаем релиз и надеемся, что никто не проверит, что там было на самом деле.
Дети! Никогда так не делайте и не обманывайте других! Ваша компания может потерять миллионы долларов и доверие специалистов.
Level 10, свежий! С нейросетями!
Вообще подобных случаев — очень много. Даже в России я сталкиваюсь с подобными ситуациями примерно пару раз в год (к нам, как к хозяевам compression.ru, информация стекается). На западе разводят
В последнее время очень популярны стали нейросети. Абсолютно все, к чему они прикасаются, волшебным образом улучшается. А не применить ли их к сжатию видео?
Сказано — сделано!
В ноябре прошлого года очередная благая весть с подачи самого «Уолл Стрит Джорнал» облетела мир. Создан видеокодек на основе машинного обучения, который всех порвал! Вот пруф:
Вообще я лично крайне скептически воспринимаю все новости с упоминанием нейросетей. И вам советую (ОСОБЕННО, если вы инвестор). Нейросети устроены таким образом, что грамотно подбирая обучающую выборку под тестовую можно показать любой (для непонятливых — ЛЮБОЙ!) желаемый результат. Нейросети — идеальный инструмент для постановки на поток маркетинговых чудес. Одно чудеснее другого!
В общем график есть, картинки есть. Согласитесь — убедительно. Специально для скептиков господа привели еще несколько графиков на известных тестовых наборах:
Впрочем, если предыдущий график с картинками лично для меня был еще как-то объясним (заточиться на одно видео да еще с глубокими нейросетями можно всегда), то эти два графика заставили резко насторожиться.
Вас в них ничего не смущает?
Они даже под это подводят базу, типа классические кодеки уперлись в предел и уже особо не развиваются (и тут на сцену выходят они, все в белом). И вы знаете, такая наглая ложь прекрасно работает! Причем ладно «The Wall Street Journal» — они (хотелось бы верить) только в финансах разбираются, ладно «MIT Technology Review» — эти джентльмены джентльменам Кремниевой долины верят на слово, но как некритически воспринял новость такой уважаемый ресурс, как Хабр — ума не приложу! Чего уж говорить про массово перепечатавших новость …
В реальности картина развития кодеков, к счастью, заметно отличается. Во-первых, на графике ниже, построенном нами на том же наборе видео xiph, можно увидеть, что H.265 на 25?31% лучше, чем H.264. Т.е. 10 лет развития кодеков таки не прошли даром! (Уфф, прямо от сердца отлегло...) Во-вторых, свежий AV1 показывает практически двукратное улучшение по сравнению с H.264, и ступенька его преимущества, прямо скажем, весьма заметна:
Соответственно на глаз видно, что если наложить график AV1 на 45% левее H.264 на графике авторов — он покроет новый кодек как… [вырезано цензурой]. Хорошо покроет, короче. Потому с ним и «?забыли»? сравниться. Реальный расклад выглядит как-то так (сильно менее кучно, согласитесь):
Чтобы было понятно — у кодеков есть стандартные пресеты, которые позволяют варьировать скорость в значительных пределах (часто десятки раз), но при этом достигать большего сжатия при том же качестве (часто больше 2 раз). У x265 (очень неплохой open-source реализации стандарта HEVC) они называются: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo. Если взять medium за 1, то по скорости и размеру файла при том же качестве они для конкретного файла могут располагаться, например, как на графике ниже. Можно говорить, что относительно medium можно сделать файл на 40% больше или меньше, варьируя скорость в 10 раз:
Как легко заметить выше, господа взяли для сравнения «slower». Хорошо, что не «veryfast», ведь могли бы и его! ) И не важно, что у них у самих кодек феерически медленный. Люди в массе своей, глядя на график, не вспоминают о том, что скорость работы кодека может на пару порядков отличаться в зависимости от параметров. Поэтому такой прием вполне прокатывает. Хотя на нашем графике выше («Bitrate/quality...») их пачка линий была в районе красной (которая самая плохая). Заодно оправдывая топтание на месте в развитии кодеков. Ага-ага!
Есть и более тонкие подтасовки, например, господа пишут: «To remove B-frames, we use H.264/5 with the bframes=0 option, VP9 with -auto-alt-ref 0 -lag-in-frames 0, and use the HM encoder lowdelay P main.cfg profile.» То есть они не смогли побить обычные кодеки в честном соревновании и выбрали low-latency режим с низкой задержкой, который используется обычно для реального времени, например, для видеоконференций. Результаты кодека в нем хуже, естественно. При этом их декодер (про энкодер промолчим) работает 2 секунды на кадр, то есть ни о каком low-latency даже близко говорить нельзя. Зато еще несколько процентов наиграли.
Это не все трюки, которые были использованы господами стартаперами, но картина уже ясна.
Понятно, что, чтобы фокус выглядел правдоподобно, нужны еще дополнительные штрихи, которые придают реализма. Например, эти господа опубликовали статью на https://arxiv.org/abs/1811.06981. Сегодня развитие алгоритмов идет настолько быстро, что ждать, пока выйдет статья в журнале становится нестерпимо, поэтому многие сильные авторы публикуют результаты сначала на arxiv.org. Для уличных магов этот сайт удобен тем, что там можно разместить абсолютно любой материал — в отличие от рецензируемых журналов и конференций никто не задаст неприятных вопросов и не зарубит публикацию (нет kill reviewing серьезных мест). А про то, что, например, на 1 апреля на arxiv.org принято публиковать разного рода пародии на научные статьи, в том числе высмеивая его как место публикаций, широкая публика не знает, поэтому для широкой публики публикация там выглядит типа даже солидно.
Идем дальше. Статья на хабре про них называлась «?Первый видеокодек на машинном обучении кардинально превзошел все существующие кодеки, в том числе H.265 и VP9»?. Очередной прикол заключается в том, что машинное обучение в сжатии не только активно исследуется, чему уже посвящаются отдельные треки конференций (то есть статей много), но и активно используется, например, в AV1 (специально привожу гугловый запрос). Но, если бы они честно сказали: «?Мы выпустили второй кодек с использованием машинного обучения, при этом проиграв первому и по скорости, и по сжатию»?, то Wall Street Journal мог про них и не написать… И MIT TechReview не написал бы… И даже Хабр… Очевидно, не вынеся последнего, в компании чуть-чуть поправили подачу. При этом особенностью современного интернета является то, что люди не проверяют информацию, что позволяет спокойно провозглашать себя первыми много кому (начиная с известных компаний). Наглость, как известно, города берет! А фактчекинг не моден.
— Загугли!
— Это как это?
[пример запроса дан выше)))]
И еще про ML/DL. В далекие-далекие времена, когда дискеты были большими, а винчестеры маленькими, одним из приемов «?уличной магии для архиваторов»? было сохранить часть сжимаемого файла куда-нибудь подальше в директорию со временными файлами и таким образом показать рекорд. С тех пор времена изменились. Винчестеры — выросли, дискеты совсем пропали, а данные стало модно прятать вглубь нескольких сотен мегабайт коэффициентов сетки. Можно сохранить «?авторский знак»? в сетке, можно — пасхалку, а можно фейковый рекорд сжатия поставить. Глубокие нейросети — однозначно сила, короче!
Резюмируя данный путь к успеху:
- Игнорируем современного лидера так, будто его вообще нет.
- Аккуратно формулируем все так, чтобы читалось будто мы первые использовали какую-нибудь новую технологию (и даже если первый это сделал лидер — никто проверять не будет).
- У стандартов 5? и 15?летней давности откручиваем ручки так, чтобы они работали хуже нас.
- Побольше наглости — обосновываем то, что они легли кучно позади нас тем, что они уперлись в предел и уже не развиваются.
- Публикуемся в «The Wall Street Journal» и на Хабре…
И… (барабанная дробь!)… вам дают еще несколько миллионов долларов! Или не дают… Я бы не давал… Инвесторы! Не спать! А то потом опять будете на воду дуть...
А теперь мастер-класс!
Как я и обещал выше, к концу этого текста вы сможете легко блистать на подмостках условного pikabu.
Сейчас, о почтеннейшая публика, я покажу вам фокус, позволяющий сравнивать, что угодно с чем угодно с любым заранее заданным результатом. Т.е. если надо, чтобы кодек А был лучше кодека Б — значит покажем это, если нужно, чтобы Б был лучше А, хорошо, можем показать и это. Исполним любой каприз отдела маркетинга
Давайте сами проверим, как эти самые кодеки жмут. Как говорится — не верь никому, проверь сам. А то, может, и правда эти стандарты не развиваются и нас просто дурят, заставляя зря платить заработанные непосильным трудом деньги непонятно за что?
Возьмем «?Аватар»? в формате 480p24 и сожмем его кодеком x264 c настройками "-preset superfast -x264-params «nal-hrd=cbr» -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M" и кодеком xvid с настройками "-preset superfast -b:v 1M -minrate 1M -maxrate 1M -bufsize 2M" (две очень неплохие open-source реализации стандартов H.264 и MPEG-4). Почему взяты эти кодеки и настройки будет объяснено позднее.
У нас получились два файла почти одного размера:
avatar_x264_cbr1M_superfast.mkv — 1402 MB
avatar_xvid_cbr1M_superfast.mkv — 1401 MB
А теперь, дамы и господа! Внимательно следите за руками!!!
Смотрим, вот новый стандарт и старый:
Смотрим другой кадр:
Без комментариев! А если быстрое движение?
Согласитесь! Прогресс явный и неумолимый! Все развивается и становится все лучше и лучше! А жизнь — краше и веселее!
Хотя…
Боже, что это??? Новый стандарт совсем слил…
А-а-а-а! Люди! Знайте! Корпорации вас обманывают!!! Кодеки уже давно не развиваются, но вам сообщают что все идет хорошо!
Вы видите? Все, чему они научились за 10 лет — это размывать блочность! Причем делают это просто отвратительно! Стало хуже, чем было! Вас водят за нос все эти годы!!!!!!!11
А теперь разберемся, как это сделано.
На самом деле полный кадр выглядит так:
Когда кодек работает, особенно в режиме постоянного битрейта, качество кадров достаточно сильно колеблется. Вот начало фильма, например — качество по классической метрике PSNR (сомнений кто лучше, кто хуже, кстати, нет, видно что зеленый xvid проигрывает в среднем):
Картинка кликается
Если вычесть один график из другого (на рисунке ниже, другое место в файле) — то видно, что в целом кодек более старого стандарта будет проигрывать, однако местами он может вполне уходить на +5 dB (PSNR удобна тем, что она обратно логарифмически пропорциональна среднеквадратичному отклонению, за счет чего, обычно, работает правило: на диапазоне средних и низких битрейтов на глаз видна разница в 1.5 dB). И тут же виден кадр, где в другую сторону разница 20 dB:
Картинка кликается
Теперь вы понимаете, почему ваш покорный слуга всегда с искренним умилением смотрит на приведенные в маркетинговых материалах компаний отдельные кадры, как на доказательство более высокого качества на видео (особенно когда нет графиков)… И ведь так до сих пор иногда приводят!
Чтобы отбирать кадры было проще, мы больше 10 лет назад сделали режим сравнения в нашей тулзе MSU VQMT, при котором сравнивались сразу 3 файла — оригинал, кодек-1 и кодек-2 и сразу сохранялись, например, 30 лучших пар кадров в одну или в другую сторону. Главное — взять файл подлиннее!
А MPEG-4 с низким битрейтом был взят, чтобы с блочностью было все нагляднее.
Итого, путь к успеху:
- Выбираем режим, при котором колебание качества у кодеков максимально (обычно, однопроходный CBR).
- Уменьшаем разрешение исходника в 2 раза (ибо скорее всего придется увеличивать фрагменты, например выше фрагменты были увеличены в 3 раза)
- Берем какую-нибудь метрику (PSNR, SSIM, модную в этом сезоне VMAF).
- Берем в качестве сравнения старый стандарт с блочностью или отключаем внутренний деблокинг у конкурента опциями.
- И последнее, не забываем взять файл подлиннее: 3 часа фильма — самое оно!
И БИНГО! У вас несколько примеров насколько вы лучше конкурента!
Ну или где-нибудь, где публика не слишком разборчива, можно кого-нибудь с кем-нибудь успешно сравнить. Пипл будет доволен.
Теперь вы знаете, какие вопросы задавать, когда видите сравнение с кадрами в материалах компаний! Может хоть пореже, наконец, они будут встречаться...
Вместо заключения
Выше разбирались относительно простые способы подготовки маркетинговых материалов «в свою пользу» в сравнениях кодеков и кодеров. Естественно, в реальной жизни все сложнее. Увы, если идти глубже, оно будет не так увлекательно и заметно сложнее (желающие могут почитать статью и комментарии тут, например).
А людей, обычно, интересуют простые ответы. Самый популярный ответ в Ответы@Mail.ru на вопрос ?«Какой самый лучший видеокодек?»? — «K-Lite Mega Codec Pack». И это для массового зрителя действительно самый короткий, понятный и точный ответ. А вы говорите — кодеки, стандарты…
Но чем больше будет людей, хотя бы на среднем уровне разбирающихся в предмете, тем реже будут совсем уж нахально лапшу на уши вешать отделы маркетинга или дуть в уши инвесторам нахальные стартаперы. И жизнь станет чуточку лучше.
Спасибо за внимание, дамы и господа! Всем — технической грамотности!
- Лабораторию Компьютерной Графики ВМК МГУ им. М.В.Ломоносова за вклад в развитие компьютерной графики в России и не только,
- наших коллег из видеогруппы, в том числе Сергея Звездакова, Анастасию Анциферову и Романа Казанцева, чьи примеры использованы выше,
- персонально Константина Кожемякова, который сделал очень много для того, чтобы эта статья стала лучше и нагляднее,
- и, наконец, огромное спасибо Сергею Лаврушкину, Егору Склярову, Ивану Молодецких, Евгению Ляпустину, Дмитрию Куликову, Александре Анзиной, Виталию Людвиченко, Михаилу Ерофееву и Георгию Осипову за большое количество дельных замечаний и правок, сделавших этот текст намного лучше!
Комментарии (109)
maedv
28.05.2019 11:47Очень интересно! Простой вопрос: имеет ли смысл кодировать бытовое видео в h.265 и AV1, или могут быть проблемы с совместимостью и «тормозами» при просмотре у заказчика? Кодирую по старинке в h.264 1280x720
3Dvideo Автор
28.05.2019 11:54+1AV1 — точно рано. Там разработка в разгаре. HEVC/H.265 — уже вполне, его декодирование уже несколько лет, как акселерируется аппаратно. Как обычно — вопрос кейса, контента, конкретной ситуации.
drWhy
28.05.2019 12:33Жаль только, что как только аппаратную акселерацию добавляют в процессор, кодек вдруг массово перестают использовать (H.264).
3Dvideo Автор
28.05.2019 12:37Вопрос к политике лицензионных отчислений соответствующего альянса. Рубят сук.
drWhy
28.05.2019 13:17Китайцы вставляют H.264 везде, на заморачиваясь соображениями лицензионности, а при выкладывании полученных видео на тытрубу оно пережимается, замыливается. А смотреть приходится на процессоре, с аппаратным декодером H.264 (бесполезным из-за выбора другого кодека), с 80% загрузкой. Печаль.
Riod
28.05.2019 14:13Вроде же стандарт уже есть. В активной разработке кодеры-декодеры, нет?
3Dvideo Автор
28.05.2019 14:25Да, есть. Торжественно зафиксирована версия битового потока 1.0.0, что дает возможность производителям работать над своими реализациями, но надо отдавать себе отчет, что его делали стахановскими темпами, учитывая количество багов в процессе, они еще остались. И кодеры-декодеры по опыту предыдущих стандартов доводят до ума примерно за 2-3 года. В этот раз сильно помогает открытая реализация и мощная поддержка Google, но сильно мешает более высокая сложность стандарта.
drWhy
28.05.2019 14:33сильно помогает открытая реализация и мощная поддержка Google, но сильно мешает более высокая сложность стандарта.
И непонятно, станет ли Intel со своими текущими вопросами внедрять аппаратное декодирование ещё одного (пусть и замечательного) кодека в новые процессоры.3Dvideo Автор
28.05.2019 14:46Ранее они не только для декодирования, но и для кодирования аппаратную акселерацию поддерживали. Сейчас 100% работы над этим идут (благо принципиально похожих моментов много), а дальше класть ли все в железо или оставить софтверные оптимизации — станет виднее.
Nexon
29.05.2019 05:38Ох, раз уж мы пошли в эту степь.
Я где-то вычитал, что для декодирования AV1 будут использовать OpenCL/CUDA, там где аппаратного ускорения нет.
Звучит просто супер, но так ли это?3Dvideo Автор
29.05.2019 08:18Почему супер? Накладные расходы на передачу данных на GPU реально мешают очень сильно. Сейчас, понятно, супер-медленное сжатие становится популярно, там влияние передачи невелико, но это ускорение только для медленных кейсов.
Nexon
29.05.2019 08:30Медленный кейс для нового кодека это дефолтный кейс же.
То есть, у меня вот относительно новый системник, но там 6700K и аппаратного ускорения 4K у него нет для VP9/H265/AV1.
В таком сценарии хотелось бы иметь какую-нибудь альтернативу покупке нового процессора и материнской платы.3Dvideo Автор
29.05.2019 08:47Что значит дефолтный медленный? )
Новые кодеки не делают специально медленнымичтобы вы покупали новое железо)))). Основная задача — минимум в 1.5 раза (лучше в два) переплюнуть по сжатию прошлый стандарт, иначе новый стандарт будет внедряться с жутким скрипом. Хрестоматийный пример — JPEG-2000, который несмотря на массу плюсов поторопились выпустить к красивой дате и не додавили сжатие в итоге он до сих пор идет в массы, хромая на все четыре лапы…
А дальше идут три процесса:
- Оптимизация кодека, при которой он начинает жать с той же силой за гораздо меньшее время (большой и сложный процесс)
- Увеличение производительности железа (в последние годы все медленнее)
- И… совершенствование кодеков старых стандартов, ибо они на новом железе и с новыми оптимизациями тоже начинают жать быстрее и лучше.
И дальше скорости этих процессов определяют, выживет стандарт или нет. MPEG-4, например, относительно не повезло.
drWhy
29.05.2019 15:03Действительно, печально что невозможно обновить поддержку аппаратного кодирования/декодирования новых кодеков обновлением микрокода процессора.
А альтернативой тотального апгрейда могли бы стать аппаратные декодеры, но, видимо у индустрии свои заботы.3Dvideo Автор
29.05.2019 15:57Ну чипмейкеры на новые части новых кодеков часто ругаются по-черному, ибо они на железо ложатся, бывает, плохо. Но… Приходится работать с тем, что есть.
drWhy
29.05.2019 16:15Аппаратный декодер можно было бы делать на программируемой логике. При появлении нового кодека обходилось бы сменой прошивки. При недостатке ресурсов чипа можно было бы просто снизить разрешение. Или купить новый, благо стоило бы это счастье при больших тиражах копейки.
3Dvideo Автор
29.05.2019 16:18Скажите это разработчикам. Получите ответ типа: «Идите, и так и сделайте!» (censored version))) Если кратко: это так не работает, к сожалению )
nidalee
29.05.2019 05:57AV1
Вы в курсе, какая там сейчас скорость? :)
3Dvideo Автор
29.05.2019 08:22Спасибо за цитирование нашего графика! )
Нам пришлось релизить часть отчета 2018 года в 2019 году из-за того, что ждали, когда все досчитается на AV1…
flashmozzg
31.05.2019 11:34Это уже устаревшие данные. Сейчас енкодинг AV1уже на порядок быстрее, хоть всё равно непрактично долго для большинства «домашних» сценариев.
nckma
28.05.2019 11:51На мой дилетантский взгляд кажется, что каждый новый кодек требует все больших вычислительных ресурсов. Экстраполируя в будущее, предполагаю, что возможно кодеки будут делать что-то вроде 3д рендеринга. Например, у персонажа есть 5 костюмов. Кодек сохраняет текстуры этих костюмов в начале ролика и далее рендерит их на персонажа при любом освещении, ракурсе и т.д… Требуются огромные ресурсы у клиента, но вероятно сжатие будет очень высоким. Передавать нужно будет только вертексы объектов и натягивать закешированные текстуры.
3Dvideo Автор
28.05.2019 12:02Если в общем: Подобные идеи были модными еще почти 20 лет назад при разработке расширений MPEG-4. В итоге получился мертворожденный стандарт (большинство расширений стандарта собирают пыль на полках, так никогда и не уйдя в жизнь). Поскольку мощность железа продолжает расти, попытки ее эффективно задействовать конечно будут, вопрос успешности.
Если конкретно: вы говорите про free view rendering, это большая активно развивающаяся область, но там в общем случае до успеха еще довольно далеко. Хотя для узких спортивных кейсов ее скоро порешают. Забавно, что в MPEG-4 было расширение с поддержкой DIBR (Depth Image-Based Rendering) — эффективное сжатие вольюметрических моделей, 20 лет спустя можно смело прогнозировать ренессанс темы.
drWhy
28.05.2019 12:18Если уж речь зашла о ренессансе и экстраполяции видео, здесь просто обязана быть
эта картинка
3Dvideo Автор
28.05.2019 12:35Да, это типичное свежее нейросетевое чудо ). Виктор Лемпицкий с товарищами отжег, конечно.
Aquahawk
28.05.2019 12:35Блин, вот у меня есть совершенно потребительский вопрос, у меня есть архив видео, снятый разными камерами, старой видеокамерой Sony, Canon 60D, зоопарком телефонов, иногда в слоумо. Я хочу всё пережать и привести в один стандарт. И я ничерта не понимаю какой битрейт мне нужен. И мне условно пофиг сколько времени на пережатие уйдёт, i7 на пару месяцев могу выделить. Но битрейт нужен разный под разные видео. Есть ли инструмент в котором можно было-бы выбрать абстрактное качество видео, и пусть он пережуёт всё что надо? Я знаю про двупроходное кодирование, но оно всё-равно имеет целью заданный средний битрейт, вот его не понятно как выбрать.
3Dvideo Автор
28.05.2019 12:511. Вам нужен не фиксированный битрейт, а фиксированное качество (модный сейчас constant quality), чтобы даже если сцена с сильным движением — она все равно смотрелась хорошо. Это отдельная тема сейчас, более сложная чем старое фиксированное квантование.
2. Да, вам нужен конкретный всеядный продукт, тут я не слежу за новинками, увы. Но люди подсказать могут, надеюсь )
drWhy
28.05.2019 13:04Вопрос в цели.
Хотите просматривать любое видео из зоопарка однотипно — смотрите с компьютера, используя, например VLC media player. Он справляется почти с любыми комбинациями контейнеров/кодеков. Ничего не нужно пережимать, качество не ухудшится, простодобавляйтеменяйте накопители на более ёмкие, ну и какая-нибудь программа-каталогизатор понадобится, чтобы не заблудиться в зоопарке.
Хотите избавиться от наследуемых форматов пережав всё и выбросив все исходники?
Жмите в сторону лучшего устройства, т.е. Canon'а. Да, у смартфона может быть выше разрешение, но более шумная матрица и оптика попроще. Full-HD на 40" смотрится всё еще пристойно.
Лучше всё-таки не пережимать — потери будут всегда, а экономия пространства после пережатия быстро съестся очередным гаджетом с 100500 мегапиксельной камерой с очередным модным кодеком.3Dvideo Автор
28.05.2019 14:14Некоторые камеры (особенно старые) по умолчанию генерируют фактически MotionJPEG поток. Оно может быть не в этом стандарте, но внутри поток из одних I-frames. Такие потоки можно пережимать практически без потерь качества с экономией раз в 10.
Если поток хотя бы H.264, то много наиграть не получится, а потери качества точно будут, это правда.drWhy
28.05.2019 14:27Ещё можно без перекодирования видеопотока перебросить в другой контейнер, например, тот же MotionJPEG из .mov в .mkv или в .avi (убавится хотя бы зоопарка расширений, да и медиаплеерам файл станет понятнее). Звук при этом можно сжать, иногда получив заметную экономию.
Tallefer
28.05.2019 15:48Еще хочется добавить, что Motion JPEG имеет одно редкое и полезное свойство — его кадры можно обрезать (кропать) без потерь, ну то есть как обычный жпег — по сетке 8 (или 16?) пикселей.
Пример использования — какие-нибудь записи с камер, где много «мертвого» пространства, а еще «перекодирование» какого-нибудь сверхширокого формата в обычный 16:9, а то и 4:3, чтобы справлялось старое железо и картинка без полей была.
Вполне возможно, какой-то более редкий лосслесс кодек тоже это умеет, но я исходил из того, что умел FFMpeg на тот момент. :)3Dvideo Автор
28.05.2019 16:58кадры можно обрезать (кропать) без потерь, ну то есть как обычный жпег — по сетке 8 (или 16?) пикселей
Есть такое свойство ).
Сетка зависит от режима прореживания цветовых компонент, все что не 4:4:4 (4:2:0 или 4:2:2 например — можно посмотреть в свойствах файла) — это сетка из 16х16 пикселей. 4:4:4 — это 8x8.
Tallefer
28.05.2019 17:43О, спасибо за ликбез. :) И вообще спасибо за сайт, программы сравнения кодеков (хотя не все заработали, уже не помню почему) и проделанную работу — здорово помогло, когда изучал актуальные кодеки и параметры, чтобы выбрать какой-то для конечного формата перекодировки с камеры. Да и для общего развития интересно было почитать. :)
3Dvideo Автор
28.05.2019 18:05+1Вам наше пожалуйста! :) По сжатию на широкую аудиторию еще делать будем, ибо мифов — море.
Barafu_Albino_Cheetah
29.05.2019 05:57Мне попалось видео со старой камеры. Размытое, но 720p, и формат WMV. Пережал его, уменьшив до 480р, в результате файл уменьшился с 1.2 Гб до 90Мб, а видимой разницы никакой. А у кого-то таких файлов могут быть залежи.
mOlind
28.05.2019 14:53В большинстве случаев перекодирование не добавит качества. Сжатие с потерями, на то и сжатие с потерями.
Eagle_NN
28.05.2019 16:37+1Любое, повторю, ЛЮБОЕ пережатие между форматами с потерями ведет к деградации качества.
Чем больше итераций пережатия будет, тем хуже будет качество материала.
Более того, по своей сути сжатие с потерями так или иначе основана на выделении значимых и не значимых кусков исходного материала, при этом незначимые куски откидываются или сильно деградируют.
Большая часть преймущества современных кодеков — имено в наилучшем выборе таких кусков, которые можно сильно деградировать/отбросить.
Если же мы на вход подаем материал уже деградированый другим кодеком, то эта эффективность стремительно теряется. Более того, она вносит дополнительную деградацию в те куски которые после первой стадии сжатия оставались «хорошими».
Как результат пережатое видео лучше вообще не пережимать без сильной аргументации на это.
Чтобы смотреть все подряд — лучше использовать кодек паки или всеядные просмотрщики, так хоть что то будет видно на записи снятой старым телефоном :)
По процессору отдельная тема. На рядовом i7 пережатие видео в новомодные форматы может производиться со скоростью, к примеру, 1-2 кадра в секунду (при всех максимальных настройках). А это значит, что ролик в 10 минут, будет пережиматься около 4 часов. Так что при наличии архива записей пары месяцев может не хватить :)drWhy
28.05.2019 16:52Чтобы смотреть все подряд — лучше использовать кодек паки или всеядные просмотрщики
Голосую за второе. Установка кодек-паков (особенно нескольких, «для верности») чревата наличием в системе нескольких кодеков, условно подходящих для воспроизведения контента. Причём выбран будет не обязательно лучший и не всегда с оптимальными настройками.
Ещё бывает, заканчивается триальный период какого-нибудь платного кодека, но пользователь не получает сообщения об этом или не может понять его смысла.
В итоге, может перестать воспроизводиться определённый тип видеофайлов.
3Dvideo Автор
28.05.2019 16:54+1Любое, повторю, ЛЮБОЕ пережатие между форматами с потерями ведет к деградации качества.
С оговоркой на MotionJPEG и форматы сжатия с поддержкой режимов сжатия без потерь.
Чем больше итераций пережатия будет, тем хуже будет качество материала.
И тоже с оговоркой. Мы в свое время проводили эксперименты с многократным пережатием. Там есть тоже свои нюансы, ибо можно сжимать так, чтобы качество при пережатии почти не деградировало. Это свойство алгоритмов сжатия актуально при редактировании видеоматериала, когда хотелось бы держать материал сжатым, но минимально терять качество при итерациях редактирования. Минимизировать потери возможно, если об этом заботиться.
А в целом — да, лучше пережимать пореже ), согласен совершенно.
Скажу больше — если вообще не пережитьмать, то лет через 20 можно будет с большой вероятностью успешно увеличить разрешение материала (например, сделать HD из старой SD записи). При этом даже одна итерация пережатия кардинально снижает успех этого мероприятия.Eagle_NN
30.05.2019 00:08+1То что это применимо только для алгоритмов с потерями я как раз и написал :)
При пережатии другим кодеком с потерями качество будет всегда деградировать, т.к. происходит выполнение следующей последовательности:
1) Оригинальное изображение
2) Деградация качества для оптимальной работы кодека (например блочность, или разнесение на слои)
3) При декодировании фильтры воспроизведения «додумывают» картинку, чтобы избавиться от артефактов
4) Это «придуманное» изображение деградирует для оптимальной работы нового кодека (а если установлен режим Constant Quality, то и для такого-же кодека как и в пункте 2 будут выбираться другие зоны для деградации)
5) При воспроизведении декодер опять «додумывает» изображение.
Т.е. чем больше таких итераций, тем больше циклов деградации и «додумывания» (восстановления) будет. А значит оригинальной информации будет все меньше и меньше.3Dvideo Автор
30.05.2019 08:16На практике там скучные математические преобразования, а не «додумывание» )
В итоге есть варианты, при которых при определенном устройстве декодера и энкодера возможно в точности «попадать» в старые коэффициенты и всегда одинаково сжимать кусок, если он не изменялся. Да, при этом этом придется отключить часть модных фич, но это возможно.
Тема слабо востребована, но она реализуема в рамках текущих стандартов.
sumanai
30.05.2019 11:05А нет ли однокнопочных программ для такого сжатия «без потерь»? А то для картинок есть.
3Dvideo Автор
30.05.2019 11:29И даже для MotionJPEG есть. А так — не встречал.
Повторюсь — мал спрос. По факту народ мало парится по поводу потерь, которые не видно на глаз. А то бы давно сделали)flashmozzg
30.05.2019 23:01AV1 и hevc могут в Lossless. Но для этого спец. кодеки обычно разрабатываются, для архивов всяких.
3Dvideo Автор
30.05.2019 23:02Чистый lossless, понятно, хорош, но степень сжатия сразу катастрофически падает по сравнению с описанным выше режимом.
Javian
31.05.2019 05:56Если говорить о «без потерь», то был кодек Huffyuv/Lagarith — что-то вроде сжатия архиватором каждого кадра ru.wikipedia.org/wiki/Huffyuv
dsapsan
28.05.2019 15:54К сожалению, такой подход (подлога) встречается довольно часто. Работал в одном полу-государственном НИИ, где все достижения на полном серьёзе именно так и презентовались. При этом дополнительно делалась ставка на максимальный охват — как можно больше публикаций, выступлений на конференциях, патентов. Причём, судя по тем же конференциям, такой подход вообще довольно популярен (по крайней мере в России).
3Dvideo Автор
28.05.2019 16:44Печаль.
Могу сказать две вещи:
1. Сильно не везде в России так, довольно много мест, где реально все еще делом занимаются даже в госконторах.
2. В Китае ситуация с фейковыми публикациями (особенно внутри) хуже чем у нас на порядок (если не сильнее). У нас, как ни странно, по крайней мере технические направления держатся.drWhy
28.05.2019 17:00-12. Зато в Китае уже есть система социального кредита.
НИИ ССК — это звучит гордо.3Dvideo Автор
28.05.2019 17:082 недели назад был в Пекине в Запретном городе. Такого количества нахальных самоуверенных громко говорящих колхозников, сколько на посещении Запретного города, я не видел никогда в жизни. Это толпы людей с одной извилиной (интеллект на лице не просматривается вообще), которых срочно надо как-то вводить в какие-то рамки. Коллега ехал на высокоскоростном поезде, был в шоке. Через 2 часа пол был весь в обертках от еды и т.д. Под конец поездки был натуральный свинарник, где все эти люди чувствовали себя крайне комфортно. И это все на скорости 300 км/ч в интерьерах из будущего. Не уверен, что социальный кредит их спасет, но они явно пытаются хоть что-то сделать ) Учитывая скорость роботизации Китая и скорость роста зарплат — это сверхнеобходимость. Возможно запоздавшая )))
DistortNeo
28.05.2019 23:14Никогда не был в Пекине. Видимо, и не поеду туда теперь. В других местах Китая (Чунцин, Чэнду, Ханчжоу, Циндао) было очень чисто и приятно находиться. Но это ещё и особенность Китая: не там чисто, где не мусорят, а там, где постоянно ходит дворник и тут же подбирает мусор.
perfect_genius
28.05.2019 17:24Существуют ли плееры, позволяющие проигрывать одновременно два видео и имеющий «шторку» посередине, чтобы мышкой перетягивать влево-вправо и сравнивать эти видео?
maedv
28.05.2019 17:42Примерно похож редактор VirtualDub2, два окна, в одном исходник, в другом после обработки на лету
Tallefer
28.05.2019 17:45Могу сильно наврать (давно дело было), но мне кажется, у автора статьи на сайте были как раз такие проги или плагины для плееров, которые позволяли еще и визуально посмотреть различия тестируемого материала :)
3Dvideo Автор
28.05.2019 18:07+1Каюсь, есть такое )))
Javian
28.05.2019 18:27off Пару недель назад развлекался сжиманием в HandBrake файла в DV. У меня этот DV-файл с видеокамеры давно лежит, пережив несколько ПК и HDD, и своего рода образец для измерения производительности ПК при кодировании видеокодеками в менее объемные файлы.
Причина экспериментов с HandBrake — попалась на глаза на хабре статья от Intel о QuickSync Encoder. Действительно кодирует быстро, но если важно оригинальное качество, то лучше оставить в DV. x264 хоть с ускорением, хоть без, хоть с огромным битрейтом — артефакты сжатия оригинала можно найти.
ofmetal
28.05.2019 20:10Как я понимаю работу кодеков.
Каждый кадр бьётся на блоки, и эти блоки (максимально похожие на них) ищутся в предыдущих (примерно 5, но можно и 16) кадрах радиально-недалеко (в 8 разных направлениях, но бывает и в 32) к текущему блоку. Блоки примерно от 4х4 до 64х64 пикселя. Блоки копируются (без афинных преобразований) как есть. Получившаяся разница кодируется дополнительно позже.
Вопрос!
Львиная доля видео в мире, это видео движущейся примерно вперёд камеры. Видеорегистраторы, квадрокоптеры, экшен-камеры. Где очередной кадр сильно похож на предыдущий, только «растянутый» слегка, а также на следующий кадр, только «растянутый» в обратном направлении. Интуитивно кажется, что применив здесь специализированнй подход — чтобы вся серия кадров строилась на однообразном простейшем преобразовании. Щепотки бит буквально достаточно для описания однообразного преобразования. Дополнительная разница с реальным кадром аналогично будет кодироваться позже.
Реализовано ли такое где-то сейчас? Или разница между растянутым кадром и кадром с камеры, сдвинутой в пространстве, слишком велика и потребует сравнимого количества бит и поэтому такой подход не используется?3Dvideo Автор
28.05.2019 20:45Идея старая. И нерабочая. Глобальное преобразование на практике была попытка применить к кадру еще в расширениях MPEG-4 (которые благополучно умерли).
По факту:
Во-первых, все ощутимо сложнее. Например, есть B-frames, которые и повышают сжатие, и важны, когда идет навигация по файлу (и в которые вектора как с прошлых, так и с будущих кадров).
Во-вторых, если картинка резкая, а не замыленная, то важны субпиксельные сдвиги. И нам важен блок, максимально похожий, например, с четвертьпиксельной точностью. Они находятся и это работает. Это сразу убивает вашу идею.
И, в-третьих, арифметическое сжатие очень эффективно (в доли бита) сжимает вектора, если у вас они смотрят в одну сторону. Т.е. панорамирование (дрон поворачивает) обходится на самом деле достаточно дешево. По крайней мере экономия на более точной компенсации позволяет намного больше потратить на вектора, там нет смысла какой-то один большой вектор сохранять.
Как-то так, если кратко.ofmetal
28.05.2019 21:48Да, жаль. Стало быть, архив видео с квадрокоптера на 1.44" дискете не получится разместить)
И тонкая настройка x264/x265 тоже наврядли лучше placebo (у них же) справится с такими видео?3Dvideo Автор
28.05.2019 22:51И тонкая настройка x264/x265 тоже наврядли лучше placebo (у них же) справится с такими видео?
Может и лучше.
Пример был в статье:
На этом видео звезды так легли, что можно сжать в разы быстрее placebo, причем примерно на треть сильнее при этом. Представление, что placebo обеспечивает максимально возможное сжатие (оно же так долго работает!) — это популярный миф.ofmetal
29.05.2019 22:15На всякий случай спрошу, нет ли у вас готового ответа, на вопрос, какие настройки нужно подкрутить, чтобы квадрокпотерное видео (FHD и 4K) кодировалось быстрее и качественнее (кодеки x264 и x265)? Как на вашей картинке, например)
Пробовал плацебо на x265 @ FHD — просто невозможно использовать, на 8+8 ядерном компе фпс сильно меньше 1 получался. Кодирую в Constant Quality, CRF=22 чтоли ставил.Javian
30.05.2019 06:25попробуйте Intel Quick Sync habr.com/ru/company/intel/blog/311320
Только проверьте качество результата.3Dvideo Автор
30.05.2019 08:02Да, в тестах участвовали много лет подряд и по соотношению скорость-качества в свое время всех порвали, как минимум пробовать стоит.
Javian
30.05.2019 08:43Местами у меня вылазили сильные дефекты. Если бы можно было указать участки видео, где использовать это ускорение, а где качественно просчитать по старинке.
3Dvideo Автор
30.05.2019 09:49Если это места с сильным движением, то частично это параметрами лечится.
Вообще тема настройки — большая тема, к сожалению.
3Dvideo Автор
30.05.2019 07:59+1На всякий случай спрошу, нет ли у вас готового ответа, на вопрос, какие настройки нужно подкрутить, чтобы квадрокпотерное видео (FHD и 4K) кодировалось быстрее и качественнее (кодеки x264 и x265)? Как на вашей картинке, например)
Если бы был какой-то один волшебный пресет — его бы уже прошили в стандартные, т.е. на этот вопрос нет простого ответа.
Вообще возможно стоит на эту тему отдельный пост. Разобрать мифы, обозначить возможности, разобрать сложности. Стоит писать?ofmetal
30.05.2019 08:26Да, было бы очень круто, а то смотришь на эту груду параметров — многие каракули там ни о чём не говорят.
3Dvideo Автор
30.05.2019 09:52Многие параметры коммерческих кодеков даже нам ничего не говорят (настолько абстрактно их описание в документации)))), а мы параметры кодеков профессионально вертим уже без малого 20 лет.
К счастью, это не означает, что их нельзя подобрать и улучшить )
Но там масса сложностей, начиная с чисто вычислительной, увы…
mkarev
28.05.2019 21:48Реализовано ли такое где-то сейчас?
В драфте VVC есть "affine motion compensation": https://jvet.hhi.fraunhofer.de/
Работает ооочень медленно (енкодер)
На сценах c вращением типа "In to tree" из стандартных тестовых последовательностей
рвет в тряпки все классические блочные кодеры (прирост порядка +40% по BD-Rate)3Dvideo Автор
28.05.2019 23:27Посмотрел, кросс-чек Роман Черняк из русского Хуавей (а ранее — из Элекарда) делал, т.е. можно спросить, как оно вблизи и на разных видео выглядит. Ибо с ходу я что-то хорошего анализа что там не нашел. Кстати, предсказание остается блочным. И если я правильно распарсил
www.researchgate.net/publication/328438797_An_Improved_Framework_of_Affine_Motion_Compensation_in_Video_Coding основной выигрыш таки за засчет субпиксельных сдвигов, однако теперь при поворотах )
Вообще ранее от такого подхода отказались, поскольку он был неэффективен по соотношению затраченное время/результат. Посмотрим, что будет в этот раз. У них AV1 появился в сильных компетиторах. Спасибо за наводку!
mkarev
29.05.2019 04:10Поправка — сцена с движением "blue_sky" https://media.xiph.org/video/derf/
PS: Я делал бенчмарки когда он был еще JEM'ом, но идея вроде как сохранилась
vk000
29.05.2019 08:55Про это ещё есть блестящая старая статья Dark Shikari (одного из разработчиков x264 и эксперта по видеокодекам): «How to cheat on video encoder comparisons». Там прямо по косточкам разложено всё.
(Ссылка на archive.fo потому что блог, увы, удалён. Вот тут есть сделанная кем-то копия текста, но там убилось форматирование.)3Dvideo Автор
29.05.2019 09:01Да, это отличный текст про следующие (менее увлекательные) уровни читинга при сравнении кодеков. И обратите внимание, как он жестко пишет о том, как компании себя измеряют ) (часто внаглую некорректно измеряя конкурента).
Шикари нам массу предложений по изменению сравнения выкатил, мы многие реализовали. Интересно, что в целом это сделало сравнения совершенно непригодными для широкой публики (слишком много графиков), но профессионалы рады — картина (кто где реально лучше, кто где хуже) яснее.
ValdikSS
29.05.2019 23:22+13DVideo, может, не совсем подходящая тема для вопроса, но какой кодек использовать для скринкастов?
10 лет назад я писал скринкасты в Microsoft Video 1, в RGB555. 10 минут видео занимало 200-250 мегабайт, но ужималось компрессором до 1.5-2 мегабайт(!). Качество видео было постоянно высоким, и всё выглядело отлично, в т.ч. из-за отсутствия субдискретизации цвета.
Аналогичное видео в VP9 или H.264 получается раза в 3-6 больше по размеру.
Есть ли какой-то рекомендуемый кодек для скринкастов?3Dvideo Автор
30.05.2019 08:07Скринкаст скринкасту рознь. Тьюториал по статическому интерфейсу — одно, прохождение игры-шутера — совсем другое. На этот вопрос нет простого ответа.
Вообще думаем про отдельный пост с разбором оптимизации параметров под контент. Разобрать сложности, обозначить сколько можно наиграть, почему это сложно, как можно действовать на практике и т.д.
Стоит писать? Какие вопросы были бы интересны?Tallefer
30.05.2019 14:55Страдал точно такой же фигней, как и товарищ выше. :) И тоже остановился на каком-то кодеке, который потом винраром сжимался адски и вызывал поначалу этим легкий шок. :)
Да, писать однозначно стоит, хотя бы ради вопроса качественных гуи-скринкастов, с динамичной картинкой-то в принципе все те же приемы, что и с живым видео.
Просматривается некая аналогия с жпег против пнг, кстати. :)3Dvideo Автор
30.05.2019 23:00тоже остановился на каком-то кодеке, который потом винраром сжимался адски
Ужас какой… Где вы такие берете…
Да, писать однозначно стоит, хотя бы ради вопроса качественных гуи-скринкастов,
Принято. Еще вопросы в теме, которые интересны, приветствуются.Tallefer
31.05.2019 04:35Ну где-где… тут вариантов только два: либо это был встроенный в Камтазию кодек, либо один из тех, что идут в мегакодекпаке :)
Что еще было круто, так это возможность установить всего 1 кадр в 30 секунд для предельной экономии места (записывал какую-то динамическую страницу).
Во, вопрос кстати вспомнился в связи со скринкастами: примерно в то же время я нашел какую-то мелкую программу, которая писала скринкасты в файл формата флэша (ну почти как все), но — сжатие, в отличие от других, достигалось невероятное (заметнее всего — на почти статических моментах), и у меня вопрос частично по формату (программу ту я посеял и не смог найти снова с тех пор, о чем жалел не раз) — возможно ли, что та прога делала не просто сжатие картинки, а сперва анализировала геометрию оконного менеджера и, грубо говоря, записывала не тупо покадрово, а делала смещение прямоугольников при движении окон и других объектов по экрану и писала не просто видеопоток, а еще и описания всего? Ну почти как кодеки анализируют предыдущий и следующий кадр для лучшего сжатия. Ведь технически это не должно вызывать большие трудности, верно? :)3Dvideo Автор
31.05.2019 10:12Ведь технически это не должно вызывать большие трудности, верно? :)
Если с конца начинать, то имейте ввиду, что обычно ответ на этот вопрос «нет» ))), особенно если легкие решения на каждом углу не лежат. Очень часто простые в постановке задачи сложно решаются.
По поводу сжатия такого контента — есть даже отдельное направление — Screen Capture Codec, коих кодеков было создано довольно много (в том числе мы делали). И софта подобного тоже очень много. Там несколько параметров — и собственно их баланс и тюнингуется. Это если кратко. Если подробно — можно большой пост только про алгоритмическую часть написать.
drWhy
31.05.2019 13:03Анализировать геометрию уже отрисованных примитивов накладно (всякие градиенты, тени, субпиксельные эффекты). Но никто не мешает перехватывать все вызовы GUI, записывать их часть, соответствующую изменениям в зоне интереса, паковать, а при воспроизведении передавать обратно GUI для отрисовки. Плотность будет максимально возможная, нагрузка на cpu/gpu околонулевая, потребление памяти минимальное.
Под Windows это довольно затруднительно, но есть ReactOS, Kolibri.
Также существовали векторные дисплеи, отрисовывавшие вызовы аппаратно. Даже сейчас в драйверах устройств отображения под Windows есть набор флагов, соответствующих наличию реализации различных векторных функций. Если бы развитие подобных дисплеев продолжилось, офисный дисплей можно было бы подключать через com порт, а не hdmi. И, вероятно, офисный компьютер мог бы питаться от солнечной батареи, как калькулятор.
Речь, конечно, только о графическом интерфейсе, офисные приложения без 3d и видео котиков в 4k.
napa3um
30.05.2019 03:54Инвесторов научили биологии, отучив от элексиров бессмертия, научили химии, отучив от философского камня, научили физике, отучив от вечных двигателей. Теперь вот учат информатике (теории информации), отучая от магии нейросетей. Нейросети оказались скучными статистическими алгоритмами для работы с данными, а не волшебной палочкой, рождающей байты из пустоты. Когда же нам уже разрешат инвестировать во что-нибудь нормальное? Телепортацию когда подвезут?
3Dvideo Автор
30.05.2019 08:11У вас хорошие поэтические аналогии! )
Впрочем — судя по тому, что ежегодно успешно патентуется несколько идей вечных двигателей, отучили не всех. Да и в биологии ситуация не волшебна. Впрочем в нейросетях кратно хуже ))) Человеку свойственно верить в чудо.
masai
31.05.2019 12:10Инвесторов научили биологии, отучив от элексиров бессмертия, научили химии, отучив от философского камня, научили физике, отучив от вечных двигателей. Теперь вот учат информатике (теории информации), отучая от магии нейросетей. Нейросети оказались скучными статистическими алгоритмами для работы с данными, а не волшебной палочкой, рождающей байты из пустоты.
В отличие от эликсира бессмертия, философского камня и вечных двигателей, нейронные сети — это рабочий инструмент, который успешно применяется на практике. Весь хайп из-за того, что неспециалисты не понимают их возможностей и границ применимости. Ну и название даёт некий налёт фантастичности, что тоже смущает обывателя.
APXEOLOG
Отличная статья, спасибо! Теперь буду скептичнее относиться к очередному "убийце джипега"
3Dvideo Автор
Старине JPEG-у уже 28 лет, стандарт времен бронзового века по компьютерным меркам. Его замена вполне возможна еще со времен JPEG-2000, а сейчас с нейросетями и подавно. Другое дело, что это вряд ли будет стартап с громкими заявлениями )))
nckma
Хм… вы же только что писали, что скептически относитесь к нейросетям?
3Dvideo Автор
Внимательно следим за руками! )
Эти тезисы не противоречат друг-другу! ) Но они объясняют, почему инвесторы несут хорошие деньги в ИИ-стартапы и почему разных чудес в новостях от них будет в ближайшие годы заведомо много.
drWhy
Есть добрый анекдот про пропавшую серебряную ложку, обнаружившуюся в кармане соседа фокусника по столу.