Question

Мы работаем над приложением, которое позволяет в реальном времени контролировать ваш задний двор. У каждого клиента есть камера, подключенная к inte rnet, транслируемая на наш сервер publi c node.js.

Я пытаюсь использовать node-media-server для публикации sh MPEG- Поток DA SH (или HLS), который будет доступен для наших клиентов приложений в различных сетях, полосах пропускания и разрешениях по всему миру.

Наша цель - максимально приблизить к жизни, "реальной" -time ", чтобы вы могли мгновенно отслеживать, что происходит на вашем заднем дворе.

Технический поток, который уже выполнен:

Процесс ffmpeg на нашем сервере обрабатывает входящие поток с камеры (отдельный дочерний процесс для каждой камеры) и публикует поток через RTSP на локальном компьютере для использования медиа-сервером узла в качестве «входных данных» (мы также сохраняем сегментированные файлы, генерируя миниатюры и т. д. c.) , за это отвечает команда ffmpeg:

-c:v libx264 -preset ultrafast -tune zerolatency -b:v 900k -f flv rtmp://127.0.0.1:1935/live/office

узел-медиа-сервер работает с тем, что я нашел в качестве конфигурации по умолчанию для «прямой трансляции»

private NMS_CONFIG = {
server: {
  secret: 'thisisnotmyrealsecret',
},
rtmp_server: {
  rtmp: {
    port: 1935,
    chunk_size: 60000,
    gop_cache: false,
    ping: 60,
    ping_timeout: 30,
  },
  http: {
    port: 8888,
    mediaroot: './server/media',
    allow_origin: '*',
  },
  trans: {
    ffmpeg: '/usr/bin/ffmpeg',
    tasks: [
      {
        app: 'live',
        hls: true,
        hlsFlags: '[hls_time=2:hls_list_size=3:hls_flags=delete_segments]',
        dash: true,
        dashFlags: '[f=dash:window_size=3:extra_window_size=5]',
      },
    ],
  },
},

};

Насколько я понимаю, из коробки NMS (node-media-server) публикует входной поток, который он получает, в нескольких выходных форматах : flv, mpeg-da sh, hls. со всеми видами онлайн-плееров для этих форматов я могу получить доступ к потоку, используя URL на localhost. с mpeg-da sh и hls я получаю что-то между 10-15 секундами задержки и более.

Моя цель сейчас - реализовать локальный клиент- side mpeg-da sh player, используя da sh. js и настройте его как можно ближе к жизни.

мой код для этого:

<!doctype html>
<html>
    <head>
        <title>Dash.js Rocks</title>
        <style>
            video {
                width: 640px;
                height: 480px;
            }
        </style>
    </head>
    <body>
        <div>
            <video autoplay="" id="videoPlayer" controls=""></video>
        </div>
        <script src="https://cdnjs.cloudflare.com/ajax/libs/dashjs/3.0.2/dash.all.min.js"></script>

        <script>
            (function(){
                // var url = "https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd";
                var url = "http://localhost:8888/live/office/index.mpd";
                var player = dashjs.MediaPlayer().create();
                
                

                // config
                targetLatency = 2.0;        // Lowering this value will lower latency but may decrease the player's ability to build a stable buffer.
                minDrift = 0.05;            // Minimum latency deviation allowed before activating catch-up mechanism.
                catchupPlaybackRate = 0.5;  // Maximum catch-up rate, as a percentage, for low latency live streams.
                stableBuffer = 2;           // The time that the internal buffer target will be set to post startup/seeks (NOT top quality).
                bufferAtTopQuality = 2;     // The time that the internal buffer target will be set to once playing the top quality.


                player.updateSettings({
                    'streaming': {
                        'liveDelay': 2,
                        'liveCatchUpMinDrift': 0.05,
                        'liveCatchUpPlaybackRate': 0.5,
                        'stableBufferTime': 2,
                        'bufferTimeAtTopQuality': 2,
                        'bufferTimeAtTopQualityLongForm': 2,
                        'bufferToKeep': 2,
                        'bufferAheadToKeep': 2,
                        'lowLatencyEnabled': true,
                        'fastSwitchEnabled': true,
                        'abr': {
                            'limitBitrateByPortal': true
                        },
                    }
                });

                console.log(player.getSettings());

                setInterval(() => {
                  console.log('Live latency= ', player.getCurrentLiveLatency());
                  console.log('Buffer length= ', player.getBufferLength('video'));
                }, 3000);

                player.initialize(document.querySelector("#videoPlayer"), url, true);

            })();

        </script>
    </body>
</html>

с тестовым онлайн-видео (https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd) Я вижу, что значение задержки в реальном времени близко к 2 секундам (но у меня нет возможности на самом деле это подтверждают. Это видеофайл, передаваемый в потоковом режиме. в моем офисе у меня есть камера, чтобы я мог фактически сравнить задержку между реальной жизнью и потоком, который я получаю). однако при локальной работе с моей NMS кажется, что это значение не хочет, чтобы go было меньше 20-25 секунд.

Я что-то не так делаю? любая конфигурация на плеере (на стороне клиента html) я забыл? или отсутствует пропущенная конфигурация на стороне сервера (NMS)?

Mick · Answer 1 · 14 февраля 2020

HLS и MPEG DA SH в стандартной комплектации имеют не очень низкую задержку, и цифры, которые вы получаете, не являются необычными.

Некоторые примеры из общедоступного документа форума DA SH (ссылка ниже) включают :

Учитывая ресурсы некоторых из этих организаций, результаты у вас есть Достигнуты не плохо!

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

Один ключ Компонент задержки в кусочной адаптивной битовой скорости (ABR, см. этот ответ для получения дополнительной информации: { ссылка }) - это необходимость для проигрывателя получать и декодировать один или несколько сегментов видео, прежде чем оно сможет отображаться Это. Традиционно игрок должен был получить весь сегмент, прежде чем он мог начать декодировать и отображать его. Диаграмма из первой ссылки на открытый исходный код ниже иллюстрирует это:

DA с малой задержкой SH и HLS с использованием CMAF, 'Common Media Application Format 'который разбивает сегменты, которые могут быть длиной, например, 6 секунд, на более мелкие "кусочки" внутри каждого сегмента. Эти фрагменты предназначены для того, чтобы позволить игроку декодировать и начать их воспроизведение до того, как он получит полный сегмент.

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

В настоящее время имеется достаточно много полезной информации о потоковой передаче с низкой задержкой как от органов стандартизации, так и от открытых Исходные обсуждения, которые, я думаю, действительно помогут вам оценить проблемы (все ссылки актуальны на момент написания статьи) Из открытых источников и обсуждений стандартов:

https://dashif.org/docs/Report%20on%20Low%20Latency%20DASH.pdf (DA SH focus)
https://github.com/video-dev/hlsjs-rfcs/pull/1. (Фокус HLS)

и от поставщиков:

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

Как видите, потоковая передача с низкой задержкой - непростая задача, и может случиться так, что вы захотите рассмотреть другие подходы в зависимости от деталей вашего варианта использования, в том числе от того, сколько у вас подписчиков, какая-то потеря качества, если справедливая компромисс за меньшую задержку и т. д. c. Как упомянуто @ user1390208 в комментариях, более сфокусированная технология видеосвязи в реальном времени, такая как WebRT C, может лучше подходить для решения, на которое вы ориентируетесь.

Если вы хотите предоставить услугу, обеспечивающую жизнь потоковую передачу, а также запись, вы можете рассмотреть возможность использования протокола реального времени для просмотра в режиме реального времени и потоковой передачи HLS / DA SH для всех, кто просматривает записи, где задержка может быть не важна, но качество может быть более важным.

Прямая трансляция: узел-медиа-сервер + Da sh. js, настроенный на низкую задержку в реальном времени

Пожалуйста, войдите или зарегистрируйтесь чтобы ответить на этот вопрос.

1 Ответ

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

Прямая трансляция: узел-медиа-сервер + Da sh. js, настроенный на низкую задержку в реальном времени

Пожалуйста, войдите или зарегистрируйтесь чтобы ответить на этот вопрос.

1 Ответ

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

Похожие темы