Как передавать потоковое аудио и видео, сохраняя при этом низкую задержку - PullRequest
1 голос
/ 07 июля 2011

Я пишу программу, похожую на StreamMyGame, с той разницей, что клиент свободен и, что более важно, с открытым исходным кодом, поэтому я могу портировать его на другие устройства (в моем случае OpenPandora) или даже сделать html5 или flash клиент.

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

Прямо сейчас я могу записывать видео игр Direct 3D 9 с фиксированной частотой кадров, кодировать его с помощью libx264 и выгружать его на диск, а также отправлять входные данные удаленно, но я озадачен отправкой видео и, в конечном счете, аудио через сеть.

Я не хочу реализовывать способ только для того, чтобы обнаружить, что он вводит несколько секунд задержки, и мне все равно, как это делается, пока это делается.

От головы я могу думать несколькими способами:

  • Мой нынешний способ - кодировать видео с помощью libx264 и аудио с lame или ac3 и отправлять их с live555 в виде канала RTSP, хотя библиотека не очень хорошо работает с MSVC, и я все еще пытаюсь понять ее функционирование .

  • Пусть библиотека ffmpeg выполнит всю грубую работу, где она кодирует и отправляет (я думаю, мне придется использовать ffserver, чтобы получить представление о том, как это сделать)

  • То же самое, но с использованием libvlc, возможно, это ухудшает конфигурируемость кодирования в процессе.

  • Использование нескольких каналов с независимыми программами (например, передача данных в x264.exe или ffmpeg.exe)

  • Используйте другие библиотеки, такие как pjsip или JRTPLIB , которые могут упростить процесс.

  • Трудный путь, отправка видео и аудио по каналу UDP и выяснение того, как синхронизировать все на клиенте (хотя причина использования RTSP состоит в том, чтобы этого избежать).

  • Твой путь, если я о чем-то не думал.

Второй вариант действительно будет лучшим, так как он уменьшит количество библиотек (интегрирует swscale, libx264, аудиокодек и библиотеку отправителя), упростит разработку и предоставит больше вариантов кодеков (CELT выглядит многообещающе), но я волнуюсь о задержке, поскольку это может иметь более длинный конвейер.

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

Кто-нибудь из вас имеет опыт работы с этими библиотеками, чтобы рекомендовать мне перейти на ffmpeg, продолжать борьбу в прямом эфире555 или делать что-то еще (даже если я об этом не упоминал)?

1 Ответ

0 голосов
/ 08 июля 2011

У меня были очень хорошие результаты потоковой передачи больших блоков данных с низкой задержкой с использованием библиотеки UDT4. Но сначала я бы предложил проверить сетевые возможности ffmpegs, чтобы у вас было собственное решение во всех операциях.

...