RunOnReady not running sometimes

[EmadHelmi]

Which version are you using?

v0.23.7-ffmpeg

Which operating system are you using?

• [ ] Linux amd64 standard
• [x] Linux amd64 Docker
• [ ] Linux arm64 standard
• [ ] Linux arm64 Docker
• [ ] Linux arm7 Docker
• [ ] Linux arm7 standard
• [ ] Linux arm6 standard
• [ ] Linux arm6 Docker
• [ ] Windows amd64 standard
• [ ] Windows amd64 Docker (WSL backend)
• [ ] macOS amd64 standard
• [ ] macOS amd64 Docker
• [ ] Other (please describe)

Describe the issue

I've defined a command in the runOnReady section of a path:

paths:
    "~^transcode/(.*)$":
        runOnReady: ffmpeg -hide_banner -i rtmp://localhost:1935/transcode/$G1 -vf "scale='min(320,iw)':-2" -c:v libx264 -preset veryfast -c:a copy -f flv "rtmp://transcode:1935/stream/$G1"
        runOnReadyRestart: yes

When I publish a stream to the 1935 port using the rtmp protocol, sometimes the runOnReady command does not run. So in the log, I just see the converting.... and not is reading....! Then I must stop the stream and restart it to make the runOnReady work.

Describe how to replicate the issue

As I don't know how this happens, so I cannot describe how to reproduce the bug.

Did you attach the server logs?

no

Did you attach a network dump?

no

[EmadHelmi]

@aler9 Can you please help me?

[aler9]

Hello, runOnReady is always executed when a stream is ready. The reason why FFmpeg doesn't connect to the server depends only FFmpeg, that is not developed here.

Anyway my advice is to pull the stream with RTSP (even if you're publishing it with RTMP), the issue may go away, but i repeat, it doesn't depend from the server at all.

paths:
    "~^transcode/(.*)$":
        runOnReady: ffmpeg -hide_banner -i rtsp://localhost:8554/transcode/$G1 -vf "scale='min(320,iw)':-2" -c:v libx264 -preset veryfast -c:a copy -f flv "rtmp://transcode:1935/stream/$G1"
        runOnReadyRestart: yes

[EmadHelmi]

Thank you for your response. I will test it. But I still have a question. I am publishing to 1935 port using an external ffmpeg command

ffmpeg -re -stream_loop -1 -i files/sample-mp4-file.mp4 -c copy -f flv "rtmp://0.0.0.0:1935/transcode/14test?pt=wieuryqwoieruyqwea"

and these log lines are logged in the container

2023/08/07 15:47:05 DEB [path transcode/14test] created
2023/08/07 15:47:05 INF [HLS] [muxer transcode/14test] created automatically
2023/08/07 15:47:05 INF [RTMP] [conn 172.26.0.1:52006] is publishing to path 'transcode/14test', 2 tracks (H264, MPEG-4 Audio)

about 98 percent of times, I also see these lines in the logs:

2023/08/07 15:14:23 INF [RTMP] [conn 127.0.0.1:54166] opened
2023/08/07 15:14:23 INF [RTMP] [conn 127.0.0.1:54166] is reading from path 'transcode/14test', 2 tracks (H264, MPEG-4 Audio)

so the runOnReady command seems to be run. But in 2 percent of times the is reading line does not appear. Is it because of the publisher ffmpeg command or because of the inner ffmpeg command (the runOnReady)? I ask the question because in both situations (whether the runOnReady is run or not) I can watch my stream at mydomain:8888/transcode/14test and just cannot what the converted one (the one which runs within the runOnReady) when the runOnReady is not run.

this is the part of paths in the config file:

paths:
  all: ...
  "~^transcode/(.*)$":
    runOnReady: ffmpeg -hide_banner -i rtmp://localhost:1935/transcode/$G1 -vf "scale='min(320,iw)':-2" -c:v libx264 -preset veryfast -c:a copy -f flv "rtmp://transcode:1935/stream/$G1"
    runOnReadyRestart: yes

  "~^stream/(.*)$":
    runOnReady: /bin/sh -c "mkdir -p /records/$G1/ && ffmpeg -hide_banner -i rtmp://localhost:1935/stream/$G1 -c copy -y /records/$G1/output.mp4"
    runOnReadyRestart: yes

[liusuyi2021]

me too

[isometriq]

Hello, I'm facing the same issue. I'm running with the public docker image: bluenviron/mediamtx:1.1.1-ffmpeg. I'm using a volume to override the mediamtx.yml (based on the original in the repo) and define some paths.

I'm pushing a local video file from a terminal to the dockerized service with the following command.

ffmpeg -hide_banner -re -stream_loop -1 -i ./media/count.mp4 -c copy -f rtsp rtsp://localhost/sample

With the following path

  'sample':
    runOnReady: echo "RUN ON READY $MTX_PATH"
    runOnReadyRestart: no
    runOnNotReady: echo "RUN ON NOT READY $MTX_PATH"

The onRunReady hook is executed every single time

mediamtx  | 2023/10/06 16:10:16 INF [RTSP] [conn 192.168.65.1:32987] opened
mediamtx  | 2023/10/06 16:10:16 INF [RTSP] [session 8e402686] created by 192.168.65.1:32987
mediamtx  | 2023/10/06 16:10:16 INF [path sample] runOnReady command started
mediamtx  | 2023/10/06 16:10:16 INF [RTSP] [session 8e402686] is publishing to path 'sample', 2 tracks (H264, MPEG-4 Audio)
mediamtx  | RUN ON READY sample
mediamtx  | 2023/10/06 16:10:19 INF [path sample] runOnReady command stopped
mediamtx  | 2023/10/06 16:10:19 INF [path sample] runOnNotReady command launched
mediamtx  | 2023/10/06 16:10:19 INF [RTSP] [session 8e402686] destroyed: torn down by 192.168.65.1:32987
mediamtx  | 2023/10/06 16:10:19 INF [RTSP] [conn 192.168.65.1:32987] closed: EOF
mediamtx  | RUN ON NOT READY sample

With the following path (using regex)

  '~^sample$':
    runOnReady: echo "RUN ON READY $MTX_PATH"
    runOnReadyRestart: no
    runOnNotReady: echo "RUN ON NOT READY $MTX_PATH"

Most of the time, the onRunReady is not executed

mediamtx  | 2023/10/06 16:13:39 INF [RTSP] [conn 192.168.65.1:32990] opened
mediamtx  | 2023/10/06 16:13:39 INF [RTSP] [session 43a8e53e] created by 192.168.65.1:32990
mediamtx  | 2023/10/06 16:13:39 INF [RTSP] [session 43a8e53e] is publishing to path 'sample', 2 tracks (H264, MPEG-4 Audio)
mediamtx  | 2023/10/06 16:13:42 INF [RTSP] [session 43a8e53e] destroyed: torn down by 192.168.65.1:32990
mediamtx  | 2023/10/06 16:13:42 INF [RTSP] [conn 192.168.65.1:32990] closed: EOF

On the 4th time, i got it to execute, then after a dozen times, again, but it's basically unpredictable

mediamtx  | 2023/10/06 16:19:31 INF [RTSP] [conn 192.168.65.1:32994] opened
mediamtx  | 2023/10/06 16:19:31 INF [RTSP] [session 1cf7a177] created by 192.168.65.1:32994
mediamtx  | 2023/10/06 16:19:31 INF [path sample] runOnReady command started
mediamtx  | 2023/10/06 16:19:31 INF [RTSP] [session 1cf7a177] is publishing to path 'sample', 2 tracks (H264, MPEG-4 Audio)
mediamtx  | RUN ON READY sample
mediamtx  | 2023/10/06 16:19:34 INF [path sample] runOnReady command stopped
mediamtx  | 2023/10/06 16:19:34 INF [path sample] runOnNotReady command launched
mediamtx  | 2023/10/06 16:19:34 INF [RTSP] [session 1cf7a177] destroyed: torn down by 192.168.65.1:32994
mediamtx  | 2023/10/06 16:19:34 INF [RTSP] [conn 192.168.65.1:32994] closed: EOF
mediamtx  | RUN ON NOT READY sample

@aler9 Is there a chance that paths defined as regular expression affect the hook execution behavior?

[isometriq]

Having the the same issue with the runOnDemand hook when using regular expression paths. Same behaviour as with the runOnReady hook.

I can consistently trigger the hook when reading the path from a player like VLC while not pushing on the path, if path is not a regular expression.

[isometriq]

When running directly from source, instead of the docker image, like so...

export MTX_PROTOCOLS=tcp && export MTX_RTSPADDRESS=:554 && go run main.go

..the runOnReady is consistently trigger every time with or without regular expressions.

[aler9]

i'm still not able to replicate the bug. I used this configuration file:

paths:
  '~^sample$':
    runOnReady: echo "RUN ON READY $MTX_PATH"
    runOnReadyRestart: no
    runOnNotReady: echo "RUN ON NOT READY $MTX_PATH"

then i launched the v1.1.1 image with

docker run --rm -it -p 8554:8554 -v $PWD:/v:ro bluenviron/mediamtx:1.1.1-ffmpeg /v/mediamtx.yml

and started publishing in an infinite loop

while true; do ffmpeg -re -f lavfi -i testsrc=size=1920x1080:rate=30 -pix_fmt yuv420p -c:v libx264 -g 60 -keyint_min 60 -preset ultrafast -b:v 600k -t 00:00:00 -f rtsp rtsp://localhost:8554/sample; done

server output was consistent:

2023/11/30 21:59:47 INF [RTSP] [conn 172.17.0.1:36076] opened
2023/11/30 21:59:47 INF [RTSP] [session 334a6309] created by 172.17.0.1:36076
2023/11/30 21:59:47 INF [path sample] runOnReady command started
2023/11/30 21:59:47 INF [RTSP] [session 334a6309] is publishing to path 'sample', 1 track (H264)
RUN ON READY sample
2023/11/30 21:59:47 INF [path sample] runOnReady command stopped
2023/11/30 21:59:47 INF [path sample] runOnNotReady command launched
2023/11/30 21:59:47 INF [RTSP] [session 334a6309] destroyed: torn down by 172.17.0.1:36076
2023/11/30 21:59:47 INF [RTSP] [conn 172.17.0.1:36076] closed: EOF
RUN ON NOT READY sample
2023/11/30 21:59:47 INF [RTSP] [conn 172.17.0.1:36086] opened
2023/11/30 21:59:47 INF [RTSP] [session 6a3d329f] created by 172.17.0.1:36086
2023/11/30 21:59:47 INF [path sample] runOnReady command started
2023/11/30 21:59:47 INF [RTSP] [session 6a3d329f] is publishing to path 'sample', 1 track (H264)
RUN ON READY sample
2023/11/30 21:59:47 INF [path sample] runOnReady command stopped
2023/11/30 21:59:47 INF [path sample] runOnNotReady command launched
2023/11/30 21:59:47 INF [RTSP] [session 6a3d329f] destroyed: torn down by 172.17.0.1:36086
2023/11/30 21:59:47 INF [RTSP] [conn 172.17.0.1:36086] closed: EOF
RUN ON NOT READY sample
2023/11/30 21:59:48 INF [RTSP] [conn 172.17.0.1:36088] opened
2023/11/30 21:59:48 INF [RTSP] [session 1b51b7e3] created by 172.17.0.1:36088
2023/11/30 21:59:48 INF [path sample] runOnReady command started
2023/11/30 21:59:48 INF [RTSP] [session 1b51b7e3] is publishing to path 'sample', 1 track (H264)
RUN ON READY sample
2023/11/30 21:59:48 INF [path sample] runOnReady command stopped
2023/11/30 21:59:48 INF [path sample] runOnNotReady command launched
2023/11/30 21:59:48 INF [RTSP] [session 1b51b7e3] destroyed: torn down by 172.17.0.1:36088
2023/11/30 21:59:48 INF [RTSP] [conn 172.17.0.1:36088] closed: EOF
RUN ON NOT READY sample

[aler9]

closed since no one provided additional feedback.