Кодирование видео

[Uncle Vёder]

Я не совсем понял, что ты именно хотел сказать здесь.

Проблемы с кодированием через GPU, как я уже говорил, скорее всего вытекают из-за их архитектурных ограничений. Косвенно об этом говорили сами разработчики x264, хотя вначале они были настроены достаточно оптимистично.

Ну насколько я узнал из информации с различных форумов, уже при попытке распараллелить процесс на большое количество CPU-потоков, например на 16, начинаются потери качества на выходе.

Вот например инфа из официального описания параметров x264 от разработчика:

threads

Default: auto (frame based threads: 1.5 * logical processors, rounded down; slice based threads: 1 * logical processors)

Enables parallel encoding by using more than 1 thread to increase speed on multi-core systems. The quality loss from multiple threads is mostly negligible unless using very high numbers of threads (say, above 16). The speed gain should be slightly less than linear until you start using more than 1 thread per 40px of vertical video, at which point the gain from additional threads sharply decreases.

x264 currently has an internal limit on the number of threads set at 128, realistically you should never set it this high.

Связано это со спецификой самого алгоритма.

При попытке распараллелить процесс на тысячи ядер потери качества становятся судя по всему ещё больше, и алгоритм приходится ставить в гораздо более мягкие условия, что в итоге сказывается на размере выходного файла.

По сути единственый серьёзный H.264 GPGPU энкодер на рынке - MainConcept. И при попытке поискать его сравнение с x264 натыкаешься на примерно вот такую картину:

Видимо, по этой причине разработчики x264 и не стали акцентироваться на GPGPU.

[Daniel5555]

Ну насколько я узнал из информации с различных форумов, уже при попытке распараллелить процесс на большое количество CPU-потоков, например на 16, начинаются потери качества на выходе.

Связано это со спецификой самого алгоритма.
При попытке распараллелить процесс на тысячи ядер потери качества становятся судя по всему ещё больше, и алгоритм приходится ставить в гораздо более мягкие условия, что в итоге сказывается на размере выходного файла.

Ты уверен, что ты не смешиваешь разные концепты?

 

Существует формула, которая гласит, что при увеличении числа тредов снижается качество. На ОЧЕНЬ малое значение, которые на практике вообще никак не проявляется на мой взгляд и я не могу сказать, на чем именно основана эта формула. Когда говорят о числе 16, как мне кажется, имеют в виду именно это, причем на практике я очень сильно сомневаюсь, что 16 тредов реально снизят качество.

 

Ты цитируешь, насколько я понимаю, документацию MeGUI. Это не тоже самое, что документация от разработчиков x264.

 

Вот здесь есть старая цитата от разработчика: http://forum.doom9.org/showpost.php?p=1213185&postcount=10

 

Это было в далеком 2008 и он даже говорит об опциональном использовании B-фреймов, сейчас мы всегда их используем. Более того, это как-то связано с VBV, которое я лично не использую.

 

Проблемы с GPU это несколько иная тема, на мой взгляд. Обычно в связи с GPU говорят именно об ограниченности в их архитектуре, которая перекрывает все преимущества от их использования еще до того, как эта формула начинает работать.

[Daniel5555]

Netflix опубликовал интересный пост, где они описывают свою технологию кодирования видео: http://techblog.netflix.com/2015/12/per-title-encode-optimization.html

 

Там имеется печальный график: https://docs.google.com/a/netflix.com/drawings/d/slENw4764sdpuOx1-QWeifA/image?w=624&h=427&rev=1&ac=1

 

В целом вывод не новый: для наилуичшего соотношения качество/размер нужно применять персональные настройки к каждому конкретному видео.

 

Было бы интересно сравнить с результатами, которые получили мы во время работы над ЕнЕ-релизом Евы.

[Мота]

Господа, т.к. я недавно занялся летсплеем, то обратил внимание вот на такую кракозябру.

 

Для монтирования видео пользуюсь я Sony Vegas (одним из последних). Так вот, я стараюсь перекодировать конечное видео максимально с бОльшим качеством, несмотря на конечный размер файлы (иначе ютуб будет пережимать то, что уже и так пережато, что не айс). Так вот, и на DIVX кодеке и x264 кодеке одна и та же проблема. Видео как-бы отсветляется:

Исходное:

Скрытый текст

Пережатое:

Скрытый текст

 

Думаю разница очевидна, хотя настройки я оставлял по дефолту. Изменял только один параметр - чтобы кодировал 1 к 1.

Собственно настройки для DIVX (которым я сейчас пользуюсь):

Скрытый текст

И x264

Скрытый текст

 

Но последним я не пользуюсь, ибо есть бага - звук опережает видео. После кодирования почему-то видео стартует на 1 секунду позже звука. Но в любом случае у них глобально одна проблема - отсветляется видео.

 

Я ламер, сразу скажу. Мне главное смонтировать видео с максимально исходным качеством видео, чтобы потом Ютуб это всё не пережал в треш. Вот и прошу помощи :)

[Gabriel]

мота, крайне не рекомендую пользоваться кодером, который встроен в сони вегас. он работает через пень колоду, и твои баги одна из множества возможных проблем.

используй лосслесс кодек как тут указано

после чего его можно ужать сторонними кодировщиками (я использую AMVSimple_4.0 с выставленным битрейтом 6000 кб/с, но мне для АМВ большое качество особо не нужно) или залить так на ютуб, он сам ужмет.

правда возможна другая проблема - полученный файл будет просто огромного размера, и если у тебя длинный ролик, он просто не поместится на жесткий диск.

тогда можно использовать эппловские кодеки

правда я ими пользовался только раз, когда мне нужно было выставить фиксированный битрейт, поэтому возможно тебе потребуется попробовать несколько попыток, чтобы подобрать оптимальный вариант.

Изменено 16 июля, 2017 пользователем Gabriel

[Daniel5555]

4 часа назад, Мота сказал:

Я ламер, сразу скажу. Мне главное смонтировать видео с максимально исходным качеством видео, чтобы потом Ютуб это всё не пережал в треш. Вот и прошу помощи :)

 

В этой теме в первом же сообщении у тебя есть один из способов решения именно этой задачи, которую я решал сначала для видео с фигурным катанием, а потом ее решал Вейдер для релиза Евы.

 

Вкратце (после того, как ты смонтировал и сохранил видео в оригинальном качестве, как описал @Gabriel):

 

1. Скачиваешь Handbrake.

2. Обязательно определяешь имя выходного файла через кнопку Browse, иначе все пойдет насмарку.

3. В табе Video выбираешь "Use advanced tab instead".

4. Выбери значение параметра Constant Quality в табе Video. Я не знаю какой именно тебе стоит выбрать, из моего опыта для видео лучше всего подходит 16, для анимации 18. Я пробовал диапазон от 12 до 23. Чем выше число, тем хуже качество и меньше размер. Значение для Lossless зависит от видео.

5. В табе "Advanced" задаешь настройки так, чтобы внизу появилась строчка:

 

ref=6:bframes=5:b-adapt=2:direct=auto:me=tesa:subme=10:merange=64:analyse=all:trellis=2:no-dct-decimate=1

Вот это:

vbv-maxrate=20000:level=4.0:vbv-bufsize=25000:rc-lookahead=30:

и другие параметры, которые там могут быть, удаляешь из нее.

 

6. В Audio выбираешь AAC с меньшим битрейтом, чем в оригинале, либо Passthru.

7. Остальные настройки я оставляю на твое усмотрение, там просто много писать и мало толку, ты быстрее разберешься.

 

Почему это все так, описано в первом сообщении в теме и далее.

 

1 час назад, Gabriel сказал:

я использую AMVSimple_4.0 с выставленным битрейтом 6000 кб/с

 

Это звучит как очень плохая идея. И CBR это наихудший вариант для кодирования с высоким соотношением качество/размер. @Uncle Vёder в этой теме написал отличный пост на эту тему.

[Gabriel]

46 минут назад, Daniel5555 сказал:

Это звучит как очень плохая идея. И CBR это наихудший вариант для кодирования с высоким соотношением качество/размер. @Uncle Vёder в этой теме написал отличный пост на эту тему.

скорее всего так оно и есть, но у меня изначально источник был довольно скверного качества, так что выигрыш был бы незначительным. плюс на сайте, куда я выкладывал видео, были строгие [идиотские] требования к битрейту и размеру видео, а заморачиваться не хотелось, поэтому я искал программу с однокнопочным интерфейсом. потом как-нибудь, когда будет время, может попробую метод вёдера.

[Мота]

Спасибо за наводку, попробую!

 

5 часов назад, Gabriel сказал:

используй лосслесс кодек как тут указано

 

А в настройках что желательнее указывать?

 

Я как-то слышал, что надо не в RGB, а в YUY2 кодировать.

 

Кстати, на выходе 45 секунд весит 1.45 гб. Это как-то не просто монструозно - это уж слишком дохера, честно говоря :)

У меня на выходе видео по 45-55 минут - страшно представить сколько они будут весить.

Но в итоге хотите смейтесь, хотите нет - всё-равно осветляет.

Скрытый текст

 

Похоже в настройках самого Сони Вегаса где-то закралась бяка.

Изменено 16 июля, 2017 пользователем Мота

[Uncle Vёder]

Проблема скорее всего всё та же самая, древняя как говно мамонта: https://habrahabr.ru/post/136318/

[Daniel5555]

5 часов назад, Мота сказал:

Я как-то слышал, что надо не в RGB, а в YUY2 кодировать.

 

YUY2 это цветовая схема, в которой кодируют большинство устройств захвата, видеокамер и т. д., потому что в ней лучше сжатие при определенной "потери" качества. В твоем случае ты захватываешь компьютерную игру, то есть цвета в ней обрабатываются в RGB, плюс к этому на этом этапе ты делаешь захват в оригинальном качестве.

 

5 часов назад, Мота сказал:

Кстати, на выходе 45 секунд весит 1.45 гб. Это как-то не просто монструозно - это уж слишком дохера, честно говоря :)

У меня на выходе видео по 45-55 минут - страшно представить сколько они будут весить.

 

Около 100 гигабайт? Это не так уж много.