[не удалять] Как выбрать оптимальный битрейт и ключевые параметры для рипа в x264 [архив №1]

Страницы :   Пред.  1, 2, 3 ... 31, 32, 33 ... 98, 99, 100  След.
Тема закрыта
 

shellgen

VIP (Адм)

Стаж: 18 лет 1 месяц

Сообщений: 6417

shellgen · 10-Окт-09 12:07 (15 лет назад)

Ang+ писал(а):
1) После перевода в rgb32 одна и та же картинка светлее чем в YV12?
C чего бы это?
Ang+ писал(а):
2) Программные пееры (mpc и т.п.) на выходе так или иначе показывают rgb, и те настройки делались, чтобы преобразование выполнялось именно через ffdshow, а не что-то еще?
Именно так, на выходе в любом случае мы смотрим RGB, который можно получить из YUV c одной из двух стандартных матриц цвет-преобразований, завязав этот процесс на ffdshow, явно указывая способ определения нужной матрицы, исключается вероятность того, что другой фильтр в системе сделает апскейл цвета по другой схеме.
[Профиль]  [ЛС] 

Ang+

Top Loader 01* 100GB

Стаж: 16 лет 7 месяцев

Сообщений: 993

Ang+ · 10-Окт-09 13:11 (спустя 1 час 3 мин.)

shellgen писал(а):
C чего бы это?
После добавления converttorgb32(matrix="PC.709") посветлела. Сменил на Rec709 - вот так не меняется, только желтеет (но так и должно быть по идее. Нельзя для VC1Source как-то указать, что на входе эта самая BT.709?)
[Профиль]  [ЛС] 

Dr.Chook

Стаж: 16 лет 2 месяца

Сообщений: 1037

Dr.Chook · 10-Окт-09 16:01 (спустя 2 часа 50 мин., ред. 10-Окт-09 16:01)

У меня возник вопрос...
Имеется ремукс Midnight Meat Express, внутри видео пожатое AVC. Решил его пережать x264
вот такой строкой
--profile high --level 4.1 --crf 18.0 --thread-input --deblock -1:-1 --bframes 4 --b-adapt 2 --b-pyramid --ref 5 --vbv-bufsize 62500 --vbv-maxrate 50000 --no-mbtree --merange 32 --me umh --subme 9 --partitions p8x8,b8x8,i4x4,i8x8 --trellis 2
А вот итог вышел непонятный для меня... размер видео остался прежним! Так не бывает... всегдя в 2 или 1.5 раза уменьшался объем, а тут как было 20 со звуком, так и стало 20 со звуком. Где подвох?
попробовал crf 25 сделать - размер видео прогнозируется 3гига... crf 19 - 14.5, сrf 18 - 17.5
Это что же такое в исходнике то сделано было? Кстати картинка как-бы зашумленая вся специально в мелких копошащихся точках. Похожее видел в Twilight (сумерки) там тоже сжимается плохо, но все же сжимается. А тут было 20, стало 20... значит при сжатии какой-то фокус делали...
И еще... если я не указываю --psy-rd, то все равно этот параметр по умолчанию берется с настройками 1.0:0.0, так?
Медиаинфо оригинала
Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Duration : 1h 42mn
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
[Профиль]  [ЛС] 

Furyx

Стаж: 16 лет 6 месяцев

Сообщений: 1335

Furyx · 10-Окт-09 16:19 (спустя 17 мин.)

Dr.Chook писал(а):
попробовал crf 25 сделать - размер видео прогнозируется 3гига... crf 19 - 14.5, сrf 18 - 17.5
вы б лучше кванты показали... а так что сказать, если источник изначально чистенький, за счет чего вы хотите добиться существенного выигрыша? B-фреймы не поднимаете, рефы не поднимаете (я так понимаю из-за dxva), me на максимум крутить не хотите...
вобщем то в первом посте все написано -
Цитата:
1. Использовать более тяжёлые настройки кодека: поднимать b-frames, --ref , --b-pyramid, --subme ...
2. Упростить видео, вычистив из него посторонние шумы
3. Опускайте размер кадра
[Профиль]  [ЛС] 

Dr.Chook

Стаж: 16 лет 2 месяца

Сообщений: 1037

Dr.Chook · 10-Окт-09 16:24 (спустя 5 мин., ред. 10-Окт-09 16:24)

Я немного не то имел в виду.
Я спрашивал, как такое может быть что при использовании --crf 18 размер оригинала и результата примерно равен?
[Профиль]  [ЛС] 

Furyx

Стаж: 16 лет 6 месяцев

Сообщений: 1335

Furyx · 10-Окт-09 16:29 (спустя 5 мин.)

Dr.Chook
для 1080р crf18 это как бы не мало, для отличного качества я бы насчет 22-23х думал.
остальные настройки оригинала у вас есть? b-frames, me ну и т.д... да и сказали бы что кодируете - от источника то тоже зависит...
[Профиль]  [ЛС] 

Dr.Chook

Стаж: 16 лет 2 месяца

Сообщений: 1037

Dr.Chook · 10-Окт-09 16:51 (спустя 21 мин.)

Furyx, увы, настроек того как закодирован оригинал у меня нет, иначе я бы нашел отличия того что делаю я и что делали они. В качестве исходника - ремукс.
Поэксперементирую с --psy-rd, кстати если отключить psy вообще, то размер результата уменьшается на 12%, но и качество передачи мелких деталей тоже падает...
[Профиль]  [ЛС] 

Bladru

Стаж: 17 лет

Сообщений: 535


Bladru · 10-Окт-09 21:21 (спустя 4 часа, ред. 11-Окт-09 00:07)

Ang+
У тебя каша в голове. Нет ничего хуже рипера, который меняет умолчания, не понимая сути своих действий. А тема, которую ты затронул, довольно велика.
скрытый текст
Начнём с того, что "цвет" это очень субъективное понятие. В природе есть световые волны разной частоты. Исследования показали, что определённый диапазон частот (видимый свет) воспринимается человеческим глазом. Но воспринимается не каждая волна по отдельности, а их совокупность. Причём есть три основных частоты, "смешивая" которые можно получить почти все воспринимаемые человеком цвета. Если эти частоты излучаются отдельно (например лазером), то воспринимаются они как красный, зелёный и синий цвета. Отсюда родилась RGB модель. Она очень удобна для технической реализации в устройствах, которые свет излучают (мониторы и проекторы). Т.к. там из одной точки можно "посветить" тремя цветами разной интенсивности и таким образом, используя только 3 основных цвета получать почти весь видимый спектр.
Надо понимать разницу между светом излучаемым и отражаемым.
Если на белую стену посветить тремя прожекторами то получится вот такая штука:

На пересечении красного, зелёного и синего пятна мы получаем области, которые излучают сразу два цвета: зелёный+синий=cyan, синий+красный=magenta, красный+зелёный=yellow.
Но представим ситуацию, когда мы не можем излучать свет самостоятельно. Это случай журналов и картин. В природе естественным является белый свет: смесь из волн разной частоты, но примерно одинаковой энергии. Когда этот свет попадет на поверхность покрытую определённым веществом, волны одних частот от неё отражаются, волны других частот поглощаются веществом. Тогда можно взять три основных вещества (краски), которые по отдельности отражают только цвета cyan, magenta и yellow, и смешивая их в определённой пропорции получить почти все существующие цвета. Если нанести три пятна на белую бумагу и посветить на них белым светом, то будут они выглядеть так:

Например, смешивая cyan (голубой: поглощает красный, отражает зелёный и синий) и magenta (розовый: поглощает зелёный, отражает красный и синий) мы получаем поверхность, которая поглащает красный и зелёный и, соответственно, отражает только синий. Отсюда появилась цветовая схема CMYK, которая используется при печати. "K" означает четвёртую, чёрную, краску. Её используют по техническим соображениям.
Но вернёмся к "компьютерным" цветовым моделям. RGB удобна для воспроизведения цветов на мониторе или проекторе. Однако для передачи и кодирования сигнала она мало пригодна по нескольким причинам:
1) ЭЛТ мониторы имеют нелинейную зависимость между подаваемым напряжением и интенсивностью свечения фосфора. Это значит, что точность кодирования и устойчивость к шуму не одинакова для разных цветов.
2) Считается, что человеческий глаз больше замечает изменения яркости, чем цвета. RGB модель не позволяет это учесть.
3) Когда появилось цветное телевидение, необходимо было сохранить совместимость с чёрно-белыми телевизорами.
Поэтому для передачи цветного сигнала была разработана модель YUV, которая использовала один компонент (Y) для передачи яркости (чёрно-белое телевидение) и два дополнительных компонента (UV) для передачи цвета. В цифровом кодировании сигнала схожая модель зовётся YCbCr.
Да, пару слов нужно сказать ещё об одной модели.
Это теоретическая модель XYZ, созданная CIE (Commission Internationale de l'Eclairage) на основе исследований человеческого цветовосприятия. Эта модель вмещает все видимые человеку цвета. Она разработана таким образом, что два компонента представляют цвет, а третий — яркость (Y). Для иллюстраций используют модель xyY, получающуюся из XYZ простыми преобразованиями. При это трёхмерными изображениями обычно не заморачиваются и компонент яркости отбрасывается. Получается такое изображение (эта xy плоскость отмечена на предыдущем изображении синим срезом):

На краю, обведённом чёрным, находятся монохроматические цвета. Соответствующая им длина волны подписана синим. Эта диаграмма имеет одно замечательное свойство: если выбрать на ней три основных цвета (праймари), то внутри получившегося треугольника окажутся все цвета, которые можно представить при помощи этих праймари. Вообще, это распространяется на любой n-угольник. Отсюда и родилась RGB-модель.
Но праймари можно выбрать различным образом. Как правило, выбор диктуется некими практическими соображениями. Например наличием в производстве соответствующего люминофора. И вот тут начинаются проблемы...
В зависимости от выбора праймари мы получаем разные цветовые пространства.
CIE RGB:

Это пространство основано на трёх монохроматических цветах. E — точка белого.
sRGB:

Стандарт, созданный HP и Microsoft в 1996 году. Данный стандарт применяется повсеместно: компьютерные мониторы, интернет, принтеры... Кроме 3-х праймари и точки белого, он определяет ещё и кривую гамма-коррекции. Она устанавливает связь между реальной интенсивностью цвета и сохраняемым его значением. Это требовалось из-за нелинейной зависимости свечения люминофора на экране ЭЛТ монитора от подаваемого напряжения. ЭЛТ мониторов уже нет, а гамма-коррекция осталась.
Ещё несколько цветовых пространств:
ITU-R Recommendation BT.709 совпадет с sRGB.
ITU-R BT.601 совпадает с ITU-R BT.470-2.
Вообще, большинство используемых пространств похожи или на BT.709, или на BT.601.
Так вот. Чтобы преобразовать сигнал из YCbCr в RGB нужно знать, какое цветовое пространства использовалось при получении YCbCr. Для MPEG-1 это всегда BT.601. Для MPEG-2 значение устанавливается в заголовке, по умолчанию — BT.709. Для MPEG-4 по умолчанию BT.601 для SD и BT.709 для HD.
Казалось бы, в чём сложности? Внимание, сюрприз! В отличии от общедоступных стандартов MPEG, спецификация DVD-Video стоит $5000, и каждый подписчик обязуется не разглашать полученную информацию. В итоге, выводы о том, какая матрица должна использоваться для DVD, делаются по косвенным признакам. Например по тому, что коммерческие продукты предполагают именно BT.601.
Учитывая, что многие приложения склонны игнорировать флаги в заголовке, при кодировании вполне разумно использовать BT.601 для SD и BT.709 для HD. Для конвертации можно воспользоваться плагином ColorMatrix для Avisynth.
Есть несколько способов контроля цветового пространства преобразования YCbCr -> RGB при воспроизведении: настройки рендерера, выполнение преобразования в RGB через ffdshow, скрипты Avisynth, шейдеры в MPC-HC и т.д.
Ещё одна особенность YCbCr -> RGB преобразования состоит в том, что на каждый из трёх компонентов YCbCr выделено по 8 бит (т.е. значения 0-255). Однако не всегда они используются полностью. Стандарты BT.601 и BT.709 используют значения 16-235 для яркости и 16-240 для цветности. Традиция эта идёт от аналогового телевидения. В "компьютерных" же стандартах (JPEG, MJPEG, Fraps) используются диапазоны 0-255 и 1-255 соответственно. Кроме того, для значений RGB компьютерные мониторы используют диапазон 0-255, в то время как телевизоры и проекторы 16-235. Дефолтные рендереры в Windows (VMR7, VMR9, EVR) в некоторых случаях неправильно преобразовывают диапазон (для SD видео, как правило).
В отличии от неверного цветового пространства, неправильно выставленные уровни легко заметить: чёрный цвет становится тёмно-серым, а белый светло-серым. Исправить также можно несколькими способами: в настройках некоторых рендереров, делая RGB преобразование через ffdshow, шейдерами в MPC-HC, отдельным фильтром в ffdshow или даже настройками в драйверах видеокарты.
Как уже упоминалось, считается, что человек сильнее воспринимает изменения яркости, чем изменения цветности. Так как YCbCr кодирует яркость (Y) и цветность (CbCr) отдельно, то эта особенность человеческого восприятия активно используется кодеками.
Называется это Chroma subsampling.
Расмотрим 2 строки по 4 пикселя в каждой.
В стандартном варианте мы имеем по 4 значения Y для каждой строки, и по 4 значения CbCr для каждой из двух строк. Это описывается соотношением 4:4:4. В общем виде записывается как J:a:b, где J — количество Y-сэмплов в каждой из строк, a — количество CbCr сэмплов в первой строке, b — количество CbCr сэмплов во второй строке.

На иллюстрации указано по два соседних блока (2 строки по 8 пикселей). Белые и серые квадратики символизируют пиксели, для каждого из которых отдельно задаётся своё значение Y (яркость), красные и синие прямоугольники — группы пикселей имеющие общее, усреднённое, значение CbCr (цветность). Для кодирования видео применяется, как правило 4:2:0 (возможно в x264 появится поддержка 4:4:4). Т.е. блок из четырёх пикселей имеет один усреднённый цвет. При это каждый из этих пикселей имеет разную яркость.
Что это нам даёт? Существенное уменьшение в размере (на блок 2*4=8 пикселей вместо 3*8=24 байт приходится 8+2*2=12 байт — в два раза меньше, 1.5 байта на пиксель). С другой стороны, преобразовывая обратно в RGB мы можем получить артефакты. Заметны они становятся либо на видео низкого разрешения с текстом (в этом случае перед кодированием стоит сделать апскейл), либо при переходах между некоторыми цветами (чёрный-красный, зелёный-маджента), либо на специальных тестовых изображениях. Для того, чтобы избежать артефактов при воспроизведении нужно либо использовать качественный рендерер (Haali, madVR), либо выполнять преобразование в RGB програмно, через ffdshow.
RGB преобразование через ffdshow несколько медленнее, чем через рендерер. Если использовать опцию "высококачественного преобразования", то значительно медленнее. Чтобы ffdshow выполнял преобразования самостоятельно, нужно на закладке "Вывод" оставить галки только напротив RGB форматов. Параметры преобразования настраиваются на закладке "RGB преобразование".
YCbCr -> RGB является преобразованием с потерями. Происходит это как из-за ошибок Chroma upsampling, так и из-за округлений при преобразовании.
Учитывая, что большинство кодеков использует YCbCr, RGB преобразования при кодировании можно и нужно избегать. К слову, для изменения цветового пространства при кодировании, RGB преобразование тоже не требуется.
[Профиль]  [ЛС] 

crazy-cactus

Top Seed 02* 80r

Стаж: 16 лет 10 месяцев

Сообщений: 2813

crazy-cactus · 10-Окт-09 22:19 (спустя 57 мин.)

Всем доброй ночи. Имеется вот такое видео (оцифрованная VHS в MPEG-2):
скрытый текст

хочется вытащить из него максимум возможного, при этои уложившись в приемлемый битрейт. Какие настройки x264 стоит крутить для такого страшного видеоряда?
[Профиль]  [ЛС] 

sasha990

Стаж: 16 лет 2 месяца

Сообщений: 378

sasha990 · 10-Окт-09 23:35 (спустя 1 час 16 мин.)

Bladru
Большое спасибо за пару слов по многим важным аспектам
Несколько вопросов...
Цитата:
(возможно в x264 появится поддержка 4:4:4)
А поддержка более чем 8-ми битных цветовых пространств не планируется случайно? По-моему это было бы несколько "нужнее", чем чем "4:4:4"...
Цитата:
YCbCr -> RGB является преобразованием с потерями. Происходит это как из-за ошибок Chroma upsampling, так и из-за округлений при преобразовании.
Учитывая, что большинство кодеков использует YCbCr, RGB преобразования при кодировании можно и нужно избегать. К слову, для изменения цветового пространства при кодировании, RGB преобразование тоже не требуется.
А "изменение цветового пространства" – это не "преобразование с потерями"? Из-за тех-же ошибок округления...
Цитата:
4:1:1 — 4:2:0 — 4:2:2 — 4:4:4
Глядел-глядел на картинки, но так и не понял смысла этого обозначения... Чего где 2, чего где 1...
[Профиль]  [ЛС] 

Bladru

Стаж: 17 лет

Сообщений: 535


Bladru · 11-Окт-09 00:46 (спустя 1 час 10 мин.)

sasha990 писал(а):
А поддержка более чем 8-ми битных цветовых пространств не планируется случайно?
Я про это не слышал пока.
sasha990 писал(а):
А "изменение цветового пространства" – это не "преобразование с потерями"? Из-за тех-же ошибок округления...
Угу. Только одно дело преобразовать коэффициенты в YCbCr (одно преобразование, только ошибки округления), и несколько иное перегонять YCbCr -> RGB -> YCbCr (двойная ошибка округления, Chroma upsampling, Chroma subsampling). Тут в соседней теме подобные идеи проскакивали, так что на всякий случай упомянул.
sasha990 писал(а):
Глядел-глядел на картинки, но так и не понял смысла этого обозначения... Чего где 2, чего где 1...
Немного подправил текст. Картинки с википедии, каждую из них по-хорошему бы напополам разрезать, чтобы остались только блоки 2*4, а не 2*8. Там по три картинки. Верхняя — количество семплов яркости (Y) для каждой из двух строк. Оно как правило равно количеству пикселей. Средняя — показывает сэмплы, имеющие разную цветность. Например для 4:1:1 вся первая строка имеет одинаковое значение CbCr, т.е. один сэмпл (имеется в виду блок 4 пикселя; на картинке два соседних блока, поэтому пикселей восемь и, соответсвенно, сэмплов два). Для второй строки тоже имеется свой отдельный сэмпл цветности. Для 4:2:0 немного по-другому: 4(сэмпла яркости на каждую строку):2(сэмпла цветности на первую строку):0(сэмплов цветности на вторую строку — используется тот же цвет, что и в первой строке). Нижняя картинка — суперпозиция яркости и цветности, т.е. двух верхних картинок, особо ничего не демонстрирует.
[Профиль]  [ЛС] 

sasha990

Стаж: 16 лет 2 месяца

Сообщений: 378

sasha990 · 11-Окт-09 01:02 (спустя 15 мин.)

Bladru
скрытый текст
Цитата:
Тут в соседней теме подобные идеи проскакивали, так что на всякий случай упомянул.
В какой теме?
Цитата:
Немного подправил текст...
Спасибо, наконец то понял этот момент...
[Профиль]  [ЛС] 

Bladru

Стаж: 17 лет

Сообщений: 535


Bladru · 11-Окт-09 01:18 (спустя 15 мин.)

sasha990
[Профиль]  [ЛС] 

_Woland_

Стаж: 15 лет 10 месяцев

Сообщений: 1067

_Woland_ · 12-Окт-09 02:18 (спустя 1 день 1 час)

Какое значение SSIM считается достаточно хорошим?
[Профиль]  [ЛС] 

Furyx

Стаж: 16 лет 6 месяцев

Сообщений: 1335

Furyx · 12-Окт-09 02:51 (спустя 33 мин.)

_Woland_
думаю как и crf зависит от размера картинки. у себя на SD как правило вижу около 0.99 +- 0.005, это при QP где-то 15, 17, 19 для I, P, B соответственно.
[Профиль]  [ЛС] 

Ang+

Top Loader 01* 100GB

Стаж: 16 лет 7 месяцев

Сообщений: 993

Ang+ · 12-Окт-09 11:29 (спустя 8 часов)

Bladru, спасибо-спасибо) А каша - все ж таки не пустота, надеюсь) Огромное спасибо не жалеющим времени ответить на вопросы начинающих
[Профиль]  [ЛС] 

shellgen

VIP (Адм)

Стаж: 18 лет 1 месяц

Сообщений: 6417

shellgen · 13-Окт-09 17:50 (спустя 1 день 6 часов, ред. 13-Окт-09 17:51)

_Woland_ писал(а):
Какое значение SSIM считается достаточно хорошим?
Для живого видео цифра пригодна больше для сравнения эффективности различных синтетических настроек на одном и том же подопытном. Хоть SSIM в отличие от PSNR и заточено в некоторой степени на восприятие, но psy портит его почём зря, часто заметно прибавляя визуального комфорта, так что обращать избыточное внимание на этого попугая имхо не стоит. ))
[Профиль]  [ЛС] 

Ironcast

Стаж: 16 лет

Сообщений: 915

Ironcast · 13-Окт-09 18:46 (спустя 55 мин., ред. 13-Окт-09 18:46)

Ang+ писал(а):
shellgen писал(а):
C чего бы это?
После добавления converttorgb32(matrix="PC.709") посветлела. Сменил на Rec709 - вот так не меняется, только желтеет
Обычное дело--против законов физики не попрёшь. Видео со временем на свету стареет , светлеет и желтеет. Если не веришь, проведи эксперимент с газетой: расстели её в солнечный день на подоконнике, спустя двое суток с ней будет тоже , что и с твоим видео. Отсюда делай выводы
[Профиль]  [ЛС] 

_Woland_

Стаж: 15 лет 10 месяцев

Сообщений: 1067

_Woland_ · 13-Окт-09 21:14 (спустя 2 часа 28 мин.)

shellgen
Не, ну просто интересно стало. Включил вот на анимации, сделал тестовую серию, получилось:
Цитата:
SSIM Mean Y:0.9932448
Ну и интересно стало, хорошее ли это значение. А то, что это не так уж и точно отражает реальную картину, это я знаю.
[Профиль]  [ЛС] 

@lolkin@

Стаж: 16 лет 7 месяцев

Сообщений: 1362


@lolkin@ · 13-Окт-09 21:39 (спустя 24 мин.)

_Woland_
хорошее ))
[Профиль]  [ЛС] 

Furyx

Стаж: 16 лет 6 месяцев

Сообщений: 1335

Furyx · 13-Окт-09 22:00 (спустя 20 мин.)

@lolkin@ писал(а):
хорошее ))
кстати, насчет "попугайчиков"... а каким попугайчикам больше других вы доверяете?
[Профиль]  [ЛС] 

@lolkin@

Стаж: 16 лет 7 месяцев

Сообщений: 1362


@lolkin@ · 14-Окт-09 00:14 (спустя 2 часа 14 мин., ред. 14-Окт-09 00:14)

Furyx
насчет попугайчиков соглашусь с шеллгеном, доверяю глазам ))
[Профиль]  [ЛС] 

Furyx

Стаж: 16 лет 6 месяцев

Сообщений: 1335

Furyx · 14-Окт-09 00:32 (спустя 17 мин.)

@lolkin@
это все понятно, но всетаки глаза - это не попугайчики а речь шла именно о них
я вот не пойму например, почему у меня на втором проходе QP немного поднимаются для I, P, а для B немного падают... на глаз различить не могу.
[Профиль]  [ЛС] 

Ang+

Top Loader 01* 100GB

Стаж: 16 лет 7 месяцев

Сообщений: 993

Ang+ · 15-Окт-09 14:17 (спустя 1 день 13 часов, ред. 15-Окт-09 14:17)

Товарищи кодеры, задался таким вопросом - насколько связаны между собой параметры --me и --merange (ну и --subme, возможно)? В смысле того, какие значения второго целесообразны для каких значений первого.
--me наиболее часто встречаю umh, --merange: 16, 24, 32, иногда даже 64.
Но тут вот раз - рип от DON, me_range=36. Почему именно такое значение?
Попробовал погуглить - нашел пару старых обсуждений на doom9:
http://forum.doom9.org/showthread.php?t=96636
http://forum.doom9.org/showthread.php?t=110636
где есть такой пост:
Цитата:
In this thread Manao sad, that merange works only with --esa. With --dia, --umh it only slowdown without any effect. I offer rewrite contexthelp.xml in megui: <Recomended>8 to 16</Recomended> in section about merange.
Топы старинные, еще 2005 года, но, поскольку английским не владею, самостоятельно искать трудно среди обсуждений. А также еще и понимать, к чьим словам следует прислушиваться. Кто его знает, этого Manao)
В тех же http://mewiki.project357.com/wiki/X264_Settings#merange и http://wiki.oszone.net/index.php/MeGUI из практических указаний только то, что
Цитата:
Для алгоритмов "diamond" и "hexagon" допустимыми значениями являются числа от 4 до 16 (рекомендуется 16). Для остальных алгоритмов - от 4 до 64 (рекомендуется 32).
но без подробностей.
[Профиль]  [ЛС] 

sasha990

Стаж: 16 лет 2 месяца

Сообщений: 378

sasha990 · 15-Окт-09 15:29 (спустя 1 час 12 мин.)

Ang+, пару слов про me–merange...
скрытый текст
  1. umh – по-моему самый оптимальный алгоритм, с точки зрения соотношения производительность/качество. Всё, что "ниже его" – несколько быстрее и ощутимо хуже. Всё что выше – ощутимо медленнее и незначительно лучше
  2. На счёт merange при umh: разницы между всеми значениям "16 и выше" вижу немного. Меньше 16 ставить не стОит. Можно поднять до 24-32.
  3. Алгоритмы esa и tesa – медленные, дающие небольшой прирост в качестве, логично их использовать, когда скорость энкода совсем не важна, а +капельку улучшения получить хочется. Логично что в таком случае поставить merange можно и побольше (раз времени то совсем не жалко). Но всё равно не думаю, что в значениях больше 32 есть хоть какой-то смысл.
  4. Алгоритмы "меньше umh" – быстрые алгоритмы, позволяющие получить "максимум" fps энкода. Логично, что если стремимся именно к этому, то ставить большИе значения merange нелогично, т.к. скорость "уйдёт", а качество "не придёт"... Иными словами больше 16 ставить смысла не вижу.

А вообще, думаю, что достаточно просто никогда не ставить ниже umh 16, и не думать об этом Т.к. все эти изменения на практике как-то не вызывают каких-либо "глобальных явлений", а если хочется "подумать", то уж лучше над другими параметрами, которые влияют на результат намного сильнее...
//если я не прав – меня поправят
//если кто-то покажет "более научные" изложения соответствия me–merange, с удовольствием почитаю, "для общего развития"=)
[Профиль]  [ЛС] 

Ang+

Top Loader 01* 100GB

Стаж: 16 лет 7 месяцев

Сообщений: 993

Ang+ · 15-Окт-09 15:46 (спустя 17 мин., ред. 15-Окт-09 15:46)

sasha990, ну вот как бы это-то понятно и общеизвестно) Из "незначительно лучше" следует тоже логичная рекомендация - смотри на глаз. Но ведь алгоритмы поиска --me отличаются, и то что логично для одного может быть совсем не нужно для другого? Плюс еще для разных --subme возможно тоже могут быть разные варианты?
То есть я клоню к тому, что при прозрачной логике - "больше значение - лучше результат, но сильно задирать мало целесообразно" нет ли еще каких-то правил, типа "--merange должно быть кратно тому-то" / "при таком-то --me --merange должно быть кратно тому-то"?
16, 24, 32, 64... А что если взять нечетное число?
[Профиль]  [ЛС] 

@lolkin@

Стаж: 16 лет 7 месяцев

Сообщений: 1362


@lolkin@ · 15-Окт-09 20:19 (спустя 4 часа, ред. 15-Окт-09 20:19)

Furyx писал(а):
@lolkin@
это все понятно, но всетаки глаза - это не попугайчики а речь шла именно о них
Ну бывает на ssim поглядываю psnr имхо мало эффективна в "полевых условиях"
Проблема в том, что ssim/psnr метрики "вводят в заблуждение" до тех пор пока используется psy оптимизация, на что тебе указывал shellgen
[Профиль]  [ЛС] 

_Woland_

Стаж: 15 лет 10 месяцев

Сообщений: 1067

_Woland_ · 19-Окт-09 20:52 (спустя 4 дня, ред. 19-Окт-09 20:52)

Цитата:
Make B-pyramid spec-compliant
The rules of the specification with regard to picture buffering for pyramid coding are widely ignored.
x264's b-pyramid implementation, despite being practically identical to that proposed by the original paper, was technically not compliant.
Now it is.
Two modes are now available:
1) strict b-pyramid, while worse for compression, follows the rule mandated by Blu-ray (no P-frames can reference B-frames)
2) normal b-pyramid, which is like the old mode except fully compliant.
This patch also adds MMCO support (necessary for compliant pyramid in some cases).
MB-tree still doesn't support b-pyramid (but will soon).
Это значит, что модель пирамиды была переработана в последних сборках икса для пущего соответствия стандартам?
И как теперь задается режим пирамиды?
[Профиль]  [ЛС] 

arestarh1986

Стаж: 16 лет

Сообщений: 193


arestarh1986 · 19-Окт-09 21:10 (спустя 17 мин.)

Цитата:
Это значит, что модель пирамиды была переработана в последних сборках икса для пущего соответствия стандартам?
И как теперь задается режим пирамиды?
--b-pyramid <string> Keep some B-frames as references [none]
- none: Disabled
- strict: Strictly heirarchical pyramid
- normal: Non-strict (not Blu-ray compatible)
[Профиль]  [ЛС] 

AmegaMen

Стаж: 15 лет 7 месяцев

Сообщений: 16

AmegaMen · 20-Окт-09 06:28 (спустя 9 часов)

каким образом можно отключить mbtree, эта функция почему-то принудительно выставляется, а в настройках кодека её нигде нет.
[Профиль]  [ЛС] 
 
Тема закрыта
Loading...
Error