Question / Help nginx RTMP server on debian, using avconv

Eska

New Member
Hello!

Im streaming using OBS on Windows (QuickSync), pushing 20k bitrate to 2nd PC based on linux (Debian Jessie 8.4.0, 64bit) in local network area (1gbps lan link).

Debian Jessie is a minimal linux instalation without X server (just CLI), where i compiled and installed nginx 1.10. with rtmp module.

Debian Jessie specs:

- AMD Athlon X2 64 4200
- 2GB RAM
- Regular 7200 RPM hdd


nginx.conf:

Code:
root@streamer:~# cat /usr/local/nginx/conf/nginx.conf
worker_processes 2;

error_log logs/error.log debug; events {
  worker_connections 1024;
}

rtmp {
  server {
  listen 1935;
  chunk_size 4000;

  application transcode {
  live on;
  record off;
  exec avconv -re -i rtmp://localhost:1935/transcode/1234 -c:v libx264  -preset superfast -g 60 -keyint_min 30 -b:v 2800k -minrate 2800k -maxrate 2800k  -s 1280x720 -r 30 -f flv rtmp://localhost:1935/live/1234;
  }

  application live {
  live on;
  record off;
  push rtmp://live-ams.twitch.tv/app/STREAMKEY;
  }
}
}

My question is, i can stream video using SUPERFAST preset without stutters. If ill go to VERYFAST, video on twitch is stopping every like 5 seconds for a while (not a buffering)

Is that athlon not enough to stream video with veryfast - faster preset? This machine got literally only needed stuff on the CLI Debian just to stream, so I'm not losing any resources.

I was quite sure i can push the quality as faster/veryfast with this rig.

Could anyone elaborate on the topic?

EDIT
: and could switching to ffmpeg from avconv could do any changes in performance?
EDIT2: with the ffmpeg instead of avconv i see a performance boost, but still my 2 core cpu gets up to 200% usage on "veryfast" preset, and then video on twitch shtutters.
ffmpeg version 3.0.22 - backport for jessie.

For me something is not right here, i was quite sure i can get veryfast preset with the AMD X2 64 4200+ (2.2 GHz per core) :F
Again, anyone can elaborate on this topic?
 
Last edited:

ArthurOudini

New Member
I would suggest taking away -re since your input is streamed.

I'm using a similar command line for transcoding at the moment, and also using avconv.
I believe it is heavy for CPU, using only "-i" works fine if you stream your input.

Here is a quote from FFmpeg documentation about -re :
"Read input at native frame rate. Mainly used to simulate a grab device. or live input stream (e.g. when reading from a file). Should not be used with actual grab devices or live input streams (where it can cause packet loss). By default ffmpeg attempts to read the input(s) as fast as possible. This option will slow down the reading of the input(s) to the native frame rate of the input(s). It is useful for real-time output (e.g. live streaming)."

I hope this helps, let me know.
 
Top