|
x264
|
|
plov333
|
Дата: Пятница, 18 Апреля 2014, 22:08 | Сообщение #1
|
|
Группа: Проверенные
Сообщений: 70
Статус: Оффлайн
|
Добрый вечер товариЩИ!  Предлагаю хоть немного затронуть тему кодирования видео с помощью x264) Предлагаем свои варианты настройки кодировщика, варианты расчета битрейта для разных материалов, обсуждаем софт, которые помогают упростить процесс кодирования или достичь дополнительных плющек) Лично я, пользуюсь xvid4psp 5 уже пару лет и нареканий на нее конкретных не могу дать. В программе уже есть готовые пресеты для x264 для желающих, но я больше предпочитаю в ручную настройку. Единственный недостаток: трудность обновления кодеков, вернее, их поиск и ручная замена в файлах программы. Сейчас как раз обновляю то самый x264. А так, всем удачи и новых начинаний! 
Кстати, если кому интересно, хорошая и подробная статья про Xvid4Psp есть на Рутрекере)
Тфу, дурень, хрень написал на счет версий. Простите мою больную голову, день загруженый был...
Сообщение отредактировал plov333 - Пятница, 18 Апреля 2014, 22:51
|
|
  |
|
|
|
Dave_Scream
|
Дата: Пятница, 05 Декабря 2014, 18:23 | Сообщение #2
|
|
Группа: Проверенные
Сообщений: 51
Статус: Оффлайн
|
на меня нашло просветление - используем всего два ползунка - Quantitizerом выставляем качество видео, Profile'м выставляем насколько долго готовы ждать, чтобы минимизировать размер файла при заданном качестве. |
|
|
|
|
|
zub35
|
Дата: Пятница, 05 Декабря 2014, 21:56 | Сообщение #3
|
|
Группа: Проверенные
Сообщений: 61
Статус: Оффлайн
|
У меня оно примерно так, разделю на два блока, основное и вторичное
основное:
--level 41, задаю ограничение по уровню, для нормального воспроизведения на всех устройствах.
--preset veryslow, пред-установки сжатия, всегда и везде использую только его.
--crf 18-23 (в зависимости от необходимого выходного качества), редко когда опускаюсь ниже 20.
--qpmin (qmin для ffmpeg), задаю нижнею планку для crf, обычно на 1 или 2 меньше значения самого crf, иногда равное самому crf. По умолчанию равно 0, что не есть гуд, потому как
значения ниже 18, для qpmin и crf - бессмысленны по визуальному восприятию.
вторичное:
--no-psy (-psy 0 для ffmpeg) отключаю псишку, только в том случае, если пережимаю не оригинал, у которого посредственное качество (например записи с веб-камер ;)
Для видео с шумами и высокой четкостью, псишку лучше не отключать, а наоборот улучшить:
--psy-rd 1.0:0.15 и --deblock -1:-1 , что равноценно команде --tune film
Для пере-сжатия всегда использую ffmpeg, пример команды: сжатие видео в x264 и звука в opus и упаковка в mkv контейнер:
ffmpeg -i "input.file" -c:v -libx264 -level 41 -preset veryslow -crf 20 -qmin 20 -psy 0 -c:a libopus -ab 128k -ar 44100 -sample_fmt s16 "output.mkv"
аналог ключей для x264, советую сборку от http://komisar.gin.by/
x264 --level 41 --preset veryslow --crf 20 --qpmin 20 --no-psy -o "output.mkv" "input.file"
пожалуй это самые основные команды, остальное чисто рюшечки, для ознакомления:
http://www.videorip.info/x264....vatelej
http://www.videorip.info/x264....libx264
p.s. использовать контейнер avi для H264(AVC) крайне не советую, либо mp4 (h264 + aac/mp1-3), либо mkv (всеяден по разным форматам и сочетаниям кодеков видео и звука)
зачастую пользуюсь VirtualDub, если необходимо произвести обработку видео. Для этого использую ffmpeg input plugin и вывода через внешнике кодеки и мультиплексеры.
Сообщение отредактировал zub35 - Пятница, 05 Декабря 2014, 22:22
|
|
|
|
|
|
Dave_Scream
|
Дата: Пятница, 05 Декабря 2014, 23:57 | Сообщение #4
|
|
Группа: Проверенные
Сообщений: 51
Статус: Оффлайн
|
zub35, но ведь veryslow очень медленный. Не пробовали изучать Nvidia CUDA или Intel Quick Sync? или X264 c использованием OpenCL?
Просто veryslow неприемлемо медленный
Сообщение отредактировал Dave_Scream - Суббота, 06 Декабря 2014, 00:01
|
|
|
|
|
|
Rollinnn
|
Дата: Суббота, 06 Декабря 2014, 00:31 | Сообщение #5
|
|
Группа: Эксперты
Сообщений: 1409
Статус: Оффлайн
|
Цитата Dave_Scream ( )
veryslow неприемлемо медленный
Так это смотря какой процессор... Всё относительно.
FLAC1.3.3NOSSE Opus1.3.1NOSSE LAME3.99.5ICL12.1 Monkey'sAudio4.10(NOSSE2) ffmpeg для Windows XP и процессоров без SSE2
|
|
|
|
|
|
zub35
|
Дата: Суббота, 06 Декабря 2014, 01:25 | Сообщение #6
|
|
Группа: Проверенные
Сообщений: 61
Статус: Оффлайн
|
Nvidia CUDA в H264 лучше не использовать, хуже даже чем XviD. nVidia даже сама отказалась от поддержки nvcuvenc.dll в новых драйверах, предоставляя только возможности декодирования.
Intel Quick Sync, можно использовать но в тех случаях если качество-размер, не играют важной роли. Вполне годен для записи геймплея сразу в H264
К примеру, там где Quick Sync требуется 11мбит битрейта, в x264 нужно всего 6мбит (в пресетах выше среднего). Пресеты x264 ниже среднего дадут то-же качество как и у QuickSync, но в 2 раза медленее.
наглядное сравнение кодеков, за основу 100% взят XviD
http://www.compression.ru/video....lts.png
скорость: http://www.tetrachromesoftware.com/q264Tes....FPS.png
качество: http://www.tetrachromesoftware.com/q264Tes....SNR.png
сама статья: http://www.tetrachromesoftware.com/q264Test1Analysis/q264test_1.html
--preset veryslow даст максимально-оптимальное сжатие по стандарту H264(AVC), использование настроек попроще, даст эффект "недосжатости" видеоряда (при использовании CRF) или потерю качества при использовании четко указанного битрейта.
т.е. пресеты для одинакового CRF влияют только на размер видео, сохраняя одинаковое качество. А пресеты для битрейта, дают одинаковый размер но с потерей качества.
BDRip'ы вообще делаются очень интересным образом в 2 прохода:
1 проход сжатие с параметром CRF=18 и флагом --slow-firstpass (либо всего видеоряда, либо большого количества нарезанных кусочков)
2 проход указывается битрейт на основе полученного битрейта от первого прохода.
Если вы копнёте многие x264 рипы через mediainfo, вы увидите, что зачастую был применен 2pass с каким-то неровным "для глаза" битрейтом.
Сообщение отредактировал zub35 - Суббота, 06 Декабря 2014, 01:56
|
|
|
|
|
|
Pyroxylin
|
Дата: Суббота, 06 Декабря 2014, 01:50 | Сообщение #7
|
|
Группа: Проверенные
Сообщений: 52
Статус: Оффлайн
|
Не совсем понимаю, зачем кодировать в х264, когда есть HEVC.
После всех этих соседей с Dolby Surround-аппаратурой, пожелание "в твоём доме будет играть музыка, но ты её не услышишь" обретает даже очень приятный оттенок.
|
|
|
|
|
|
zub35
|
Дата: Суббота, 06 Декабря 2014, 02:19 | Сообщение #8
|
|
Группа: Проверенные
Сообщений: 61
Статус: Оффлайн
|
Цитата Pyroxylin ()
Не совсем понимаю, зачем кодировать в х264, когда есть HEVC.
Не понимаю, зачем кодировать в HEVC, когда есть HM11.
Видимо из-за того, что НЕТ выигрыша в качестве на одинаковый битрейт, с существенным проседанием в скорости кодирования, так и в требуемых мощностях системы для декодирования.
Всё то, что вам навесили на уши про HEVC, пока только на бумаге и в википедии... возможно, найдеться гений способный оптимизировать и ускорить обработку ... но пока такого гения-программиста увы нет.
Там где x264 требуется минута, у HEVC уйдет пол часа, а то и больше, для достижения одного и того-же результата.
Единственный плюс HEVC возможность кодировать 6К и 8К видео
Сообщение отредактировал zub35 - Суббота, 06 Декабря 2014, 02:20
|
|
|
|
|
|
plov333
|
Дата: Суббота, 06 Декабря 2014, 15:47 | Сообщение #9
|
|
Группа: Проверенные
Сообщений: 70
Статус: Оффлайн
|
HEVC пока не хватает оптимизации. Пока её не запилят, вместе с 10-битным профилем, то его использовать будут одни интузиасты. Это примерно как с AVC было в 2007... Так что, ждем, болеем, сопереживаем) |
|
|
|
