|
DotaSeal
Стаж: 12 лет 7 месяцев Сообщений: 333
|
DotaSeal ·
08-Апр-14 19:41
(10 лет 7 месяцев назад, ред. 08-Апр-14 19:41)
tracker9229
я ожидал , что кодирует изначально страна-производитель фильма и потом уже просто рассылает готовый материал, а а наши просто добавляют дубляж, перевод текста, обложку и т.д.
|
|
tracker9229
Стаж: 14 лет 10 месяцев Сообщений: 321
|
tracker9229 ·
08-Апр-14 19:59
(спустя 18 мин., ред. 08-Апр-14 19:59)
DotaSeal
да! так всегда и происходит. только кодит компания-владелец, а не страна
большинство компании, типа 20 Century Fox, Universal, Warner Bros. и др. имеют свои подразделения во всех регионах и странах, типа "Юниверсал Пикчерз Россия" или "20-й Век Фокс СНГ"
поэтому у нас выходит тот же блюрей но с дополнительными дорогами.
а вот к примеру ВВС (или НВО) не имеют у нас своего подразделения, соответственно, к примеру, выпуск Шерлока у нас официально не возможен, если только через компанию-дистрибъютера (типа Флагман-трейд), а они делают как правило ужасные блюрей.
|
|
DotaSeal
Стаж: 12 лет 7 месяцев Сообщений: 333
|
DotaSeal ·
08-Апр-14 20:04
(спустя 4 мин.)
tracker9229
а ну ок, теперь всё ясно
|
|
Bill Ein
Стаж: 15 лет 3 месяца Сообщений: 272
|
Bill Ein ·
09-Апр-14 09:25
(спустя 13 часов, ред. 09-Апр-14 09:25)
Снова возвращаясь к проблеме блендинга от кодирования:
Выяснилось, что замыливание шума перед кодингом на артефакты блендинга после кодирования никак толком не влияет, просто человек, который мне закодил чисто, насамом деле просто кодил только первые 18 секунд, а попытавшись закодить весь клип также получил этот артефакт.
Следующий месяц я провёл в попытках найти оптимальные настройки, при которых блендинга было бы меньше всего и выяснил ряд интересных вещей:
1) Оптимальный выбор ref и bframes ОКАЗЫВАЕТСЯ во многом зависит от deblock и чем deblock меньше - тем меньше должны быть ref и bframes. Так при кодировании в 8бит CRF16 deblock 0:0 с psy-rd оптимальные значения ref и bframes в отношении наименьших артефактов блендинга были значения 8 и 8 соответственно; для 10бит CRF15 с тем же deblock - 9 и 9. В то же время для deblock -1:-1 уже 6/6 для 8бит и 7/7 для 10. Причём уменьшение deblock лишь усиливало артефакты блендинга. Также правильно подобранные ref и bframes снижали блочность и улучшали градиенты. Более того отличные друг от друга значения ref и bframes давали весьма уродливый артефакт чёрного точечного рингинга вокруг рингинга обычного, что выглядит весьма уродско, в связи с чем мне не понятно стремление некоторых риперов делать эти параметры разными.
2) Оптимальный выбор psy-rd ОКАЗЫВАЕТСЯ не зависит от deblock вообще, но при этом верно подобранные параметры psy-rd уменьшают артефакты блендинга. Так в моём случае при кодировании в 8бит CRF16 меньше всего блендинга из диапазона 0.2:0.0-1.2:0.0 было при psy-rd 0.7:0.0, а для 10бит CRF15 - при 1.0:0.0
3) В плане качества mbtree=0 всё равно лучше чем mbtree=1
4) В плане качества на средних и высоких битрейтах aq=2:1.00 всё равно лучше чем aq=1:1.00
5) В плане качества как минимум на SD разрешениях merange=16 всё равно лучше чем merange=24 или 32 или 64
6) В плане качества на средних и высоких битрейтах decimate=0 всё равно лучше чем decimate=1
7) В плане качества как минимум на SD-разрешениях me=tesa / subme=11 всё равно лучше чем me=umh / subme=10 или subme=9
8) В плане качества "--partitions all" всё равно лучше и полностью обнуляет необходимость форсинга определённого "--level" при любых разрешениях и битрейтах.
9) В плане качества на средних и высоких битрейтах как минимум при кодировании по CRF direct=1 всё равно лучше, чем direct=3
10) В плане качества и веса иногда проще снизить CRF, чем мудрить с deadzone и qcomp
|
|
Vospik
Стаж: 15 лет 9 месяцев Сообщений: 1793
|
Vospik ·
09-Апр-14 11:09
(спустя 1 час 44 мин.)
|
|
Bill Ein
Стаж: 15 лет 3 месяца Сообщений: 272
|
Bill Ein ·
09-Апр-14 13:09
(спустя 2 часа)
Vospik писал(а):
63544161чудеса в решете
Как минимум половина из этого нигде толком не описана, а в большей части БД-рипов аниме у меня на руках настройки вообще не поддаются никакой логике. Например некоторые известные риперы часто повышают qcomp до 0.7 при mbtree=0, понижают keyint_min до 23, ставят высокие значения ref и bframes при deblock -3:-3 и преимущественно кодят с aq=1:1.00, subme=9 и me=umh, а также выставляют разные qpmin/qpmax для каждой серии. На doom9 ещё рекомендуют снижать keyint до 240. Профита от всех этих странностей экспериментально мне извлечь не удалось, разве что от некоторых в скорости кодирования и весе, но уж точно не в качестве.
Кстати, когда я описал проблему блендинга на doom9, то за месяц ответил лишь один человек и ответ его был что-то на вроде "а и хрен с ним, всё равно при воспроизведении это не заметно".
|
|
unreal666
Стаж: 16 лет 10 месяцев Сообщений: 1713
|
unreal666 ·
09-Апр-14 18:16
(спустя 5 часов)
Bill Ein писал(а):
63545260понижают keyint_min до 23
keyint_min по умолчанию 23.
|
|
Bill Ein
Стаж: 15 лет 3 месяца Сообщений: 272
|
Bill Ein ·
10-Апр-14 00:14
(спустя 5 часов, ред. 10-Апр-14 00:14)
unreal666 писал(а):
63548401
Bill Ein писал(а):
63545260понижают keyint_min до 23
keyint_min по умолчанию 23.
В тех билдах иксы 8бит и 10бит что у меня - 25, в билде от 2010г 8бит тоже 25. Почему у вас 23?
|
|
Lenchik
Стаж: 18 лет 4 месяца Сообщений: 854
|
Lenchik ·
10-Апр-14 06:29
(спустя 6 часов)
Цитата:
Код:
-i, --min-keyint <integer> Minimum GOP size [auto]
А авто зависит от частоты кадров.
|
|
DotaSeal
Стаж: 12 лет 7 месяцев Сообщений: 333
|
DotaSeal ·
10-Апр-14 20:18
(спустя 13 часов, ред. 10-Апр-14 20:18)
а теперь немного моего личного бреда, допустим , есть телевизор 107 см и у него разрешение 8к пикселей, через него пускаем видео с таким же разрешением, но битрейт данного видео будет около 5000, естественно оно будет биться на ужасные "кирпичики", но из-за огромного разрешение их не будет (по идее) видно с расстояния даже в 30 см от экрана. Ибо чтобы уместились 8к пикселей на 107см экране сами эти пиксели должны быть ничтожно малы. Так ли это?
|
|
5ton
Стаж: 13 лет 3 месяца Сообщений: 33
|
5ton ·
10-Апр-14 22:39
(спустя 2 часа 21 мин.)
Скажите, для видео с непостоянной динамикой видеоряда (пол фильма статичные сцены, пол фильма кадры с движением) лучше всего выбирать Variable bitrate?
|
|
alfsuind
Стаж: 14 лет 8 месяцев Сообщений: 880
|
alfsuind ·
10-Апр-14 23:28
(спустя 49 мин., ред. 10-Апр-14 23:28)
5ton
Если цель - получить одинаковое визуальное качество во всех сценах, и при этом максимальное качество при любом заданном среднем битрейте, то нужно выбирать variable bitrate (режим 2pass для подгона под заданный битрейт, crf для подгона под заданное качество).
Режимы 1pass variable bitrate и constant bitrate применяются в особых случаях, не в "обычных" рипах/энкодах.
|
|
dionus108
Стаж: 14 лет 6 месяцев Сообщений: 166
|
dionus108 ·
11-Апр-14 12:14
(спустя 12 часов)
Bill Ein писал(а):
63543148Оптимальный выбор ref и bframes ОКАЗЫВАЕТСЯ во многом зависит от deblock и чем deblock меньше - тем меньше должны быть ref и bframes.
Как я понимаю, сами по себе ref и bframes - чем они меньше тем выше качество, но и больше размер. Ну а увеличивая deblock, мы замыливаем картинку, т.е. понижаем качество. Вот и получается, что замылив картинку высоким значением deblock мы уже не сможем ее улучшить понижая ref и bframes. Поэтому оптимальным и будет их тоже сделать побольше в целях экономии битрейта. И наооборот, для сохранения деталей надо понижать не только deblock, но и ref/bframes.
Мне кажется, это можно сравнить с компьютером, когда нет смысла использовать мощный многоядерный процессор вместе с 256 Мб оперативной памяти, и наоборот, увеличивая память до десятков гигабайт нет смысла использовать слабый бюджетный одноядерник.
|
|
DotaSeal
Стаж: 12 лет 7 месяцев Сообщений: 333
|
DotaSeal ·
11-Апр-14 13:09
(спустя 55 мин., ред. 11-Апр-14 13:09)
"Как я понимаю, сами по себе ref и bframes - чем они меньше тем выше качество"
чем выше bframes - тем выше качество "Reference Frames Параметр задает количество используемых рефернсных кадров. Определяет, сколько предыдущих кадров может быть связано (заимствование макроблоков) с P- или B-кадрами. Рекомендации: Приблизительно 4-6. Большие значения могут быть полезны для анимации, аниме, скринкастов и другого "статичного" видео.
Примечание: При 5-ти и более референсных кадрах, качество, обычно, повышается незначительно.
Кроме того, 4 - максимальное значение для 1080p, а 9 - максимальное для 720p, придерживаясь спецификации Level 4.1. Это самый высокий уровень, поддерживаемый в большинстве бытовой электроники, которая поддерживают воспроизведение H.264, включая также Xbox 360 и Playstation 3.
Чем больше референсных кадров, тем медленнее кодирование."
|
|
Lenchik
Стаж: 18 лет 4 месяца Сообщений: 854
|
Lenchik ·
11-Апр-14 16:34
(спустя 3 часа)
да просто в понятие качества вы вкладываете разные вещи
|
|
GarfieldX
Стаж: 19 лет 9 месяцев Сообщений: 4016
|
GarfieldX ·
11-Апр-14 16:42
(спустя 7 мин.)
DotaSeal писал(а):
63559803а теперь немного моего личного бреда
С давних пор действует простая истина: лучше меньше, да лучше.
Т.е. лучше небольшое разрешение с хорошим качеством, чем паршивое качество с большим разрешением (от которого в итоге все равно не будет толку, т.к. низкий битрейт не позволит сохранить детализацию).
В первом случае будет уменьшение детализации за счет пониженного разрешения, но зато сохранится оставшийся уровень детализации. Во втором случае артефакты сжатия испортят больше, чем уменьшенное разрешение.
|
|
Lenchik
Стаж: 18 лет 4 месяца Сообщений: 854
|
Lenchik ·
11-Апр-14 17:51
(спустя 1 час 9 мин.)
GarfieldX
А тесты проводил кто-нибудь? На предмет поиска этих ускользающих границ. С одной стороны не особо большой набор алгоритмов апсайза в телевизорах или аппаратных декодерах, а с другой — артефакты сжатия (в статике и динамике).
|
|
unreal666
Стаж: 16 лет 10 месяцев Сообщений: 1713
|
unreal666 ·
12-Апр-14 01:25
(спустя 7 часов, ред. 12-Апр-14 01:25)
Bill Ein писал(а):
63552968
unreal666 писал(а):
63548401
Bill Ein писал(а):
63545260понижают keyint_min до 23
keyint_min по умолчанию 23.
В тех билдах иксы 8бит и 10бит что у меня - 25, в билде от 2010г 8бит тоже 25. Почему у вас 23?
выше уже сказали, что keyint_min оказывается зависит от частоты кадров.
|
|
dionus108
Стаж: 14 лет 6 месяцев Сообщений: 166
|
dionus108 ·
12-Апр-14 02:10
(спустя 44 мин., ред. 12-Апр-14 02:24)
DotaSeal писал(а):
63566479чем выше bframes - тем выше качество
"Reference Frames
Параметр задает количество используемых рефернсных кадров. Определяет, сколько предыдущих кадров может быть связано (заимствование макроблоков) с P- или B-кадрами.
Вот в одной инструкции написано: "B-кадры – это кадры, в которых закодированы изменения не только от предыдущих кадров, но и от последующих. Имеют еще большую степень сжатия, чем P-кадры, но также и наихудшее качество."
Самая идеальная картинка - это когда вообще нету связанных кадров (ни P-кадров ни B-кадров, только I-кадры). Т.е. когда каждый кадр является ключевым и сжимается как есть. Но тогда и размер у видеофайла будет огромный. Соответсвенно чтобы сэкономить место используются P и B-кадры.
А то что увеличение bframes повышает качество - так это за счет того, что B-кадры экономят битрейт, который может быть использован для улучшения тех же P и I-кадров. Не знаю насколько хитер алгоритм кодировщика, но предположу следующее. Если нужно вписаться в заданный размер файла, то повышение bframes позволит оптимальнее распределить битрейт и тем самым улучшить картинку. А если видео кодируется с постоянным качеством (CRF) то увеличение bframes качество не повышает, а скорее незначительно но понижает, но зато и размер файла уменьшится.
Т.е. фактически все сводится к поиску приемлемого компромиса между качеством, размером и скоростью кодирования.
|
|
busoti
Стаж: 13 лет 5 месяцев Сообщений: 2839
|
busoti ·
12-Апр-14 02:15
(спустя 5 мин.)
GarfieldX писал(а):
63568453Т.е. лучше небольшое разрешение с хорошим качеством, чем паршивое качество с большим разрешением
А вариант родного разрешения с хорошим качеством не подходит ?
|
|
GarfieldX
Стаж: 19 лет 9 месяцев Сообщений: 4016
|
GarfieldX ·
12-Апр-14 02:31
(спустя 16 мин.)
busoti4444 писал(а):
63574319А вариант родного разрешения с хорошим качеством не подходит ?
Родного для чего?
Всегда правильно оставлять либо исходное разрешение носителя, либо уменьшать его пока нет заметных потерь детализации. Так многие BD можно спокойно ужать до HD и не потерять ничего.
|
|
busoti
Стаж: 13 лет 5 месяцев Сообщений: 2839
|
busoti ·
12-Апр-14 02:54
(спустя 22 мин.)
Родное - то, в котором видео снято. Можно назвать его и исходным.
|
|
GarfieldX
Стаж: 19 лет 9 месяцев Сообщений: 4016
|
GarfieldX ·
12-Апр-14 04:47
(спустя 1 час 53 мин.)
busoti4444 писал(а):
63574447Можно назвать его и исходным.
Тогда я уже ответил
|
|
Bill Ein
Стаж: 15 лет 3 месяца Сообщений: 272
|
Bill Ein ·
13-Апр-14 01:03
(спустя 20 часов, ред. 14-Апр-14 10:28)
dionus108 писал(а):
Как я понимаю, сами по себе ref и bframes - чем они меньше тем выше качество, но и больше размер. Ну а увеличивая deblock, мы замыливаем картинку, т.е. понижаем качество. Вот и получается, что замылив картинку высоким значением deblock мы уже не сможем ее улучшить понижая ref и bframes. Поэтому оптимальным и будет их тоже сделать побольше в целях экономии битрейта. И наооборот, для сохранения деталей надо понижать не только deblock, но и ref/bframes. Мне кажется, это можно сравнить с компьютером, когда нет смысла использовать мощный многоядерный процессор вместе с 256 Мб оперативной памяти, и наоборот, увеличивая память до десятков гигабайт нет смысла использовать слабый бюджетный одноядерник.
Нет, не совсем, прикол именно в том, что слишком низкие также деструктивно сказываются на качестве как и слишком высокие. Т.е. подбирать нужно именно оптимальные. Скорее всего потому, что завышенные значения портят качество попыткой сильнее сжать, а заниженные требуют больше битрейта, чем им позволяет заданный CRF. В итоге в обоих случаях имеем больше искажений, больше блочности и больше бленда, чем при оптимально подобранных ref и bframes.
Кстати, в варианте для 8бит deblock=0:0 CRF17 без psy-rd оптимальными были значения 3/3.
Ещё бы хотел заметить, что на SD-разрешениях последствия от изменения ref/bframes в моих экспериментах были куда более очевидны чем на HD.
Сообщения из этой темы были выделены в отдельный топик Обсуждение форматов сжатия звука GarfieldX
|
|
dionus108
Стаж: 14 лет 6 месяцев Сообщений: 166
|
dionus108 ·
14-Апр-14 00:08
(спустя 23 часа)
Bill Ein писал(а):
63585035Нет, не совсем, прикол именно в том, что слишком низкие также деструктивно сказываются на качестве как и слишком высокие. Т.е. подбирать нужно именно оптимальные. Скорее всего потому, что завышенные значения портят качество попыткой сильнее сжать, а заниженные требуют больше битрейта, чем им позволяет заданный CRF. В итоге в обоих случаях имеем больше искажений, больше блочности и больше бленда, чем при оптимально подобранных ref и bframes.
Так вроде ж режимы CRF и CQP не ограничивают битрейт. Они просто сжимают кадр в N раз. И если в кадре квадрат малевича, то размер выходит пару килобайт, а если в кадре шелестит листва дерева - то десятки и сотни килобайт. Соответсвенно если кадр является B-кадром - то он сожмется в те же N раз, но займет меньше места по сравнению с I или P кадрами, потому что хранит меньше информаци, а именно разницу между соседними c ним кадрами.
Вот если речь идет о постоянном битрейте, тогда конечно, занизив bframes видео ухудшится, уперевшись в нехватку битрейта.
|
|
Bill Ein
Стаж: 15 лет 3 месяца Сообщений: 272
|
Bill Ein ·
14-Апр-14 11:17
(спустя 11 часов, ред. 14-Апр-14 11:17)
dionus108, я не говорю, что моё предположение верно, я говорю что результаты моих экспериментов противоречат вашей теории о повышении качества при снижении ref и bframes ниже оптимальной отметки как для отдельно взятых CRF и deblock, так и для двухпроходки с заданным битрейтом и отдельно взятом deblock. Для каждого варианта я брал диапазон ref и bframes от 1-го до 10-и, результаты, где артефактов кодирования было меньше всего, приведу таблицей: 480x270@29.97 (2 pass, no-psy)
--bitrate 504 --ref 2 --bframes 2 --trellis 2 --b-adapt 2 --me tesa --subme 11 --direct auto --partitions all --no-mbtree --deblock 0:0 --no-psy --no-fast-pskip --b-pyramid none --ratetol 100
(более того в этом примере общее качество статичных сцен при ref=3 / bframes=3 было лучше, но и больше артефактов на динамичных) 768x432@29.97 (no-psy)
--crf 17.0 --ref 3 --bframes 3 --trellis 2 --b-adapt 2 --me tesa --subme 11 --direct spatial --partitions all --no-mbtree --deblock 0:0 --no-psy --aq-mode 2 --no-dct-decimate 768x432@29.97
8bit v1
--crf 16.0 --ref 8 --bframes 8 --trellis 2 --b-adapt 2 --me tesa --subme 11 --direct spatial --partitions all --no-mbtree --deblock 0:0 --psy-rd 0.70:0.00 --aq-mode 2 --no-dct-decimate
8bit v2
--crf 16.0 --ref 6 --bframes 6 --trellis 2 --b-adapt 2 --me tesa --subme 11 --direct spatial --partitions all --no-mbtree --deblock -1:-1 --psy-rd 0.70:0.00 --aq-mode 2 --no-dct-decimate
8bit v3
--crf 16.0 --ref 5 --bframes 5 --trellis 2 --b-adapt 2 --me tesa --subme 11 --direct spatial --partitions all --no-mbtree --deblock -2:-2 --psy-rd 0.70:0.00 --aq-mode 2 --no-dct-decimate 768x432@29.97
10bit v1
--crf 15.0 --ref 9 --bframes 9 --trellis 2 --b-adapt 2 --me tesa --subme 11 --direct spatial --partitions all --no-mbtree --deblock 0:0 --psy-rd 1.00:0.00 --aq-mode 2 --no-dct-decimate
10bit v2
--crf 15.0 --ref 7 --bframes 7 --trellis 2 --b-adapt 2 --me tesa --subme 11 --direct spatial --partitions all --no-mbtree --deblock -1:-1 --psy-rd 1.00:0.00 --aq-mode 2 --no-dct-decimate
10bit v3
--crf 15.0 --ref 6 --bframes 6 --trellis 2 --b-adapt 2 --me tesa --subme 11 --direct spatial --partitions all --no-mbtree --deblock -2:-2 --psy-rd 1.00:0.00 --aq-mode 2 --no-dct-decimate P.S. Хотя может быть ваша теория то верна, но не взяты во внимание все аспекты и сделаны неверны выводы
|
|
Tim68
Стаж: 14 лет 9 месяцев Сообщений: 712
|
Tim68 ·
15-Апр-14 14:18
(спустя 1 день 3 часа, ред. 15-Апр-14 17:31)
Bill Ein писал(а):
63600200более того в этом примере общее качество статичных сцен при ref=3 / bframes=3 было лучше, но и больше артефактов на динамичных
По другому и быть не может. Снизив bframes до 3-х Вы не уменьшили keyint. Что получилось? Получились длинные группы с очень короткими подгруппами и близкими опорными кадрами. Слишком много последовательных P-кадров ссылающихся на предыдущие, к концу группы неизвестно, что останется от изображения.
При таких подгруппах (--ref 3) можно смело выставлять постоянный паттерн --b-adapt 0 и снижать длинну группы до частоты кадров, для 29,97 - > (--keyint 30). Увеличение размера из за увеличения I кадров можно смело скомпенсировать снижением битрейта задав более высокие значения crf. Вроде как-то так.
Tim68 писал(а):
63127180Давнеько уже сошелся к тому, что по большому счету в основе всего лежит длина самой группы (GOP), входящих в нее минигрупп (miniGOP) кадров и одной серьезной особенности икса - поддержки пирамиды В-кадров, правда только 1-го уровня, т.е. в подгруппе может быть только один ссылочный В-кадр. Все остальное может рассматриваться только в отношении вышеуказанного.
|
|
Bill Ein
Стаж: 15 лет 3 месяца Сообщений: 272
|
Bill Ein ·
15-Апр-14 22:40
(спустя 8 часов, ред. 15-Апр-14 22:40)
Tim68 писал(а):
По другому и быть не может. Снизив bframes до 3-х Вы не уменьшили keyint. Что получилось? Получились длинные группы с очень короткими подгруппами и близкими опорными кадрами. Слишком много последовательных P-кадров ссылающихся на предыдущие, к концу группы неизвестно, что останется от изображения.
При таких подгруппах (--ref 3) можно смело выставлять постоянный паттерн --b-adapt 0 и снижать длинну группы до частоты кадров, для 29,97 - > (--keyint 30). Увеличение размера из за увеличения I кадров можно смело скомпенсировать снижением битрейта задав более высокие значения crf. Вроде как-то так.
Я пробовал снижать --b-adapt до 1, но на выбор наилучших ref и bframes для вариантов в 8 и 10бит с psy-rd это никак не сказалось, а вот вес... Вес видеодорожки вырос на 30%, т.е. практически также как если бы я кодил не с CRF15, а с CRF12!
C keyint тоже пробовал мудрить на тех же вариантах энкода, но снижение с 250 до 240 каких-то очевидно положительных результатов не дало.
Возможно стоит помудрить с двухпроходным вариантом при 500 кбпс в том ручье что вы сказали...
Tim68 писал(а):
"Давнеько уже сошелся к тому, что по большому счету в основе всего лежит длина самой группы (GOP), входящих в нее минигрупп (miniGOP) кадров и одной серьезной особенности икса - поддержки пирамиды В-кадров, правда только 1-го уровня, т.е. в подгруппе может быть только один ссылочный В-кадр. Все остальное может рассматриваться только в отношении вышеуказанного."
Т.е. bpyramid должно быть =1? Вообще я слабо знаком с матчастью и попытся с нуля разобраться в математических принципах работы всех функций и ключей как-то сложновато.
|
|
Tim68
Стаж: 14 лет 9 месяцев Сообщений: 712
|
Tim68 ·
16-Апр-14 18:10
(спустя 19 часов, ред. 16-Апр-14 18:10)
Bill Ein писал(а):
63618243Я пробовал снижать --b-adapt до 1
Если Вы снизили bframes до 3-х, то о каком --b-adapt 1 может быть речь, только --b-adapt 0. Иначе икс может на темных (черных) кадрах оставить ваши подгруппы вообще без b-кадров, что очень не любят аппаратные декодеры, там же Вы лишитесь и пирамиды.
Bill Ein писал(а):
63618243но снижение с 250 до 240 каких-то очевидно положительных результатов не дало
Это называется снижение? Группа не стала короче даже на 10%, Я говорил о значении --keyint 30 для 29,97к/с.
Bill Ein писал(а):
63618243bpyramid должно быть =1?
Если Вы хотите использовать пирамиду, но отказать P-кадрам ссылаться на B-кадры, то да "strict" - способствует совместимости с аппаратным декодированием.
|
|
Bill Ein
Стаж: 15 лет 3 месяца Сообщений: 272
|
Bill Ein ·
16-Апр-14 20:30
(спустя 2 часа 19 мин.)
Tim68 писал(а):
Если Вы снизили bframes до 3-х, то о каком --b-adapt 1 может быть речь, только --b-adapt 0. Иначе икс может на темных (черных) кадрах оставить ваши подгруппы вообще без b-кадров, что очень не любят аппаратные декодеры, там же Вы лишитесь и пирамиды.
А как к --b-adapt 0 отнесутся смартфоны и планшеты при онлайн-просмотре?
Tim68 писал(а):
Это называется снижение? Группа не стала короче даже на 10%, Я говорил о значении --keyint 30 для 29,97к/с.
Как именно должен выглядеть по вашему двухпроходный скрипт для энкода 480х270@29.97 c заданным битрейтом=500кбпс и с совместимостью со смартфонами и планшетами?
Tim68 писал(а):
Если Вы хотите использовать пирамиду, но отказать P-кадрам ссылаться на B-кадры, то да "strict" - способствует совместимости с аппаратным декодированием.
Я не хочу, просто ту цитату так понял.
|
|
|