H 264 linux embedded

BlackIkeEagle / h264-vivaldi-linux.md

How to use H.264 support In Vivaldi, via an alternative FFMpeg library

The following is a quick guide to get tthis working on various Linux distros. As a side note, if you have Chrome installed alongside Vivaldi, Netflix should also work after making these changes.

You will now need to restart Vivaldi. You can then test support on this page.

Install vivaldi-snapshot from AUR

Install vivaldi-ffmpeg-codecs from AUR

Install from unofficial repo

You can also install both packages from the [herecura] repo.

Test if all media is supported

If your distro does not provide a package with a suitable lib, you can probably use the one from Ubuntu.

Fetch a package

Extract the lib from the package

Note: ar is from the GNU binutils package.

Installing in the Vivaldi directory

Issue the following as root (or prefaced with sudo ):

You will now need to restart Vivaldi. You can then test support on this page.

Building your own replacement libffmpeg.so

If you don’t want to use the file in the package provided by Ubuntu, you can compile your own.

Installing build dependencies

Ubuntu, Debian & Mint

• autoconf
• automake
• gcc
• gcc-c++
• libtool
• make
• nasm (or yasm)
• pkg-config
• the zlib development support files

Fetch and unpack the appropriate Chromium source archive

Fetch and configure Depot Tools

Note: On systems that don’t use PulseAudio (e.g. Slackware), you should also include the define -Duse_pulseaudio=0 .

Copy the lib into your Vivaldi install

Issue the following as root or prefaced with the sudo command:

You will now need to restart Vivaldi. You can then test support on this page.

Tips for package maintaners

If you repackage Vivaldi browser for your distro, you might want to consider making a vivaldi-snapshot-ffmpeg-codecs package containing a replacement ffmpeg library. It is suggested that you place this library in the directory /opt/vivaldi-snapshot/alt_ffmpeg .

To ensure that Vivaldi detects and prefers the replacement libffmpeg.so stored there, apply the following patch to the Vivaldi startup script ( /opt/vivaldi-snapshot/vivaldi-snapshot ):

This comment has been minimized.

Copy link Quote reply

Kabouik commented Dec 11, 2016 •

Thanks for the thorough guide. On Solus 1.2.1, I have had to use a different path to make it work so it may be worth reporting it.

I fetched the following package:
wget http://security.ubuntu.com/ubuntu/pool/universe/c/chromium-browser/chromium-codecs-ffmpeg-extra_45.0.2454.101-0ubuntu0.14.04.1.1099_amd64.deb

Extracted the lib from the package:
ar p chromium-codecs-ffmpeg-extra_53.0.2785.143-0ubuntu0.16.04.1.1257_amd64.deb data.tar.xz | tar xJf — ./usr/lib/chromium-browser/libs/libffmpeg.so —strip 5

Installed it in the Vivaldi directory (differs from what is written in the original how-to):
sudo install libffmpeg.so /usr/share/vivaldi-snapshot/lib/libffmpeg.so

Seems to work correctly now.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Как установить декодер h.264?

Вы можете просто использовать приложение запуска Ubuntu для запуска Kodi как автономного. В поле имени введите имя запуска, например Kodi. В поле команды поставьте «-d 5 —стандарт -fs». Чтобы выйти из Kodi в Ubuntu Desktop, нажмите на значок выхода в Kodi в левом нижнем углу главного экрана Kodi.

7 ответов

Для воспроизведения кодированных видео h.264 соответствующий декодер поставляется со следующей библиотекой:

Я думаю, что это часть пакета gstreamer-plugins-bad. Если вы ищете это в Software Center, он должен появиться. Возможно, вам нужно активировать репозиторий multiverse (запустите Software & amp; Sources и отметьте соответствующее поле для этого).

После того, как вы установили пакет, Movie Player должен иметь возможность воспроизводить файл.

Установка gstreamer0.10-ffmpeg из PPA, как описано ниже, разрешила это для меня.

У меня была такая же проблема с воспроизведением видео. Видеопроигрыватель хотел скачать декодер mpeg-4 acc и декодер h.264, но этого не произошло по юридическим причинам (если я правильно понял, что было написано в окне, что появляется после того, как компьютер пытался загрузить упомянутые программы).

После того, как я отключил Software & amp; обновления -> Программное обеспечение Ubuntu -> «unclick». Программное обеспечение, ограниченное авторскими или юридическими вопросами (multiverse), все снова начинает работать. (Я имею в виду, что после этой операции pc загружает то, что ему нужно, и что он начал работать).

Источник

Быстрое кодирование видео в Linux c Nvidia NVENC с SDK 7.5 и ffmpeg 3.0.2 на Nvidia GTX 960/970/980

Данная статья была написана по мотивам статьи Эффективное кодирование видео в Linux c Nvidia NVENC: часть 1, общая, однако имеет свои особенности и в отличие от оригинальной статьи, на момент написания которой не было выпущено патча, о котором пойдет речь дальше, я применил переработанный патч Nvidia Acceleration к FFmpeg 3.0.2, получив помимо энкодера nvenc еще и быстрый фильтр ресайза — nvresize.

В итого я получил возможность аппаратно кодировать видео в H.264 и HEVC при помощи видеокарты Nvidia GTX 960 на достаточно слабом компьютере (Xeon L5420) со скоростью (для H.264), превышающей возможности данного процессора до 10 раз (и в 3 раза относительно Core i7)! Причем на моем любимом Debian 8 Jessie.

Технология

Nvidia NVENC это технология, обеспечивающая кодирование видео в H.264 и HEVC на вычислительных мощностях GPU. Важное замечание: сколь-нибудь качественное и быстрое кодирование на момент написания статьи (май 2016) могут обеспечить только карты второго поколения Maxwell, и для десктопных это: GM206 (GTX 950, GTX 960), GM204 (GTX 970 и GTX 980) (для справки: есть еще дорогие проф.линейки Nvidia Tesla/Quadro/GRID, полный перечень можно найти здесь). Причем NVENC модуль работает с одинаковой скоростью на всех картах и количество CUDA ядер не влияет на производительность, как бы странно это не звучало, поэтому брать старшие версии имеет смысл только если платформа используется (помимо кодирования) для игр, даже более того, карты на GM206 целесообразнее т.к. помимо энкодера, получили еще и аппаратный HEVC декодер. Важное примечание: вся линейка GeForce имеет лицензионное ограничение в 2 одновременных потока. Его можно попробовать обойти методом, указанным во второй части статьи YourChief

Реализация (FFmpeg)

Все многообразие реализаций Nvidia CUDA можно посмотреть по ссылке. От себя хочу сказать что для видео наиболее распространенным является популярный инструмент — FFmpeg. Его мы и будем использовать.

Аппаратное обеспечение

0.7 Гб.

Видеокарта: любая видеокарта Nvidia 900 Series (Рекомендую GM206: GTX 950, GTX 960 или GM204: GTX 970, GTX 980). 2 Гб или 4 Гб, геймерская или нет — не важно! Главное, следите за габаритами и учтите что у всех моделей GTX 960 что я видел, дополнительное питание подключается сверху.

БП ATX с доп.коннектором питания (6 пин для нашей задачи хватит). Рекомендую мощность не менее 400 Вт.

Источник

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

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

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

задержку Http mjpg стриминг на python

Этот подход оказался (почти) работающим. В качестве приложения для просмотра можно было использовать любой 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 типов пакетов:

• Picture parameter set (PPS)
• Sequence parameter set (SPS)
• Coded slice layer without partitioning, IDR picture
• Coded slice layer without partitioning, non-IDR picture
• Coded slice data partition

IDR (Instantaneous decoding refresh) — пакет, содержащий кодированное изображение. При этом все необходимые данные для декодирования изображения находятся в этом пакете. Этот пакет необходим декодеру, чтобы начать формировать изображение. Обычно первый кадр любого видео сжатого h264 — IDR picture.

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, пусть и пришлось применить немного силы, чтобы заставить отдавать ее кадры без буферизации.

Источник