Почему видеоплеер на сайте пытается забрать несуществующие сегменты hls?

Question

[karpo518]

На сервере(nging + rtmp-module + ffmpeg) настроена ретрансляция по протоколу hls. Проблема заключается в том, что видеоплеер запрашивает с сервера сегменты, которые сервер уже удалил. Почему так происходит и как это исправить?

Если отключать hls cleanup, то для воспроизведения берутся старые фрагменты. Это уже не трансляция в режиме реального времени, а воспроизведение записи получается.

конфиги

rtmp.conf

# RTMP configuration
rtmp {
    server {
        listen 1935; # Listen on standard RTMP port
        chunk_size 4000;

        application show {
            live on;
            hls on;
            hls_path /tmp/hls;

            hls_fragment 1;
            hls_playlist_length 10;

            exec_static ffmpeg -i "rtsp://@10.10.120.200/0" -vcodec h264 -vf scale=640:480 -f flv -an rtmp://localhost:1935/show/live 2>>/var/log/nginx/ffmpeg_show.log;

        }
    }
}

test.ru.conf

server {
    listen      192.168.100.87:80;
    server_name test.ru www.test.ru;

    index       index.php index.html index.htm;
    access_log  /home/user1/logs/tm2.demis.ru.log combined;
    access_log  /home/user1/logs/tm2.demis.ru.bytes bytes;
    error_log   /home/user1/logs/tm2.demis.ru.error.log error;

    root        /home/user1/web/blog/public;

    location / {

        add_header 'Access-Control-Allow-Origin' '*';
        try_files $uri $uri/ /index.php?$query_string;

        location ~* ^.+\.(jpeg|jpg|png|gif|bmp|ico|svg|css|js)$ {
            expires     max;
        }

        location ~ [^/]\.php(/|$) {
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            if (!-f $document_root$fastcgi_script_name) {
                return  404;
            }

            fastcgi_pass    127.0.0.1:9006;
            fastcgi_index   index.php;
            include         /etc/nginx/fastcgi_params;
            add_header Access-Control-Allow-Origin *;
        }
        

    }


    location /hls {
        # Disable cache
        add_header Cache-Control no-cache;

        # CORS setup
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Expose-Headers' 'Content-Length';

        # allow CORS preflight requests
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' '*';
            add_header 'Access-Control-Max-Age' 1728000;
            add_header 'Content-Type' 'text/plain charset=UTF-8';
            add_header 'Content-Length' 0;
            return 204;
        }

        types {
            application/vnd.apple.mpegurl m3u8;
            video/mp2t ts;
        }

        if ($request_method = 'GET') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
        add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
     }

        root /tmp;
        #alias /tmp/hls;

    }

    error_page  403 /error/404.html;
    error_page  404 /error/404.html;
    error_page  500 502 503 504 /error/50x.html;

}

Answer 1

[alexdora]

Даю ссылку по которой обычно вспоминаю как конфиг делать на hls:
https://www.vultr.com/docs/setup-nginx-on-ubuntu-t...

Смысл в том, что вроде логика нарушена:
У вас прописан в /show exec в теле и указывающий на то что надо запустить некий rtsp и пустить его в /show/live
Но на сколько мне не изменяет память пока вы не сделаете вещание на точку show, он не запустит exec
Но самое смешное что если вы что-то запустите на /live он два раза запустит exec и возникнет конфликт

hls_fragment пропустили s после единицы.
Во-вторых это практически заведомо не работающая конфигурация. У клиентов возникнут беды. По-русски вы просите сделать буфер из 10 кусков по одной секунде.
Это бред. Куски должны быть больше, а кусков меньше. В этой конфигурации вы заставляете клиента скачивать 10 кусков подряд, что создаст проблему даже по количеству соединений.
Конфа: 10s / 1 - рабочая средняя задержка 12-15 секунд
Конфа: 3s / 2 - задержка порядка 6-7 секунд, тестил, работает стабильно.
Вторая цифра это playlist_length

Comments

[karpo518]

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

"Но на сколько мне не изменяет память пока вы не сделаете вещание на точку show, он не запустит exec". Не понимаю, как это должно работать? Можете показать на примере? По ссылке несколько application, что осложняет понимание сути. Мне нужно иметь 2 application, один из которых вещает на второй?

[alexdora]

karpo518, можете вашу логику словами описать?

[karpo518]

alexdora, есть ip-камера доступная по сети через rtsp. Необходимо организовать онлайн трансляцию с него на сайте. Я делаю это по протоколу HLS.

В вашем примере есть приложение application live, которое забирает и ретранслирует поток в application mobile, но при этом само приложение live тоже каким-то образом способно транслировать видео в исходном качестве. Да и my-stream-key нигде в конфиге не фигурирует, но используется в URL.

[alexdora]

karpo518, Немного ошибся, да exec_static стартует вместе с nginx и удерживает запуск.
Последнее на что могу указать:
Вам к сожалению придется забыть о HLS Low Latency и поставить куски по-умолчанию 10s. Связано все с тем что если exec_static отвалится, пока будет перезапуск у клиентов на мелких кусках все залагает. А камера по-любому отвалится. + Это не та задача где нужна низкая задержка
Вполне возможно по причине перезапуска ffmpeg у вас ломаются плейлисты на HLS
Второй возможный вариант - где-то с кэшированием напортачили при отдаче
PS: Не вижу этой строчки из мануала: default_type application/octet-stream;