Чем отличаются кодеки x264 и h264
Я так запутался . в чем разница между аудио / видео кодеком (который, по-видимому, является сокращением для "кодера / декодера", вроде того, как "модем" на самом деле "модулятор / демодулятор") и аудио / видео формат?
(Я даже использую правильную терминологию?)
то есть: в чем разница между тем, чтобы что-то сказать «MPEG-4», и тем, что что-то использует кодек «DivX»? Почему Windows Media Player иногда запускает .mpg файлы, а иногда нет?
Кроме того, какие из следующих кодеков, какие форматы файлов, а какие нет?
- Quicktime MOV
- MPEG (1, 2, 3, 4)
- WMV
- FFmpeg
- AVC
- Xvid
- DivX (чем он отличается от своего палиндрома, Xvid?)
- H.264
Глядя на мой собственный вопрос 6 лет спустя, и все, что я могу думать, это "как ты не знаешь этого ?!"
Некоторые основные определения:
- Кодек (например, H.264, HEVC, VP9) отвечает только за видео или аудио часть, и один или несколько кодеков могут быть объединены в контейнер.
- Контейнер (например, MP4, MKV) отвечает за их хранение, и это также то, что вы обычно открываете в своем медиаплеере по выбору.
- Конкретный кодер (например, x264, libvpx) отвечает за превращение входного потока в поток битов, совместимый с кодеками. Часто существует несколько кодеров для одного конкретного кодека.
Как вы можете видеть, мы должны объяснить несколько вещей здесь.
В настоящее время, когда указывается видеокодек, участвующие в нем учреждения обычно определяют только синтаксис стандарта. Например, они скажут: «Формат битового потока должен быть таким», « 0x810429AAB Здесь будет переведено в это» и т. Д. Часто они предоставляют эталонный кодер и декодер, но как тогда кодер пишется для соответствия такому Формат полностью зависит от производителей.
По этой причине вы найдете так много кодеров для одного и того же кодека, а некоторые даже коммерческие.
Это было предсказуемо: разбираемся, как H.264 сжимает видео
Вернемся к таблице, с которой мы начали. Как видите, помимо таких параметров, как разрешение, фреймрейт и качество картинки решающим фактором, определяющим конечный размер видео, оказывается уровень динамичности снимаемой сцены. Это объясняется особенностями работы современных видеокодеков вообще, и H.264 в частности: используемый в нем механизм предсказания кадров позволяет дополнительно сжимать видео, при этом практически не жертвуя качеством картинки. Давайте посмотрим, как это работает.
Кодек H.264 использует несколько типов кадров:
- I-кадры (от английского Intra-coded frames, их также принято называть опорными или ключевыми) — содержат информацию о статичных объектах, не меняющихся на протяжении длительного времени.
- P-кадры (Predicted frames, предсказанные кадры, также именуемые разностными) — несут в себе данные об участках сцены, претерпевших изменения по сравнению с предыдущим кадром, а также ссылки на соответствующие I-кадры.
- B-кадры (Bi-predicted frames, или двунаправленные предсказанные кадры) — в отличие от P-кадров, могут ссылаться на I-, P- и даже другие B-кадры, причем как на предыдущие, так и на последующие.
[НАЧАЛО СЪЕМКИ] I-P-P-P-P-P-P-P-P-P-P-P-P-P- .
Поскольку в процессе вычитания возможны ошибки, приводящие к появлению графических артефактов, то через какое-то количество кадров схема повторяется: вновь формируется опорный кадр, а вслед за ним — серия кадров с изменениями.
Полное изображение формируется путем «наложения» P-кадров на опорный кадр. При этом появляется возможность независимой обработки фона и движущиеся объектов, что позволяет дополнительно сэкономить дисковое пространство без риска упустить важные детали (черты лиц, автомобильные номера и т. д.). В случае же с объектами, совершающими однообразные движения (например, вращающимися колесами машин) можно многократно использовать одни и те же разностные кадры.
Независимая обработка статических и динамических объектов позволяет сэкономить дисковое пространство
Данный механизм носит название межкадрового сжатия. Предсказанные кадры формируются на основе анализа широкой выборки зафиксированных состояний сцены: алгоритм предвидит, куда будет двигаться тот или иной объект в поле зрения камеры, что позволяет существенно снизить объем записываемых данных при наблюдении за, например, проезжей частью.
Кодек формирует кадры, предсказывая, куда будет двигаться объект
В свою очередь, использование двунаправленных предсказанных кадров позволяет в несколько раз сократить время доступа к каждому кадру в потоке, поскольку для его получения будет достаточно распаковать только три кадра: B, содержащий ссылки, а также I и P, на которые он ссылается. В данном случае цепочку кадров можно изобразить следующим образом.
[НАЧАЛО СЪЕМКИ] I-B-P-B-P-B-P-B-P-B-P-B-P-B-P-B-P-…
Такой подход позволяет существенно повысить скорость быстрой перемотки с показом и упростить работу с видеоархивом.
Пример дела - H.264
Прежде чем мы перепутаем терминологию, давайте рассмотрим пример. Рассмотрим случай для H.264 . Название стандарта - H.264 - это не имя фактического кодировщика. Mainconcept - очень хороший коммерческий кодер, тогда как x264 - бесплатный и с открытым исходным кодом. Конечно, оба претендуют на высокое качество.
Тот факт, что вы можете оптимизировать кодировку, создает конкуренцию здесь. Оба кодера доставляют стандартизированный поток битов, который всегда можно декодировать с помощью H.264-совместимого декодера.
FLV
Формат видео Flash был создан Adobe для использования в их потоковых приложениях. Он больше не используется, так как способ потоковой передачи значительно изменился за последние годы.
MPEG-4 часть 2
Вероятно, это тот, который использовался в основном для кодирования видео для Интернета в середине 2000-х, но в то же время он был заменен. Он предлагает хорошее качество при практических размерах файлов, что означает, что вы можете записать весь фильм продолжительностью 90 минут на компакт-диск объемом 600 МБ (тогда как для MPEG-2 вам понадобился бы DVD, см. Мой ответ здесь ). Это больше не работает так хорошо для HD или 4K контента.
Некоторыми кодировщиками, которые выводят видео в формате MPEG-4 Part 2, являются DivX , его Ripoff с открытым исходным кодом XviD и Nero Digital .
Видеоролики MPEG-4 Part 2 в основном поставляются в контейнере AVI , но MP4 также часто просматривается.
В чем разница между H.264 и H.265?
В H.265 используются все те же принципы сжатия, что и в H.264: фоновое изображение сохраняется единожды, а затем фиксируются лишь изменения, источником которых являются движущиеся объекты, что позволяет значительно снизить требования не только к объему хранилища, но и к пропускной способности сети. Однако в H.265 многие алгоритмы и методы прогнозирования движения претерпели значительные качественные изменения.
Так, обновленная версия кодека стала использовать макроблоки дерева кодирования (Coding Tree Unit, CTU) переменного размера с разрешением до 64×64 пикселей, тогда как ранее максимальный размер такого блока составлял лишь 16×16 пикселей. Это позволило существенно повысить точность выделения динамических блоков, а также эффективность обработки кадров в разрешении 4K и выше.
Кроме того, H.265 обзавелся улучшенным deblocking filter — фильтром, отвечающим за сглаживание границ блоков, необходимым для устранения артефактов по линии их стыковки. Наконец, улучшенный алгоритм прогнозирования вектора движения (Motion Vector Predictor, MVP) помог заметно снизить объем видео за счет радикального повышения точности предсказаний при кодировании движущихся объектов, чего удалось достичь за счет увеличения количества отслеживаемых направлений: если ранее учитывалось лишь 8 векторов, то теперь — 36.
Помимо всего перечисленного выше, в H.265 была улучшена поддержка многопоточных вычислений: квадратные области, на которые разбивается каждый кадр при кодировании, теперь могут обрабатываться независимо одна от другой. Появилась и поддержка волновой параллельной обработки данных (Wavefront Parallelel Processing, WPP), что также способствует повышению производительности сжатия. При активации режима WPP обработка CTU осуществляется построчно, слева направо, однако кодирование каждой последующей строки может начаться еще до завершения предыдущей в том случае, если данных, полученных из ранее обработанных CTU, для этого достаточно. Кодирование различных строк CTU с временной задержкой со сдвигом, наряду с поддержкой расширенного набора инструкций AVX/AVX2 позволяет дополнительно повысить скорость обработки видеопотока в многоядерных и многопроцессорных системах.
Проверка отклонения битрейта
Чистая формальность, чтобы убедиться, что кодеки попадают в битрейт, указанный в настройках. Отклонение до 5% считается нормальным, здесь все уложились.
В конце статьи есть ссылки на результаты кодирования. Некоторые типы артефактов сильно заметны на картинках, но не сильно заметны на видео. А некоторые наоборот. Так что если кому интересно, можете оценить.
Всё-таки сложно оценить практическую пользу от того, что у одного видео попугаев на сколько-то больше, чем у другого. Так что ещё я решил проверить, в какой размер может уложить видео x264 при том же визуальном качестве, что и у Theora. Пресет Theora тот же, для x264 — тот, который x264 normal. Для сравнения использовал SSIM. Для всех последовательностей SSIM у x264 чуть выше, но приближен максимально, насколько мне это удалось.
Вот график битрейтов получившихся файлов:
Файлы различаются в размере в 2-4 раза.
- Увеличить число ссылочных кадров
- Увеличить число последовательных b-кадров
- Увеличить максимальный радиус оценки движения
- Использовать опции --tune ssim и --tune psnr, которые позволяют улучшить показатели по одной метрике, несколько ухудшив их по другой (в первом сравнении от разработчиков Theora был только PSNR)
- Включить и настроить психовизуальные оптимизации, если бы сравнение было субъективным
- Заняться подгонкой параметров устранения блочности
- Использовать другие более хитрые настройки, использующие особенности тестового видео
- Отключить использование нескольких ссылочных кадров
- Оставить включённые по дефолту психовизуальные оптимизации, которые просаживают и SSIM, и PSNR
- Выбрать менее качественный алгоритм оценки движения
- Оставить возможность использования блоков только размером 16x16 пикселей
- Использовать не по назначению опции адаптивного квантования для просаживания одной из метрик
- Использовать какие-нибудь неадекватные настройки
H.264 — более эффективный, чем Ogg Theora, формат по показателю качество/размер. Также он куда более гибкий, позволяет значительно варьировать параметры в зависимости от поставленной задачи.
И не стоит слепо верить сравнениям, в которых не приведены настройки кодеков. Слишком много возможностей для манёвра.
Результаты кодирования (25 МБ)
Исходное видео (365 МБ) — весит так много, потому что закодировано lossless-кодеком huffyuv.
Затраты на хранение данных зачастую становятся основным пунктом расходов при создании системы видеонаблюдения. Впрочем, они были бы несравнимо больше, если бы в мире не существовало алгоритмов, способных сжимать видеосигнал. О том, насколько эффективны современные кодеки, и какие принципы лежат в основе их работы, мы и поговорим в сегодняшнем материале.
Для большей наглядности начнем с цифр. Пускай видеозапись будет вестись непрерывно, в разрешении Full HD (сейчас это уже необходимый минимум, во всяком случае, если вы хотите полноценно использовать функции видеоаналитики) и в режиме реального времени (то есть, с фреймрейтом 25 кадров в секунду). Предположим также, что выбранное нами оборудование поддерживает аппаратное кодирование H.265. В этом случае при разных настройках качества изображения (высоком, среднем и низком) мы получим примерно следующие результаты.
Кодек
Интенсивность движения в кадре
Использование дискового пространства за сутки, ГБ
H.265 (Высокое качество)
H.265 (Высокое качество)
H.265 (Высокое качество)
H.265 (Среднее качество)
H.265 (Среднее качество)
H.265 (Среднее качество)
H.265 (Низкое качество)
H.265 (Низкое качество)
H.265 (Низкое качество)
Но если бы сжатия видео не существовало в принципе, мы бы увидели совсем иные цифры. Попробуем разобраться, почему. Видеопоток представляет собой не что иное, как последовательность статичных картинок (кадров) в определенном разрешении. Технически каждый кадр является двумерным массивом, содержащим информацию об элементарных единицах (пикселях), формирующих изображение. В системе TrueColor для кодирования каждого пикселя требуется 3 байта. Таким образом, в приведенном примере мы бы получили битрейт:
1920×1080×25×3/1048576 = ~148 Мб/с
Учитывая, что в сутках 86400 секунд, цифры выходят поистине астрономические:
148×86400/1024=12487 ГБ
Итак, если бы мы записывали видео без сжатия в максимальном качестве при заданных условиях, то для хранения данных, полученных с одной единственной видеокамеры в течение суток нам бы потребовалось 12 терабайт дискового пространства. Но даже система безопасности квартиры или малого офиса предполагает наличие, как минимум, двух устройств видеофиксации, тогда как сам архив необходимо сохранять в течение нескольких недель или даже месяцев, если того требует законодательство. То есть, для обслуживания любого объекта, даже весьма скромных размеров, потребовался бы целый дата-центр!
К счастью, современные алгоритмы сжатия видео помогают существенно экономить дисковое пространство: так, использование кодека H.265 позволяет сократить объем видео в 90 (!) раз. Добиться столь впечатляющих результатов удалось благодаря целому стеку разнообразных технологий, которые давно и успешно применяются не только в сфере видеонаблюдения, но и в «гражданском» секторе: в системах аналогового и цифрового телевидения, в любительской и профессиональной съемке, и многих других ситуациях.
Наиболее простой и наглядный пример — цветовая субдискретизация. Так называют способ кодирования видео, при котором намеренно снижается цветовое разрешение кадров и частота выборки цветоразностных сигналов становится меньше частоты выборки яркостного сигнала. Такой метод сжатия видеоданных полностью оправдан как с позиции физиологии человека, так и с точки зрения практического применения в области видеофиксации. Наши глаза хорошо замечают разницу в яркости, однако гораздо менее чувствительны к перепадам цвета, именно поэтому выборкой цветоразностных сигналов можно пожертвовать, ведь большинство людей этого попросту не заметит. В то же время, сложно представить, как в розыск объявляют машину цвета «паука, замышляющего преступление»: в ориентировке будет написано «темно-серый», и это правильно, ведь иначе прочитавший описание авто даже не поймет, о каком оттенке идет речь.
А вот со снижением детализации все оказывается уже совсем не так однозначно. Технически квантование (то есть, разбиение диапазона сигнала на некоторое число уровней с последующим их приведением к заданным значениям) работает великолепно: используя данный метод, размер видео можно многократно уменьшить. Но так мы можем упустить важные детали (например, номер проезжающего вдалеке автомобиля или черты лица злоумышленника): они окажутся смазаны и такая запись будет для нас бесполезной. Как же поступить в этой ситуации? Ответ прост, как и все гениальное: стоит взять за точку отсчета динамические объекты, как все тут же становится на свои места. Этот принцип успешно используется со времен появления кодека H.264 и отлично себя зарекомендовал, открыв ряд дополнительных возможностей для сжатия данных.
Популярные контейнеры
Вы найдете видео в основном в следующих контейнерах. Есть и другие, менее популярные, но, как я уже сказал, в основном это:
Toys and calendar
Вот здесь у Теоры полный провал. Урезанный пресет x264 аккуратно замыливает высокие частоты, и в целом картинка смотрибельная. У Теоры же местами жуткая блочность и местами снос деталей. А обычному пресету x264 вполне хватило битрейта, даже узоры на обоях остались.
Флэш-карты для видеонаблюдения: когда значение имеет не только размер
И вновь вернемся к табличке, с которой мы начали сегодняшний разговор. Давайте подсчитаем, сколько дискового пространства нам понадобится в том случае, если мы хотим хранить видеоархив за последние 30 дней при максимальном качестве видеозаписи:
138×30/1024 = 4
По нынешним меркам 4 терабайта для винчестера индустриального класса — практически ничто: современные жесткие диски для видеонаблюдения имеют емкость до 14 терабайт и могут похвастаться рабочим ресурсом до 360 ТБ в год при MTBF до 1.5 миллионов часов. Что же касается карт памяти, то здесь все оказывается не так однозначно.
В IP-камерах флэш-карты играют роль резервных хранилищ: данные на них постоянно перезаписываются, чтобы в случае потери связи с видеосервером недостающий фрагмент видеозаписи можно было восстановить из локальной копии. Такой подход позволяет существенно повысить отказоустойчивость всей системы безопасности, однако при этом сами карты памяти испытывают колоссальные нагрузки.
При бытовом использовании подобное попросту невозможно, поэтому даже самая бюджетная карта памяти способна прослужить вам несколько лет к ряду без единого сбоя. А все благодаря алгоритмам выравнивания износа (wear leveling). Схематично их работу можно описать следующим образом. Пусть в нашем распоряжении есть новенькая флеш-карта, только что из магазина. Мы записали на нее несколько видеороликов, использовав 7 из 16 гигабайт. Через некоторое время мы удалили часть ненужных видео, освободив 3 гигабайта, и записали новые, объем которых составил 2 ГБ. Казалось бы, можно задействовать только что освободившееся место, однако механизм выравнивания износа выделит под новые данные ту часть памяти, которая ранее никогда не использовалась. Хотя современные контроллеры «тасуют» биты и байты куда более изощренно, общий принцип остается неизменным.
Напомним, что кодирование битов информации происходит путем изменения заряда в ячейках памяти за счет квантового туннелирования электронов сквозь слой диэлектрика, что вызывает постепенный износ диэлектрических слоев с последующей утечкой заряда. И чем чаще меняется заряд в конкретной ячейке, тем раньше она выйдет из строя. Выравнивание износа как раз направлено на то, чтобы каждая из доступных ячеек перезаписывалась примерно одинаковое количество раз и, таким образом, способствует увеличению срока службы карты памяти.
Нетрудно догадаться, что wear leveling перестает играть хоть сколько-нибудь значимую роль в том случае, если флэш-карта постоянно перезаписывается целиком: здесь на первый план уже выходит выносливость самих чипов. Наиболее объективным критерием оценки последней является максимальное количество циклов программирования/стирания (program/erase cycle), или, сокращенно, циклов P/E, которое способно выдержать флеш-память. Также достаточно точным и в данном случае наглядным (так как мы можем заранее рассчитать объемы перезаписи) показателем является коэффициент TBW (Terabytes Written). Если в технических характеристиках указан лишь один из перечисленных показателей, то вычислить другой не составит особого труда. Достаточно воспользоваться следующей формулой:
TBW = (Емкость × Количество циклов P/E)/1000
Так, например, TBW флеш-карты емкостью 128 гигабайт, ресурс которой составляет 200 P/E, будет равен: (128 × 200)/1000 = 25,6 TBW.
Давайте считать дальше. Выносливость карт памяти потребительского уровня составляет 100–300 P/E, и 300 — это в самом лучшем случае. Опираясь на эти цифры, мы можем с достаточно высокой точностью оценить срок их службы. Воспользуемся формулой и заполним новую таблицу для карты памяти емкостью 128 ГБ. Возьмем за ориентир максимальное качество картинки в Full HD, то есть в сутки камера будет записывать 138 ГБ видео, как мы выяснили ранее.
Удивительно, но факт — стандарту сжатия видео High Efficiency Video Coding (HEVC) уже более трех лет. Существуют не только программные, но и аппаратные решения для кодирования и даже бытовые медиаплееры с поддержкой этого формата. Интернет завален рекламными хвалебными восторженными отзывами и обзорами, причем обозреватели, в зависимости от наглости безграмотности доверчивости, обещают улучшение сжатия на 30-50% по сравнению с h.264 при том же качестве картинки. Теоретически оно наверняка так и есть и я совершенно ничего не имею против самого стандарта, всей этой высшей математики, множественности профайлов и объективной оценки субъективного восприятия психофизиологических параметров с помощью PSNR. Побудительным мотивом для написания этой антинаучной статьи послужила чистая недоверчивость, желание самостоятельно пощупать имеющиеся на данный момент свободные реализации кодировщиков видео в этот формат (x265) и сравнить результаты со старым добрым x264.
Чтобы понять масштаб проблемы и степень моей недоверчивости, отмечу, что я не верю в аппаратное кодирование в h.264/AVC (а точнее уверен, что с той же и скоростью при лучшем качестве может работать и чисто программный x264.exe), не верю в кодирование видео с помощью CUDA и DXVA и считаю все реализации таких «кодировщиков» чистым шарлатанством и не верю в магические двухкнопочные программы, которые могут «закодировать быстро и хорошо». Еще я не верю в демократию, антивирусы и современное высшее образование, но это уже чисто мои проблемы не имеющие отношения в кодированию видео :)
А теперь, зарядившись изрядной долей скептицизма возьмем один из скомпилированных вариантов свободного кодировщика x265, а точнее восьмибитовую GCC сборку 1.7+286 и все дальнейшие действия будем производить с ней.
В этом пункте, кстати, моя недоверчивость опять взбрыкнула и пришлось потратить около 6 часов для сравнения 11 разных сборок с разных сайтов чтобы ее успокоить. Оказалось что результаты кодирования с аналогичными параметрами были идентичны до степени смешения, а время кодирования отличалось не больше чем на 5-6 процентов.
Для начала, возьмем в качестве исходника упомянутый выше отрывок из Аватара брызги-дерево-туман и чтобы исключить тормоза декодера, сохраним 100 кадров и из него в виде несжатого YUV4MPEG2 файла, который в дальнейшем и будет кодироваться. В x265 по умолчанию применяется CRF метод сжатия с постоянным качеством, поэтому закодируем и в x264 тоже в режиме CRF с показателем качества 17.2. Цифра взята не с потолка, а опытным путем выяснено что любое увеличение этой цифры ведет к понижению и битрейта и качества картинки на выходе, а уменьшение только повышает битрейт без какого-либо заметного увеличения качества. Конечно же остальные параметры кодирования были тоже на максимуме и в результате получился сжатый файл с битрейтом 17.6 Mb/s (что почти в 2 раза ниже исходных 31 Mb/s на BD диске). Время кодирования 100 кадров — 40 секунд. Качество картинки получилось почти идентичным по сравнению с исходником и даже не стоит выкладывать сравнение. В дальнейшем мы будем сравнивать 12-й В-кадр файла x264-17.2.mkv с разными вариантами кодирования в HEVC.
И тут же сравнение результатов пресета placebo с вручную заданными -me full --subme 7
Теперь посмотрим что будет если закодировать в x265 с тем же битрейтом что и x264 и с максимальными параметрами.
Этого же битрейта удалось достичь при значении crf 16.2. В этот раз кодирование заняло 90 минут.
Ссылка на файл
Результаты очень близки, но все же x264 сохранил чуть больше деталей и добавил чуть меньше мыла.
Вывод: Текущие реализации x265 проигрывают по качеству x264 на высоких битрейтах.
А вот и не отгадали :) Даже на родном для x265 битрейте x264 выглядит поприличнее.
Итак, я использую Xbmc на своем Raspberry Pi, и у меня возникают проблемы с пониманием, что я могу на самом деле играть с ним, а что нет.
Я читал, что RPi может воспроизводить видео в кодировке H.264 , но я могу найти только видео в кодировке x264 . Это тоже сработает? И если так, почему некоторые файлы не будут работать, вероятно?
Кажется, существует много недоразумений относительно того, что на самом деле представляет собой H.264 (с точкой). Итак, цитата из Википедии :
H.264 / MPEG-4 Part 10 или AVC (Advanced Video Coding) является стандартом для сжатия видео , и в настоящее время один из наиболее часто используемых форматов [. ]
Здесь важно отметить, что это только стандарт . Это означает, что видео фактически кодируется не с помощью H.264, а с помощью кодека, соответствующего стандарту H.264. Одним из наиболее распространенных является x264 ( строчный x, без точки):
x264 - это бесплатная программная библиотека для кодирования видеопотоков в формат H.264 / MPEG-4 AVC.
[. ]
x264 реализует большое количество функций по сравнению с другими кодерами H.264.
Итак, H.264 является своего рода интерфейсом, а x264 является реализацией (с реальной функциональностью) этого интерфейса.
Таким образом, Pi будет нормально воспроизводить файлы в формате x264.
Тогда почему некоторые файлы в кодировке x264 не воспроизводятся плавно, а останавливаются каждые 4-6 секунд (в зависимости от количества GPU-Ram)?
В большинстве случаев это звук . Поскольку x264 является кодировщиком для видеофайлов HD, большинство этих файлов снабжены цифровой высококачественной звуковой дорожкой, в которой используется кодек DTS .
Pi (на данный момент) не способен аппаратно декодировать DTS-трек, и его процессор недостаточно мощный. На официальных форумах обсуждается этот вопрос, который стоит посмотреть.
Чтобы узнать, так ли это для вас, вы можете использовать mediainfo -tool (должен быть установлен, имена пакетов зависят от вашего дистрибутива):
Теперь у вас есть два варианта:
- Купите DTS-совместимый приемник (может, ваш телевизор тоже может это сделать?) И включите «сквозной» (последний пункт) в Xbmc (или любом другом плеере, который вы используете).
- Конвертируйте DTS-треки в AC3, который можно передавать (быстрее) или декодировать ЦП.
Чтобы выяснить, на что способен ваш ресивер (то, к чему вы подключили HDMI-кабель), используйте параметр tvservice -tool (которого нет в PATH, поэтому вам потребуется полный путь):
Как вы можете видеть, мой текущий приемник способен декодировать PCM и AC3 (не DTS).
Мое решение этой проблемы состоит в том, чтобы преобразовать Аудио-Треки, которые являются DTS к AC3. Вот небольшая строчка, которая преобразует все аудиопотоки в infile.mkv AC3 и не касается видео:
ffmpeg :
avconv :
Примечание. Приведенная выше команда также устанавливает битрейт для результирующего AC3-кодированного аудиопотока (что кажется необходимым). Хотя 256 кбит / с достаточно хороши (большинство DVD используют 192 кбит / с), вы можете захотеть увеличить или уменьшить его.
К счастью, это займет всего около 5 минут (конечно, в зависимости от вашего оборудования). В качестве небольшого бонуса, ваш файл становится меньше, и если вы не аудиофил , вы не услышите разницу.
Тем не менее, фильмы 1080p FullHD заикаются , экран гаснет на несколько секунд без звука, но воспроизведение видео продолжается. Фильм H.264, закодированный в контейнере MKV с дорожками AC3. В чем проблема?
Скорее всего, нет ничего плохого в файле фильма, но с вашими настройками Xbmc. В моем случае проблема заключалась в «частоте обновления» Xbmc . Это установлено на 60 Гц по умолчанию. Для 720p и любых других небольших видеофайлов это, похоже, не проблема для Pi, но файлы 1080p приводят к вышеуказанной проблеме.
Уменьшите частоту обновления до значения менее 60 Гц (для фильмов достаточно 24 Гц). Здесь есть два варианта:
- Глобальный Xbmc (включая сам Xbmc): System -> Settings -> System -> Video output -> Refresh rate
- Только фильмы (определяется по видео-файлу): System -> Settings -> Video -> Playback -> Adjust display refresh rate to match video
После снижения частоты обновления фильмы в формате 1080p также должны воспроизводиться очень хорошо.
MPEG-4 Part 10 / AVC / H.264
Это также известно как MPEG-4 Advanced Video Coding (AVC) или H.264 ; это самый используемый кодек сегодня. Он предлагает хорошее качество при небольших размерах файлов и поэтому идеально подходит для всех видов видео для Интернета или мобильных устройств. Вы найдете H.264 практически во всех современных приложениях, от телефонов до видеокамер. На дисках Blu-ray видео теперь кодируется в формате H.264.
Некоторые кодеры для этого: x264 , NVENC (от NVIDIA), Mainconcept . Видео в основном приходят в контейнерах MP4 , MKV или MOV .
MKV и WebM
Matroska Video (MKV) - это бесплатный формат файлов с открытым исходным кодом, который часто встречается в настоящее время, поскольку он поддерживает практически любой кодек, от H.264 до VP9, и, конечно, также много аудиокодеков.
WebM основан на MKV и в основном используется для видео VP9 и Opus audio - он является контейнером для потокового видео в Интернете, когда используются эти кодеки.
MPEG-2,
MPEG-2 довольно старый. Его первый публичный выпуск вышел в 1996 году. Видео MPEG-2 в основном используется для DVD и телевизионного вещания, например, DVB-T или спутникового, а также для унаследованных приложений, где важна совместимость. Видео MPEG-2 в основном находятся в контейнере .MPG .
Пресеты
Theora:
--soft-target --two-pass --optimize --speedlevel 0 --keyint 250
x264 analogue:
--bframes 0 --no-cabac --partitions i8x8,p8x8 --me umh --no-mbtree --no-psy --no-fast-pskip --no-dct-decimate --subme 1
x264 normal:
--bframes 4 --b-pyramid normal --partitions all --me umh --no-psy --trellis 2 --no-fast-pskip --no-dct-decimate --subme 10 --b-adapt 2 --direct auto
В списке возможностей Теоры заявлено использование нескольких ссылочных (референсных) кадров, но эта фича в настройки никак не вынесена. И поскольку использование нескольких ссылочных кадров Теорой я никак проконтролировать не могу, я разрешил x264 ни в чём себе не отказывать и использовать дефолтное ref=3.
Shuttle start
С этим видео оба кодека справились одинаково хорошо. Но в среднем x264 чуть-чуть вытянул в деталях.
Football
Футбольное поле у Теоры получилось какое-то неровное. На результат x264 смотреть намного приятнее.
Обобщить
Итак, в общем, давайте просто скажем, что кодер будет:
- взять видеокадры
- создать действительный поток битов
Затем поток битов мультиплексируется в контейнер.
- принять этот действительный поток битов
- реконструировать видео кадры из него
Они оба соответствуют стандарту кодеков. Вот и все!
В наши дни вы, вероятно, найдете только видео с кодеками, о которых я упомяну ниже. Интересно, что почти все они были созданы группой экспертов по кинематографии (MPEG). Но есть и другие бесплатные кодеки, например, созданные Google или Alliance for Open Media, которые являются конкурентами стандартов MPEG.
Обратите внимание, что «MPEG» может относиться как к кодекам, так и к контейнерам, как вы увидите ниже. Это добавляет путаницы, но просто знайте, что само по себе «MPEG» ничего не значит, например, «у меня есть файл в формате MPEG», это очень неоднозначно ».
AVI
Audio Video Interleave - это самый простой контейнер, он просто для чередования аудио и видео. Он был написан в 1992 году и до сих пор используется сегодня, но считается устаревшим, поэтому не используйте его больше.
HEVC / H.265
Также называется MPEG-H Part 2, это преемник MPEG-4 Part 10 / AVC / H.264. Он нацелен на более высокие разрешения (до 8 КБ ) и может обеспечить производительность кодирования на 50% выше (с точки зрения качества и скорости передачи битов) по сравнению с H.264 (см. , Например, эту статью ).
Стандарт был опубликован в 2013 году, и постепенно кодек начинает все больше и больше использоваться, например, для IPTV или онлайн-трансляции видео. HEVC также используется Apple для хранения видео и изображений (с использованием HEIF ) на iOS. Однако тот факт, что с HEVC связано несколько патентных пулов, заставляет многие компании (почти все, кроме Apple) переходить на альтернативы без роялти. HEVC также изначально не поддерживается всеми браузерами, что делает его непригодным для потоковой передачи через Интернет.
Самый известный кодер - x265 . Там же NVENC . Видео обычно приходят в контейнерах MP4 .
Популярные кодеки и форматы
Кроме того, какие из следующих кодеков, какие форматы файлов, а какие нет?
- Quicktime MOV : .mov - это расширение файла для формата файлов QuickTime , который является контейнером, созданным Apple. Этот контейнер был позже адаптирован для MP4. Он может нести все виды кодеков. Quicktime на самом деле представляет собой целую медиа-инфраструктуру, насколько мне известно, он не определяет сам кодек.
- MPEG (1, 2, 3, 4) : стандарты, определенные группой экспертов по кинематографии. Смотрите мой пост выше для деталей.
- WMV : Windows Media Video. На самом деле это кодек, заключенный в контейнер Advanced Systems Format , который снова использует расширение .wmv . Странно, но так оно и есть.
- FFmpeg : Это не кодек и не контейнер. Это библиотека видеоинструментов, которые также позволяют конвертировать различные кодеки и контейнеры. FFmpeg опирается на открытый код libavcodec и libavformat библиотеки для создания кодеков и контейнеров соответственно. Большинство видео инструментов, которые вы найдете сегодня, основаны на нем.
- AVC : синоним для MPEG-4 Part 10 или H.264.
- DivX : еще один тип кодера для видео MPEG-4 Part 2.
- Xvid : один тип кодера для видео MPEG-4 Part 2. Это просто бесплатная версия DivX с открытым исходным кодом, что, конечно, привело к противоречиям.
- H.264 : синоним для MPEG-4 Part 10 или AVC.
На примечании стороны:
Я даже использую правильную терминологию?
Я думаю, что однажды предпочел бы специально использовать «кодек» и «контейнер» вместо «формат», чтобы избежать недоразумений. Формат теоретически может быть любым, потому что кодеки и контейнеры определяют формат (то есть, как должны быть представлены данные).
При этом терминология FFmpeg будет заключаться в использовании «формата» для контейнера. Это также из-за различия между:
После того, как Youtube и Vimeo представили свои тестовые страницы в HTML5, вновь пошла волна разговоров, о том, что же лучше: H.264 или Ogg Theora.
Я, конечно, за свободный веб. Но выводы о том, что Theora превосходит H.264 по качеству, сделанные многими людьми по результатам двух сомнительных сравнений (раз и два) весьма поспешны.
В первом сравнении вообще не представлено ни тестового видео, ни каких-либо настроек кодеков. Во втором сказано, что для H.264-кодека взят заведомо отстойный пресет с Youtube, а настройки Теоры умалчиваются.
Так я решил сам проверить, что есть Ogg Theora и на что этот кодек способен.
Первое, на что я обратил внимание, это список возможностей Ogg Theora. Для сравнения список возможностей H.264
- Минимальный размер блока 8x8 (в H.264 минимальный — 4x4, что позволяет лучше сохранять мелкие детали)
- Отсутствие арифметического кодирования (которое позволяет на халяву наиграть процентов 15)
- Полупиксельная точность компенсации движения (четвертьпиксельная в H.264)
- Отсутствие b-кадров
Для сравнения я решил взять кодек x264. Довольно продвинутый представитель семейства H.264-кодеков с большим количеством настроек и хорошей поддержкой сообщества. С открытыми исходниками, к тому же. По результатам последнего сравнения от MSU Videogroup он занял второе место, совсем немного проиграв лидеру. Итак, в красном углу ринга .
Для декодирования использовал плагин к AviSynth FFmpegSource2 версии 2.12.
Для сравнения взял четыре видеопоследовательности с разрешением по ширине 640 пикселей. Кодировал в два прохода (так намного проще попадать в размер) с битрейтом 500 kbps. Настройки Теоры были выставлены на максимальное качество и наиболее гибкий rate control. Для x264 я взял два пресета: первый — аналогичный возможностям Теоры (полупиксельные сдвиги, нет b-кадров, размер блоков 8x8 и т.д.), второй — обычный такой пресет x264 со всеми включёнными фичами. Качество измерял метриками PSNR и SSIM c помощью MSU Video Quality Measurement Tool.
Время кодирования я не оценивал, так как выравнивать результаты ещё и по времени — большая заморочка. И скорее всего x264 получил бы заметное преимущество в скорости за счёт ассемблерных оптимизаций, так как это более зрелый проект.
Battle
Тут и PSNR Теоре подыграл, и вообще отставание небольшое. Отмечу, что по моему восприятию результата, битрейта не хватило даже обычному пресету x264 — слишком динамичное видео.
Скриншоты пары кадров для сравнения.
Пример, где Теора превосходит x264
Ogg
MP4
также известен как MPEG-4 Part 14 и основан на формате файла QuickTime. Это формат перехода к видео H.264, но он также охватывает HEVC, MPEG-4 Part 2 и MPEG-2.
Этот контейнер может также обернуть только аудио, поэтому вы найдете так много файлов .mp4, которые не являются видео, а представляют собой аудио в кодировке AAC , также в файлах .m4a (просто с другим расширением). Расширение .m4v обычно используется для видеопотоков.
Последовательности
- Battle
Небольшой кусок из второго Терминатора, где постоянно что-то происходит, стреляет, взрывается. Очень динамичное видео. - Football
Небольшой кусок из футбольной трансляции. Типичный use-case, кстати. - Shuttle start
Запуск шаттла, что следует из названия. Статичное видео. - Toys and calendar
Видео с плавным движением и большим количеством мелких деталей.
Для начала графики по метрикам PSNR и SSIM. Вообще, SSIM появилась позже и считается более продвинутой. Также, насколько мне известно, результаты сравнения с использованием SSIM обычно ближе к результатам субъективного сравнения. Но PSNR на всякий случай тоже померял.
Как видим, Theora безнадёжно сливает обычному пресету x264. Относительно пресета x264 с урезанными настройками Теоре тоже можно засчитать поражение. Чуда не произошло.
Теперь немного пройдусь по последовательностям.
VP9 и AV1
VP9 (преемник VP8) - это кодек, в основном разработанный Google. Он открыт и бесплатен, и реализован во многих браузерах . Его качество почти так же хорошо, как HEVC, а иногда даже лучше (см. Эту статью Netflix). VP9 - это то, что вы получаете, когда смотрите YouTube в браузере, который его поддерживает.
VP9 может быть закодирован с помощью кодера libvpx , и он часто поставляется в контейнерах WebM или MKV .
Некоторые компании собрались вместе, чтобы сформировать еще более сильного конкурента HEVC - но в качестве альтернативы без роялти. AV1 будет преемником VP9, и он основан на том, что должно было стать VP10. Он поддерживается Альянсом открытых медиа (основанным Amazon, Cisco, Google, Intel, Microsoft, Mozilla и Netflix). Подробнее об этом читайте здесь .
Libaom кодер может быть использован для создания AV1 битовых потоков, но это все еще является экспериментальной.
До сих пор мы только объясняли необработанный «поток битов», который в основном представляет собой просто необработанные видеоданные. Вы могли бы пойти дальше и посмотреть видео, используя такой сырой битовый поток. Но в большинстве случаев этого просто недостаточно или не практично.
Поэтому вам нужно обернуть видео в контейнер. Есть несколько причин, почему:
- Может быть, вы хотите аудио вместе с видео
- Может быть, вы хотите перейти к определенной части видео (например, «перейти к 1: 32: 20.12»)
- Аудио и видео должны быть идеально синхронизированы
- Возможно, видео потребуется передать по надежной сети и разбить на пакеты до того, как
- Видео может даже передаваться по сети с потерями (например, 3G) и разбиваться на пакеты до того, как
По всем этим причинам были изобретены форматы контейнеров, некоторые простые, некоторые более продвинутые. Все, что они делают, это «оборачивают» поток битов видео в другой поток битов.
Контейнер будет синхронизировать видео и аудио кадры в соответствии с их меткой времени представления (PTS), которая гарантирует, что они отображаются в одно и то же время. Он также позаботится о добавлении информации для потоковых серверов, если необходимо, чтобы потоковый сервер знал, когда отправлять какую часть файла.
Давайте посмотрим на некоторые популярные контейнеры.
Читайте также: