Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Ну вот, уже лучше. :) Пара замечаний
Битность определяется на этапе компиляции и скодировать в 8 и 10 одним бинарником не выйдет. Так что и смысла выставлять профиль в принципе нет (если только не надо 4:2:2 или 4:4:4).
Кроме извращенных случаев когда вы передаёте иксу RAW-видео, указывать эти параметры не нужно. FPS ещё может быть разумно если у вас таймкоды корявые в исходном контейнере (тогда ещё стоит --force-cfr может?), но указание разрешения — явно лишняя работа. Особенно если вы ещё раз указываете FPS при упаковке в mkv.
Кстати, --tune animation подходит только для очень чистых источников типа «три линии два градиента». В большом количестве случаев имеет смысл подкрутить aq вручную.
И мне интересно — какой смысл кодировать 10битное видео в 480p? На железках вы его всё равно не посмотрите, на телефоне смысла от 10 бит особого нет (и батарею жрет больше), а для компьютера с BD можно и 720 и выше делать.
В данном случае кодируем в 10 бит, поэтому high10, если в 8 — high.
Битность определяется на этапе компиляции и скодировать в 8 и 10 одним бинарником не выйдет. Так что и смысла выставлять профиль в принципе нет (если только не надо 4:2:2 или 4:4:4).
--input-res 1920x1080 --fps 23.976
Кроме извращенных случаев когда вы передаёте иксу RAW-видео, указывать эти параметры не нужно. FPS ещё может быть разумно если у вас таймкоды корявые в исходном контейнере (тогда ещё стоит --force-cfr может?), но указание разрешения — явно лишняя работа. Особенно если вы ещё раз указываете FPS при упаковке в mkv.
Кстати, --tune animation подходит только для очень чистых источников типа «три линии два градиента». В большом количестве случаев имеет смысл подкрутить aq вручную.
И мне интересно — какой смысл кодировать 10битное видео в 480p? На железках вы его всё равно не посмотрите, на телефоне смысла от 10 бит особого нет (и батарею жрет больше), а для компьютера с BD можно и 720 и выше делать.
Битность определяется на этапе компиляции и скодировать в 8 и 10 одним бинарником не выйдет. Так что и смысла выставлять профиль в принципе нет (если только не надо 4:2:2 или 4:4:4).
Это само собой. Просто сила привычки.
--input-res 1920x1080 --fps 23.976
Передаю на всякий случай. Мало ли.
И мне интересно — какой смысл кодировать 10битное видео в 480p? На железках вы его всё равно не посмотрите, на телефоне смысла от 10 бит особого нет (и батарею жрет больше), а для компьютера с BD можно и 720 и выше делать.
Смысл тот же что и для 720р рипов в 10 бит. Увеличение качества видео (гладкие переходы без лесенок). Я, к примеру, смотрю 480p на небольшом экране нетбука.
720р 10 бит он не тянет (большинство рипов), 720р 8 бит едва едва на процессоре, через DXVA без проблем, но попробуйте найти ещё такой рип. А вот 480р 10 и 8 бит без проблем. Так что для меня смысл есть.
а то что монитор у вас 8-битный вас не смущает? и то что плеер/операционка/whatever уже сами делают ковертацию 10->8 бит.
Нет, что вы.
Спойлер
Это значит лишь то, что от декодера до madvr у вас идет полноценное 10-битное видео. А уже madvr его дитерит в 8бит и выводит вам на монитор. Так что комментатор в этом плане прав.
Впрочем, это нисколько не уменьшает пользы 10-битного видео, тема которого уже даже тут обсасывалась много раз.
Впрочем, это нисколько не уменьшает пользы 10-битного видео, тема которого уже даже тут обсасывалась много раз.
Подождите, ты кодируете 10бит в 4:2:0 семплинг..? Аха… Ахаха… АХАХАХА!!! Нет, правда, простите, но это ОЧЕНЬ СМЕШНО!
А почему?
Я не силен в бытовых кодеках, но в профессиональном кино/видео пайплайне так не делает никто. 422 8бит выглядит лучше (при правильном дитеринге) чем 420 10бит. 444 вообще сказка. Ответить на вопрос почему разработчики стандартов выбрали именно такую странную конфигурацию для кодирования 10 бит я к сожалению не могу.
10бит вообще используется только для того чтобы на цветокоррекции можно было сильно растягивать диапазон.
10бит вообще используется только для того чтобы на цветокоррекции можно было сильно растягивать диапазон.
Что имеется ввиду под профессиональным кино и видео пайплайном? Обработка? Окей, там разумно иметь 444 lossless.
Профессиональное сжатие? Увольте, большинство профессионалов во-первых, не умеют сжимать видео, а во-вторых, делают это в 420 8-бит, если мы говорим об обыкновенном видео на BD и прочих потребительских дисках/сервисах, а не узкоспециализированных областях.
В любом случае, проф. индустрия может работать с 444 изначально. При наличии же только 420 исходника как в статье, делать из него 444 имеет смысл только если (а) производится даунсайз картинки и (б) в хроме действительно есть что-то важное (много красного цвета и тонких деталей). В основном оно того не стоит.
В отличии от более клёвого сабсемплинга хромы, 10бит почти всегда понижают размер (иногда очень значительно в аниме) и никогда не вредят качеству. Так что ваш смех тут очень не к месту.
Профессиональное сжатие? Увольте, большинство профессионалов во-первых, не умеют сжимать видео, а во-вторых, делают это в 420 8-бит, если мы говорим об обыкновенном видео на BD и прочих потребительских дисках/сервисах, а не узкоспециализированных областях.
В любом случае, проф. индустрия может работать с 444 изначально. При наличии же только 420 исходника как в статье, делать из него 444 имеет смысл только если (а) производится даунсайз картинки и (б) в хроме действительно есть что-то важное (много красного цвета и тонких деталей). В основном оно того не стоит.
В отличии от более клёвого сабсемплинга хромы, 10бит почти всегда понижают размер (иногда очень значительно в аниме) и никогда не вредят качеству. Так что ваш смех тут очень не к месту.
Я автор статьи, на которую вы ссылаетесь, за что спасибо. Надеюсь, вы не обидитесь, если я выскажу свои замечания.
--preset. Вы сказали: «выше скорость — хуже качество». Это неправда, если читали документацию внимательно, должны знать почему.
--deblock. Вы сказали, что большие значения размывают линии. Это не вполне правда. deblock призван устранить квадратичность макроблоков, о чём вы забыли упомянуть. Квадратичность появляется как следствие увеличение квантизатора и именно она виновна в искривлении линий. deblock пытается соединить линии, которые проходят через смежные блоки и при максимальных значениях он делает это всегда. Так что психовизуальное восприятие человека не будет потрясено, а именно под это заточен x264. Как недостаток этой функции может быть замыливание резких линий, но уж лучше это, чем разрыв линии вовсе. Тем более, что можно включить резкость во время просмотра и нет проблем.
--trellis. Если вы читали документацию, то trellis имеет смысл в паре с --psy-rd. Это ещё одна фича для психовизуального восприятия, которая должна уменьшить размер файла. Когда я тестировал их, то у меня размер увеличивался, а качество не улучшалось. Поэтому резонно спросить: зачем оно надо и вы сами пробовали кодировать без этого?
CRF. Решил внять рекомендациям и попробовать закодировать в CRF. Подвох обнаружился, когда я смекнул, что значит «динамическая сцена» с точки зрения кодера. В VirtualDub я изменил частоту кадров и кодировал с теми же настройками CRF. В итоге стало ясно, что то же самое видео с меньшей частотой кадров воспринимается кодеком как slow-mo, а с большей частотой как «динамическая сцена». И естественно, что в первом случае размер файла стал больше, а во втором меньше. Такой фокус с CQP не проходит, поэтому это ещё одна причина не кодировать в CRF — слишком непредсказуемый результат.
--preset. Вы сказали: «выше скорость — хуже качество». Это неправда, если читали документацию внимательно, должны знать почему.
--deblock. Вы сказали, что большие значения размывают линии. Это не вполне правда. deblock призван устранить квадратичность макроблоков, о чём вы забыли упомянуть. Квадратичность появляется как следствие увеличение квантизатора и именно она виновна в искривлении линий. deblock пытается соединить линии, которые проходят через смежные блоки и при максимальных значениях он делает это всегда. Так что психовизуальное восприятие человека не будет потрясено, а именно под это заточен x264. Как недостаток этой функции может быть замыливание резких линий, но уж лучше это, чем разрыв линии вовсе. Тем более, что можно включить резкость во время просмотра и нет проблем.
--trellis. Если вы читали документацию, то trellis имеет смысл в паре с --psy-rd. Это ещё одна фича для психовизуального восприятия, которая должна уменьшить размер файла. Когда я тестировал их, то у меня размер увеличивался, а качество не улучшалось. Поэтому резонно спросить: зачем оно надо и вы сами пробовали кодировать без этого?
CRF. Решил внять рекомендациям и попробовать закодировать в CRF. Подвох обнаружился, когда я смекнул, что значит «динамическая сцена» с точки зрения кодера. В VirtualDub я изменил частоту кадров и кодировал с теми же настройками CRF. В итоге стало ясно, что то же самое видео с меньшей частотой кадров воспринимается кодеком как slow-mo, а с большей частотой как «динамическая сцена». И естественно, что в первом случае размер файла стал больше, а во втором меньше. Такой фокус с CQP не проходит, поэтому это ещё одна причина не кодировать в CRF — слишком непредсказуемый результат.
Почитал, там на английском сказано то же самое, только раньше. И что-же? В чём суть вашего комментария? Ведь это только лишний раз подтверждает мои выводы, что качество на выходе непредсказуемо.
Остальное не комментируете, потому что нечего сказать?
Остальное не комментируете, потому что нечего сказать?
--preset
Как я сказал так и есть. Пресет влияет на большое количество опций. medium имеет одни установки, very slow другие. Например он влияет на ref, для very slow будет 16, для medium точно не помню, вроде 3 и на кучу других параметров, на то он и пресет.
--deblock
Я так же привел ссылку. Советую почитать. А так же тут, если вы можете в английский.
--trellis
Значение 2 имеет смысл использовать только с
По поводу crf прочтите пожалуйста это. Ссылка есть в посте. А так же те ссылки, что дал tp7 в комментарии выше.
Ну и по всем параметрам могу посоветовать почитать тут. Интересный материал для новичков есть ещё тут, правда для ffmpeg.
Как я сказал так и есть. Пресет влияет на большое количество опций. medium имеет одни установки, very slow другие. Например он влияет на ref, для very slow будет 16, для medium точно не помню, вроде 3 и на кучу других параметров, на то он и пресет.
--deblock
Я так же привел ссылку. Советую почитать. А так же тут, если вы можете в английский.
--trellis
Значение 2 имеет смысл использовать только с
--psy-rd. А равное 1 можно и без. Причем влияет это на эффективность сжатия. Уменьшение размера заметно. Не совсем ясно, что вам не понятно.По поводу crf прочтите пожалуйста это. Ссылка есть в посте. А так же те ссылки, что дал tp7 в комментарии выше.
Ну и по всем параметрам могу посоветовать почитать тут. Интересный материал для новичков есть ещё тут, правда для ffmpeg.
Напишу вам ответ, т.к. не знаю, куда еще, а информация может быть полезна.
В ffmpeg есть несколько неприятных «багов» (не совсем багов, на самом деле), о которых нужно помнить, если им кодировать, особенно аниме.
1) ASS субтитры по умолчанию воспринимаются как SSA. Из-за этого, субтитры муксятся в mkv обычным способом, а не с использованием ReadOrder, и два таймкода не могут быть одновременно показаны. Караоке разваливается, некоторые строки не показываются, и совсем не очевидно, из-за чего такое происходит, т.к. если вытащить субтитры из контейнера в отдельный файл, а потом их загрузить, все воспроизводится нормально.
Чтобы этого избежать, нужно задать декодер ass для субтитров.
Обязательно нужно указывать перед -i.
2) Отставание звука в Matroska на 1 фрейм (~40мс). Это какая-то регрессия, которую я никак не пойму, как исправить. В некоторых случаях, происходит смещение pts у звука, и из-за этого такой эффект. Можно обойти это, добавив -avoid_negative_ts 0, но с этом случае у видео будет первый фрейм с отрицательным pts, что не соответствует стандарту, но, вроде, работает.
3) Matroska muxer записывает теги трека не так, как это делает mkvmerge, поэтому в mkvmerge они видны, как отдельные треки, что не очень удобно иногда, но больше это ни на чем не сказывается.
В ffmpeg есть несколько неприятных «багов» (не совсем багов, на самом деле), о которых нужно помнить, если им кодировать, особенно аниме.
1) ASS субтитры по умолчанию воспринимаются как SSA. Из-за этого, субтитры муксятся в mkv обычным способом, а не с использованием ReadOrder, и два таймкода не могут быть одновременно показаны. Караоке разваливается, некоторые строки не показываются, и совсем не очевидно, из-за чего такое происходит, т.к. если вытащить субтитры из контейнера в отдельный файл, а потом их загрузить, все воспроизводится нормально.
Чтобы этого избежать, нужно задать декодер ass для субтитров.
ffmpeg -c:s ass -i input.mkv…Обязательно нужно указывать перед -i.
2) Отставание звука в Matroska на 1 фрейм (~40мс). Это какая-то регрессия, которую я никак не пойму, как исправить. В некоторых случаях, происходит смещение pts у звука, и из-за этого такой эффект. Можно обойти это, добавив -avoid_negative_ts 0, но с этом случае у видео будет первый фрейм с отрицательным pts, что не соответствует стандарту, но, вроде, работает.
3) Matroska muxer записывает теги трека не так, как это делает mkvmerge, поэтому в mkvmerge они видны, как отдельные треки, что не очень удобно иногда, но больше это ни на чем не сказывается.
Спасибо за информацию. Буду учитывать.
Субтитры ASS никода не засовываю в контейнер, тем более средствами ffmpeg. Если это необходимо, всегда использую mkvmerge.
FFmpeg использую лишь для кодирования звука, т.к. на мой взгляд это удобнее чем вытаскивать звук из контейнера оригинала, а потом скармливать oggenc2 или чему-нибудь ещё.
Субтитры ASS никода не засовываю в контейнер, тем более средствами ffmpeg. Если это необходимо, всегда использую mkvmerge.
FFmpeg использую лишь для кодирования звука, т.к. на мой взгляд это удобнее чем вытаскивать звук из контейнера оригинала, а потом скармливать oggenc2 или чему-нибудь ещё.
OMG !) 0,04 секунды отставание звука.
А как вы это определили? ) не на слух же
А как вы это определили? ) не на слух же
Если вам нужен предсказуемый размер — вы кодируете в битрейт. Если вам нужно предсказуемое качество — в CRF. Какую предсказуемость вы хотите получить?
По опыту предыдущего топика я понял, что комментировать ваши мысли бесполезно. Но окей, покажите, пожалуйста, документацию, которая объясняет что preset — это не компромисс между скоростью и качеством, а что-то другое.
Потом покажите мне такую документацию, которая говорит, что деблок пытается соединить линии (как очень быстрый eedi3, да), а не просто немного замазывает границы макроблоков.
Как по мне, так вы пришли с XviD, выставили постоянный квантайзер и пытаетесь подобрать такие параметры, при которых у вас получится минимальный размер. Это в корне неверно, это не то, как используют x264. Это другой мир, попытайтесь разобраться в его правилах прежде чем нести откровенный нонсенс.
Кстати, вы случайно никак не связаны с человеком с ником «Жрец Нефтиды»?
По опыту предыдущего топика я понял, что комментировать ваши мысли бесполезно. Но окей, покажите, пожалуйста, документацию, которая объясняет что preset — это не компромисс между скоростью и качеством, а что-то другое.
Потом покажите мне такую документацию, которая говорит, что деблок пытается соединить линии (как очень быстрый eedi3, да), а не просто немного замазывает границы макроблоков.
Как по мне, так вы пришли с XviD, выставили постоянный квантайзер и пытаетесь подобрать такие параметры, при которых у вас получится минимальный размер. Это в корне неверно, это не то, как используют x264. Это другой мир, попытайтесь разобраться в его правилах прежде чем нести откровенный нонсенс.
Кстати, вы случайно никак не связаны с человеком с ником «Жрец Нефтиды»?
Почитал статьи про деблок по ссылкам sudzuharu, не нашёл прямых противоречий со своими словами. Если кто нашёл — пусть укажет цитату. К тому же я не теоретик, а практик. Я кодировал с деблоком и без и сравнивал картинки в масштабе 400. И всё вышло так, как и описал.
preset — это компромисс между скоростью и размером файла. Качество может только ухудшиться, но не улучшиться, потому что процесс кодирования с потерями это подразумевает. Высокий пресет уменьшает размер за счёт лучшего просчёта движения и применения фичей, которые ухудшают кадр и уменьшают его размер в байтах. B-кадры тому пример.
По поводу CRF и CQP, не понимаю, как вам ещё доступнее объяснить. CQP даёт стабильное качество, поэтому я выбрал его, CRF определяет качество на своё усмотрение, в зависимости от динамики сцены. Конечно, вы задаёте значение CRF, но это только приблизительный ориентир для кодека, и он лучше подходит для двухпроходного кодирования, потому что кодеку необходимо учесть соотношение многих параметров по статистике всего видео, иначе можно получить совершенно противоречивые результаты, о чём я и писал выше.
«Жрец Нефтиды» — не знаю такого. Он в розыске? :-)
preset — это компромисс между скоростью и размером файла. Качество может только ухудшиться, но не улучшиться, потому что процесс кодирования с потерями это подразумевает. Высокий пресет уменьшает размер за счёт лучшего просчёта движения и применения фичей, которые ухудшают кадр и уменьшают его размер в байтах. B-кадры тому пример.
По поводу CRF и CQP, не понимаю, как вам ещё доступнее объяснить. CQP даёт стабильное качество, поэтому я выбрал его, CRF определяет качество на своё усмотрение, в зависимости от динамики сцены. Конечно, вы задаёте значение CRF, но это только приблизительный ориентир для кодека, и он лучше подходит для двухпроходного кодирования, потому что кодеку необходимо учесть соотношение многих параметров по статистике всего видео, иначе можно получить совершенно противоречивые результаты, о чём я и писал выше.
«Жрец Нефтиды» — не знаю такого. Он в розыске? :-)
preset — это компромисс между скоростью и размером файла.
Совершенно верно.
Качество может только ухудшиться, но не улучшиться, потому что процесс кодирования с потерями это подразумевает.
preset не влияет прямым образом на качество, так что не соглашусь.
Высокий пресет уменьшает размер за счёт лучшего просчёта движения и применения фичей
которые ухудшают кадр
Нет.
CRF, но это только приблизительный ориентир для кодека, и он лучше подходит для двухпроходного кодирования
CRF может быть использован только для однопроходного кодирования.
Кстати, CRF неправильно зависит от частоты кадров.
Пример: делаю 2 абсолютно статичных видео (дублирую кадр) с разной частотой кадров – 10 и 100, например, но с одинаковым количеством кадров.
Ничем, кроме частоты кадров, видео не отличаются.
Сжимаю с одинаковым CRF.
Файл с 10 кадрами/сек. получается в 1,5 раза больше, чем со 100.
Это совершенно нелогично.
Движение в кадре нулевое (картинка статичная) – следовательно, CRF качество сжатия снижать не должен.
Т. е. частота кадров должна влиять не на качество вообще, а на коэффициент движения в кадре, чтобы на статичных картинках качество не снижалось.
Пока не понял, где это находится в коде. Если не ошибаюсь, коммит, вносящий зависимость от частоты кадров, был в 2010-м году: VFR/framerate-aware ratecontrol, part 2, и менять что-либо нужно в районе строки 2955.
Пример: делаю 2 абсолютно статичных видео (дублирую кадр) с разной частотой кадров – 10 и 100, например, но с одинаковым количеством кадров.
Ничем, кроме частоты кадров, видео не отличаются.
Сжимаю с одинаковым CRF.
Файл с 10 кадрами/сек. получается в 1,5 раза больше, чем со 100.
Это совершенно нелогично.
Движение в кадре нулевое (картинка статичная) – следовательно, CRF качество сжатия снижать не должен.
Т. е. частота кадров должна влиять не на качество вообще, а на коэффициент движения в кадре, чтобы на статичных картинках качество не снижалось.
Пока не понял, где это находится в коде. Если не ошибаюсь, коммит, вносящий зависимость от частоты кадров, был в 2010-м году: VFR/framerate-aware ratecontrol, part 2, и менять что-либо нужно в районе строки 2955.
Неделя статей про x264? Уже есть бетки x265, имхо интереснее было почитать сравнение скорости/качества/размера/нагрузки ЦП/ГП.
Насколько мне известно он все ещё альфа, в состоянии активной разработки. Работает медленно и не очень эффективно. Так что пока рано.
Уже есть бетки x265, имхо интереснее было почитать сравнение скорости/качества/размера/нагрузки ЦП/ГП.В трех словах: все пока плохо.
Самый продвинутый кодер h.265 на текущий момент — DivX HEVC. Вот пример видео, сжатого им: trailers.divx.com/hevc/TearsOfSteelFull12min_1080p_24fps_27qp_1474kbps_GPSNR_42.29_HM11.mkv
Смущает то, что мы одновременно кодируем в 10 бит, и при этом ограничиваем --ref, типа чтобы «бытовые плееры поддерживали». А смысл? Покажите бытовой плеер, который поддерживает 10 бит?
Кроме того многие SmartTV и плееры не дружат с vorbis, им либо aac, либо ac3 подавай.
Кроме того многие SmartTV и плееры не дружат с vorbis, им либо aac, либо ac3 подавай.
Я ограничиваю --ref только для собственного удобства, чтобы увеличить скорость кодирования. Никто не мешает вам использовать пресет veryslow или выставить вручную 16, но тогда готовьтесь к сильному падению скорости.
При данных настройках одна серия у меня кодируется около ~25 минут на i7-4700HQ, при fps = 18-24, не считая времени потраченного на звук и пары секунд на сборку.
При данных настройках одна серия у меня кодируется около ~25 минут на i7-4700HQ, при fps = 18-24, не считая времени потраченного на звук и пары секунд на сборку.
Ну --ref да можно регулировать скорость, но это всё-таки больше тонкая настройка. В первую очередь я бы крутил --preset в сторону fast и veryfast для ускорения кодирования. --ref выкручивать на максимум тоже нет смысла задирать, даже при длительном кодировании, т. к. таких кадров ref>=12 может быть крайне мало, и лучше увеличить параметры оценки движения.
А вообще тут следует различать, за чем мы гонимся, и поэтому сценарии, а соответственно и параметры могут быть разные:
1) Получение среднее качества видео за минимальное время.
2) Получение хорошего качества за приемлемое время (в статье используется этот сценарий)
3) Получение максимального качества за длительное время.
А вообще тут следует различать, за чем мы гонимся, и поэтому сценарии, а соответственно и параметры могут быть разные:
1) Получение среднее качества видео за минимальное время.
2) Получение хорошего качества за приемлемое время (в статье используется этот сценарий)
3) Получение максимального качества за длительное время.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кодирование x264 + Vorbis