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

melt failing to run when called from a daemon #39

Closed
ReubenM opened this issue Apr 4, 2014 · 12 comments
Closed

melt failing to run when called from a daemon #39

ReubenM opened this issue Apr 4, 2014 · 12 comments

Comments

@ReubenM
Copy link

ReubenM commented Apr 4, 2014

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.

@ReubenM
Copy link
Author

ReubenM commented Apr 4, 2014

Forgot to mention, this is with 0.9.0.

@ddennedy
Copy link
Member

ddennedy commented Apr 5, 2014

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

@ReubenM
Copy link
Author

ReubenM commented Apr 5, 2014

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
Copy link
Member

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
Copy link
Author

ReubenM commented Apr 10, 2014

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
Copy link
Member

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
Copy link
Member

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
Copy link
Author

ReubenM commented Apr 12, 2014

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

@ReubenM ReubenM closed this as completed Apr 12, 2014
@ReubenM ReubenM reopened this Apr 12, 2014
@hatsch
Copy link

hatsch commented Apr 12, 2014

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
Copy link
Member

unable to reproduce

@ReubenM
Copy link
Author

ReubenM commented Apr 12, 2014

@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
Copy link
Author

ReubenM commented Apr 13, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants