Как работают видеоредакторы?

Question

[ixon]

Какой путь проходит абстракция прежде чем стать видеофайлом?
При поиске ответа на этот вопрос, обычно получается найти лишь информацию о том как из одного видеоформата происходит конвертирование в другой. А что насчёт видео, которые получаются не из других видео?
Допустим, у нас есть какие-то данные о геометрических примитивах, их цвете, их расположении в какие-то ключевые моменты. Например,

Синий квадрат 20 x 20 пикселей располагается в 10 пикселях слева и 25 пикселях сверху от крайней левой точке, через 5 секунд он меняет своё расположение отдаляясь от верхнего-левого края вниз на 6 пикселей и вправо на 12.

Как обычно записывают такие данные для подготовки к созданию кадров? С помощью каких библиотек их отрисовывают попиксельно и в итоге соединяют все кадры? Какие языки программирования чаще всего для этого используют?

Answer 1

[Максим Гришин]

Вкратце - это называется рендер. Он бывает 2D и 3D, при 2D примитивы двигаются напрямую по области экрана, при 3D рисуется трехмерная сцена. Для отрисовки 3D используется специальное ПО: Maya, 3DS Max, ещё несколько. Данные для сцен кодируются в специфических форматах, данные движения - отдельно, текстуры отдельно, материалы ("синий" - это какой? Блестящий или нет, шершавый или нет, если шершавый, то какой именно? Это всё свойства материала) отдельно. Потом ПО собирает всю информацию в сцену и запускает ray tracing или проверку каждого луча, идущего от зрителя в каждый пиксель (или субпиксель, т.е. несколько лучей на пиксель), куда он попал, куда отразился, куда был преломлен, куда в итоге улетел, и прочие эффекты вроде bump mapping'a, фонового освещения и ещё много чего, что может технически быть на сцене. Из этих пикселей собирается один кадр.

Если разговор об игровом рендеринге, то подход меняется на отрисовку полигонов вместо трассировки лучей - трассировка чересчур затратная, а frame rate нужно держать на уровне. Спецэффекты, освещение, bump mapping и подобное реализуются шейдерами на GLSL/HLSL или чем-то более продвинутом, сцена кодируется в BSP или другом формате, специфическом для игрового движка (BSP - "дедушка" трехмерных сцен, использовался в Quake 1), объекты внутри сцены имеют свои структуры в том же формате, а для отрисовки используются OpenGL, Direct3D/DirectX и на нижнем уровне - всё те же C++.

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

Comments

[ixon]

Вопрос именно в кодировании видео, а не в том как работает трёхмерная графика.

[Максим Гришин]

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

[ixon]

Максим Гришин, можно написать это в ответ, чтобы я пометил его решением? Алсо, чем обычно создаются статичные кадры? Какие инструменты существуют, чтобы их создать, какие из них применяются чаще?

[d'Ivan]

ixon,

можно написать это в ответ, чтобы я пометил его решением?

к чему формальности?

[Stalker_RED]

ixon, что за странная тяга помечать ответом то, что на самом деле ответом на поставленный вопрос не является?

У вас в заголовке про видеоредакторы, в самом вопросе про рендер, но пометить вы хотите про то, как из отдельных картинок собирается видеофайл.
ffmpeg -f ...!

Answer 2

[nidalee]

Зависит от кодека. В целом, да: видео - всего лишь слайдшоу. С большой частотой кадров.
Видео даже можно просчитать в последовательность изображений в большинстве редакторов. И потом так же импортировать обратно в него.
Вопреки некоторым мнениям, прямой зависимости кодека (а соответственно размера файла) от расширения (будь то avi, mp4 или mov) нет. Расширение связано с контейнером, который сам по себе - всего лишь компиляция звукового и видео -файлов. Можно переименовать тот же mp4 в avi - во многих плеерах он все равно будет открываться.
Что касается кодеков, то тут уже кто во что горазд. Их много, и про все рассказывать просто долго. Если очень грубо: видеофайлы получаются разными по качеству и объёму как раз из-за кодеков. Они разделяют каждый кадр на N количество частей, плюс разделяют их в... 4 измерении - времени (На самом деле в 3-х, ведь у видео нет глубины, ну да ладно). Допустим, на отрезки GOP по 25 кадров (про них можно почитать здесь).
Если в квадрате N1 ничего за 25 кадров не изменилось, то он остается, новый не пишется - уменьшается размер файла. Если изменилось - там уже возможны варианты. Наглядно, так делит на квадраты H264 и H265. Вот еще страшные картинки. Из-за этих же квадратов чересчур пережатое видео рассыпается на квадраты - они просто начинают слишком сильно отличаться от соседей, теряются градиенты и тому подобное. И из-за этих же квадратов не советуют пережимать видеофайлы в lossy-кодеки, вообще. Потому что качество в любом случае станет хуже, ведь уже сжатое сжимается опять.
Что касается камер - тут уже понятия не имею, как и что они делают, чтобы сделать кадр, а из набора кадров - видео. :)

Answer 3

[Saboteur]

Видео кодируется уже из готовых кадров. Популярные видеокодеки не работают с векторной графикой, работают с обычным растром.
То есть сперва из 3д моделей и векторов создается набор обычных растровых картинок нужного разрешения, чаще всего даже рендерится видео с использованием какого-нибудь lowless кодека, который работает максимально быстро, жмет не так сильно но все же уменьшает нагрузку на носители.

А затем уже такое видео может пережиматься стандартным двухпроходным, например h.264, и упаковываться в подходящий контейтер, например .mkv или .avi

Answer 4

[Xilian]

>>Допустим, у нас есть какие-то данные о геометрических примитивах, их цвете, их расположении в какие-то ключевые моменты.

Это векторный формат выходит. Это не совсем видео.

>>С помощью каких библиотек их отрисовывают попиксельно и в итоге соединяют все кадры?

С помощью SDK конкретной операционной системы. Они радикально различаются. Можешь посмотреть код того же mplayer/VLC как кроссплатформенный.

>>Какие языки программирования чаще всего для этого используют?

Си/ASM/OpenCL/CUDA.

Сами алгоритмы невероятно сложные. Для обработки того-же mp4/avc/h264/h265 куча постпроцессинговых фильтров используется. Там очень много нетривиальной математики.