[Bug] http API doesn't report correct stats when using SRT publisher
Closed this issue · 9 comments
Hello,
Using SRS/7.0.115, when publishing using srt, I get through ffprobe the usual h264/aac stream.
Input #0, mpegts, from 'srt://127.0.0.1:1935?streamid=#!::h=live/test,m=request':
Duration: N/A, start: 67707.653811, bitrate: N/A
Program 1
Stream #0:0[0x101]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn
Stream #0:1[0x102]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 133 kb/s
Stream #0:2[0x119]: Data: scte_35
However, when probing the HTTP callback API in order to get stats for this stream, I can't get anything that useful:
{
"code": 0,
"server": "vid-6ou26s1",
"service": "3h9e8o93",
"pid": "1053709",
"stream": {
"id": "vid-jr8187k",
"name": "test",
"vhost": "vid-35c3886",
"app": "live",
"tcUrl": "srt://xx.xx.xx.xx/live",
"url": "/live/test",
"live_ms": 1762131537295,
"clients": 1,
"frames": 0,
"send_bytes": 6777842,
"recv_bytes": 222383846,
"kbps": {
"recv_30s": 10196,
"send_30s": 951
},
"publish": {
"active": true,
"cid": "b2579bz9"
},
"video": null,
"audio": null
}
}
video/audo doesn't seem to be detected at all, frames is also empty. I was looking to get data here to detect bitrate of audio/video, etc. Am I doing something wrong here or is it a bug?
srt_server {
enabled on;
listen 1935;
maxbw 1000000000;
mss 1500;
connect_timeout 4000;
peer_idle_timeout 8000;
default_app live;
peerlatency 0;
recvlatency 0;
latency 0;
tsbpdmode off;
tlpktdrop off;
sendbuf 2000000;
recvbuf 2000000;
pbkeylen 16;
}
vhost __defaultVhost__ {
min_latency off;
tcp_nodelay off;
chunk_size 128;
in_ack_size 0;
out_ack_size 2500000;
publish {
mr off;
mr_latency 350;
firstpkt_timeout 20000;
normal_timeout 7000;
parse_sps on;
try_annexb_first on;
kickoff_for_idle 0;
}
play {
gop_cache off;
gop_cache_max_frames 2500;
queue_length 10;
time_jitter full;
atc off;
mix_correct off;
atc_auto off;
mw_latency 350;
mw_msgs 8;
send_min_interval 10.0;
reduce_sequence_header on;
}
srt {
enabled on;
srt_to_rtmp off;
}
}
FYI, I updated to 7.0.116 hoping it would fix the issue like #4555, but it remained:
{
"code": 0,
"server": "vid-6ou26s1",
"service": "1u97sy24",
"pid": "2247188",
"stream": {
"id": "vid-5g7g36z",
"name": "test",
"vhost": "vid-229md1k",
"app": "live",
"tcUrl": "srt://xx.xx.xx.xx/live",
"url": "/live/test",
"live_ms": 1762203501947,
"clients": 1,
"frames": 0,
"send_bytes": 0,
"recv_bytes": 38246908,
"kbps": {
"recv_30s": 0,
"send_30s": 0
},
"publish": {
"active": true,
"cid": "s06x542f"
},
"video": null,
"audio": null
}
}
And ffprobe shows the stream just fine:
Stream #0:0[0x101]: Video: h264 (Main) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn
Stream #0:1[0x102]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 133 kb/s
Stream #0:2[0x119]: Data: scte_35
Fixed in v7.0.117. The issue was that SRT streams with srt_to_rtmp off weren't reporting codec info and frame stats to the HTTP API. Now statistics are collected directly from SRT frame processing, so the API will correctly show video/audio metadata and frame counts regardless of the srt_to_rtmp setting.
@winlinvip Just a quick feedback: frames is still always 0.
"code": 0,
"server": "vid-6ou26s1",
"service": "91h157e8",
"pid": "617435",
"stream": {
"id": "vid-x4em786",
"name": "test",
"vhost": "vid-593zr55",
"app": "live",
"tcUrl": "srt://xx.xx.xx.xx/live",
"url": "/live/test",
"live_ms": 1762283099995,
"clients": 3,
"frames": 0, # <==== Always
"send_bytes": 18876990888,
"recv_bytes": 9501504208,
"kbps": {
"recv_30s": 10197,
"send_30s": 20395
},
"publish": {
"active": true,
"cid": "s6n9b808"
},
"video": {
"codec": "H264",
"profile": "Main",
"level": "4",
"width": 1920,
"height": 1080
},
"audio": {
"codec": "AAC",
"sample_rate": 44100,
"channel": 2,
"profile": "LC"
}
}
}
@winlinvip also, my log is filling up with this message:
[2025-11-04 16:35:30.718][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:30.819][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:30.896][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:31.016][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:31.105][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:31.209][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:31.299][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:31.416][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:31.503][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:31.603][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:31.700][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:31.807][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:31.930][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
[2025-11-04 16:35:32.006][WARN][617435][s6n9b808][62] ts: drop pid=0x119, stream=0xffffff86
This is because on this PID I have a scte-35 stream. However, I'm not converting it to RTMP...so srs shouldn't be dropping this pid at all. Reverting to f90a96a03 fixes this issue. So I'm guessing the v7.0.117 must've missed something.
If you want, here's a lint to a 5min mpegts stream for SRT input:
https://drive.google.com/file/d/10RIbaFi3LY1t1M1t_luWo9-yErYp1Gme/view?usp=sharing
This issue is not about SRT scte-35 stream. I fixed the HTTP API frames 0 issue.
@winlinvip thanks for the feedback.
I know the issue is not scte-35 related, I just mentioned that this log message didn't happen prior to v7.0.117 at all.
It only showed up if I enabled srt_to_rtmp. Now, it shows all the time even with it off and it increases CPU usage. (from 2% to 5% for a single SRT stream ingestion)
I'm guessing this is because of stats commit, right?
Anyways, I've tried building v7.0.118 for testing but hit a snag:
g++ -c -ansi -Wall -g -O0 \
-I./src/app -I./src/core -I./src/kernel -I./src/protocol \
-I./objs -I./objs/openssl/include -I./objs/srtp2/include -I./objs/ffmpeg/include \
-o ./objs/src/app/srs_app_rtc_source.o \
./src/app/srs_app_rtc_source.cpp
In the source file `srs_app_rtc_source.cpp`, within the member function `SrsRtcFormat::on_rtp_packet` of the `SrsRtcFormat` class, there is an error on line 3812 at column 36. The error indicates that the member variable `track_desc_` of the class `SrsRtcRecvTrack` is protected and cannot be accessed from the current context.
3812 | if (!req_ || !track || !track->track_desc_ || !track->track_desc_->media_) {
| ^~~~~~~~~~~
In file included from ./src/app/srs_app_rtc_source.cpp:7:
./src/app/srs_app_rtc_source.hpp:860:29: note: declared protected here
860 | SrsRtcTrackDescription *track_desc_;
| ^~~~~~~~~~~
In the file `srs_app_rtc_source.cpp`, at line 3812 and column 59, there is an error indicating that the member variable `track_desc_` of the class `SrsRtcRecvTrack` is protected and is being accessed in a way that is not allowed from the current context.
3812 | if (!req_ || !track || !track->track_desc_ || !track->track_desc_->media_) {
| ^~~~~~~~~~~
./src/app/srs_app_rtc_source.hpp:860:29: note: declared protected here
860 | SrsRtcTrackDescription *track_desc_;
| ^~~~~~~~~~~
In the source file `srs_app_rtc_source.cpp`, at line 3823, position 41, there is an error because the member variable `track_desc_` of the class `SrsRtcRecvTrack` is protected and cannot be accessed from the current scope.
3823 | SrsCodecPayload *media = track->track_desc_->media_;
| ^~~~~~~~~~~
./src/app/srs_app_rtc_source.hpp:860:29: note: declared protected here
860 | SrsRtcTrackDescription *track_desc_;
| ^~~~~~~~~~~
In the file `srs_app_rtc_source.cpp`, at line 3853, column 41, there is an error indicating that the member `track_desc_` of the class `SrsRtcRecvTrack` is protected and is being accessed in a way that is not allowed from the current context.
3853 | SrsCodecPayload *media = track->track_desc_->media_;
| ^~~~~~~~~~~
./src/app/srs_app_rtc_source.hpp:860:29: note: declared protected here
860 | SrsRtcTrackDescription *track_desc_;
| ^~~~~~~~~~~
make[1]: *** [objs/Makefile:724: objs/src/app/srs_app_rtc_source.o] Error 1
make[1]: Leaving directory '/home/ubuntu/srs/repo/trunk'
make: *** [Makefile:96: server] Error 2
This is using Ubuntu 24.04.3 LTS with:
gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
TRANS_BY_GPT4
didn't happen prior to v7.0.117 at all.
I suppose it is not introduced by this commit. And, I didn't reproduce this issue, you should description the step to reproduce.
@winlinvip ok, so...with dc8b2a8 (v7.0.118) it's indeed reporting the frames in http API, so thanks!
However, the logs are full of:
[2025-11-06 15:37:24.576][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:24.680][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:24.773][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:24.876][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:24.980][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:25.083][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:25.185][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:25.285][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:25.387][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:25.491][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:25.585][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:25.689][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:25.784][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:25.881][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:25.980][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:26.085][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:26.189][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:26.288][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:26.380][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:26.486][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:26.581][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:26.683][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:26.781][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:26.880][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:26.996][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:27.089][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:27.184][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:27.276][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:27.390][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
[2025-11-06 15:37:27.482][WARN][2320390][5w9xv886][22] ts: drop pid=0x119, stream=0xffffff86
This is using this input:
https://cloudflare.cdn.spalla.io/vod/test/test.ts?sjwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1cmlfc3ViIjoiL3Rlc3QvIiwidWlkIjoiMDE4OTZlOTctZGYwMi03OGEzLWFlYTItZmQ0Njg4NTViYjMxIiwicmF1IjpudWxsLCJiZXkiOmZhbHNlLCJpaXAiOmZhbHNlLCJuYmYiOjE3NjI0NTU0NjcsImlhdCI6MTc2MjQ1NTQ2NywiZXhwIjo4NzYyNTQxODY3LCJqdGkiOiIwMTg5NmU5Ny1kZjAyLTc4YTMtYWVhMi1mZDQ2ODg1NWJiMzEiLCJpc3MiOiJTcGFsbGEifQ.-W9ve8eRfrM045_7aSIHW-fvS6bW9rEF1yvlpWwbzcc
I'm using tsduck as ingestion tool:
tsp -I file ./test.ts -P regulate -O srt -c 127.0.0.1:1935 --streamid '#!::h=live/test,m=publish'
I'm guessing that the decoding logic introduced by v7.0.117 is not able to decode that specific pid, which is fine, but it's flooding the log files unnecessarily, I suppose (many times a second).