как транслировать видео в реальном времени без задержки (ffplay, mplayer) и какую оболочку можно использовать с ffplay?
Я тестировал воспроизведение нескольких живых потоков с использованием разных игроков, потому что хотел получить наименьшее значение задержки. Я попробовал GStreamer player (gst-launch-0.01), mplayer, totem и ffmpeg player (ffplay). Я использовал разные значения конфигурации, чтобы получить наименьшую задержку для каждого из них, например:
ffplay -fflags nobuffer
mplayer -benchmark
протокол я течь с UDP и я получаю лучшего значения с ffplay, чем mplayer или ГСТ запуска. Честно говоря, я не знаю какой конфигурация мне нужно сделать это gstreamer, чтобы получить более низкую задержку. Теперь мне нужны две вещи:--2-->
Я хотел бы знать, есть ли у кого-то лучшее предложение о потоковой передаче живого потока с меньшей задержкой
Так как я использую ffplay в настоящее время, потому что это лучший до сих пор. Я хотел бы сделать простой графический интерфейс с кнопкой воспроизведения и записи и 3 экранами чтобы транслировать с разных видеосерверов, я просто не знаю, какую обертку (которая должна быть очень быстрой) использовать!
2 ответов
Ну, для очень низкого сценария потоковой передачи с задержкой вы можете попробовать NTSC. Своя латентность может быть под 63us (микросекундами) идеально.
для цифровой потоковой передачи с качеством, приближающимся к NTSC, и бюджетом задержки 40 мс см. ответ rsaxvc на 120hz. Если вам нужно потоковое вещание, это лучший вариант с низкой задержкой, который я видел, и он очень хорошо продуман, и разрешение будет масштабироваться с аппаратными возможностями.
Если вы имеете в виду цифровую потоковую передачу, и вы хотите хорошо коэффициенты сжатия, т. е. 1080p через wifi, тогда вам не повезло, если вы хотите меньше, чем 100 мс задержки с сегодняшним товарным оборудованием, потому что для того, чтобы алгоритм сжатия дал хорошую степень сжатия, ему нужно много контекста. Например, Mpeg 1 использовал 12 кадров в расположении ipbbpbpbbpbbpb GOP (группа изображений), где i - "внутри" кадр, который по-прежнему является jpeg, p-прогнозирующий кадр, который кодирует некоторые движения между I и P кадрами, а B-кадрами кодирует некоторые точечные исправления, где предсказание не очень хорошо работает. В любом случае, даже 12 кадров в 60fps еще 200мс, так что 200мс только для сбора данных, потом какое-то время, чтобы закодировать ее, потом какое-то время, чтобы передать его, потом какое-то время, чтобы расшифровать его, потом некоторое время для буферизации аудио, так что звуковой карты не кончатся данные, а процессор посылает новый блок в DMA область памяти, и в то же время 2-3 кадрах видеозаписи должны быть поставлены в очередь, чтобы отправить видео-дисплей для того, чтобы предотвратить разрыв на цифровом дисплее. Так что на самом деле есть минимум 15 кадров или 250 мс, плюс задержка, возникающая при передаче. NTSC не имеет таких задержек, потому что он передается аналоговым с единственным "сжатием", являющимся двумя хитрыми трюками: переплетение, где только половина каждого кадра передается каждый раз как альтернативные строки, даже на одном кадре, нечетные на следующем, а затем второй трюк-сжатие цветового пространства с использованием 3 черно-белых пикселей плюс его фазовая дискриминация, чтобы определить, какой цвет показано, поэтому цвет передается на 1/3 полосы пропускания сигнала яркости (luma). Круто да? И я думаю, вы могли бы сказать, что звук имеет своего рода "сжатие", а также в том, что автоматическая регулировка усиления может быть использована для создания аналогового аудиосигнала 20dB, чтобы обеспечить ближе к опыту 60dB, взорвав наши уши из наших голов в рекламных роликах из-за того, что AGC поднимает громкость в течение 2-3 секунд тишины между шоу и рекламой. Позже, когда мы получили более высокую точность аудиосхемы, рекламные ролики на самом деле транслировались громче, чем шоу, но это был просто их способ обеспечить такое же влияние, как старые телевизоры дали рекламодателям.
эта прогулка по переулку памяти принесла вам ностальгия (tm). Купите туалетное мыло марки Nostalgia! ;-)
проблема с традиционными медиаплеерами, такими как VLC, ffmpeg и в некоторой степени mplayer, заключается в том, что они будут пытаться играть с последовательной частотой кадров, и это требует некоторой буферизации, которая убивает цель задержки. Альтернативой является рендеринг входящего видео так быстро, как вы можете, и не заботиться ни о чем другом.
@genpfault и я пользовательский протокол UDP, планируется для летающих RC автомобилей и квадроциклов. Это цели с низкой задержкой за счет все остальное(разрешение, битрейт, packetrate, эффективность сжатия). При меньших разрешениях мы заставили его работать над 115200 baud UART и XBEE, но видео под этими ограничениями было не так полезно, как мы надеялись. Сегодня я тестирую конфигурацию 320x240, работающую на ноутбуке (Intel i5-2540M), так как у меня больше нет оригинальной установки.
вам нужно спланировать свой бюджет задержки, вот где я провел свой:
- приобретение-мы выбрали 125FPS PS3 Глазные камеры. Таким образом, наша задержка здесь составляет не более 8 мс. "Умные" камеры, которые делают сжатие на борту (либо h264, либо MJPEG), следует избегать. Кроме того, если у вашей камеры есть какое-либо время автоматической экспозиции, вам нужно отключить его, чтобы заблокировать его в самой быстрой частоте кадров или обеспечить достаточное освещение(сегодня моя встроенная веб-камера делает только 8 кадров в секунду из-за AE).
- преобразование-если возможно, камера излучает кадры в формате, который вы можете сжать напрямую(обычно формат YUV, который Глаз поддерживает изначально). Тогда вы можете пропустить этот шаг, но я провожу здесь 0,1 мс.
- кодировка - мы использовали специально настроенный H. 264. Он занимает ~2,5 мс и не требует буферизации будущих кадров за счет коэффициента сжатия.
- транспорт - мы использовали UDP через WiFi,
- декодирование-это в значительной степени ограничено процессором приемника. Кодировщик может помочь, отправив работу, которая многопоточный декодируемый. Это обычно быстрее, чем кодирование. ~1,5 МС сегодня.
- преобразование-ваш декодер может сделать этот шаг для вас, но обычно кодеры/декодеры говорят YUV, а дисплеи говорят RGB, и кто-то должен конвертировать между ними. 0.1 mS на моем ноутбуке.
- дисплей-без VSYNC, монитор 60 FPS имеет задержку до ~17mS, плюс некоторая задержка LCD, возможно 6ms? Это действительно зависит от дисплея и я не уверен, что панель этого ноутбука имеет.
итого получается: 40,2 МС.
кодировка:
в то время X264 был лучшим кодировщиком H264-AnnexB, который мы могли найти. Мы должны были контролировать битрейт, slice-max-size, vbv-bufsize, vbv-maxrate. Начните с значений по умолчанию для "superfast" и "zerolatency", которые отключат B-фреймы.
кроме того, внутрикадровое обновление является обязательным! Эффектно это позволяет прерывать вверх нормальную рамку " я " и смешивать ее вверх с следующий P-кадров. Без этого у вас будут "пузыри" в требовании битрейта, которые временно забьют ваш транспорт, увеличивая задержку.
Кодирование-Транспорт-Планирование:
кодировщик был настроен для генерации UDP-размера H264 NALUs. Таким образом, когда UDP-пакет был отброшен, был отброшен весь NALU H264, и нам не нужно было повторно синхронизировать, декодер просто своего рода...рыгавший...и продолжил с некоторыми графическими коррупция.
окончательные результаты 320x240
Это...быстрее, чем я могу надежно измерить с помощью мобильного телефона, направленного на камеру, направленную на мой ноутбук. Коэффициент сжатия 320x240x2B = 150kB / frame, сжатый до чуть более 3kB / frame.