2

Я заядлый геймер. Иногда мне нравится записывать свой игровой процесс с помощью Fraps и загружать его на YouTube. Для своей кодировки я использую кодек Komisar x264 в VirtualDub со следующими настройками: ссылка на изображение

Сейчас я пытаюсь написать небольшую статью в блоге, потому что недавно снял со своего старого Q6600 и обновил до 2700k.

Вот небольшой фрагмент из черновика:

Скорость кодирования измеряется в (средних) кадрах в секунду. Чем больше тем лучше. Также важно знать, что существуют сцены, которые я люблю называть "тяжелые" и "легкие".

а также

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

Теперь, что касается связанного кодека, используемого программного обеспечения для кодирования и связанных настроек, я прав в утверждении о сценах с интенсивным движением и сценами с движущимся светом?

Мой личный опыт говорит да. У меня уходит гораздо больше времени на кодирование сцен, где на экране происходит много событий, в отличие от движущихся легких. Использование того же кодека, того же программного обеспечения для кодирования и тех же настроек, которые указаны выше.

3 ответа3

3

Сжатие видео в основном кодирует различия между кадром и следующим. Таким образом, чем больше различий между двумя кадрами, тем больше данных вам придется записывать. Это на самом деле намного сложнее, но это основа. Вы заметите, что на DVD-дисках или любом другом сжатии с фиксированной полосой пропускания (MPEG1, MPEG2, h.264 и т.д.)Неподвижные изображения почти идеальны, а движущиеся - размытыми. Это потому, что много движения требует больше данных для записи, поэтому необходимо найти компромисс.

3

Я не уверен, что объем данных для обработки является значительным. Поскольку каждый кадр имеет одинаковое количество пикселей, вы можете генерировать "больше данных", только если вы уже запустили сложный алгоритм (ы) оценки движения, и даже в этом случае результирующий кадр P/B будет только меньше (как в противном случае компенсация движения была бы бесполезна). Пропускная способность памяти в современных системах настолько высока, что я не думаю, что объем данных вообще влияет на скорость кодирования.

Кодер должен сначала запустить некоторый алгоритм для каждого кадра, чтобы определить, какой тип кадра следует использовать. Этот алгоритм может быть сложным, но сложность должна быть примерно одинаковой для каждого кадра (поэтому здесь не фактор). Однако, когда он определяет, что требуется P / B, должны выполняться очень сложные алгоритмы оценки движения с различными параметрами, чтобы определить, какой из них является наилучшим способом сжатия движения в кадре. Когда выбор опорных кадров вступает в игру, как в B кадрах, предыдущая сложность будет умножена.

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

2

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

Так что технически да, это влияет на общее время кодирования, и интенсивное движение будет дольше кодироваться, чем движение света.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .