x264 или как кодировать видео
Проблема с кодированием видео и его сжатием его из гигабайтов в мегабайты, по-моему, всегда была актуальной. Если более менее профессиональные операторы, монтажники и т.д. уже не одну кошку съели на этой теме, то например любители и те, кто записывают видео с экрана своего монитора, порой долго чешут затылок, прежде чем добиться каких либо серьезных результатов. В итоге куча потерянного времени, никому не нужные гигабайты исходящего трафика для загрузки домашнего видео на ютуб. Конечно, можно использовать в какой-то степени готовые решения в лице одной программы, и сжать видео буквально тремя кликами, но это не наш подход, когда абсолютно все шаги можно контролировать и влиять на них. Покопавшись в поиске, Хабр так и не выдал ничего похожего. Хотя возможно, что просто плохо поискал.
Сразу оговорюсь, что изначально статья не моя. Я наткнулся на неё, лет пять назад, когда встала задача что-то делать с записанными моментами из тогда любимой многими игры Battlefield 2, на популярном отечественном ресурсе мувимейкеров. Постепенно статья допиливалась и публиковалась, то там, то там. Не исключаю, что первоначально статья пришла из-за «бугра» и всего на всего была переведена на наш могучий язык.
Итак, кодек х264 пришел на смену таким монстрам своего времени как DivX и XviD и удачно положил обоих на лопатки. Для того, что бы добиться действительно впечатляющего результата, нам понадобится следующие вещи:
1. MeGUI — этим мы сжимаем само видео. Вернее, сжимает сам кодек, а это только GUI объединивший в себе десятки разных специализированных утилит.
2. Avisynth — фреймсервер. Если вдруг кто не знает, что это такое, то он является посредником между нашим не сжатым видео и кодеком.
3. VLC media player — Тут совсем все просто. Всеядный плеер, умеющий работать с потоковым видео. Достаточно популярный.
4. K-Lite Codec Pack — пакет все возможных кодеков, на все случаи жизни. Нам нужна сборка Mega.
Настоятельно рекомендую обновлять K-Lite Codec Pack, как минимум всегда перед сжатием видео. Это конечно не обязательно, но опыт подсказывает, что если вы столкнетесь с непонятными ошибками/косяками/глюками/etc то в 50%, а то и больше, обновление кодеков избавит вас от лишнего геморроя.
Кстати, MeGUI достаточно быстро и часто обновляется и дополняется. Скриншоты приведенные ниже, могут уже не соответствовать текущей версии, но это не страшно. Как правило, меняется расположение элементов, что то пододвинули вправо, что-то перенесли в другую закладку. Пропажа находится очень быстро, поэтому не пугайтесь.
Поехали. Устанавливаем Avisynth, а затем MeGUI. После того, как MeGUI обновится, идем в папку, где лежит наш опытный образец, и для удобства создаем там файл с расширением *.avs. Открываем блокнотом и пишем заветные строки:
Первая строка, подскажет MeGUI с каким файлом требуется работать. Вторая строка, указывает на используемую систему цветов.
Существует несколько различных способов представление цвета. Например: цветовое пространство YUV и RGB. В YUV цветовом пространстве есть один компонент, который представляет яркость (сигнал яркости) и два других компонента, которые представляют цвет (сигнал цветности). В то время как яркость передается со всеми деталями, некоторые детали в компонентах сигнала цветности могут быть удалены путем понижения разрешения отсчетов (фильтрация или усреднение), что может быть сделано несколькими способами (т.е. есть много форматов для сохранения изображения в цветовом пространстве YUV). YV12 — один из таких форматов (тут сигнал цветности общий для каждого блока пиксел 2×2), который поддерживается AviSynth.
У нас получился скрипт. Идем дальше. Открываем MeGUI и указываем месторасположение скрипта. Если скрипт AviSynth находится в той же папке где и ваше видео, то вторая строка заполнится автоматически.
Открываем настройки кодека, нажатием на кнопку Config, справа от Encoder settings. Ставим галочку, подтверждая, что нам действительно нужны расширенные настройки. Дальше нам остается поставить галочки в соответствии со скриншотами.
Нажимаем на кнопку queue и идем спать, пить кофе и т.д. в зависимости от предпочтений и мощностей ПК.
Хочу оговориться, что данный конфиг подходит для исходного видео 720p. Для 1080p нужно немного под редактировать конфиг:
Так же можно указать, сколько кодеру можно использовать ядер:
Что мы получаем в итоге. Я имел в наличии следующий видео-ролик:
Format: RGB
Codec ID: 0x00000000
Codec ID/Info: Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples
Duration: 3mn 42s
Bit rate: 663 Mbps
Width: 1 280 pixels
Height: 720 pixels
Display aspect ratio: 16:9
Frame rate: 29.970 fps
Bit depth: 8 bits
Bits/(Pixel*Frame): 24.000
Stream size: 17.2 GiB (100%)
После ожидания около 15-16 минут, я получил на выходе 184 Мб.
Если Хабру интересны подобные статьи на тематику сжатия видео, то я продолжу и поделюсь своим опытом. Если хотите меня поправить и указать на ошибку, то с радостью отвечу на всю критику и замечания.
Магия H.264
H.264 — стандарт сжатия видео. И он вездесущ, его используют для сжатия видео в интернете, на Blu-ray, телефонах, камерах наблюдения, дронах, везде. Все сейчас используют H.264.
Нельзя не отметить технологичность H.264. Он появился в результате 30-ти с лишним лет работы с одной единственной целью: уменьшение необходимой пропускной способности канала для передачи качественного видео.
С технической точки зрения это очень интересно. В статье будут поверхностно описаны подробности работы некоторых механизмов сжатия, я постараюсь не наскучить с деталями. К тому же, стоит отметить, что большинство изложенных ниже технологий справедливы для сжатия видео в целом, а не только для H.264.
Видео в несжатом виде это последовательность двумерных массивов, содержащих информацию о пикселях каждого кадра. Таким образом это трёхмерный (2 пространственных измерения и 1 временной) массив байтов. Каждый пиксель кодируется тремя байтами — один для каждого из трёх основных цветов (красный, зелёный и синий).
1080p @ 60 Hz = 1920x1080x60x3 =>
Этим практически невозможно было бы пользоваться. Blu-ray диск на 50Гб мог бы вмещать всего около 2 мин. видео. С копированием так же будет не легко. Даже у SSD возникнут проблемы с записью из памяти на диск.
Поэтому да, сжатие необходимо.
Обязательно отвечу на этот вопрос. Но сперва я покажу кое-что. Взгляните на главную страницу Apple:
Я сохранил изображение и приведу в пример 2 файла:
Эмм… что? Размеры файлов кажется перепутали.
Нет, с размерами всё в порядке. Видео H.264 с 300 кадрами весит 175 Кб. Один единственный кадр из видео в PNG — 1015 Кб.
Кажется, мы храним в 300 раз больше данных в видео, но получаем файл весом в 5 раз меньше. Получается H.264 эффективнее PNG в 1500 раз.
Как такое возможно, в чём заключается приём?
А приёмов очень много! H.264 использует все приёмы о которых вы догадываетесь (и уйму о которых нет). Давайте пройдёмся по основным.
Избавляемся от лишнего веса.
Представьте, что вы готовите машину к гонкам и вам нужно её ускорить. Что вы сделаете в первую очередь? Вы избавитесь от лишнего веса. Допустим, машина весит одну тонну. Вы начинаете выбрасывать ненужные детали… Заднее кресло? Пфф… выбрасываем. Сабвуфер? Обойдёмся и без музыки. Кондиционер? Не нужен. Коробка передач? В мусо… стойте, она еще пригодится.
Таким образом вы избавитесь от всего, кроме необходимого.
Этот метод отбрасывания ненужных участков называется сжатием данных с потерями. H.264 кодирует с потерями, отбрасывая менее значимые части и сохраняя при этом важные.
PNG кодирует без потерь. Это означает, что вся информация сохраняется, пиксель в пиксель, и поэтому оригинал изображения можно воссоздать из файла, закодированного в PNG.
Важные части? Как алгоритм может определять их важность в кадре?
Существует несколько очевидных способов урезания изображения. Возможно, верхняя правая четверть картинки бесполезна, тогда можно удалить этот угол и мы уместимся в ¾ исходного веса. Теперь машина весит 750 кг. Либо можно вырезать кромку определенной ширины по всему периметру, важная информацию всегда ведь по середине. Да, возможно, но H.264 всего этого не делает.
Что же на самом деле делает H.264?
H.264, как и все алгоритмы сжатия с потерями, уменьшает детализацию. Ниже, сравнение изображений до и после избавления от деталей.
Видите как на сжатом изображении исчезли отверстия в решётке динамика у MacBook Pro? Если не приближать, то можно и не заметить. Изображение справа весит всего 7% от исходного и это при том, что сжатия в традиционном смысле не было. Представьте машину весом всего лишь 70 кг!
7%, ого! Как возможно так избавиться от детализации?
Для начала немного математики.
Информационная энтропия
Мы подходим к самому интересному! Если вы посещали теорию информатики, то возможно вспомните про понятие информационной энтропии. Информационная энтропия это количество единиц для представления некоторых данных. Заметьте, что это вовсе не размер самих данных. Это минимальное количество единиц, которое нужно использовать, чтобы представить все элементы данных.
Например, если в виде данных взять один бросок монеты, то энтропия получится 1 единица. Если же бросков монетки 2, то понадобятся 2 единицы.
Предположим, что монета весьма странная — её подбросили 10 раз и каждый раз выпадал орёл. Как бы вы кому нибудь рассказали об этом? Вряд ли как-то вроде ОООООООООО, вы бы сказали «10 бросков, все орлы» — бум! Вы только что сжали информацию! Легко. Я вас спас от многочасовой утомительной лекции. Это, конечно же, огромное упрощение, но вы преобразовали данные в некое короткое представление с той же информативностью. То есть уменьшили избыточность. Информационная энтропия данных не пострадала — вы только преобразовали представление. Такой способ называется энтропийным кодированием, который подходит для кодирования любого вида данных.
Частотное пространство
Теперь, когда мы разобрались с информационной энтропией, перейдем к преобразованию самих данных. Можно представить данные в фундаментальных системах. Например, если использовать двоичный код, будут 0 и 1. Если же использовать шестнадцатеричную систему, то алфавит будет состоять из 16 символов. Между вышеупомянутыми системами существует взаимно однозначная связь, поэтому можно легко преобразовывать одно в другое. Пока всё понятно? Идём дальше.
А представьте, что можно представить данные, которые изменяются в пространстве или времени, в совершенно иной системе координат. Например, яркость изображения, а вместо системы координат с x и y, возьмём частотную систему. Таким образом, на осях будут частоты freqX и freqY, такое представление называется частотным пространством[Frequency domain representation]. И существует теорема, что любые данные можно без потерь представить в такой системе при достаточно высоких freqX и freqY.
Хорошо, но что такое freqX и freqY?
freqX и freqY всего лишь другой базис в системе координат. Так же как можно перейти из двоичной системы в шестнадцатеричную, можно перейти из X-Y в freqX и freqY. Ниже изображён переход из одной системы в другую.
Мелкая решётка MacBook Pro содержит высокочастотную информацию и находится в области с высокими частотами. Таким образом мелкие детали имеют высокую частоту, а плавные изменения, такие как цвет и яркость низкую. Всё, что между, остаётся между.
В таком представлении, низкочастотные детали находятся ближе к центру изображения, а высокочастотные в углах.
Пока всё понятно, но зачем это нужно?
Потому что теперь, можно взять изображение, представленное в частотных интервалах, и обрезать углы, иными словами применить маску, понизив тем самым детальность. А если преобразовать изображение обратно в привычное, можно будет заметить, что оно осталось похожим на исходное, но с меньшей детализацией. В результате такой манипуляции, мы сэкономим место. Путём выбора нужной маски, можно контролировать детализацию изображения.
Ниже знакомый нам ноутбук, но теперь уже с, применёнными к ней, круговыми масками.
В процентах указана информационная энтропия относительно исходного изображения. Если не приближать, то разница не заметна и при 2%! — машина теперь весит 20 кг!
Именно таким образом нужно избавляться от веса. Такой процесс сжатия с потерями называется Квантованием.
Это впечатляет, какие еще приёмы существуют?
Цветовая обработка
Человеческий глаз не особо хорошо различает близкие оттенки цвета. Можно легко распознавать наименьшие различия в яркости, но не цвета. Поэтому должен существовать способ избавления от лишней информации о цвете и сэкономить ещё больше места.
В телевизорах, цвета RGB преобразуются в YCbCr, где Y это компонента яркости (по сути яркость черно-белого изображения), а Cb и Cr компоненты цвета. RGB и YCbCr эквиваленты в плане информационной энтропии.
Зачем же тогда усложнять? RGB разве не достаточно?
Во времена чёрно-белых телевизоров, была только компонента Y. А с началом появления цветных телевизоров у инженеров встала задача о передаче цветного RGB изображения вместе с чёрно-белым. Поэтому вместо двух каналов для передачи, было решено кодировать цвет в компоненты Cb и Cr и передавать их вместе с Y, а цветные телевизоры уже сами будут преобразовывать компоненты цвета и яркости в привычный им RGB.
Но вот в чём хитрость: компонента яркости кодируется в полном разрешении, а компоненты цвета лишь в четверть. И этим можно пренебречь, т.к. глаз/мозг плохо различает оттенки. Таким образом можно уменьшить размер изображения в половину и с минимальными отличиями. В 2 раза! Машина будет весить 10 кг!
Данная технология кодирования изображения со снижением цветового разрешения называется цветовой субдискретизацией. Она используется повсеместно уже давно и относится не только к H.264.
Это самые значительные технологии в уменьшении размера при сжатии с потерями. Нам удалось избавиться от большинства детализации и сократить информацию о цвете в 2 раза.
Да. Обрезание картинки это лишь первый шаг. До этого момента мы разбирали отдельно взятый кадр. Пришло время взглянуть на сжатии во времени, где нам предстоит работать с группой кадров.
Компенсация движения
H.264 стандарт, который позволяет компенсировать движения.
Представьте, что вы смотрите теннисный матч. Камера зафиксирована и снимает с определенного угла и единственное что движется это мячик. Как бы вы закодировали это? Вы бы сделали что и обычно, да? Трёхмерный массив пикселей, две координаты в пространстве и один кадр за раз, так?
Но зачем? Большая часть изображения одинакова. Поле, сетка, зрители не меняются, единственное что движется это мячик. Что если определить единственное изображение фона и одно изображение мячика, движущегося по нему. Не сэкономило бы это значительно места? Вы видите к чему я клоню, не так ли? Компенсация движения?
И это именно то, что H.264 делает. H.264 разбивает изображение на макроблоки, обычно 16х16, которые используются для расчёта движения. Один кадр остаётся статичным, обычно его называют I-кадр [Intra frame], и содержит всё. Последующие кадры могут быть либо P-кадры [predicted], либо B-кадры [bi-directionally predicted]. В P-кадрах вектор движения кодируется для каждого макроблока на основе предыдущих кадров, таким образом декодер должен использовать предыдущие кадры, взяв последний из I-кадров видео и постепенно добавляя изменения последующих кадров пока не дойдёт до текущего.
Ещё интереснее обстоят дела с B-кадрами, в которых расчёт производится в обоих направлениях, на основании кадров идущих до и после них. Теперь вы понимаете почему видео в начале статьи весит так мало, это всего лишь 3 I-кадра, в которых мечутся макроблоки.
При такой технологии кодируется только различия векторов движения, тем самым обеспечивая высокую степень сжатия любого видео с перемещениями.
Мы рассмотрели статическое и временное сжатия. С помощью квантования мы во много раз уменьшили размер данных, затем с помощью цветовой субдискретизации ещё вдвое сократили полученное, а теперь еще компенсацией движения добились хранения лишь 3х кадров из 300, которые были первоначально в рассматриваемом видео.
Выглядит впечатляюще. Теперь что?
Теперь мы подведём черту, используя традиционное энтропийное кодирование без потерь. Почему нет?
Энтропийное кодирование
После этапов сжатия с потерями, I-кадры содержат избыточные данные. В векторах движения каждого из макроблоков в P-кадрах и B-кадрах много одинаковой информации, так как зачастую они двигаются идентично, как это можно наблюдать в начальном видео.
От такой избыточности можно избавиться энтропийным кодированием. И можно не переживать за сами данные, так как это стандартная технология сжатия без потерь, а значит всё можно восстановить.
Вот теперь всё! В основе H.264 лежат вышеупомянутые технологии. В этом и заключаются приёмы стандарта.
Отлично! Но меня разбирает любопытство узнать, сколько же весит теперь наша машина.
Исходное видео было снято в нестандартном разрешении 1232×1154. Если посчитать, то получится:
5 сек. @ 60 fps = 1232x1154x60x3x5 => 1.2 Гб
Сжатое видео => 175 Кб
Если соотнести результат с оговорённой массой машины в одну тонну, то получится вес равный 0.14 кг. 140 граммов!
Конечно же я в очень упрощённом виде изложил результат десятилетних исследований в этой сфере. Если захотите узнать больше, то страница в википедии вполне познавательна.
Как использовать кодеки Nvidia NVENC: HEVC или H264
Выбираем кодек для записи игровых видео с графической картой NVIDIA:
H.264 против HEVC: какой кодек лучше?
Хотя H.264 долго оставался стандартом качества для западных стримеров, сейчас лучшим выбором будет HEVC. Хотя максимальный стандарт качества у них одинаковый, HEVC лучше справляется с предоставленным ему дисковым пространством. Если записать два видео, одинаковых по продолжительности, содержанию и месту на жёстком диске, видео, кодированное в HEVC, будет лучшего качества. При одинаковом качестве записи файлы HEVC всегда меньше, чем видео, записанные в H.264.
Почему же многие пользователи до сих пор предпочитают H.264? Проблема нового формата — в высоких требованиях и совместимости:
Для стримеров, которые не обновляют железо каждый год, но всё же обладают достаточно мощными видеокартами, чтобы играть в ресурсоёмкие игры, H.264 на сегодняшний день будет лучшим выбором.
Сравнение скорости, качества и размера видео H.264 и HEVC
В приведённой ниже таблице для сравнения указаны показатели видео, записанного разными кодировщиками.
| Кодек | Размер | Качество | Скорость | Особенности |
|---|---|---|---|---|
| HEVC | 33,5 Мб | Выше среднего — соответствует настройкам | Высокая | Кодек обладает более совершенным алгоритмом сжатия без потери качества |
| H264 | 34,2 Мб | Выше среднего — соответствует настройкам | Высокая | Лучший кодек для большинства пользователей за счёт низких требований к железу |
Для сравнения использовалось видео продолжительностью в одну минуту, записанное в разрешении 1920×1080 при частоте кадров (FPS) 30 кадров в секунду. Качество записи в обоих случаях было установлено на 80 из 100.
Чтобы использовать кодировщик Nvidia NVENC, выполните следующие шаги:
Как настроить кодек:
Если вы не видите нужные опции кодеков H264 или HEVC в панели выбора кодеков Bandicam, попробуйте следующие решения:
Кодировщики NVENC работают на операционных системах Win 7, 8 и 10. В Windows XP и более старых ОС опции NVENC будут недоступны.
Обратите внимание: не все модели, поддерживающие H264, будут поддерживать новый стандарт HEVC.
Если вы устанавливали или обновляли Bandicam в последние несколько лет, проблем возникнуть не должно: кодировщик NVENC H264 поддерживается с Bandicam 2.0, а обновлённый стандарт NVENC HEVC — с 2.4.0.
Сообщение об ошибке: не удалось инициализировать кодек. Хотите попробовать снова с кодеком H.264 (CPU)?
Если компьютеру не хватает ресурсов или NVENC используется другой программой, вы получите сообщение об ошибке. Чтобы начать запись, закройте все ненужные приложения, чтобы освободить память, и попробуйте ещё раз. Если проблема сохраняется, используйте другой кодек, например, H.264 (CPU). Если вам нужно использовать Bandicam одновременно с другими программами, которые задействуют технологию NVENC (STEAM VR, Shadow Play и т.д.), загрузите программное решение с GitHub.
Аппаратное кодирование в h264 для видеонаблюдения. Чем?
Доброго дня. В ближайших планах создание видеонаблюдения на базе ПО Trassir и IP видеокамер (16 шт).
Судя по описаниям кодек h264 подходит для видеоархива лучше прочих. И предварительно на 40 дней архива должно хватить 12Tb.
Но интересно на каком оборудовании есть аппаратная поддержка этого кодека? Нужно ли покупать видеокарту, или процессор серии i3 справиться с таким потоком самостоятельно?
Прошу поделиться опытом, у кого он есть :).
одно дело аппаратная поддержка воспроизведения, а другое дело кодирования.
А еще вспомним, что в системах видеонаблюдения нередко пишется аж 5 кадров в секунду. Ну и сцены обычно статичные дни напролет.
К сожалению, обычные аппаратные средства (кодирование в процессорах intel или средствами видеокарты) вам не подойдут. Они в лучшем случае могут кодировать 4 потока одновременно, больше никак. Большинство же кодирует либо 1, либо 2 потока одновременно, либо же могут одновременно декодировать и кодировать, но не больше.
Какое у вас разрешение камер? Какой профиль/настройки хотите использовать у h264? Скажем, на Intel Core i5 можно кодировать около 10 320×240 baseline 24fps потоков.
Спасибо всем, кто откликнулся. Через пару недель будут и сами камеры.
Камеры не сильно навороченные, что-то в духе HIKVISION DS-2CD7153-E
На разрешениеи 1280×720 выдает 25fps, на практике хватит и 15.
Задачи у нас простые — видеонаблюдение за производственными площадями. h264 привлекает именно компактностью записи, так как глубину архива просят сделать побольше. У нас в судах пока не сталкивался с придирками к кодекам, правда и записи были с аналоговых камер.
Ну а раз поток кодирует камера, то все намного проще, главное дисковую подготовить, а здесь уже можно поизвращаться и с сетевым диском, который например сделать на ZFS, и скорость даст и надежность при полной бюджетности.
H.265 vs H.264 сравнение форматов видео. Что такое HEVC и AVC
Опубликовано admin в 24 октября, 2019 24 октября, 2019
H.265 vs H.264 – сравнение современных форматов сжатия видео.
H.265 (HEVC), в отличии от H.264 (AVC), становится наиболее часто используемым форматом для сжатия видео и записи контента 4K / 8K UHD, не говоря уже о видео HD / SD. Увеличение количества видео 4K и 8K бросает вызов текущему стандарту сжатия H.264, поскольку ему больше не удается кодировать видео Ultra HD с удовлетворительной скоростью передачи данных, чем контент HD.
Вследствие этого, стандарт сжатия видео HEVC следующего поколения получает преимущество над AVC благодаря лучшей эффективности сжатия. Это позволяет на 50% снизить скорость передачи, но обеспечивает такое же качество видео.
Этот пост показывает различия между двумя стандартами, основанные на размере файла, использовании полосы пропускания, скорости передачи данных, качестве и совместимости.
Что такое H.265 (HEVC)?
H.265 также называется высокоэффективным кодированием видео (HEVC). Данный формат в два раза более эффективен, чем H.264 при кодировании. Он вдвое снижает скорость передачи при том же уровне качества по сравнению со своим предшественником. Предназначен для дисплеев HDTV следующего поколения и систем захвата контента, которые имеют прогрессивную частоту кадров и разрешение, а также улучшенное качество изображения с точки зрения уровня шума, цветовых пространств и динамического диапазона.
Что такое H.264 (AVC)?
H.264 или MPEG-4 AVC – это формат кодирования видео, который в настоящее время является одним из наиболее часто используемых для сжатия и доставки видеоконтента. AVC экономит битрейт на 50% и более по сравнению с его предшественником MPEG-2. Имеет более широкий спектр приложений, охватывающих все сжатое видео, начиная от потоковых приложений с низким битрейтом (YouTube, iTunes, Vimeo, Facebook, Instagram) для различных передач HDTV по наземному, кабельному и спутниковому телевидению. Он также широко используется для дисков Blu-ray, DVD, IP-сетей и приложений для цифрового кино с кодированием, практически без потерь.
Сравнение форматов сжатия видео
Эффективность сжатия
H.265 отличается от H.264 эффективностью сжатия. HEVC удваивает эффективность кодирования по сравнению со своим предшественником. Это означает, что кодек H.265 экономит около 50% битрейта при том же качестве кодирования. В частности, среднее уменьшение битов для H.265 составляет 64% при 4K UHD, 62% при 1080p, 56% при 720p и 52% при 480p. Таким образом, если загрузить фильм в H.265 и воспроизвести его на устройстве iPhone Android, то будет сохранено 50% памяти мобильного устройства. И качество фильма не пострадает!
Сравнение форматов видео и эффективность сжатия
Полоса пропускания
H.265 превосходит H.264 и в отношении использования полосы пропускания. Поскольку алгоритм HEVC использует эффективное кодирование, он обещает приблизительно 40-50% уменьшения полосы пропускания передачи, необходимой для сжатия видео (например, в формате 720p), с тем же качеством. Как правило, для потоковой передачи 4K H264 (AVC) требуется полоса пропускания 32 Мбит / с, а для передачи видео 4K HEVC – всего 15 Мбит / с. Таким образом, можно наслаждаться 4k видео без проблем даже при перегруженном сетевом соединении.
H.264 и H.265 – полоса пропускания
Качество видео
Большая разница между рассматриваемыми кодеками заключается в качестве видео при одинаковой скорости передачи данных. В AVC границы областей блока, вероятно, будут искажены, потому что каждый макроблок является фиксированным, а данные независимы друг от друга. В то время как H.265 предлагает более четкие детали на гранях и сглаживает градиентные области с меньшим количеством артефактов.
Таким образом, H.265 лучше, чем H.264, когда речь идет о сжатии видео с лучшим качеством изображения.
Размер файла
Высокая степень сжатия также тесно связана с требованием цифрового хранения видеопотоков и передачи. Уменьшенная пропускная способность приводит к уменьшению размера файла. Тесты показывает, что видео, закодированное с помощью H.264, в 1-3 раза больше, чем H.265. Это выгодно для хранения информации на жестком диске или устройствах с ограниченным пространством хранения, необходимого для размещения видеоданных. В этом отношении большое преимущество H.265 перед H.264.
H.265 vs H.264 сравнение форматов – размер файла
Совместимость форматов
Ничто не совершенно. Так же, как и HEVC. Все, сказанное выше, является преимуществом HEVC перед H264. Но есть и недостаток – плохая совместимость. В настоящее время новый формат далеко не так популярен, как H264. Современные устройства и платформы, поддерживающие кодек H264, составляют 99%. Поддержка кодека H265, может составлять около 30-40%.
Преимущества и недостатки
H.265 имеет много преимуществ перед H.264. Например, он поддерживает до 8K UHDTV (разрешением, максимум 8192 × 4320), скорость передачи данных составляет несколько ГБ / с, а размер файла вдвое меньше, и это с лучшим качеством! H.265 имеет большое влияние на увеличение спроса и продажи экранов 4К, предлагая более высокое качество видео даже в сети с ограниченной пропускной способностью.
Но есть и обратная сторона. HEVC требует больше времени для кодирования по сравнению с AVC. Во-вторых, поскольку перспективный кодек, который сейчас широко не используется, просмотр видео H.265 не так прост. Поэтому преобразование H.265 в H.264 по-прежнему очень востребовано в наши дни.
Пишите в комментариях ниже какую информацию добавить или убрать для форматов сжатия видео – H.264 (AVC) vs H.265 (HEVC). Открыт для предложений по оформлению и наполнению страницы.
