RTSP кідірісі 5-30 секунд — 7 себебі және low-latency баптау
Live-стрим кешігеді және сіздің бақылау «сол ретте» емес пе? RTSP тікелей 200-500 мс беруі керек — егер 5-30 сек кідіріс болса, себебі HLS-конверсия, буферизация немесе GOP-та. Мына мақалада — 7 негізгі себеп, әрқайсысын қалай жоюдың нақты жолы.
Қысқаша
- Ең үлкен себеп: HLS-сегмент буферизация (2-10 сек)
- Тікелей RTSP: 200-500 мс, бірақ браузерде ашылмайды
- Low-Latency HLS (LL-HLS): 2-3 сек
- WebRTC: 200 мс (Zoom стандарты)
- RTSP.KZ автоматы WebRTC + LL-HLS береді
1. HLS-сегмент буферизация
Стандартты HLS-те бейне 2-10 секундтық .ts-сегменттерге кесіледі. Ойнатқыш алдын ала 3 сегмент буферлеп алады → минимал кідіріс = сегмент ұзындығы × 3.
Мысал: сегмент 6 сек → буфер 18 сек. Осы бөгет.
Шешу — Low-Latency HLS (LL-HLS)
Apple 2020 жылы LL-HLS ұсынды. Сегмент 2 сек, ішінде — 200 мс partial-сегменттер. Ойнатқыш partial-ды алдымен алады → кідіріс 2-3 сек.
- Safari iOS 14+ нативтіде қолдайды
- Chrome/Firefox: hls.js @1.2+ керек
- Ретрансляторда LL-HLS қосу керек (MediaMTX, Nimble, Wowza)
2. GOP (Group of Pictures) ұзын
GOP — I-кадрлар арасындағы аралық. Ойнатқыш I-кадрдан бастап декодтауы керек. Егер GOP=100 (4 сек 25fps-те) — ойнатқыш бір I-кадрды 4 сек күте алады.
Шешу
Камерада GOP-ты азайту: 25-30 (1 сек). Live-стрим үшін оңтайлы. Hikvision: Video → I Frame Interval = 25. Dahua: Encode → I-Frame Interval = 25.
3. TCP retransmit
RTSP over TCP пакет жоғалғанда retransmit жасайды — оған 100-500 мс жоғалады. Кумулятивті — секунд болып жиналады.
Шешу
- Егер желі жақсы (Ethernet, күшті Wi-Fi) — UDP пайдалану:
rtsp_transport udp - Егер желі нашар — TCP қалдыру, өйткені UDP-де пакет жоғалғанда бейне бұзылады
- Ethernet-ке ауыстыру Wi-Fi орнына
4. Декодер буфері
FFmpeg, VLC, hls.js декодтау кезінде буфер сақтайды — көбінесе 3-5 кадр.
Шешу (FFmpeg)
-fflags nobuffer— буферді өшіру-flags low_delay— низкий кідіріс режимі-probesize 32 -analyzeduration 0— старт жылдамдату
5. Camera жағынан кодтау уақыты
Камерадағы h.264 encoder кадрды кодтауға 40-100 мс жұмсайды. Күшті процессор — жылдамырақ.
Шешу
- H.264 → H.265: 30% дұрыс трафик, кодтау 1.5x баяу (Snapdragon-де айтарлықтай емес)
- Sub-stream пайдалану — көп жиі кадр (fps) төмен
6. Wi-Fi jitter
Wi-Fi 2.4 ГГц-те пакеттер тұрақсыз жетеді. Кейбір кадрлар 200 мс, кейбіреуі — 800 мс. Ойнатқыш ең баяу жағдайдан «үлкен буфер» жасайды.
Шешу
- Ethernet — тұрақты латентілік ~2-5 мс
- 5 ГГц Wi-Fi — 2.4 ГГц-ден 2x жылдам
- Роутерге жақынырақ орналастыру
7. Ретранслятор жағында кідіріс
Егер сіз ретрансляторды (MediaMTX, RTSP.KZ, Wowza) пайдалансаңыз — оның да буфері бар.
MediaMTX low-latency
my_camera:
source: rtsp://cam-ip
sourceProtocol: tcp
rtspEncryption: "no"
hlsSegmentCount: 3
hlsSegmentDuration: 1s
hlsPartDuration: 200ms
webrtcICEServers:
- url: "stun:stun.l.google.com:19302"
RTSP.KZ автомат low-latency
Барлық реттеулер жасалған: WebRTC 200 мс, LL-HLS 2 сек, автоматты кодек-таңдау. Күнделікті пайдаланушыға reset баптау қажет емес.
Тегін бастау →Кідіріс: салыстырма
| Технология | Кідіріс | Қолдау |
|---|---|---|
| Тікелей RTSP (VLC) | 200-500 мс | Тек жеке ойнатқыш |
| Стандартты HLS | 10-30 сек | Барлық браузерлер |
| Low-Latency HLS | 2-3 сек | Safari, hls.js |
| WebRTC | 0.2 сек | Заманауи браузерлер |
| MJPEG | 1-2 сек | Барлық браузерлер |
| SRT | 0.5-1 сек | Кәсіби құралдар |
Жиі қойылатын сұрақтар
Ең үлкен себеп — HLS-конверсия (сегмент 2-10 сек буферизацияланады). RTSP тікелей 200-500 мс береді. Басқа себептер: TCP retransmit, GOP ұзын, декодер буфері.
Low-Latency HLS (LL-HLS) 2-3 сек-ке дейін азайтады. iOS 14+ нативтіде, Chrome/Firefox — hls.js @1.2+. Сегмент ұзындығын 2 сек-ке қою.
Иә. WebRTC 200 мс жеткізеді. Бірақ TURN сервері мен күрделі баптау керек. RTSP.KZ WebRTC-ты автоматты береді.
UDP жылдамырақ (retransmit жоқ), бірақ пакет жоғалғанда бейне бұзылады. Wi-Fi нашар болса — TCP. CGNAT/firewall арқылы тек TCP өтеді.
GOP — I-кадрлар аралығы. GOP=25 (1 сек) — жылдам старт, көп трафик. GOP=100 (4 сек) — аз трафик, ұзақ бастау. Live үшін GOP=25-30 оңтайлы.