just keeping things short at the beginning.

I stream via rtmp with avconv through a nginx configuration. Catching that stream onto a website is only possible via flash as far as i know. Nowadays it's a bad thing to play flash files via a smartphone (iPhone/Android/whatsoever). What I want to do is, grabbing that stream (incoming as rtmp) and convert that into a HTML5 playable file/stream. I know about the possibility about dash on; or hls on; but it's not really working flawlessly. (I have to turn on CORS, to get that damn thing up and running but then it's still stuttering)

Here are my settings:


avconv \
-f video4linux2 -input_format mjpeg -r 10 -s hd720 -i /dev/video0 \
-f video4linux2 -input_format mjpeg -r 10 -s 640x480 -i /dev/video1 \
-vf transpose=cclock -filter_complex  \
"[0:v]scale=1280:-1,setpts=PTS-STARTPTS[bg]; \
[1:v]scale=320:-1,transpose=cclock,setpts=PTS-STARTPTS[fg]; \
[bg][fg]overlay=W-w-10:10[out]" \
-map "[out]" -vprofile baseline -vcodec libx264 -preset fast \
-maxrate 3000k -bufsize 6000k -b 500k \
-f flv rtmp://STREAMURL


    rtmp {
    server {
            listen 1935;
            chunk_size 4096;

            application webcam {
                    live on;
                    record off;

                    allow publish a.b.c.d;
                    deny publish all;

                    allow play all;

                    #exec /usr/bin/avconv -loglevel verbose -i rtmp://STREAMURL -vcodec libx264 -vprofile baseline /tmp/out.mp4;
    } } }

that commented line is producing an output file, which is growing by time. That may be ok in some configuration, but on an ongoing stream 24/7 it's not a really good solution I guess.

Anyone got a smart idea or an hint how I can get my problem solved: - Fetching rtmp stream, convert it into HTML5 playable file that is only cached and not safed to harddrive.


I'd personally use an Icecast server and feed that from avconv. But then again I'm sort of biased as the Icecast maintainer.

It would address your problem of a growing file, as Icecast only keeps a small (configurable) buffer in memory and by default doesn't write to any files. Also note that you should keep the keyframe interval fairly short. Then browsers shouldn't have problems to lock on to the closest keyframe in the initial data.

I'd also use WebM and not h.264, but that is my preference for non-proprietary codecs. In case of WebM, I'd keep the keyframe ratio below 1:10-1:15.

That said, HLS or DASH might be alternatives to be explored. Avconv has a sort of HLS output mode, but probably needs some additional scripts around it to clean up outdated chunks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.