melt failing to run when called from a daemon

[mltframework]

melt failing to run when called from a daemon

[ReubenM]

Forgot to mention, this is with 0.9.0.

[ddennedy]

What is the output/consumer that you are using? Show an example command line you are running.

[ReubenM]

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;
        }
    }
}

[ddennedy]

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.

[ReubenM]

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.

[ddennedy]

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:

daemon -- melt -silent -profile square_ntsc noise: -consumer avformat:'udp://224.224.224.224:1234?pkt_size=1316&reuse=1' f=mpegts vcodec=mpeg2video vb=2M acodec=mp2 ab=256k real_time=1

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
[2] https://trac.ffmpeg.org/wiki/StreamingGuide#The-reflag

[ddennedy]

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?

[ReubenM]

Yeah, I have real_time set in the preset file. It's contents are:

flags=+genpts

f=flv
real_time=1

acodec=libfdk_aac
vbr=3
ac=2
ar=48000

vcodec=libx264
vpre=medium
preset=medium
trellis=2
crf=20
g=1

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

[hatsch]

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 )
probably melt is not finding the properties file?

you could try and remove the -silent option and redirect stdout and stderr to a file with appending

 >file.log 2>&1 

to see why it is not working.

[ddennedy]

unable to reproduce

[ReubenM]

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

[ReubenM]

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.