ossrs / srs

SRS is a simple, high-efficiency, real-time video server supporting RTMP, WebRTC, HLS, HTTP-FLV, SRT, MPEG-DASH, and GB28181.

Home Page:https://ossrs.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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 · 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.

  1. SRS Version: docker srs:3
  2. 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
  3. 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

commented

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

commented

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.

Screenshot_dde-desktop_20200216115052
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