Судя по видео, алгоритм похож на опцию в кодеке x264 scenecut threshold (--scenecut) «порог изменения сцены». То есть в такой проге просто задаёшь значение порога и она собирает те блоки кадров, где переход отличается на значение порога. Если заранее неизвестно, насколько динамично видео, то можно начать с высокого порога и смотреть, какой процент видео останется
Собственная поправка. Дополнительные тесты показали, что блок Analysis с птичками frames partitions улучшает качество и даже уменьшает размер. Так что включайте все птички.
Нашёл ещё один лёгкий способ открытия неавишных файлов в VirtualDub. Здесь есть ссылки на Virtualdub FFMpeg Input Plugin. Только подберите нужную версию, а то у меня v0.7 пошла, а v0.8 нет. Из архива файл FFInputDriver.vdplugin и папку ffdlls нужно положить в папку plugins Virtualdub'а и всё. Пробовал на mkv, mp4, mov, полный список форматов указан на сайте.
Можно использовать способ FFMpeg через AviSynth, но новичкам придётся попотеть.
Почитал статьи про деблок по ссылкам sudzuharu, не нашёл прямых противоречий со своими словами. Если кто нашёл — пусть укажет цитату. К тому же я не теоретик, а практик. Я кодировал с деблоком и без и сравнивал картинки в масштабе 400. И всё вышло так, как и описал.
preset — это компромисс между скоростью и размером файла. Качество может только ухудшиться, но не улучшиться, потому что процесс кодирования с потерями это подразумевает. Высокий пресет уменьшает размер за счёт лучшего просчёта движения и применения фичей, которые ухудшают кадр и уменьшают его размер в байтах. B-кадры тому пример.
По поводу CRF и CQP, не понимаю, как вам ещё доступнее объяснить. CQP даёт стабильное качество, поэтому я выбрал его, CRF определяет качество на своё усмотрение, в зависимости от динамики сцены. Конечно, вы задаёте значение CRF, но это только приблизительный ориентир для кодека, и он лучше подходит для двухпроходного кодирования, потому что кодеку необходимо учесть соотношение многих параметров по статистике всего видео, иначе можно получить совершенно противоречивые результаты, о чём я и писал выше.
«Жрец Нефтиды» — не знаю такого. Он в розыске? :-)
Почитал, там на английском сказано то же самое, только раньше. И что-же? В чём суть вашего комментария? Ведь это только лишний раз подтверждает мои выводы, что качество на выходе непредсказуемо.
Остальное не комментируете, потому что нечего сказать?
Я автор статьи, на которую вы ссылаетесь, за что спасибо. Надеюсь, вы не обидитесь, если я выскажу свои замечания.
--preset. Вы сказали: «выше скорость — хуже качество». Это неправда, если читали документацию внимательно, должны знать почему.
--deblock. Вы сказали, что большие значения размывают линии. Это не вполне правда. deblock призван устранить квадратичность макроблоков, о чём вы забыли упомянуть. Квадратичность появляется как следствие увеличение квантизатора и именно она виновна в искривлении линий. deblock пытается соединить линии, которые проходят через смежные блоки и при максимальных значениях он делает это всегда. Так что психовизуальное восприятие человека не будет потрясено, а именно под это заточен x264. Как недостаток этой функции может быть замыливание резких линий, но уж лучше это, чем разрыв линии вовсе. Тем более, что можно включить резкость во время просмотра и нет проблем.
--trellis. Если вы читали документацию, то trellis имеет смысл в паре с --psy-rd. Это ещё одна фича для психовизуального восприятия, которая должна уменьшить размер файла. Когда я тестировал их, то у меня размер увеличивался, а качество не улучшалось. Поэтому резонно спросить: зачем оно надо и вы сами пробовали кодировать без этого?
CRF. Решил внять рекомендациям и попробовать закодировать в CRF. Подвох обнаружился, когда я смекнул, что значит «динамическая сцена» с точки зрения кодера. В VirtualDub я изменил частоту кадров и кодировал с теми же настройками CRF. В итоге стало ясно, что то же самое видео с меньшей частотой кадров воспринимается кодеком как slow-mo, а с большей частотой как «динамическая сцена». И естественно, что в первом случае размер файла стал больше, а во втором меньше. Такой фокус с CQP не проходит, поэтому это ещё одна причина не кодировать в CRF — слишком непредсказуемый результат.
Решил внять рекомендациям и попробовать закодировать в CRF. Подвох обнаружился, когда я смекнул, что значит «динамическая сцена» с точки зрения кодера. В VirtualDub я изменил частоту кадров и кодировал с теми же настройками CRF. В итоге стало ясно, что то же самое видео с меньшей частотой кадров воспринимается кодеком как slow-mo, а с большей частотой как «динамическая сцена». И естественно, что в первом случае размер файла стал больше, а во втором меньше. Такой фокус с CQP не проходит, поэтому это ещё одна причина не кодировать в CRF — слишком непредсказуемый результат.
Не имею доступа к серверу. Вы сначала объясните суть — какой размер и длительность, как проверять качество? Если длинный кусок, я не буду тратить время. Если вы с пресетами добавляете отдельные ключи — это уже другой разговор. Если диалог затягивается — пишите в лику.
Про эксперимент с пресетами я писал в комменте выше.
Ссылка на стрим не работает у меня. Если найдёте приличные настройки — скиньте. А вообще сильно сжать не проблема. Я кодировал в HD и качество получилось неплохое, при тех же требованиях сжать ещё больше — вот интересная задачка.
Если многие не используют CQP — это меня заинтересовало. Неужели мало кто понимает, что это за штука?
Обычно критиканы так и говорят: «всё у вас фигня, идите учите матчасть». А обосновать свою критику не могут. Я же в статье написал, почему я выбрал такие значения, и пользователь всегда может выбрать свои. Эта статья писалась не для вас, не для гуру, не для тех, кто сидит часами у консоли — она для тех, кто хочет получить нормальный результат быстро и без напряга.
CQP не может быть фигнёй в принципе — в данном случае это вам надо изучать матчасть, ибо вы, видимо, не знаете, зачем в x264 CQP, поэтому и говорите, что не используется.
DirectShowShource возможно хуже FFMpeg, но это мне простительно, статья вообще не об этом. Кстати, лагает он в основном на mkv, так что обычный пользователь может и не заметить разницы.
Вчера закодировал 100 минут фильм 1280х694 менее чем в 2 гига. Качество вполне пристойное. Если у вас получится лучше — скиньте настройки, буду благодарен.
Ну наконец-то я понял, что вы имели ввиду. Вы говорите о CRF, а я писал про CQP (Constant Rate Factor). Это не одно и то же. Да, CRF использует CQP, но на своё усмотрение, вы пребываете в некотором неведении относительно результата, когда кодируете через CRF, а с CQP такого казуса не произойдёт — он всегда даёт стабильный результат. Поэтому я новичкам советую именно его. А вам советую разобраться в определениях и не писать попусту. Кодирование без квантизатора вообще действительно невозможно, если говорить о ядре кодека.
Насчёт B-кадров сложный вопрос — если вы проигрываете в том же месте, что и кодировали, то проблем быть не должно. К тому же блоки из таких кадров усложняют декодирование и ухудшают качество видео, так что новичкам опять же не рекомендуется. Выигрыш в размере можно получить и другим способом, а иной пользы от B-кадров просто нет.
--merange 8, я не утверждаю, что он оптимальный, но при больших значениях заметно снижение скорости, а размер почти тот же. Так что экспериментально доказать, какое значение будет лучшим, не представляется мне возможным. Новичкам парить мозги тоже не стоит.
Deadzone лучше чем Trellis, потому что я протестировал результаты обоих. Trellis увеличивает размер и не всегда улучшает качество, а Deadzone всегда сглаживает в заданных пределах и всегда уменьшает размер. Deadzone точно по Гауссу, потому что я знаю, как выглядят картинки после такого фильтра — другим способом этого не достичь. Каким образом работает Trellis — не знаю, а потому резонно задаться вопросом: «на кой он такой кактус?»
--preset veryslow. Я писал, что пробовал версию 2274 с другим интерфейсом, там была одна вкладка и выбор пресетов. Я попробовал некоторые и результат был отстойным. Далее пробовать не было желания. А заполнять команды вручную после выбора пресета — разве это не маразм? Уж лучше учится работать в консоли.
Говорите про полноценные гайды? Если они доходчиво написаны и экспериментально подтверждены — киньте ссылку, буду благодарен.
Весьма сумбурный комментарий, если я не прав, объясните толково, где, и почему правы вы.
Мне показалось, что вы не вполне представляете себе, что такое CQP. CQP не может быть маразмом в принципе, ибо без него кодирование вообще невозможно, разве только вы придумаете и запатентируете иной принцип.
По поводу деблока я говорил, что по-умолчанию 0, компромисс 3, так что выбор есть. Особенно актуально на высоком квантизаторе.
Ключ subme — это Subpixel ME refinement, я описал его достаточно подробно. Сразу видно, что вы привыкли к консольному варианту.
И да, вы правы, GUI для тех, кто не хочет тратить время на изучение горы документации. И для них же мой пост. А насчёт честности спорный вопрос — поэтому юниксоиды и виндари совершенно из разных миров.
Собственная поправка. В первом посте я писал, что в матрице Inter важно число 12, а в этом посте я изменил его на 16, но это ошибка. Просто измените 16 на 12 в матрице Inter. В остальном матрица такая же, как в этом посте. В результате тестов я обнаружил, что мне не всегда понятна логика работы кодека, поэтому столько поправок. До сути можно дойти только «методом тыка», так что извините за неточности.
Начну с конца. То, что 99% людей не различают mp3 256Kbit и цифровой оригинал — это факт, были исследования, можете найти в инете. Вообще mp3 был создан в институте Фраунгофера, они же и выпустили наиболее качественный энкодер, и 320Kbit не с потолка взято, ибо есть наука психоакустика, и то, что 320Kbit предел для mp3 — тоже не зря сделано. Аналогичная история с JPEG, где качество 100 всё равно отличается от оригинала, но на глаз это увидеть невозможно (делал сверку в масштабе 1000%). Поэтому никто на самом деле не хранит jpeg-фотки в качестве 100, а в 90 вполне достаточно.
Теперь о моей матрице. Смысл в ней есть, ибо при квантизаторе 4 она делает лучшую картинку соответственно восприятию многих людей (и не спрашивайте, почему я в этом уверен. Даже ребёнок может задолбать учёного, пытаясь вытянуть ответ на очевидные вещи, типа «а почему солнце восходит на востоке, а садится на западе?», «а почему Земля не плоская?», «а почему все люди не могут иметь IQ 150?»). А при квантизаторе 4 размер файла получается очень небольшим. Так что мой результат с одного прохода поспорит с любым результатом в два прохода – выгода очевидна.
А ещё собственную матрицу можно использовать для получения файлов, которые потом будут обрабатываться, например в VirtualDub. Для этого нужно кодировать с квантизатором 2 и желательно все коэффициенты уменьшить на 4. И качество будет лучше, чем при стандартных настройках.
Вы сказали: «я удивился, узнав, что какие-то манипуляции с матрицей квантизации могут на что-то сильно повлиять». Сделайте простой эксперимент: зайдите в настройки кодэра, выставьте любую кустомную матрицу и измените первое число во втором квадрате на 40 или больше (в моей матрице это число 12). Закодируйте несколько кадров и откройте результат в VirtualDub. Увидите и всё поймёте. И тогда нам не придётся писать длинные и бессмысленные комменты.
Нет, я не люблю экстраполировать. Я делал покадровую сверку «на глазок» различных видеоотрезков: с высоким разрешением и низким, с чёткими краями объектов, с фоном, где цвет имеет плавный переход и т.д. Но зачем я буду вываливать читателям все нюансы исследования? Ведь в конечном итоге всё сводится к практическому применению матрицы и я убедился, что она пригодна. Как ещё я должен убеждать читателей? Возьмите и сами проведите такой эксперимент: закодируйте нединамичный отрывок стандартной матрицей H263 с постоянным квантизатором и потом с теми же настройками моей матрицей. Сравните размеры файлов и качество покадрово. Если вы скажете, что H263 делает более качественную картинку с меньшим размером — я признаю, что лоханулся.
А если вас не устраивает метод «на глазок», то это тот же древний спор о сравнении mp3 256Kbit и цифрового оригинала. Дело в том, что на практике 99% людей не в состоянии услышать разницу. Так стоит ли раздувать слона о недостаточности визуальной сверки?
Могу и это написать. Просто я думал, что читатели хабра довольно начитаны о таких понятиях, как квантизатор, дискретно-косинусное преобразование и др. К тому же об этом есть много инфы на просторах инета и даже на Википедии. А ведь копипастить не приветствуется! Если есть массовая потребность в освещении аспектов кодирования — конечно постараюсь. А она есть?
Можно использовать способ FFMpeg через AviSynth, но новичкам придётся попотеть.
preset — это компромисс между скоростью и размером файла. Качество может только ухудшиться, но не улучшиться, потому что процесс кодирования с потерями это подразумевает. Высокий пресет уменьшает размер за счёт лучшего просчёта движения и применения фичей, которые ухудшают кадр и уменьшают его размер в байтах. B-кадры тому пример.
По поводу CRF и CQP, не понимаю, как вам ещё доступнее объяснить. CQP даёт стабильное качество, поэтому я выбрал его, CRF определяет качество на своё усмотрение, в зависимости от динамики сцены. Конечно, вы задаёте значение CRF, но это только приблизительный ориентир для кодека, и он лучше подходит для двухпроходного кодирования, потому что кодеку необходимо учесть соотношение многих параметров по статистике всего видео, иначе можно получить совершенно противоречивые результаты, о чём я и писал выше.
«Жрец Нефтиды» — не знаю такого. Он в розыске? :-)
Остальное не комментируете, потому что нечего сказать?
--preset. Вы сказали: «выше скорость — хуже качество». Это неправда, если читали документацию внимательно, должны знать почему.
--deblock. Вы сказали, что большие значения размывают линии. Это не вполне правда. deblock призван устранить квадратичность макроблоков, о чём вы забыли упомянуть. Квадратичность появляется как следствие увеличение квантизатора и именно она виновна в искривлении линий. deblock пытается соединить линии, которые проходят через смежные блоки и при максимальных значениях он делает это всегда. Так что психовизуальное восприятие человека не будет потрясено, а именно под это заточен x264. Как недостаток этой функции может быть замыливание резких линий, но уж лучше это, чем разрыв линии вовсе. Тем более, что можно включить резкость во время просмотра и нет проблем.
--trellis. Если вы читали документацию, то trellis имеет смысл в паре с --psy-rd. Это ещё одна фича для психовизуального восприятия, которая должна уменьшить размер файла. Когда я тестировал их, то у меня размер увеличивался, а качество не улучшалось. Поэтому резонно спросить: зачем оно надо и вы сами пробовали кодировать без этого?
CRF. Решил внять рекомендациям и попробовать закодировать в CRF. Подвох обнаружился, когда я смекнул, что значит «динамическая сцена» с точки зрения кодера. В VirtualDub я изменил частоту кадров и кодировал с теми же настройками CRF. В итоге стало ясно, что то же самое видео с меньшей частотой кадров воспринимается кодеком как slow-mo, а с большей частотой как «динамическая сцена». И естественно, что в первом случае размер файла стал больше, а во втором меньше. Такой фокус с CQP не проходит, поэтому это ещё одна причина не кодировать в CRF — слишком непредсказуемый результат.
Ссылка на стрим не работает у меня. Если найдёте приличные настройки — скиньте. А вообще сильно сжать не проблема. Я кодировал в HD и качество получилось неплохое, при тех же требованиях сжать ещё больше — вот интересная задачка.
Если многие не используют CQP — это меня заинтересовало. Неужели мало кто понимает, что это за штука?
CQP не может быть фигнёй в принципе — в данном случае это вам надо изучать матчасть, ибо вы, видимо, не знаете, зачем в x264 CQP, поэтому и говорите, что не используется.
DirectShowShource возможно хуже FFMpeg, но это мне простительно, статья вообще не об этом. Кстати, лагает он в основном на mkv, так что обычный пользователь может и не заметить разницы.
Вчера закодировал 100 минут фильм 1280х694 менее чем в 2 гига. Качество вполне пристойное. Если у вас получится лучше — скиньте настройки, буду благодарен.
Насчёт B-кадров сложный вопрос — если вы проигрываете в том же месте, что и кодировали, то проблем быть не должно. К тому же блоки из таких кадров усложняют декодирование и ухудшают качество видео, так что новичкам опять же не рекомендуется. Выигрыш в размере можно получить и другим способом, а иной пользы от B-кадров просто нет.
--merange 8, я не утверждаю, что он оптимальный, но при больших значениях заметно снижение скорости, а размер почти тот же. Так что экспериментально доказать, какое значение будет лучшим, не представляется мне возможным. Новичкам парить мозги тоже не стоит.
Deadzone лучше чем Trellis, потому что я протестировал результаты обоих. Trellis увеличивает размер и не всегда улучшает качество, а Deadzone всегда сглаживает в заданных пределах и всегда уменьшает размер. Deadzone точно по Гауссу, потому что я знаю, как выглядят картинки после такого фильтра — другим способом этого не достичь. Каким образом работает Trellis — не знаю, а потому резонно задаться вопросом: «на кой он такой кактус?»
--preset veryslow. Я писал, что пробовал версию 2274 с другим интерфейсом, там была одна вкладка и выбор пресетов. Я попробовал некоторые и результат был отстойным. Далее пробовать не было желания. А заполнять команды вручную после выбора пресета — разве это не маразм? Уж лучше учится работать в консоли.
Говорите про полноценные гайды? Если они доходчиво написаны и экспериментально подтверждены — киньте ссылку, буду благодарен.
Мне показалось, что вы не вполне представляете себе, что такое CQP. CQP не может быть маразмом в принципе, ибо без него кодирование вообще невозможно, разве только вы придумаете и запатентируете иной принцип.
Ключ subme — это Subpixel ME refinement, я описал его достаточно подробно. Сразу видно, что вы привыкли к консольному варианту.
И да, вы правы, GUI для тех, кто не хочет тратить время на изучение горы документации. И для них же мой пост. А насчёт честности спорный вопрос — поэтому юниксоиды и виндари совершенно из разных миров.
Теперь о моей матрице. Смысл в ней есть, ибо при квантизаторе 4 она делает лучшую картинку соответственно восприятию многих людей (и не спрашивайте, почему я в этом уверен. Даже ребёнок может задолбать учёного, пытаясь вытянуть ответ на очевидные вещи, типа «а почему солнце восходит на востоке, а садится на западе?», «а почему Земля не плоская?», «а почему все люди не могут иметь IQ 150?»). А при квантизаторе 4 размер файла получается очень небольшим. Так что мой результат с одного прохода поспорит с любым результатом в два прохода – выгода очевидна.
А ещё собственную матрицу можно использовать для получения файлов, которые потом будут обрабатываться, например в VirtualDub. Для этого нужно кодировать с квантизатором 2 и желательно все коэффициенты уменьшить на 4. И качество будет лучше, чем при стандартных настройках.
Вы сказали: «я удивился, узнав, что какие-то манипуляции с матрицей квантизации могут на что-то сильно повлиять». Сделайте простой эксперимент: зайдите в настройки кодэра, выставьте любую кустомную матрицу и измените первое число во втором квадрате на 40 или больше (в моей матрице это число 12). Закодируйте несколько кадров и откройте результат в VirtualDub. Увидите и всё поймёте. И тогда нам не придётся писать длинные и бессмысленные комменты.
А если вас не устраивает метод «на глазок», то это тот же древний спор о сравнении mp3 256Kbit и цифрового оригинала. Дело в том, что на практике 99% людей не в состоянии услышать разницу. Так стоит ли раздувать слона о недостаточности визуальной сверки?