docker-srs:3 obs starts pushing a new stream (session mode), the on_dvr callback function will not be triggered for the first time.
itming001 opened this issue · 9 comments
Description
obs starts pushing a new stream (session mode). The first time does not trigger the on_dvr callback function. The second time, the callback function is triggered after clicking on start streaming, not waiting for the stop streaming to trigger the callback function.
Please describe the issue you are facing.
- SRS Version:
docker srs:3
- SRS Logs:
- Logs for the first streaming attempt.
connected stream, tcUrl=rtmp://192.168.0.120/testsrs, pageUrl=, swfUrl=rtmp://192.168.0.120/testsrs, schema=rtmp, vhost=defaultVhost, port=1935, app=testsrs, stream=78911, param=, args=null
[2020-02-13 07:56:00.481][Trace][1][682] source url=/testsrs/78911, ip=192.168.0.111, cache=1, is_edge=0, source_id=-1[-1]
[2020-02-13 07:56:00.533][Trace][1][682] hls: win=60000ms, frag=10000ms, prefix=, path=./objs/nginx/html, m3u8=[app]/[stream].m3u8, ts=[app]/[stream]-[seq].ts, aof=2.00, floor=0, clean=1, waitk=1, dispose=0ms, dts_directly=1
[2020-02-13 07:56:00.533][Trace][1][682] dvr stream 78911 to file ./objs/nginx/html/testsrs/78911.1581580560533.flv
[2020-02-13 07:56:00.533][Trace][1][682] ignore disabled exec for vhost=defaultVhost
[2020-02-13 07:56:00.533][Trace][1][682] http: mount flv stream for sid=/testsrs/78911, mount=/testsrs/78911.flv
[2020-02-13 07:56:00.533][Trace][1][682] start publish mr=0/350, p1stpt=20000, pnt=5000, tcp_nodelay=0
[2020-02-13 07:56:00.586][Trace][1][682] got metadata, width=1092, height=614
[2020-02-13 07:56:01.272][Trace][1][682] 7B audio sh, codec(10, profile=LC, 2channels, 0kbps, 44100HZ), flv(16bits, 2channels, 44100HZ)
[2020-02-13 07:56:01.281][Trace][1][682] 46B video sh, codec(7, profile=High, level=3.1, 1104x624, 0kbps, 0.0fps, 0.0s)
[2020-02-13 07:56:20.532][Trace][1][682] <- CPB time=0, okbps=1,0,0, ikbps=2654,0,0, mr=0/350, p1stpt=20000, pnt=5000
[2020-02-13 07:56:21.633][Trace][1][682] -> HLS time=21257540ms, sno=2, ts=78911-1.ts, dur=0.00, dva=3633p
[2020-02-13 07:56:25.533][Trace][1][682] <- CPB time=19257424, okbps=1,0,0, ikbps=2639,0,0, mr=0/350, p1stpt=20000, pnt=5000
[2020-02-13 07:56:35.538][Trace][1][682] <- CPB time=29551511, okbps=0,1,0, ikbps=2638,2574,0, mr=0/350, p1stpt=20000, pnt=5000
[2020-02-13 07:56:45.538][Trace][1][682] <- CPB time=39701998, okbps=0,1,0, ikbps=2636,2574,0, mr=0/350, p1stpt=20000, pnt=5000
- Logs for the first streaming attempt.
- Logs for the second streaming attempt (on_dvr triggered right from the beginning).
[2020-02-13 07:58:25.950][Trace][1][684] connected stream, tcUrl=rtmp://192.168.0.120/testsrs, pageUrl=, swfUrl=rtmp://192.168.0.120/testsrs, schema=rtmp, vhost=defaultVhost, port=1935, app=testsrs, stream=78911, param=, args=null
[2020-02-13 07:58:25.951][Trace][1][684] source url=/testsrs/78911, ip=192.168.0.111, cache=1, is_edge=0, source_id=-1[-1]
[2020-02-13 07:58:26.003][Trace][1][684] hls: win=60000ms, frag=10000ms, prefix=, path=./objs/nginx/html, m3u8=[app]/[stream].m3u8, ts=[app]/[stream]-[seq].ts, aof=2.00, floor=0, clean=1, waitk=1, dispose=0ms, dts_directly=1
[2020-02-13 07:58:26.003][Trace][1][684] dvr stream 78911 to file ./objs/nginx/html/testsrs/78911.1581580706003.flv
[2020-02-13 07:58:26.003][Trace][1][684] ignore disabled exec for vhost=defaultVhost
[2020-02-13 07:58:26.003][Trace][1][684] start publish mr=0/350, p1stpt=20000, pnt=5000, tcp_nodelay=0
[2020-02-13 07:58:26.010][Trace][1][684] http hook on_dvr success. client_id=682, url=http://192.168.0.106:8888/getdvr, request={"action":"on_dvr","client_id":682,"ip":"192.168.0.111","vhost":"defaultVhost","app":"testsrs","stream":"78911","param":"","cwd":"/usr/local/srs","file":"./objs/nginx/html/testsrs/78911.1581580560533.flv"}, response=0
[2020-02-13 07:58:26.052][Trace][1][684] got metadata, width=1092, height=614
[2020-02-13 07:58:26.739][Trace][1][684] 7B audio sh, codec(10, profile=LC, 2channels, 0kbps, 44100HZ), flv(16bits, 2channels, 44100HZ)
[2020-02-13 07:58:26.743][Trace][1][684] 46B video sh, codec(7, profile=High, level=3.1, 1104x624, 0kbps, 0.0fps, 0.0s)
[2020-02-13 07:58:26.763][Trace][1][684] -> HLS time=145595317ms, sno=10, ts=78911-9.ts, dur=0.00, dva=0p
Describe your expectation:
The first call was successful, but it does not match the functionality described in the documentation. It should trigger a callback when the start button is clicked.
TRANS_BY_GPT3
I also encountered this problem!!!
TRANS_BY_GPT3
The meaning of 'on_dvr' is 'on_dvr_end'. There is no event called 'on_dvr_start', and it is only called when generating DVR files at the end.
If you need 'on_dvr_start', please describe your scenario. In what situations do you need this mechanism?
TRANS_BY_GPT3
The problem I encountered was that after restarting SRS, I pushed the /live/stream stream. The first time I pushed the log, only the log for generating FLV was printed, but there was no log for on_dvr success. Then I used Ctrl+C to end the stream and pushed the same stream again. The log then displayed the logs for generating FLV and on_dvr success in order. I am using the latest 3.0 release branch of SRS. The push command is: ffmpeg -re -i /home/syk/avtest/mayday.mp4 -vcodec copy -acodec copy -f flv -y rtmp://localhost/live/stream.
Log Information.txt
Configuration File.txt
TRANS_BY_GPT3
The meaning of this question is that when pushing a new stream, this problem occurs. For example: rtmp://192.168.0.120/app/huojian. "huojian" appears for the first time and does not trigger the on_dvr callback. It will trigger the callback on the second time.
TRANS_BY_GPT3
Another issue is that the next trigger will return the file generated from the previous streaming, not the file generated from this recording.
TRANS_BY_GPT3
The configuration is as follows:
listen 1935;
daemon off;
srs_log_tank console;
vhost __defaultVhost__ {
http_hooks {
enabled on;
on_dvr http://127.0.0.1:8085/api/v1/dvrs;
}
dvr {
enabled on;
dvr_plan session;
dvr_path ./objs/nginx/html/[app]/[stream].[15].[04].[05].flv;
}
}
Start the API server:
python research/api-server/server.py 8085
Start streaming:
ffmpeg -re -i doc/source.200kbps.768x320.flv -c copy -f flv -y rtmp://ossrs.net/live/livestream
Temporary file generated:
-rw-r--r-- 1 chengli.ycl staff 57920 Feb 17 10:53 livestream.02.53.49.flv.tmp
Press ctrl+c
to cancel the streaming, file splitting, but without callback:
-rw-r--r-- 1 chengli.ycl staff 3858439 Feb 17 10:55 livestream.02.53.49.flv
Stream again:
ffmpeg -re -i doc/source.200kbps.768x320.flv -c copy -f flv -y rtmp://ossrs.net/live/livestream
Create a new temporary file:
-rw-r--r-- 1 chengli.ycl staff 65068 Feb 17 10:57 livestream.02.57.16.flv.tmp
Also has a callback:
[2020-02-17 02:57:16][trace] post to dvrs, req={"action":"on_dvr","client_id":1074,"ip":"172.17.0.1","vhost":"__defaultVhost__",
"app":"live","stream":"livestream","param":"","cwd":"/tmp/srs/trunk",
"file":"./objs/nginx/html/live/livestream.02.53.49.flv"}
The file for this callback is indeed the file from the previous DVR, and it does have issues.
TRANS_BY_GPT3
The reason is that an optimization was made before, where the on_dvr coroutine is only started when publishing, and it is stopped when un_publishing, causing this callback to not be triggered.
This optimization is aimed at reducing memory usage. You can find more information about it here: link
TRANS_BY_GPT3
I hope the author can quickly resolve this issue.
TRANS_BY_GPT3
Solution: When stopping SrsAsyncCallWorker::stop()
in unpublish, send out all the tasks first and then stop.
TRANS_BY_GPT3