что такое quick sync h 264

Трансляция h264 видео без перекодирования и задержки

Не секрет, что при управлении летательными аппаратами часто используется передача видео с самого аппарата на землю. Обычно такую возможность предоставляют производители самих БПЛА. Однако что же делать, если дрон собран своими руками?

Перед нами и нашими швейцарскими партнёрами из компании Helvetis встала задача транслировать видео в режиме реального времени с web-камеры с маломощного embedded-устройства на дроне по WiFi на Windows-планшет. В идеале бы нам хотелось:

Этот подход оказался (почти) работающим. В качестве приложения для просмотра можно было использовать любой web-браузер. Однако мы сразу заметили, что частота кадров была ниже ожидаемой, а уровень загрузки CPU на Minnowboard был постоянно на уровне 100%. Embedded-устройство просто не справлялось с кодированием кадров в режиме реального времени. Из плюсов данного решения стоит отметить очень небольшую задержку при передаче 480p видео с частотой не более 10 кадров в секунду.

В ходе обыска была обнаружена web-камера, которая помимо несжатых YUV-кадров могла выдавать кадры в формате MJPEG. Было решено воспользоваться такой полезной функцией, чтобы уменьшить нагрузку на CPU и найти способ передать видео без перекодирования.

FFmpeg / VLC

Первым делом мы попробовали всеми любимый open-source комбайн ffmpeg, позволяющий, среди прочего, считывать видео-поток с UVC-устройства, кодировать его и передавать. После небольшого погружения в мануал были найдены ключи командной строки, которые позволяли получить и передать сжатый MJPEG видеопоток без перекодирования.

Уровень загрузки CPU был невысок. Обрадовавшись, мы с нетерпением открыли поток в плеере ffplay… К нашему разочарованию, уровень задержки видео был абсолютно неприемлемым (около 2 — 3 секунд). Попробовав все отсюда и прошерстив Интернет, мы так и не смогли добиться положительного результата и решили отказаться от ffmpeg.

После провала с ffmpeg пришла очередь медиаплеера VLC, а точнее консольной утилиты cvlc. VLC по умолчанию использует кучу всяких буферов, которые с одной стороны помогают добиться плавности изображения, но с другой дают серьезную задержку в несколько секунд. Изрядно помучавшись, мы подобрали параметры, с которыми стриминг выглядел достаточно сносно, т.е. задержка была не очень большой (около 0.5 с), не было перекодирования, и клиент показывал видео достаточно плавно (пришлось, правда, на клиенте оставить небольшой буфер в 150 мс).

Так выглядит итоговая строка для cvlc:

К сожалению, видео работало не вполне стабильно, да и задержка в 0.5 с была для нас неприемлема.

Mjpg-streamer

Наткнувшись на статью о практически нашей задаче, решили попробовать mjpg-streamer. Попробовали, понравилось! Абсолютно без изменений получилось использовать mjpg-streamer для наших нужд без существенной задержки видео на разрешении 480p.

На фоне предыдущих неудач мы довольно долго были счастливы, но потом мы захотели большего. А именно: чуть меньше забивать канал и повысить качество видео до 720p.

H264 стриминг

Чтобы уменьшить загрузку канала, мы решили поменять используемый кодек на h264 (найдя в наших запасах подходящую web-камеру). Mjpg-streamer не имел поддержки h264, так что было решено его доработать. Во время разработки мы использовали две камеры со встроенным кодеком h264, производства Logitech и ELP. Как оказалось, содержимое потока h264 у этих камер существенно различалось.

Камеры и структура потока

Поток h264 состоит из пакетов NAL (network abstraction layer) нескольких типов. Наши камеры генерировали 5 типов пакетов:

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

Помимо IDR-кадра, декодеру нужны пакеты PPS и SPS для декодирования изображения. Эти пакеты содержат метаданные об изображении и потоке кадров.

Основываясь на коде mjpg-streamer, мы воспользовались API V4L2 (video4linux2) для считывания данных от камер. Как выяснилось, один “кадр” видео содержал несколько NAL пакетов.

Именно в содержимом “кадров” обнаружилось существенное различие между камерами. Мы воспользовались библиотекой h264bitstream для парсинга потока. Существуют standalone-утилиты, позволяющие просмотреть содержимое потока.

Поток кадров камеры Logitech состоял в основном из non-IDR кадров, к тому же разделенных на несколько data partition. Раз в 30 секунд камера генерировала пакет, содержащий IDR picture, SPS и PPS. Так как декодеру нужен IDR пакет для того, чтобы начать декодировать видео, нас эта ситуация сразу не устроила. К нашему сожалению, оказалось, что нет адекватного способа установить период, с которым камера генерирует IDR пакеты. Поэтому нам пришлось отказаться от использования этой камеры.

Камера производства ELP оказалась существенно удобнее. Каждый получаемый нами кадр содержал в себе пакеты PPS и SPS. К тому же, камера генерировала IDR пакет раз в 30 кадров (период

1с). Это нас вполне устраивало и мы остановили свой выбор на этой камере.

Реализация сервера вещания на основе mjpg-streamer

За основу серверной части решено было взять вышеупомянутый mjpg-streamer. Его архитектура позволяла легко добавлять новые плагины ввода и вывода. Мы начали с добавления плагина для считывания потока h264 с устройства. В качестве плагина вывода выбрали уже имеющийся плагин http.

В V4L2 достаточно было указать что мы хотим получать кадры в формате V4L2_PIX_FMT_H264, чтобы начать получать поток h264.Так как для декодирования потока необходим IDR-кадр, мы парсили поток и ожидали IDR-кадр. Приложению-клиенту поток отправлялся по HTTP начиная с этого кадра.

На клиентской части решили воспользоваться libavformat и libavcodec из проекта ffmpeg для чтения и декодирования потока h264. В первом тестовом прототипе получение потока по сети, разбиение его на кадры и декодирование было возложено на ffmpeg, конвертирование получаемого декодированного изображения из формата NV12 в RGB и отображение было реализовано на OpenCV.

Первые тесты показали, что данный способ транслирования видео работоспособен, но имеется существенная задержка (около 1 секунды). Наше подозрение пало на протокол http, поэтому было решено использовать для передачи пакетов UDP.

Так как у нас не было необходимости поддержки существующих протоколов вроде RTP, мы реализовали свой простейший велосипед протокол, в котором внутри UDP-датаграмм передавались NAL-пакеты потока h264. После небольшой доработки принимающей части мы были приятно удивлены малой задержкой видео на настольном ПК. Однако первые же тесты на мобильном устройстве показали, что программное декодирование h264 — не конёк мобильных процессоров. Планшет просто не успевал обрабатывать кадры в режиме реального времени.

Так как процессор Atom Z3740, используемый на нашем планшете, поддерживает технологию Quick Sync Video (QSV), мы попробовали использовать QSV h264 декодер из libavcodec. К нашему удивлению, он не только не улучшил ситуацию, но и увеличил задержку до 1.5 секунд даже на мощном настольном ПК! Однако этот подход действительно существенно снизил нагрузку на CPU.

Перепробовав различные варианты конфигурации декодера в ffmpeg, было решено отказаться от libavcodec и использовать Intel Media SDK напрямую.

Первым сюрпризом для нас стал ужас, в который предлагается погрузиться человеку, решившему разрабатывать используя Media SDK. Официальный пример, предлагаемый разработчикам, представляет из себя мощный комбайн, который умеет всё, но в котором трудно разобраться. К счастью, на форумах Intel мы нашли единомышленников, также недовольных примером. Они нашли старые, но более легкоусвояемые туториалы. На основе пример simple_2_decode мы получили следующий код.

После реализации декодирования видео при помощи Media SDK мы столкнулись с аналогичной ситуацией — задержка видео составила 1.5 секунды. Отчаявшись, мы обратились к форумам и нашли советы, которые должны были снизить задержку при декодировании видео.

Декодер h264 из состава Media SDK накапливает кадры прежде чем выдавать декодированное изображение. Было обнаружено, что если в структуре данных, передаваемых в декодер (mfxBitstream), установить флаг “конец потока”, то задержка снижается до

Далее экспериментальным путем было обнаружено, что декодер держит 5 кадров в очереди, даже если установлен флаг окончания потока. В итоге нам пришлось добавить код, который симулировал “окончательное окончание потока” и заставлял декодер выдавать кадры из этой очереди:

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

Выводы

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

Нашей главной надеждой были такие гиганты работы с видео, как FFmpeg и VLC. Несмотря на то, что вроде бы они умеют делать то, что нам надо (передавать видео без перекодирования), нам не удалось убрать получающуюся при передаче видео задержку.

Практически случайно наткнувшись на проект mjpg-streamer, мы были очарованы его простотой и четкой работой в деле трансляции видео в формате MJPG. Если вам вдруг понадобится передавать именно этот формат, то мы категорически рекомендуем его использовать. Неслучайно, что именно на его основе мы и реализовали свое решение.

В результате разработки мы получили достаточно легковесное решение для передачи видео без задержки, не требовательное к ресурсам ни передающей, ни принимающей стороны. В задаче декодирования видео нам сильно помогла библиотека Intel Media SDK, пусть и пришлось применить немного силы, чтобы заставить отдавать ее кадры без буферизации.

Источник

АУДИО И ВИДЕО

Сжатие видео и декодирование: чем и на чём лучше

Сжатие видео и декодирование | Транскодирование Blu-ray

Мы выяснили, что есть чёткие различия между аппаратно-ускоренными декорами и даже между программным декодированием. А что же со сжатием видео? Чтобы ответить на этот вопрос, мы начинаем следующий этап тестирования.

Мы использовали лучшие карты, которые можно купить – AMD Radeon HD 6970 и nVidia GeForce GTX 580.

Когда речь заходит о транскодировании видео, MediaEspresso – единственная программа, которая смогла обработать Iron Man на Blu-ray размером 31.2 Гбайт. При работе MediaConverter 7 и Badaboom мы столкнулись с ошибками аудио-кодека, поскольку никакое ПО не распознаёт TrueHD. Важно отметить, что если вы используете Quick Sync, то вам придётся выбрать установку Performance или Quality. Это недоступно, если вы работаете с картами nVidia или AMD.

Как показывают результаты наших тестов, самое узкое место возникает на стадии декодирования. Если вы используете кодирование АРР или CUDA, то получаете небольшой выигрыш (больше для CUDA), но самый большой выигрыш получается, если вы включаете аппаратно-ускоренное декодирование. Использование кодирования АРР и UVD 3 на карте Radeon – худшее, что вы можете сделать для производительности. Любая другая комбинация – быстрее, включая использование только программного кодирования. С помощью CUDA вы получаете мизерный выигрыш в 4 секунды с включёнными аппаратными возможностями (по сравнению только с PureVideo).

Оборудование Intel Quick Sync демонстрирует более впечатляющие показатели. А при настройках «Quality» используется не такое агрессивное масштабирование. То, что мы видим – это эффект более низкого битрейта при использовании программного кодирования.

AMD Radeon HD 6970

nVidia GeForce GTX 580

Intel HD Graphics 3000 (Core i5-2500K)

Хотя клип H.264/AC3 BDAV на 665 Мбайт имеет такой же битрейт, что и фильм на 31.2 Гбайт, видно, что аппаратно-ускоренное декодирование даёт гораздо лучшие результаты на Radeon HD 6970 и GeForce GTX 580. Core i5-2500K с технологией Intel Quick Sync даёт существенный прирост только с настойками «Quality» и аппаратным ускорением кодирования.

Отметим, что ArcSoft MediaConverter использует либо аппаратное либо программное транскодирование. Он не обеспечивает гибкого управления, которое предоставляет CyberLink. Но с ним транскодирование идёт гораздо быстрее. Если перейти к цифрам, то оказывается, что MediaConverter лучше оптимизирован для многопоточности. Речь идёт о преимуществе более чем минута по сравнению с MediaEspresso.

На примере небольшого клипа видно, что AMD APP работает быстрее, чем чисто программное решение, но не намного. К сожалению, использование АРР в MediaConverter всё же медленнее, чем работа только на процессоре. Как это ни удивительно, но лучшие результаты получаются с более старым компьютером и более медленным процессором, но с современной графической картой. Новый Core i5-2500K – просто слишком быстр.

В итоге – Quick Sync заметно превосходит CUDA и АРР по производительности кодирования и декодирования. Различия между AMD и nVidia менее очевидны, их сложно вывести из плученных результатов. Может быть причина в использовании файлов Blu-ray с высоким битрейтом?

Сжатие видео и декодирование | Скорость транскодирования небольших клипов

Мы загрузили три клипа с разрешением 1080р (контейнер Н.264/MOV) из набора трейлеров с сайта Apple, чтобы использовать клипы с битрейтом, более пригодным для хранения (около 9.5 Мбит/c), с которыми мы сталкиваемся ежедневно. Поскольку мы более заинтересованы в работе GPU, будем использовать только аппаратное кодирование, когда есть такая возможность.

Когда речь заходит о более мелких файлах и меньших битрейтах, то использование только CPU всегда оказывается более медленным, чем использование GPGPU или аппаратное кодирование с использованием Quick Sync.

Единственное исключение здесь – это AMD в MediaConverter. По какой-то причине мы получаем большее время транскодирования, когда выбираем декодирование на базе UVD3 и АРР-кодирование. К сожалению, MediaConverter не позволяет раздельно устанавливать эти параметры, поэтому мы не можем узнать, какая часть конвейера замедляет весь процесс. Мы уведомили компании AMD и Arcsoft о ситуации и они ответили, что работают над разрешением проблемы. Этой аномалии нет в работе CyberLink MediaEspresso.

Сжатие видео и декодирование | Качество транскодирования

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

Прежде всего, хочется поблагодарить компанию Elemental Technologies за разрешение первого тестирования Badaboom 2.0. Компания пока находится на начальной стадии развития, поэтому всё это – предварительные результаты. Но мы решили включить эту предварительную версию в наш тест, поскольку именно её настоятельно рекомендует компания nVidia после обсуждения наших тестов Brazos. Поэтому несмотря на ранний этап своего развития именно этот продукт может ответить на наши вопросы, связанные с качеством. Но поскольку мы работаем с бета-версией, не будем представлять результаты тестов.

AMD APP

Транскодированное видео от Radeon HD 6970 выглядит заметно лучше в MediaEspresso, чем в MediaConverter. Все, что выходит из MediaConverter, выглядит, как прошедшее через некоторый фильтр. Как будто вы смотрите на изображение через эффект миража. Вся картинка немного мерцает.

Nvidia CUDA

Здесь две аномалии. Вы наверняка заметили, что лампочка на ошейнике Дуга ярче в MediaConverter, а в Badaboom этого кадра нет (там просто другое изображение). Обе программы генерируют файл, которые не совпадают друг с другом, это значит, что где-то происходит смещение. И это не результат человеческой ошибки, поскольку мы используем обработку конкретных фреймов в режиме off-line. Есть нечто специфическое в использовании CUDA в MediaConverter и Badaboom. Учитывая, что Elemental находится в стадии разработки, вполне можно ожидать некоторых ошибок и проблем, связанных с энтропией, которые влияют на процесс сборки, но их несложно устранить. Проблема с MediaConverter более серьёзна, поскольку мы используем общедоступную версию для использовании CUDA (по непонятным причинам последняя бета-версия не распознаёт GeForce GTX 580).

Забыв о проблемах «трекинга», посмотрим на низкое качество результата после MediaEspresso. Оно проявляется в сценах с панорамированием или когда есть плавный переход в следующую сцену. CUDA выглядит лучше при работе с MediaConverter, чем с MediaEspresso, но лучше всего выглядит результат после Badaboom. Это говорит о том, что есть какие-то проблемы с использованием CUDA в двух первых приложениях. Стоит отметить и то, что видео после Badaboom и MediaConverter демонстрируют небольшие проблемы при предсказывании движений, которых нет в MediaEspresso.

Intel Quick Sync

Результат работы MediaEspresso – лучший из всех трёх тестируемых программ. Конечно трудно выбрать лучшее среди столь одинаковых изображений, но этому можно только радоваться. Если забыть о проблемах с «трекингом», результат у Badaboom чуть более зернистый, чем три остальных. Даже установки параметров «Performance» и «Quality» для MediaEspresso демонстрируют меньше отличий, чем можно было предположить. Без сомнения, результат от установок Quality использует больший размер файла, но различие можно будет заметить только в областях активного движения или с маленькими деталями (волосы, к примеру).

Сжатие и декодирования основным процессором

Из всех вариантов лучший результат демонстрирует программное транскодирование. Нет никаких проблем с ошибками «треккинга». Все детали выглядят прекрасно, независимо от того, сколько раз вы транскодируете файл.

Что лучше аппаратно ускоряет сжатие видео? Не такой простой вопрос, если копнуть глубже. В этом обзоре мы расскажем о сжатии видео и его декодировании при помощи Intel Quick Sync, nVidia CUDA и AMD APP, сравним различные кодеки и декодеры друг с другом, поговорим о качестве, производительности, ресурсах. В одном из предыдущих обзоров мы писали, что при сжатии видео качество на выходе было одинаковым для Intel и AMD, а результат при использованиии nVidia CUDA сильно от них отличался. Настало время разобраться в нюансах.

РЕКОМЕНДУЕМ ПРОЧЕСТЬ!

История мейнфреймов: от Harvard Mark I до System z10 EC Верите вы или нет, но были времена, когда компьютеры занимали целые комнаты. Сегодня вы работаете за небольшим персональным компьютером, но когда-то о таком можно было только мечтать. Предлагаем окунуться в историю и познакомиться с самыми знаковыми мейнфреймами за последние десятилетия. Источник ← На уроке учительница спросила что означает масштаб Вам также понравится что случилось с касымом сыном кесем 13.08.202313.08.2023 admin 0 Гастрофлат таблетки для чего 21.07.202220.07.2022 admin 0 чему учит сказка чемодан чепухи 09.10.202310.10.2023 admin 0 Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Сохранить моё имя, email и адрес сайта в этом браузере для последующих моих комментариев.