|
Описание параметров x264
| |
| Oleggg10 | Дата: Пятница, 29.11.2013, 15:01 | Сообщение # 1 |
|
Полковник
Группа: Администраторы
Сообщений: 162
Репутация: 0
Статус: Offline
| Сложно описать всё про кодек в одном сообщении, он слишком большой. Сам стандарт на 1000 страниц плюс постоянно обновляющиеся доработки. Постараюсь правильно описать реализацию этого стандарта на бесплатной основе. Речь идёт об x264 (наилучшая на данный момент реализация кодека судя по многочисленным тестам).По слухам его пишут бывшие авторы Xvid, которые написали отличный, ставший де-факто стандартом пиратства, кодек MPEG4. Все варианты реализации стандарта h264 можно увидеть здесь.
Сам кодек может работать отдельно, и доступен со своего домашнего сайта. Но, выдаёт он чистый битовый стрим видео, что не вполне удобно для нормальных людей, да и звук надо тоже добавлять вручную. Плюс вряд ли умеет читать многие разнообразные варианты входного потока, которые могут повстречаться. Но зато x264 присутствует в mplayer/mencoder в виде библиотеки, плюс все его опции там есть, так что можно сочетать удобство mplayer/mencoder, который читает что угодно, ну и закодировать может тоже как угодно, в том числе и используя x264 для видео.
Mplayer, как и mencoder в оригинале чисто command line утилиты, что для многих очень сложно и не привычно. Варианты с графической оболочкой можно подобрать здесь, где представлены неофициальные фронтенды для mencoder. Ни одного ни разу не пробовал, и вероятно не буду. Я использую командную строку, привык уже. Так что дальше я буду писать про именно параметры командной строки, а есть они или нет в фронтендах я не знаю.
Так вот про создание роликов или перекодирования фильмов. Этот вариант использования требует как правило максимального качества при том что время кодирования в принципе не важно. Это не видео-конференция где надо всё кодировать на лету, можно подождать, может даже на ночь оставить. Главное чтобы результат был качественным. Для достижения максимального качества обычно используют многопроходное кодирование, обычно 2-х проходное, но 3-4 тоже можно попробовать если никак не получается вместить то что требуется в нужный размер.
Многопроходное кодирование обеспечивает необходимое перераспределение количества битов на каждый кадр для достижения максимального качества (оценка качества программными средствами это отдельная очень большая проблема) как правило используя метрику PSNR. Во всяком случае многопроходное кодирования должно давать результат лучше чем однопроходное, так как кодек на проходе после первого будет заранее иметь информацию о всех типах фреймов на всём протижении ролика, и их сложности для кодирования.
|
| |
| |
| Oleggg10 | Дата: Пятница, 29.11.2013, 15:31 | Сообщение # 2 |
|
Полковник
Группа: Администраторы
Сообщений: 162
Репутация: 0
Статус: Offline
| Видео кодируется по кадрам. Для кодирования используется цветовое пространство YUV, а не RGB. Почему, сейчас объясню. Человеческий глаз гораздо сильнее чувствует яркость, а не цвета. Поэтому две цветовых компоненты можно передавать не целиком, а сильно их урезав. Как правило используется вариант 4:2:0 (логики в этом названии мало, в отличии от 4:2:2, но оно устоялось). Так что яркость передаётся на 100%, а цвет только на 25%. Получается что пикселей в цветовых кадрах в 4 раза меньше чем в яркостном, так как они в 2 раза меньше по горизонтали и по вертикали.
Каждый кадр традиционно разбивают на так называемые макроблоки размером 16x16 пикселей для Y, и соответственно 8x8 для U и V. В h264 допускается дополнительно разбиение на части размером вплоть до 4x4 для Y, и 2x2 для U и V. Макроблоки могут кодироваться разными способами. В первую очередь это intra (внутри кадра) и inter (через кадр) варианты.
Intra кодирования используется для кодирования ключевых кадров I (intra) и для кодирования в inter кадрах объектов, которые в других кадрах отсутсвуют. I кадры можно грубо сравнить с JPEG, они целиком состоят из intra макроблоков, но при этом используют самое большое количество бит для кодирования. Inter кодирование используется для кодирования P (predicted) и B (bi-predicted) кадров. В этом случае макроблоки ищут в других соседних кадрах, указывается вектор смещения и разница (которая чем меньше тем лучше) между соседним кадром и тем что должно быть. В случае дополнительного разбиения макроблока на подчасти вектора смещения можно указывать для каждой части отдельно. Это тратит больше бит в потоке, но даёт возможность передавать более сложное движение или больше деталей. Поиск наиболее подходящего варианта сдвига макроблока в соседних кадрах называют motion estimation. Эта часть кодирования занимает львиную долю времени при кодировании видео. В h264 допускается вплоть до четверть-пиксельного (qpel) указание смещения макроблока, что сильно добавляет точности и качества результата, но существенно увеличивает время кодирования. Для полу- или четверть- пиксельного предсказания движения кадры интерполируются по специальным алгоритмам заложенным в стандарте, но памяти при этом используется тоже до 16 раз больше.
Для кодирования макроблоки подвергаются косинусному преобразованию после чего наиболее значащие коэффициенты получаются в левом верхнем углу матрицы 16x16 или меньше для подразбиений и для цветовых макроблоков. Дополнительно макроблок подвергается квантизации, то есть, если грубо, выкидывают младшие биты у чисел полученных в результате косинуснового преобразования. Чем больше фактор квантизации, тем больше нулей получится в результате, а при кодировании в битовый поток это даёт возможность сэкономить биты. При этом теряется информация, поэтому при декодировании получается не совсем то что должно было получиться.
После квантизации, вектора, квантизованные коэффициенты, информация о разбиении, индексы кадров, с которыми надо сравнивать макроблок если он inter, и другая информация кодируются энтропийным кодированием. В h264 есть два варианта, CAVLC (context adaptive variable length codes) и CABAC (context adaptive binary arythmetic codes). Второй кодирует всегда лучше, до 15%, но существенно сложнее при декодировании, правда сейчас это важно только для встроенных или малоскоростных устройств типа мобильников. Для фильмов всегда используют CABAC.
|
| |
| |
| Oleggg10 | Дата: Пятница, 29.11.2013, 16:00 | Сообщение # 3 |
|
Полковник
Группа: Администраторы
Сообщений: 162
Репутация: 0
Статус: Offline
| Опции mencoder с комментариями для кодирования x264:
x264enc (−x264encopts)
bitrate=<value>
Собственно битрейт, думаю всем понятно: сколько бит информации тратится в секунду.
qp=<0−51>
Это настройка фактора квантизации. Лучше вообще не указывать. Пусть он сам найдёт правильный QP.
crf=<1.0−50.0>
Очень интересный режим константного качества. Кажется он есть только в x264. Размер при этом выдержать нельзя, но зато качество как бы будет всегда постоянным. Оно оценивается наверняка по метрике PSNR, которая не всегда отражает качество для субъективного просмотра. Да и режим этот экспериментальный, на форумах у людей с ним часто бывают проблемы. Так что пользоваться не советую пока. Но вообще очень интересный режим, если не важен итоговый размер.
pass=<1−3>
Многопроходное кодирование. Вещь необходимая для создания качественного результата. Как я уже писал, в 1-проходном случае encoder не может оптимально перераспределить биты в потоке для сцен с большим движением и деталями, и для сцен, где движения мало, и деталей меньше. Поэтому он будет пытаться держать битрейт всегда одинаковым, а основной "ручкой" регулирования битрейта является фактор квантизации. Если вдруг encoder наткнётся на сцену с большим и сложным движением, он значительно "отквантизирует" её так что качество будет ниже чем в других сценах. Правда, считается что человек всё равно не заметит если в кадре всё быстро мелькает и дрыгается, но тем не менее артифакты сильного сжатия будут более заметными.
2-проходного сжатия обычно хватает, так как encoder на первом проходе просчитывает типы кадров и примерный размер кадра. Но это всё немного приблизительно так как реальное кодирование на первом проходе обычно бывает не в самом высоком качестве. Поэтому для перфекционистов есть 3-й проход, где после 2-го уже качественного прохода информация известна вся. После 3-го прохода остальные смысла не имеют.
turbo=<0−2>
Турбо режим для первого прохода многопроходного кодирования. В случае 1 отключается четверть-пиксельная точность, в случае 2 используется быстрый грубый режим motion estimation. Этот режим чисто оценочный, а если процессор мощный то его вообще можно не использовать.
keyint=<value>
Количество кадров между ключевыми. В h264 это число ничем не ограничено, так как точность не теряется в отличие от MPEG2. IDR это I кадр, ранее которого ни один P или B не могут ссылаться. Поэтому с него можно начинать декодирование как с начала фильма. IDR кадры используются при быстрой перемотке, так как с них начинается показ кадров, которые на него ссылаются. Если перемотка не нужна, то keyint можно указать очень большим, но умолчательное значение 250 и так уже довольно большое. Больше смысла делать мало, так как в количестве битов выигрыш будет минимальным.
keyint_min=<1−keyint/2>
Минимальное количество кадров между IDR, то есть не ставить IDR слишком часто. Лучше не трогать, x264 вполне разумно их расставляет и так.
scenecut=<−1−100>
Фактор определения того что началась новая сцена (в этом случае большая вероятность того что encoder вставит I кадр, что соответственно отнимает много бит, но повышает качество для кадров которые на него будут ссылаться). Лучше не трогать, умолчательно значение вполне разумное.
frameref=<1−16>
Максимальное количество кадров, на которые могут ссылаться P и B кадры. Экспериментально показано что больше чем 6 значение мало улучшает качество. В теории большое (очень большое) количество референсных кадров помогает кодированию сцен с циклическим движением (догадайтесь сами каким). Но проблема в том что декодеру надо держать в памяти все кадры, на которые могут быть ссылки, так что чем больше значение этого параметра, тем больше надо памяти. Железячные ускорители h264 типа видео карт допускают не более 6 кадров, и если их больше, то декодирование будет только на процессоре. Ну а то про что кто-то мог подумать, это повторяющееся движение часто требует больше чем 16 максимально позволяемых референсных кадров, так как 16 в случае 25 кадров в секунду это примерно 2/3 секунды.
bframes=<0−16>
Максимальное количество B кадров подряд. На B кадрах в h264 экономится основное место. По сравнению с I кадрами они могут быть до 100 раз меньше, а по сравнению с P раз в 5-10 меньше. Так что много B кадров это хорошо. Но слишком много их быть не должно, так как увеличивается расстояние до ссылочных P кадров, да и качество начинает теряться. Нормальное значение должно быть 2-5. Следующая опция в любом случае предпочтительнее.
(no)b_adapt
Определять автоматически сколько делать B кадров. Отменяет максимум указанный выше. Лучше пользоваться этой опцией, тем более что она и так включена по умолчанию.
(no)b_pyramid
Хорошая опция, которая позволяет использовать B кадры как референсные для других B. Для хорошего качества лучше включить.
(no)deblock
В h264 стандартом предусмотрен фильтр для удаления границ макроблоков. Как правило добавляет качество восприятия. Включать надо.
deblock=<−6−6>,<−6−6>
Пороги работы деблочного фильтра. Лучше не трогать.
(no)cabac
CABAC включен по умолчанию. Отключать не стоит.
(no)weight_b
Взвешенное предсказание. Этот режим хорошо работает для переходов одной сцены в другую и собственно всё. Это когда в B кадре указываются сразу 2 референсных кадра на один макроблок с необходимыми коэффициентами, какую долю брать из какого. На практике качеству помогает слабо так как указание двух индексов и ещё и долей качества занимает много места, а поиск в motion estimation может очень сильно замедлить. Фактически никогда не используется.
partitions=<list>
Enable types p8x4, p4x8, p4x4. p4x4 is
recommended only with subq >= 5, and only at low resolutions.
Какие позволять подразбиения макроблоков. На качество влияет сильно. Лучше всего указать all. Хотя конечно скорость кодирования будет серьёзно увеличена, так как потребуется проверять все варианты, но умные алгоримты позволяют уменьшить перебор, то есть пробовать дополнительные подразбиения если хотя бы 8x16 или 16x8 даёт прирост качества.
(no)8x8dct
Лучше не трогать.
me=<name>
Select fullpixel motion estimation algorithm.
dia
diamond search, radius 1 (fast)
hex
hexagon search, radius 2 (default)
umh
uneven multi-hexagon search (slow)
esa
exhaustive search (very slow, and no better than umh)
Варианты алгоритмов для предсказания движения. Общепринято что UMH даёт лучшие результаты, правда он и медленнее других.
me_range=<4−64>
Размер шестиугольника для предсказания движения. Значение по умолчанию вполне разумное.
subq=<0−9>
Комплексный параметр, как бы выбора качества. Понятно что 9 самый лучший вариант, так как он включает максимальное количество оптимизационных алгоритмов. Для первого прохода при многопроходном кодировании можно ограничиться 7 или даже 5.
(no)chroma_me
Учитывать цвет, а не только яркость при предсказании движения. Обычно при нормальном изображении Y и UV плоскости очень сильно коррелируют, так что в большинстве случаев предсказывают движение только по яркости. Но это бывает неправильно для различных аномальных клипов где по изображению плавают цветные пятна одинаковой яркости. Лучше этот параметр указывать даже для фильмов если требуется качественное кодирование.
(no)mixed_refs
Позволять подразбиениям макроблока иметь различные вектора смещения. Очевидно необходимо для сцен со сложными движениями мелких деталей (трава на ветру, листья и т.д.). Надо указывать.
trellis=<0−2> (cabac only)
Оптимизация битового потока. Вещь необходимая для качества. Про алгоритмы писать долго, просто надо поверить что штука полезная, и надо указывать 2.
deadzone_intra=<0−32>
Лучше не трогать.
(no)fast_pskip
В P и в B кадрах есть такое понятие как skip, когда макроблок фактически копируется из референсного кадра почти без движения. Это очень экономит биты, так как skip-ы кодируются в очень небольшое их количество, но на качестве может сказатья, особенно если битрейт небольшой. Для качественного кодирования стоит указывать nofast_pskip.
nr=<0−100000>
Когда снимают в темноте, камеры часто дают шум, который мало того что никому не интересен, так ещё и тратит много битов для его кодирования. Денойзинг вещь для кодирования видео очень полезная, но обычно эти фильтры есть во всех видео редакторах, так что встроенным в x264 денойзером пользоваться наверное не обязательно, тем более что я не знаю какие тут надо указывать числа.
chroma_qp_offset=<−12−12>
Лучше не трогать.
aq_mode=<0−2>
Полезная опция для перераспределения битов между кадрами с разным количеством движения и деталей. Включена по умолчанию, отключать не надо.
aq_strength=<positive float value>
Лучше не трогать.
level_idc=<10−51>
Уровень h264. Кроме профилей, которые в h264 определяют фичи (типа поддержки CABAC) есть уровни, которые требуют каких-то свойств от устройства декодирования. Скажем, уровень 4.1 специфицирует максимальное количество референсных кадров 6, так что железячные декодеры могут с ним справиться. В 5.1 таких кадров может быть до 16, что требует очень много памяти. Для blue ray кажется используется 4.1, но для современных компьютеров и 5.1 вполне подходит даже для HD.
threads=<0−16>
Многопоточность. Это всегда хорошо учитывая что сейчас все процессоры многоядерные. Но ущерб качеству может быть нанесён больший чем тут написано. По моему опыту в x264 видимо параллельность сейчас сделана покадровая (не до конца понятно как это у них получается учитывая все зависимости между кадрами, но код GPL я смотреть не могу). Так что если количество потоков большое, то все кадры параллельно кодируются с примерно одинаковым фактором квантизации. Выглядит это примерно так, в начале пачка кадров кодируется с большим битрейтом, потом внезапно encoder обнаруживает что никак в битрейт он не вписывается, и следующую пачку кадров жмёт очень сильно при этом серьёзно теряя качество. Постепенно этот процесс устаканивается до следующего IDR или смены сцены.
Это справедливо в первую очередь для сильной распараллеленности, я проверял на 8- и 16- процессорных машине. Обычно стольких процессоров у нормальных людей нет, так что даже в случае 4 ядер можно наверное использовать без опасений. Плюс я уверен что многопроходное кодирование должно помочь для предсказания квантизации, так как ошибаться encoder может только если не знает заранее что там у него впереди. Но так это или нет, я не знаю.
(no)global_header
Лучше не включать, так как многие проигрыватели требуют повторяющихся SPS и PPS.
(no)interlaced
Указывает вариант видео (полный кадр или черезстрочный). Я думаю объяснять что такое черезстрочное кодирование никому не надо. Все видео камеры обычно снимают в interlaced если не включать progressive.
log=<−1−3>
−1
none
0
Print errors only.
1
warnings
2
PSNR and other analysis statistics when the encode finishes (default)
3
PSNR, QP, frametype, size, and other statistics for every frame
Статистика после кодирования. Кому надо, и кто понимает что там смотреть, можно включить.
(no)psnr
JM encoder это референсный encoder разрабатываемый ITU-T. Опция интересна только разработчикам кодеков.
(no)ssim
Печатать метрику SSIM (рейтинг выходного качества, определённый программным способом). Она на порядок сложнее вычисляется чем PSNR, хотя считается что более правильно отражает качество восприятия человеком.
(no)visualize
Визуализировать макроблоки. Интересно исключительно разработчикам x264.
|
| |
| |
|
