CQP — один из нескольких алгоритмов рейтконтрола в x264. С чего вы решили, что кодирование без постоянного квантайзера невозможно?
С чего вы решили, что при количестве B-кадров больше 1-2 будут проблемы с вопроизведением? Может, перепутали с рефами? А на каких устройствах?
Почему вы решили, что значение --merange 8 будет оптимальным для всех источников? Это по меньшей мере в два раза меньше значения, используемого иксом по-умолчанию для всех пресетов.
Почему вы решили, что использовать deadzones лучше, чем trellis? Почему вы называете его сглаживающим фильтром, работающим по принципу Гаусса, которым он не является?
О части других ошибок я уже написал выше.
У меня вопрос: вы пробовали смотреть в то, какие настройки получается при использовании обычного --preset veryslow? Они там совершенно отличные от ваших и на это есть причина. ;) Я советую вам всё же подумать, почему ваш гайд отличается от абсолютного большинства рекоммендаций, исходящих как от самих разработчиков энкодера, так и от просто опытных пользователей. Кстати, вы пробовали читать хоть какие-то полноценные гайды? Потому что у меня складывается впечатление, что нет.
Если кто-то хочет научиться кодированию видео и не может в английский, делать это можно в неплохом разделе на рутрекере, где есть много интересных тем с адекватными людьми.
В статье же вредных советов примерно столько же, сколько и самих советов. Начиная от использования не-фреймаккуратного DirectShowSource (который вряд ли нужен с учетом того, что икс умеет открывать большинство файлов самостоятельно через ffms2), проходя через откровенно странную информацию (выставление QP Factor не имеет смысла с CQP ибо квантайзер и так постоянный) и заканчивая настройками, способными убить горы битрейта вникуда (CQP в x264 это маразм, ровно как и отключение анализа, такое мизерное количество B-кадров и т.д.).
используя параметр --force-cfr (перевод в режим кодирования с постоянным качеством)
cfr != crf. Cfr это постоянная частота кадров. --crf-max тоже в принципе бесполезен в абсолютном большинстве случаев, а кому полезен — сами знают об этом.
Ребят, я вас умоляю — разберитесь в теме хоть немного, прежде чем давать советы.
Да, пробовал. Оно помогает с диалогами, но все остальные шрифты вроде описаний предметов остаются очень маленькими.
Видимо, придется расчехлять 1080p-монитор.
Многопоточность может помочь когда будет какой-нибудь asm.js. Пока даже в условиях идеальной параллельности, 8 потоков фактически сократят время блюра в 8 раз, или 400/8 — 50мс в хроме, что всё равно слишком медленно.
Буфер тоже не поможет. Он подразумевает, что вы потом сможете заполнять этот буфер достаточно быстро уже во время воспроизведения, либо буфер будет достаточно большим, чтобы компенсировать лаг. В случае с JS, придется загрузить большую часть видео, что может не очень понавится пользователю.
Ну и я не понял, при чем тут работа кодеков. В десктопных программах типа VirtualDub фильтр blur, приведенный в статье, легко может выполняться на ~800фпс на 1080p (чуть больше 1мс на кадр), что более чем достаточно для работы в реальном времене. Собственно, наличие фильтров в ffdshow подтверждает работоспособность идеи, при этом ffdshow уже много много лет.
Основная идея подобной постобработки — устранение дефектов видео, которые мешают просмотру. Если асбтрактному пользователю ничего не мешает — он может ничего не включать. Главная ЦА — большие десктопные мониторы, на мелких экранах мобильных устройств качество стрима такой большой роли не играет.
В любом случае, при адекватной реализации (не в JS), нагрузка на процессор минимальна и сравнима с декодированием.
Из очевидных: деблок, дебанд, повышение резкости, блюр, добавление шума, качественный ресайз. Из редко, но иногда полезных: деинтерлейс, корректировка уровня (TV->PC и наборот), шумодав (опционально — временнОй) и сглаживание движения (madVR-овский smooth motion).
Скорее всего, для реализации потребуется еще RGB<->YUV конвертирование, ибо писать подобные фильтры прямо в RGB может быть неприятно.
Большинство из этих фильтров по сложности в разы превосходит всё то, что сейчас предоставляет seriously.js.
Кнопка «Пуск» теперь еще больше похоже на то, к чему все привыкли.
Возможность запускать Metro UI приложения в десктоп режиме, в окне.
Посмотрел keynote, почитал The Verge и не совсем понял: вроде как в первом апдейте будут только полноэкранные метро-приложения на панели задач и всякие модификации для «живых плиток», а новый пуск и приложения в окне появятся later this year?
Поясните, пожалуйста.
Есть три вопроса:
1) Существуют ли какие-нибудь ограничения на некоммерческое распространение софта, скопилированного со студенческой версией компилятора? Может ли студент распространять библиотеки Intel, если они слинкованы динамически?
2) Планирует ли когда-нибудь некоммерческое лицензирование для других платформ, в частности Windows? Например, у нас тут есть одна довольно активно растущая экосистема, которая зачастую получает серьезные профиты от ICL, но пока работает только на Windows. Продавать её никто не собирается, поэтому некоммерческая лицензия была бы кстати.
3) Являются ли добровольные донаты нарушением некоммерческой лицензии?
Да никто не спорит, что C код писать, чаще всего, быстрее и проще. И он может быть даже векторизуется при нужном положении луны нужным компилятором. Не оптимально, но векторизируется.
Просто мы пока ну очень далеко от состояния, когда можно будет отдать всё компилятору. Вы когда-нибудь видели автовекторизатор, использующий pmaddwd? А сложные шаффлы с pshufb? А punpck**? Может, это обработка видео такая странная, но у меня от автовекторизаторов сплошное разочарование.
Но речь не об этом. Я просто хотел сказать, что интринсики, да и чистый асм — не абсолютное зло, и не надо их бояться. Если есть желание писать на них универскальный код — это можно сделать. Да, он будет менее читаем, он будет требовать от вас больше знаний, его будет сложнее «поддерживать». Зато без привязки к компилятору (ну разве что иногда производительно интринсиков в vc хромает), без дополнительных зависимостей, без платных тулзов.
Ну и насчет переписывания кода под новые инструкции — мне кажется, вы преувеличиваете. Даже сейчас многие пишут чистый SSE2-4, ибо огромная база пользователей нормальную реализацию AVX(2) не увидит еще несколько лет (с быстрыми vgather, например). Если уж критично использовать всегда последний сэт инструкций — почему бы не OpenCL? Там и перекомпилировать не придется, всё в рантайме.
Я не зря сказал «для довольно простых алгоритмов». Вы не поверите, но довольно большому количеству рутин достаточно SSE2 набора инструкций. Да, конечно, полезные инструкции есть везде, но не всегда они нужны.
А насчет того, что темплейт медленней интринсика, вы не правы. Рантайм цена темплейтов в принципе нулевая, если они инлайнятся. А если не инлайнятся, то всегда есть __forceinline.
Никто ведь особо не мешает написать темплейт-обертку над интринсиками. Должно быть достаточно для довольно простых алгоритмов, где единственный плюс новых инструкций — увеличенный размер регистра (который растет раз лет в 8). Да и если появляется что-то важное, темплейты всегда можно специализировать.
Да, такой код будет менее читаем, чем автовекторизуемый C, но не будет привязан к компилятору и его возможности векторизировать.
Такое делают и на чистом ассемблере давно, но это может быстро превратиться в макросовый ад.
Ну и насчет переключения режима работы процессора — есть такая инструкция, как vzeroupper, которая позволяет этого гигантского штрафа от переключения избежать. Конечно, писать вмеремешку SSE2 и AVX код всё равно не стоит, но и ужасных >100 циклов вы не потеряете.
Спасибо за статью!
Интересно было бы реализацию для фильтра с произвольным радиусом. Понятно, что оптимальные сети сортировки для маленьких радиусов известны и могут быть легко реализованы по-отдельности, а что делать в SIMD с большими областями?
Не всегда выход, поскольку требует содержать отдельную рутину для обработки планарного RGB, в то время как pshufb позволяет использовать одну и ту же рутину для RGB32 и RGB24 с разницей лишь в пару инструкций.
Кроме того, а как паковать обратно-то будем? :)
С чего вы решили, что при количестве B-кадров больше 1-2 будут проблемы с вопроизведением? Может, перепутали с рефами? А на каких устройствах?
Почему вы решили, что значение --merange 8 будет оптимальным для всех источников? Это по меньшей мере в два раза меньше значения, используемого иксом по-умолчанию для всех пресетов.
Почему вы решили, что использовать deadzones лучше, чем trellis? Почему вы называете его сглаживающим фильтром, работающим по принципу Гаусса, которым он не является?
О части других ошибок я уже написал выше.
У меня вопрос: вы пробовали смотреть в то, какие настройки получается при использовании обычного --preset veryslow? Они там совершенно отличные от ваших и на это есть причина. ;) Я советую вам всё же подумать, почему ваш гайд отличается от абсолютного большинства рекоммендаций, исходящих как от самих разработчиков энкодера, так и от просто опытных пользователей. Кстати, вы пробовали читать хоть какие-то полноценные гайды? Потому что у меня складывается впечатление, что нет.
Если кто-то хочет научиться кодированию видео и не может в английский, делать это можно в неплохом разделе на рутрекере, где есть много интересных тем с адекватными людьми.
В статье же вредных советов примерно столько же, сколько и самих советов. Начиная от использования не-фреймаккуратного DirectShowSource (который вряд ли нужен с учетом того, что икс умеет открывать большинство файлов самостоятельно через ffms2), проходя через откровенно странную информацию (выставление QP Factor не имеет смысла с CQP ибо квантайзер и так постоянный) и заканчивая настройками, способными убить горы битрейта вникуда (CQP в x264 это маразм, ровно как и отключение анализа, такое мизерное количество B-кадров и т.д.).
cfr != crf. Cfr это постоянная частота кадров. --crf-max тоже в принципе бесполезен в абсолютном большинстве случаев, а кому полезен — сами знают об этом.
Ребят, я вас умоляю — разберитесь в теме хоть немного, прежде чем давать советы.
Видимо, придется расчехлять 1080p-монитор.
Буфер тоже не поможет. Он подразумевает, что вы потом сможете заполнять этот буфер достаточно быстро уже во время воспроизведения, либо буфер будет достаточно большим, чтобы компенсировать лаг. В случае с JS, придется загрузить большую часть видео, что может не очень понавится пользователю.
Ну и я не понял, при чем тут работа кодеков. В десктопных программах типа VirtualDub фильтр blur, приведенный в статье, легко может выполняться на ~800фпс на 1080p (чуть больше 1мс на кадр), что более чем достаточно для работы в реальном времене. Собственно, наличие фильтров в ffdshow подтверждает работоспособность идеи, при этом ffdshow уже много много лет.
В любом случае, при адекватной реализации (не в JS), нагрузка на процессор минимальна и сравнима с декодированием.
Скорее всего, для реализации потребуется еще RGB<->YUV конвертирование, ибо писать подобные фильтры прямо в RGB может быть неприятно.
Большинство из этих фильтров по сложности в разы превосходит всё то, что сейчас предоставляет seriously.js.
Такое на самом деле редко, но встречается, особенно в коде студентов на каком-нибудь C#.
Но всё это оффтоп.
А если серьезно, то <=15км в пределах города было бы очень хорошо.
Посмотрел keynote, почитал The Verge и не совсем понял: вроде как в первом апдейте будут только полноэкранные метро-приложения на панели задач и всякие модификации для «живых плиток», а новый пуск и приложения в окне появятся later this year?
Поясните, пожалуйста.
1) Существуют ли какие-нибудь ограничения на некоммерческое распространение софта, скопилированного со студенческой версией компилятора? Может ли студент распространять библиотеки Intel, если они слинкованы динамически?
2) Планирует ли когда-нибудь некоммерческое лицензирование для других платформ, в частности Windows? Например, у нас тут есть одна довольно активно растущая экосистема, которая зачастую получает серьезные профиты от ICL, но пока работает только на Windows. Продавать её никто не собирается, поэтому некоммерческая лицензия была бы кстати.
3) Являются ли добровольные донаты нарушением некоммерческой лицензии?
Просто мы пока ну очень далеко от состояния, когда можно будет отдать всё компилятору. Вы когда-нибудь видели автовекторизатор, использующий pmaddwd? А сложные шаффлы с pshufb? А punpck**? Может, это обработка видео такая странная, но у меня от автовекторизаторов сплошное разочарование.
Но речь не об этом. Я просто хотел сказать, что интринсики, да и чистый асм — не абсолютное зло, и не надо их бояться. Если есть желание писать на них универскальный код — это можно сделать. Да, он будет менее читаем, он будет требовать от вас больше знаний, его будет сложнее «поддерживать». Зато без привязки к компилятору (ну разве что иногда производительно интринсиков в vc хромает), без дополнительных зависимостей, без платных тулзов.
Ну и насчет переписывания кода под новые инструкции — мне кажется, вы преувеличиваете. Даже сейчас многие пишут чистый SSE2-4, ибо огромная база пользователей нормальную реализацию AVX(2) не увидит еще несколько лет (с быстрыми vgather, например). Если уж критично использовать всегда последний сэт инструкций — почему бы не OpenCL? Там и перекомпилировать не придется, всё в рантайме.
А насчет того, что темплейт медленней интринсика, вы не правы. Рантайм цена темплейтов в принципе нулевая, если они инлайнятся. А если не инлайнятся, то всегда есть __forceinline.
Да, такой код будет менее читаем, чем автовекторизуемый C, но не будет привязан к компилятору и его возможности векторизировать.
Такое делают и на чистом ассемблере давно, но это может быстро превратиться в макросовый ад.
Интересно было бы реализацию для фильтра с произвольным радиусом. Понятно, что оптимальные сети сортировки для маленьких радиусов известны и могут быть легко реализованы по-отдельности, а что делать в SIMD с большими областями?
Кроме того, а как паковать обратно-то будем? :)