-
Notifications
You must be signed in to change notification settings - Fork 308
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
melt failing to run when called from a daemon #39
Comments
Forgot to mention, this is with 0.9.0. |
What is the output/consumer that you are using? Show an example command line you are running. |
Below is a small demo nginx config file. [ https://github.com/arut/nginx-rtmp-module ] The melt command shown appears to exit almost as soon as it's started internally by nginx. The same command running externally from a shell and publishing to the same location works just fine. The line below it is the ffmpeg equivalent to what melt should be doing, and it works. (I want to use melt because it offers a graceful means of looping the video) Line wrapping may make this ugly... Edit: boy did it look ugly, hopefully not as bad now. worker_processes 1;
error_log /var/log/nginx/error_log info;
events {
worker_connections 1024;
use epoll;
}
rtmp {
server {
listen 1935;
ping 30s;
notify_method get;
application melt {
live on;
exec_options on;
exec_pull /usr/bin/melt -siLent eof=loop -profile=atsc_720p_2997 /var/www/stream/vod/John.mp4 -consumer avformat:"rtmp://127.0.0.1/melt/loop live=on" properties=hq-rtmp name=loop;
exec_pull /usr/bin/ffmpeg -re -i /var/www/stream/vod/John.mp4 -c:v libx264 -g 30 -crf 20 -trellis 2 -profile:v high -preset:v slow -c:a libfdk_aac -vbr 3 -f flv "rtmp://127.0.0.1/melt/loop2 live=on" name=loop2;
}
}
} |
Can you please try with -silent instead of -siLent with an upper case L. melt is trying to do some terminal I/O when you do not use -silent. |
Sorry, I just created that config file as a stripped down example and apparently made a typo. My real world config file uses the silent option with the correct case. |
I do not have a ready nginx server with rtmp module to test exactly that. Instead, I ran melt with the daemon[1] utility, and it worked for me. Here is the command I used:
I think you should use real_time=1 on the avformat consumer when streaming; otherwise, it tries to encode as fast as possible unless libavformat's rtmp is blocking and will prevent that; I do not know. I assume it does not if you have to use its -re option [2]. Maybe there is a daemon option that makes it do something closer to what nginx does to deamonize. [1] http://libslack.org/daemon/manpages/daemon.1.html |
Going out on a limb here, but you did not happen to configure mlt with --avformat-vdpau and then try to run it on headless server, did you? |
Yeah, I have real_time set in the preset file. It's contents are:
I did enable vdpau at build time, however the machine I've been testing with so far is not headless. The problem may very well be with nginx, I don't know. But I have no way to redirect stderr when it's called direct by the server to try to see what is going on. As a work-around, I've currently placed the melt command in a shell script and call the shell script instead of melt directly, and that is working |
i have been running melt from within nginx, although not directly but through a bash script wrapper ( like explained here: https://github.com/arut/nginx-rtmp-module/wiki/Exec-wrapper-in-bash ) you could try and remove the -silent option and redirect stdout and stderr to a file with appending
to see why it is not working. |
unable to reproduce |
@hatsch I started using a shell script and that is working fine. I don't think there is anyway to redirect stderr when running it directly from nginx because it is not being run in a shell. The syntax you mention only works when called from within a shell. And in a shell, it all works fine anyway... so not sure what is causing the issue. Nginx does not redirect stdout or stderr when called directly to it's log output. Perhaps to figure out what is going on, I can make a request for the nginx rtmp module to do that. |
I asked the developer of the rtmp module, and he informed me that the module itself supported stderr redirection using "2>>logfile". Figured out the problem: the quotes around the rtmp address were causing problems. Works find now. Thanks for taking the time to look into this. |
I'm trying to use melt as a playout unit within an nginx rtmp server. Running melt from the shell works fine, but the same command fails for some reason when called from within the nginx daemon. Nginx debug messages didn't really seem to tell me anything useful. I'm assuming the problem is with melt, because ffmpeg, gst-luanch, cvlc, etc. work just fine.
The text was updated successfully, but these errors were encountered: