3109

Коротко о видео

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

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

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

Для примера возьмем что одна картинка в разрешении 1080p весит 200kb. Получается что при 30 кадрах в секунду и полуторачасовом фильме (90 минут) мы получаем следующее

200 (кб) * 30 (fps) * 90 (мин) * 60 (сек) = 32.4 Гигабайта.

А это уже сравнимо с парочкой, а то и тройкой фильмов в 4к.

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

Так как же еще пытаются уменьшить объем видео? В основном это делают, реализуя алгоритмы на основе 2х видов кадров (их, правда, побольше, но сейчас поговорим только об основных)

1. Опорные кадры - I кадры

2. Промежуточные кадры - P кадры

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

Ничего не понятно? Покажу на примере гифки, так как с видео мне сейчас лень работать


I кадр  P кадр  P кадр  P кадр  P кадр  P кадр

Ну а на выходе мы получаем следующее

И в данном случае, вместо того, чтобы потратить 10 кб * 6 кадров = 60 кб, мы потратили только 10 (кб 1 кадр) + (1 (кб) * 5 (кадров)) = 15 килобайт.

Согласитесь, выгода ощутимая.

И в итоге чем больше у нас GOP (расстояние между 2мя I кадрами) тем меньше весит видео. Но как и у любой медали здесь тоже есть обратная сторона. Я думаю, что все наблюдали подобную картинку при просмотре чего бы то ни было хотя бы раз в жизни

Ну и происходит это от того, что i кадры слишком редкие, и при декодировании видео, происходят мелкие ошибки, которые и приводят к тому, что P кадры накладываются не на тот I кадр.

И кстати, возможно вы замечали, что подобные артефакты пропадают при полной смене кадра. Например, при начале съемки с другого ракурса, или другой локации. Все потому, что при подобных финтах, P кадр не может наложиться на старый i кадр. Точнее он может, но он уже не будет выглядеть обрезком как на картинке, которую я показал. Он будет уже точно тем, чем являются опорные кадры (i кадры).


Вот, собственно, именно так и работает вся эта херня, которую мы с вами наблюдаем целыми днями.


Дальше попробую развить эту тему, и в следующем посте (если меня ссаными тряпками не погонят) обсудим, нахрен нам нужны 100+ FPS, если из каждого утюга трубят про пресловутые 24 кадра

Вы смотрите срез комментариев. Показать все
22
Автор поста оценил этот комментарий
Иллюстрация к комментарию
раскрыть ветку (16)
5
Автор поста оценил этот комментарий

это webm столько весит, mp4 версия всего 9кб)

13
Автор поста оценил этот комментарий

По размерам я немного утрировал, а цифры взял из головы для простоты расчетов

раскрыть ветку (12)
17
Автор поста оценил этот комментарий

тут проблема скорее в том что вы для простоты взяли для иллюстрации gif, а он вроде как таки не использует эту технологию с вычислением разницы между кадрами, а тупо хранит все кадры в виде отдельных картинок. А меньше чем 60 кб он получился потому как гиф это таки палитровый формат т.е. вместо 4 байт RGBA на пиксель у него 1 байт номера в палитре + RGBA палитра из 256 цветов + он еще и какую-никакую архивацию имеет (а палитровые изображения сжимаются лучше чем те у которых каждый пиксель имеет собственный цвет). Но, думаю, вы и без меня это знаете, это скорее для ваших оппонентов.

А по поводу статьи вроде как есть весьма неплохая иллюстрация что это реально так работает, это когда ты пытаешься перейти на определенный кадр в видео то, если присмотреться, по факту плеер часто прыгает не на тот кадр/время что ты выбрал, а на некоторый близкий к выбранному кадр и связано это как раз с тем что он не может просто показать 103 кадр - нету у него 103 кадра в файле, есть 100 кадр который I-кадр + отличие 103 кадра от 100 (условно, разные форматы вроде как по разному строят P) и многие плееры решают эту проблему не вычислением 103 кадра, а переходом к ближайшему i-кадру (сам так делал для получения кадра в предпросмотре).

Ну и у некоторых форматов есть еще B-кадры, от P они отличаются тем что могут зависеть не только от предыдущих, но и от последующих кадров

раскрыть ветку (11)
6
Автор поста оценил этот комментарий

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

раскрыть ветку (7)
11
Автор поста оценил этот комментарий

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

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

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

2
Автор поста оценил этот комментарий

Дак может тогда так и писать: пост для "гуманитариев", все числа от балды, совпадения с реальностью случайны?

Автор поста оценил этот комментарий

если вы в каментах делаете такое уточнение, почему бы не указывать это сразу в посте? так будет честнее, что ли

раскрыть ветку (2)
3
Автор поста оценил этот комментарий
В следующий раз постараюсь учесть
раскрыть ветку (1)
0
Автор поста оценил этот комментарий
автор, пили продолжение
1
Автор поста оценил этот комментарий

gif использует технологию наложения кадров

раскрыть ветку (2)
0
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

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

3
Автор поста оценил этот комментарий
У меня эта гифка пишет 51 кб
0
Автор поста оценил этот комментарий
Иллюстрация к комментарию
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку