|
|
|
SLadkoVVI
Стаж: 16 лет 4 месяца Сообщений: 22
|
SLadkoVVI ·
27-Янв-09 14:32
(15 лет 10 месяцев назад, ред. 27-Янв-09 14:32)
В некоторых HD-рипах, например от CtrlHD, встречал использование вместо trellis 2 таких параметров --trellis 0 --deadzone-inter 6 --deadzone-intra 6. На forum.mediatory.ru полгода назад была дискуссия, выводом которой было, что, отключая треллис, можно повысить четкость, хотя при этом обычно требуется больший битрейт, т.к. как раз треллис позволяет его экономить.
Недавно провел небольшой тест для сравнения этих режимов и сделал вывод, что при активизации треллиса скорость кодирования снижается примерно в 1,5 раза, но при сравнении скриншотов с deadzone отличий практически нет.
Что вы можетe сказать или посоветовать? Насколько вообще отключение trellis влияет на итоговую картинку?
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
27-Янв-09 15:49
(спустя 1 час 16 мин.)
SLadkoVVI
А если не скрины сравнивать, а те параметры, что приведены в первом посте темы, а также показатель PSNR? Ведь на глаз не все видно, так будет правильней оценивать, на мой взгляд.
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
27-Янв-09 17:37
(спустя 1 час 48 мин.)
Есть ли для кодека параметр, позволяющий указать конечный размер файла? Нужно, чтобы было применимо для 2-х проходов. Я рассчитываю битрейт на бумажке, делая поправки на возможные отклонения. Хочется без расчетов, чтобы просто задать размер.
|
|
|
|
k0stix
Стаж: 17 лет 8 месяцев Сообщений: 6437
|
k0stix ·
27-Янв-09 20:28
(спустя 2 часа 51 мин., ред. 27-Янв-09 20:28)
_Woland_
Есть калькулятор битрейта, в том числе и в MeGUI.
_Woland_ писал(а):
А если не скрины сравнивать, а те параметры, что приведены в первом посте темы, а также показатель PSNR? Ведь на глаз не все видно, так будет правильней оценивать, на мой взгляд.
Не согласен. На экране вы смотрите не цифры.
А если малость потренироваться, то и разница заметна на глаз без проблем
|
|
|
|
shellgen
Стаж: 18 лет 1 месяц Сообщений: 6417
|
shellgen ·
27-Янв-09 20:46
(спустя 17 мин.)
SLadkoVVI писал(а):
--trellis 0 --deadzone-inter 6 --deadzone-intra 6
Старый приём, ещё до-psy периода x264, совсем необязательно требуется больший битрейт, треллис в сочетании с psy очень тоже здорово могут потреблять битрейт. Особенность работы треллиса в том, что он может размазывать по ровным областям мусор , метрикой psy-trellis устанавливается коэффициент этой самой мазни. Если сигнал чистый, фон ровный и не имеет ярко выраженной шумовой структуры, то отключив треллис, можно предотвратить "мазню" в фоне, но вместе с тем можно потерять на резкости других деталей, поэтому для их сохранения может понадобиться доп. битрейт, который можно было сэкономить за счёт треллиса. С другой стороны, поднимая дэдзоны есть шанс уложиться и в меньший битрейт за счёт отсечения низкоквантовых деталей, в этом случае доп. битрейт не потребуется. Всё очень сильно зависит от сигнала, к каждому нужен свой подход, но как правило включенный треллис позволяет передать больше деталей в аналогичный битрейт.
_Woland_ писал(а):
А если не скрины сравнивать, а те параметры, что приведены в первом посте темы, а также показатель PSNR? Ведь на глаз не все видно, так будет правильней оценивать, на мой взгляд.
Это было рационально в до-psy период развития кодека. Почитайте как работает психовизуальная адаптация, SSIM/PSNR c включенным psy-rd - малозначащие цифры.
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
27-Янв-09 21:00
(спустя 14 мин., ред. 27-Янв-09 21:00)
k0stix
shellgen
Понял. Был не прав)
P.S. Тем не менее, по средним квантам можно ориентироваться? Если нет, я потеряю веру в человечество. 
|
|
|
|
k0stix
Стаж: 17 лет 8 месяцев Сообщений: 6437
|
k0stix ·
28-Янв-09 02:07
(спустя 5 часов)
_Woland_ писал(а):
Тем не менее, по средним квантам можно ориентироваться?
Ориентироваться очень даже можно. Но и про визуальную сторону забывать нельзя 
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
28-Янв-09 02:32
(спустя 25 мин.)
А если простыми словами, что такое кванты?
|
|
|
|
k0stix
Стаж: 17 лет 8 месяцев Сообщений: 6437
|
k0stix ·
28-Янв-09 04:08
(спустя 1 час 36 мин.)
_Woland_
Вот тут.
Лучшего объяснения не видел
|
|
|
|
TeleGRAFist
Стаж: 15 лет 11 месяцев Сообщений: 5
|
TeleGRAFist ·
28-Янв-09 10:07
(спустя 5 часов)
Кодировал видео со следующими параметрами (1280x720@29.970):
Цитата:
program --pass 2 --bitrate 4400 --stats ".stats" --level 4.1 --ref 6 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --weightb --direct auto --subme 9 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ratetol 2.0 --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"
В результате получил видео в нормальном качестве (параметры подбирал, так как указано в шапке; спасибо автору), но есть одна проблема: если начать воспроизведение с произвольного места, то появляется надпись buffering (xx%), и переход к нужному кадру осуществляется только после завершения буферизации. В связи с этим вопрос: как этого избежать? Насколько я понял дело здесь в параметрах кодирования.
И вот еще такой вопрос. Насколько сильно зависит скорость кодирования от параметра --ref?
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
28-Янв-09 21:47
(спустя 11 часов)
Есть идея сделать VGA видео для КПК. Естественно AVC. К сожалению процессор Marvell 520MHz мой энтузиазм не разделяет и безбожно тупит. В целях снижения нагрузки я сделал анаморфный кадр (448x272 @ 640x272). Стало полегче. Снизив количество ReFrames с 8 до 4-х я смог отыграть у бенчмарка дополнительные 2%, повысив, тем самым, до ~130%. Однако этого всё равно недостаточно и на динамике кадры продолжают выпадать. Отсюда вопрос. Есть ли такие настройки, которые бы облегчили незавидную участь процессора? Пробовал менять значения в VBV Maximum Bitrate, но эта настройка не работает. Возможно потому, что VBV Buffer Size стоит на автомате. Не знаю.
|
|
|
|
Freux
Стаж: 17 лет 2 месяца Сообщений: 1176
|
Freux ·
29-Янв-09 00:37
(спустя 2 часа 50 мин.)
Здравствуйте, вы бы не могли ответить на несколько дилетантских вопросов? Я столкнулся с необходимостью выбрать оптимальный битрейт для сжатия видео с минимальной потерей качества в х264. Видео - сырой m2v, полученный из DVD. Вообще, обычно я кодирую видео стандартного разрешения с такими настройками:
Код:
program --pass 3 --bitrate 2000 --stats ".stats" --bframes 16 --b-pyramid --weightb --direct auto --deblock -2:-1 --subme 2 --partitions none --me dia --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"
Битрейт беру в пределах 1800-2200, оценивая на глаз. Данные настройки - не что иное как обычный профиль HQ-Slowest из MeGUI, который я использую.
В вашей статье вы говорите:
Цитата:
Шаг 2. Сжать подготовленную последовательность с настройками, с которыми планируете сжимать последний проход, но указать не битрейт и не --pass ?, а например --crf 18 (важно, что указываем не -q, а именно --crf)
Мне непонятно, что это значит, потому что я использую графический интерфейс MeGUI для задания параметров кодирования, а не строку параметров. Если вы знакомы с MeGUI, не могли бы вы пояснить, как выставить там необходимые настройки для кодирования и затем определить оптимальный битрейт?
|
|
|
|
invidia.hs
Стаж: 16 лет 7 месяцев Сообщений: 329
|
invidia.hs ·
29-Янв-09 00:50
(спустя 13 мин.)
Freux
выбираете констант мод, и циферки вписываете
|
|
|
|
TeleGRAFist
Стаж: 15 лет 11 месяцев Сообщений: 5
|
TeleGRAFist ·
29-Янв-09 03:48
(спустя 2 часа 57 мин.)
_Woland_
Можно попробовать переключить AVC профиль с High на Main или Baseline. Самый тяжеловесные настройки сразу станут недоступны :). Причем Baseline уж совсем ущербный (отключает CABAC).
Должно помочь отключение b-pyramid, --partitions (тут надо поэкспериментировать с разными частицами), --8x8dct. Если уменьшать --ref, то можно отключить и --mixed-refs (может быть даст прирост скорости).
В крайнем случае, можно поставить --no-cabac и --nf. Первое отключает CABAC, второе деблокинг. Причем ни то ни другое не рекомендуется отключать вообще. С помощью CABAC получается 15% сжатия, с помощью деблокинга можно улучшить визуальное восприятие (отсюда опять же можно получить больше сжатие, применив меньший битрейт).
Еще один вариант: можно попробовать понизить качество за счет уменьшения потока (битрейта). Тогда, возможно, слабому процессору будет проще справится. Можно попробовать ограничить VBV Maximum Bitrate (будет быстрее работать в динамичных сценах, но с потерей качества). В этом плане может помочь изучение т.н. AVC Levels: http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
PS 130% вполне достаточно для воспроизведения. Может притормаживать только на сложных сценах.
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
29-Янв-09 11:46
(спустя 7 часов)
TeleGRAFist
Да, я об этом и писал. Выпадают кадры на динамичном ряде. Я не понимаю как работает настройка VBV Maximum Bitrate. Я что 1500 туда писал, что 1200, а всё равно пиковый битрейт порядка 1550 выходит. По Levels не понял, если честно. На профиле 2.1 (ниже не проходим по разрешению кадра) всё равно поток большой допустим. И потом я не уверен, что установка флажка позволит ограничить потолок, хотя может я не прав. CABAC и прочая отключать не хочу, это уж слишком. Надо как-то динамичный ряд занизить искусственно.
|
|
|
|
Tempter57
Стаж: 16 лет 1 месяц Сообщений: 4960
|
Tempter57 ·
29-Янв-09 12:02
(спустя 16 мин.)
_Woland_
Цитата:
CABAC и прочая отключать не хочу, это уж слишком
Здрасьте, приехали. как говорится. Ты в x264 НАСТРОЙКИ не читал разве о аппаратной поддержке CABAC. Твой аппарат уж точно его не потянет.
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
29-Янв-09 12:10
(спустя 7 мин., ред. 29-Янв-09 12:10)
Tempter57
Он тянет. Я же писал, бенчмарк показывает 130%. Начинает тормозить на сложных кадрах. К тому же, если не врут, в этом году наконец поступят в продажу устройства на базе Nvidia Tegra. Он вообще HD видео может крутить с крайне низкими энергозатратами.
P.S. Чем так измываться над 264-м, проще, мне кажется, просто Xvid использовать.
|
|
|
|
TeleGRAFist
Стаж: 15 лет 11 месяцев Сообщений: 5
|
TeleGRAFist ·
29-Янв-09 12:12
(спустя 1 мин.)
_Woland_
Можно попробовать поиграться с параметром qpmin, его увеличение должно привести к уменьшению битрейта в самых сложных сценах. Он указывает минимальную меру потери данных (т.е ограничение на качество снизу и неявное ограничение на битрейт сверху). Чем больше параметр тем больше должно быть сжатие (меньше битрейт) и соответственно больше потери в динамичных сценах.
|
|
|
|
TeleGRAFist
Стаж: 15 лет 11 месяцев Сообщений: 5
|
TeleGRAFist ·
29-Янв-09 12:20
(спустя 8 мин.)
Важный момент (забыл дописать): qpmin работает только в битрейтных режимах.
Вполне возможно тоже самое и максимальным битрейтом.
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
29-Янв-09 12:59
(спустя 39 мин.)
TeleGRAFist
Я кодирую в 2-проходном режиме с заданным битрейтом, ограничить максимальный не получается. С qpmin посмотрю, спасибо.
|
|
|
|
shellgen
Стаж: 18 лет 1 месяц Сообщений: 6417
|
shellgen ·
29-Янв-09 13:29
(спустя 29 мин.)
TeleGRAFist писал(а):
qpmin работает только в битрейтных режимах.
неправда
TeleGRAFist писал(а):
Можно попробовать поиграться с параметром qpmin, его увеличение должно привести к уменьшению битрейта в самых сложных сценах.
сомнительно
_Woland_ писал(а):
Я не понимаю как работает настройка VBV Maximum Bitrate. Я что 1500 туда писал, что 1200, а всё равно пиковый битрейт порядка 1550 выходит
без --vbv-bufsize крутить --vbv-maxrate бессмысленно. VBV корректно работает только в мультипроходе. Для низких левелов лучше опустить maxdpb: разрешение, --ref 1/2
|
|
|
|
TeleGRAFist
Стаж: 15 лет 11 месяцев Сообщений: 5
|
TeleGRAFist ·
29-Янв-09 14:29
(спустя 1 час, ред. 29-Янв-09 14:29)
shellgen
Проверил. Действительно, работает и в crf, но в qp не работает. Тут меня смутила фраза из описания к avidemux'y ( http://www.avidemux.org/admWiki/index.php?title=H264#Quantization_Limits ):
Цитата:
Remarks:: The "Quantization Limits" settings effect the bitrate-based modes only, as QP/CRF mode produces a constant quantizer video anyway.
Но битрейт он все же ужимает. Зависимость не явная, но все-таки можно добрать нужные значения.
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
29-Янв-09 18:15
(спустя 3 часа, ред. 29-Янв-09 18:15)
shellgen
А b-frame сильно нагружают? Разрешение и так снизил по максимуму. Если ещё ниже, слишком сильно виден анаморф, даже при таком он заметен. То есть если ниже, то уж делать сразу QVGA (320x240), а на таком разрешении даже 416MHz проигрывает без запинок и с довольно тяжелыми настройками.
А цель, именно получить более четкое видео для возможности воспроизведения даже на устройствах прошлого поколения (ибо помимо озвученной выше Tegra, есть процессоры от Marvell новых поколений на частотах 624MHz и самый новый на 800MHz).
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
30-Янв-09 02:09
(спустя 7 часов)
Вобщем сбил я рефы до 2-х, b-frame тоже до 2-х, вроде полегче стало, теперь не так выпадают кадры, стало вполне себе смотрибельно. Хотя бенчмарк вырос совсем немного, буквально до 137% на тестовом ролике, но те сцены, что ранее были слишком сложны, теперь проходит ровно либо лишь слегка притормаживает. Качество снизилось, но не сильно. Так что теперь в 500MB можно будет уместить 2-часовой фильм в хорошем качестве и с неплохой аудио-дорожкой. Вполне терпимо. Всем спасибо за помощь.
|
|
|
|
shellgen
Стаж: 18 лет 1 месяц Сообщений: 6417
|
shellgen ·
30-Янв-09 18:28
(спустя 16 часов)
Freux писал(а):
program --pass 3 --bitrate 2000 --stats ".stats" --bframes 16 --b-pyramid --weightb --direct auto --deblock -2:-1 --subme 2 --partitions none --me dia --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"
Битрейт беру в пределах 1800-2200, оценивая на глаз. Данные настройки - не что иное как обычный профиль HQ-Slowest
Специально посмотрел в мегуй, это никак не hq-slowest отттуда, это первый проход с галкой Turbo, вот hq-slowest/Sharktooth:
TeleGRAFist писал(а):
Кодировал видео со следующими параметрами (1280x720@29.970):
Цитата:
program --pass 2 --bitrate 4400 --stats ".stats" --level 4.1 --ref 6 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --weightb --direct auto --subme 9 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ratetol 2.0 --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"
А с какой целью задран --ratetol ?
TeleGRAFist писал(а):
В результате получил видео в нормальном качестве (параметры подбирал, так как указано в шапке; спасибо автору), но есть одна проблема: если начать воспроизведение с произвольного места, то появляется надпись buffering (xx%), и переход к нужному кадру осуществляется только после завершения буферизации. В связи с этим вопрос: как этого избежать? Насколько я понял дело здесь в параметрах кодирования.
Что за плеер? Программный? Такое может быть, если имеет место дефицит IDR кадров, но в параметрах нет ничего, чтобы их сознательно блокировало.
TeleGRAFist писал(а):
И вот еще такой вопрос. Насколько сильно зависит скорость кодирования от параметра --ref?
Довольно сильно, вычисляется эмпирически.
_Woland_ писал(а):
Вобщем сбил я рефы до 2-х, b-frame тоже до 2-х, вроде полегче стало, теперь не так выпадают кадры, стало вполне себе смотрибельно. Хотя бенчмарк вырос совсем немного, буквально до 137% на тестовом ролике, но те сцены, что ранее были слишком сложны, теперь проходит ровно либо лишь слегка притормаживает
Высокие рефы резко увеличивают потребление памяти, b-фреймы возможно стоит немного поднять, совсместно c --b-adapt 2 они могут оказаться очень кстати.
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
30-Янв-09 19:26
(спустя 58 мин.)
shellgen
Уменьшение b-frame тоже положительно сказывается на скорости воспроизведения, хоть и не слишком сильно. Когда борьба идёт за доли, повышать их, всё-таки, не хочется, тем более и так качество более чем приемлимо на мой не слишком прихотливый взгляд. Рефы ещё ниже опять же опускать не хочется. Думаю остановится на таких настройках. Хотя ещё поэкспериментирую, конечно.
|
|
|
|
Freux
Стаж: 17 лет 2 месяца Сообщений: 1176
|
Freux ·
31-Янв-09 00:46
(спустя 5 часов, ред. 31-Янв-09 00:46)
shellgen писал(а):
Freux писал(а):
program --pass 3 --bitrate 2000 --stats ".stats" --bframes 16 --b-pyramid --weightb --direct auto --deblock -2:-1 --subme 2 --partitions none --me dia --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"
Битрейт беру в пределах 1800-2200, оценивая на глаз. Данные настройки - не что иное как обычный профиль HQ-Slowest
Специально посмотрел в мегуй, это никак не hq-slowest отттуда, это первый проход с галкой Turbo
Да, вы правы. Я решил использовать профили от SDBits, попробовал, результаты мне показались весьма неплохими.
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
31-Янв-09 02:15
(спустя 1 час 28 мин., ред. 31-Янв-09 02:15)
shellgen
Вобщем сравнил я 2 тестовых ролика, в качестве которого у меня выступал Burn-E. У первого было 2 рефа и 2 b-frame, у второго 1 реф и 3 b-frame. Вначале о качестве. Средние кванты оказались ниже у второго ролика. От 0.1 для B, до 0.01 для I. Выигрыш минимальный, но есть. Теперь о воспроизведении. В самом начале Burn-E есть самый сложный кадр, где он летит через скопление светящихся частиц и поведя рукой (манипулятором?) заставляет эти частицы закручиваться в вихрь. Так вот в случае со вторым видео (1+3) на этой сцене выпало 35 кадров, а на первом видео (2+2) лишь 22 кадра. Так что, как оказалось, всё же 1-й вариант предпочтительней с точки зрения производительности, а в качестве разницы почти не выявилось. Насколько точно по тестовому ролику можно судить в отношении всего видео (особенно учитывая, что Burn-E - это анимация, пускай и не такого типа как Симпсоны) я сказать не могу, но поделиться результатами считаю нужным.
|
|
|
|
Mike7L
Стаж: 18 лет 6 месяцев Сообщений: 393
|
Mike7L ·
01-Фев-09 23:46
(спустя 1 день 21 час)
У меня есть вопрос:
По каким критериям выбирать разрешение для Rip-a (до какого размера даунсайз и нужен ли).
И тема анаморфа тоже как-то не раскрыта. Есть ли смысл, если есть - то когда.
Буду рад, если кто-то объяснит или даст ссылку на толковое объяснение.
|
|
|
|
_Woland_
Стаж: 15 лет 11 месяцев Сообщений: 1067
|
_Woland_ ·
02-Фев-09 02:55
(спустя 3 часа)
Mike7L
На мой взгляд анаморф имеет смысл применять для HD рипов только в том случае, если хочется сэкономить на битрейте и, соответственно, конечном размере файла. Какое разрешение ставить - опять же, исходя из того, какой нужно размер получить. Размер не важен? Тогда вообще никаких ресайзов, так и кодируй в 1080p. Если, скажем, хочется не более 4GB, тогда 720р используй. Хочется ещё меньше размер, значит дальше уменьшай размер кадра.
|
|
|
|
