Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker-srs:3 obs starts pushing a new stream (session mode), the on_dvr callback function will not be triggered for the first time. #1601

Closed
itming001 opened this issue Feb 13, 2020 · 9 comments
Assignees
Labels
Bug It might be a bug. TransByAI Translated by AI/GPT.
Milestone

Comments

@itming001
Copy link

itming001 commented Feb 13, 2020

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

@LinkSyk
Copy link

LinkSyk commented Feb 15, 2020

I also encountered this problem!!!

TRANS_BY_GPT3

@winlinvip
Copy link
Member

winlinvip commented Feb 16, 2020

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

@LinkSyk
Copy link

LinkSyk commented Feb 16, 2020

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

@itming001
Copy link
Author

itming001 commented Feb 17, 2020

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

@itming001
Copy link
Author

itming001 commented Feb 17, 2020

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

@winlinvip
Copy link
Member

winlinvip commented Feb 17, 2020

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

@winlinvip
Copy link
Member

winlinvip commented Feb 17, 2020

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

@itming001
Copy link
Author

itming001 commented Feb 17, 2020

I hope the author can quickly resolve this issue.

TRANS_BY_GPT3

@winlinvip
Copy link
Member

winlinvip commented Feb 17, 2020

Solution: When stopping SrsAsyncCallWorker::stop() in unpublish, send out all the tasks first and then stop.

TRANS_BY_GPT3

@winlinvip winlinvip added the Bug It might be a bug. label Feb 17, 2020
@winlinvip winlinvip added this to the SRS 3.0 release milestone Feb 17, 2020
@winlinvip winlinvip self-assigned this Sep 5, 2021
@winlinvip winlinvip changed the title docker-srs:3 obs开始推送一个新的流 (session模式)第一次不会触发on_dvr回调函数 docker-srs:3 obs starts pushing a new stream (session mode), the on_dvr callback function will not be triggered for the first time. Jul 28, 2023
@winlinvip winlinvip added the TransByAI Translated by AI/GPT. label Jul 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug It might be a bug. TransByAI Translated by AI/GPT.
Projects
None yet
Development

No branches or pull requests

3 participants