Как транслировать живое видео без задержки (ffplay, mplayer) и какую обертку можно использовать с ffplay?
Я тестировал проигрывание нескольких потоков в реальном времени с использованием разных проигрывателей, потому что хотел получить минимальное значение задержки. Я попробовал gstreamer player (gst-launch-0.01), mplayer, totem и ffmpeg player (ffplay). Я использовал разные значения конфигурации, чтобы получить минимальную задержку для каждого из них, например:
ffplay -fflags nobuffer
mplayer -benchmark
Протокол, с которым я транслирую, это udp, и я получаю лучшие значения с ffplay, чем с mplayer или gst-launch. Если честно, я не знаю, какую конфигурацию мне нужно сделать, чтобы gstreamer получил меньшую задержку. Теперь, что мне нужно, это две вещи:
Я хотел бы знать, есть ли у кого-то лучшее предложение о потоковой трансляции с более низкой задержкой < 100 мс. Сейчас я превышаю 100 мс, что не очень эффективно для меня.
Так как я сейчас использую ffplay, потому что он пока лучший. Я хотел бы сделать простой графический интерфейс с кнопкой воспроизведения и записи и 3 экранами для потоковой передачи с разных видеосерверов, я просто не знаю, какую оболочку (которая должна быть очень быстрой) использовать!
2 ответа
Ну, для действительно потокового сценария с низкой задержкой, вы можете попробовать NTSC. Его задержка в идеале может быть ниже 63 мкс (микросекунд).
Цифровую потоковую передачу с качеством, близким к NTSC, и бюджетом задержки 40 мс смотрите в ответе rsaxvc на частоте 120 Гц. Если вам нужна потоковая передача через эфир, это лучший вариант с низкой задержкой, который я когда-либо видел, и он очень хорошо продуман, а разрешение будет масштабироваться с учетом аппаратных возможностей.
Если вы имеете в виду цифровую потоковую передачу и вам нужны хорошие коэффициенты сжатия, то есть 1080p по Wi-Fi, то вам не повезет, если вы захотите с задержкой менее 100 мс на современном аппаратном оборудовании, потому что для того, чтобы алгоритм сжатия давал хорошую степень сжатия, это требует много контекста. Например, Mpeg 1 использовал 12 кадров в компоновке ipbbpbbpbbpb GOP (группа изображений), где i - это "внутренний" кадр, который фактически является неподвижным jpeg, ap - это прогнозирующий кадр, который кодирует некоторые движения между i и p-кадрами, и b-кадры закодировать некоторые точечные исправления, где предсказание не сработало. В любом случае, 12 кадров даже при 60 кадрах в секунду - это все еще 200 мс, так что это 200 мс только для захвата данных, затем некоторое время для их кодирования, затем некоторое время для передачи, затем некоторое время для декодирования, затем некоторое время для буферизации аудио, чтобы Звуковая карта не исчерпывает данные, пока ЦП отправляет новый блок в область памяти DMA, и в то же время необходимо поставить в очередь 2-3 кадра видео для отправки на видеодисплей, чтобы предотвратить разрыв цифровой дисплей. Так что на самом деле есть минимум 15 кадров или 250 мс плюс задержка при передаче. NTSC не имеет таких задержек, потому что он передает аналоговый сигнал с единственным "сжатием", представляющим собой два хитрых трюка: чередование, при котором только половина каждого кадра передается каждый раз в виде чередующихся строк, даже в одном кадре, нечетная в следующем, и затем Второй трюк - это сжатие цветового пространства с использованием 3 черно-белых пикселей и его фазовой дискриминации, чтобы определить, какой цвет отображается, поэтому цвет передается с 1/3 ширины полосы сигнала яркости (яркости). Круто, а? И я думаю, вы могли бы сказать, что звук имеет своего рода "сжатие", в том смысле, что автоматическая регулировка усиления может быть использована для того, чтобы аналоговый аудиосигнал на 20 дБ казался ближе к уровню 60 дБ, вырывая наши уши из головы на реклама из-за того, что AGC увеличивает громкость в течение 2-3 секунд молчания между шоу и рекламой. Позже, когда мы получили более качественные аудиоканалы, рекламные ролики транслировались громче, чем шоу, но это был лишь их способ оказать такое же влияние, какое давали рекламодателям старые телевизоры.
Эта прогулка по аллее памяти, принесенная вам Ностальгией (тм). Купить туалетное мыло марки Nostalgia!;-)
Проблема с традиционными медиа-плеерами, такими как VLC, ffmpeg и, в некоторой степени, mplayer, заключается в том, что они будут пытаться играть с постоянной частотой кадров, а для этого требуется некоторая буферизация, которая убивает цель задержки. Альтернатива - рендерить входящее видео так быстро, как только можете, и больше ни о чем не заботиться.
genpfault разработали собственный протокол UDP, предназначенный для полетов на автомобилях и квадроциклах. Он нацелен на низкую задержку за счет почти всего остального (разрешение, битрейт, скорость передачи пакетов, эффективность сжатия). При меньших разрешениях он работал на скорости 115200 бод UART и XBEE, но видео с такими ограничениями оказалось не таким полезным, как мы надеялись. Сегодня я тестирую в конфигурации 320x240, работающей на ноутбуке (Intel i5-2540M), поскольку у меня больше нет оригинальной настройки.
Вам нужно спланировать свой бюджет задержек, вот где я потратил свой:
- Приобретение - Мы выбрали 125FPS PS3 Eye камеры. Таким образом, наша задержка здесь составляет не более 8 мс. Следует избегать "более умных" камер, которые выполняют сжатие на борту (h264 или MJPEG). Кроме того, если ваша камера имеет какой-либо режим автоматической экспозиции, вам нужно отключить ее, чтобы зафиксировать ее на самой быстрой частоте кадров или обеспечить достаточное освещение (сегодня моя встроенная веб-камера делает только 8 кадров в секунду из-за AE).
- Преобразование - если возможно, пусть камера излучает кадры в формате, который вы можете сжать напрямую (обычно это формат YUV, который Eye поддерживает изначально). Тогда вы можете пропустить этот шаг, но я трачу 0,1 мс здесь.
- Кодирование - мы использовали специально настроенный H.264. Это занимает ~2,5 мсек и не требует буферизации будущих кадров за счет степени сжатия.
- Транспорт - Мы использовали UDP по WiFi, <5 мс при правильной работе без вмешательства других радиостанций.
- Декодирование - это в значительной степени ограничено процессором приемника. Кодировщик может помочь, отправив работу с многопоточным декодированием. Обычно это быстрее, чем кодировать. ~1,5 мс сегодня.
- Преобразование - Ваш декодер может сделать этот шаг за вас, но обычно кодеры / декодеры говорят на YUV, и отображает на RGB, и кто-то должен конвертировать между ними. 0,1 мс на моем ноутбуке.
- Дисплей - без VSYNC у монитора 60 FPS задержка до ~17 мс, плюс задержка ЖК-дисплея, может быть, 6 мс? Это действительно зависит от дисплея, и я не уверен, какая панель у этого ноутбука.
Общее количество составляет: 40,2 мс.
Кодирование:
В то время X264 был лучшим кодером H264-AnnexB, который мы могли найти. Нам пришлось контролировать битрейт, slice-max-size, vbv-bufsize, vbv-maxrate. Начните со значений по умолчанию "superfast" и "zerolatency", которые будут отключать B-кадры.
Кроме того, внутрикадровое обновление является обязательным! Фактически это позволяет разделить нормальный "I" кадр и смешать его со следующими P-кадрами. Без этого у вас будут "пузыри" в битрейте, которые будут временно забивать ваш транспорт, увеличивая задержку.
Кодирование-Transport-планирование:
Кодировщик был настроен на генерацию NALU H264 размера UDP. Таким образом, когда пакет UDP был отброшен, весь NALU H264 был отброшен, и нам не нужно было выполнять повторную синхронизацию, декодер просто отрыгивал... и продолжал с некоторым графическим искажением.
Окончательные результаты 320х240
Это... быстрее, чем я могу надежно измерить с помощью мобильного телефона, направленного на камеру, направленную на мой ноутбук. Коэффициент сжатия 320x240x2B = 150 КБ / кадр, сжатый до чуть более 3 КБ / кадр.