We have an NGINX RMTP module installed and while testing the same we came to know that the bitrate for the output was a around 7Mbps irrespective of the input stream's bitrate and as we have a lot of people watching these streams I would like to know how to reduce the same to about 4Mbps for this module?
Also, does NGNIX's RTMP module support H.265 instead of the standard H.264 which can help set the bitrate to about 2Mbps.
You can transcode the incoming rtmp stream with ffmpeg with maxrate & b:v in this case you can control the maximum bitrate. Here is a simple example(for this example use another app show as well):
application live {
live on;
exec_push ffmpeg -i rtmp://localhost/$app/$name -async 1 -vsync -1
-c:a libfdk_aac -b:a 128k -c:v libx264 -b:v 2000k -maxrate 3000k -f flv -preset superfast -profile:v baseline rtmp://localhost:1935/show/$name_with_maxrate
}
Related
I am using Nginx for live adaptive bitrate streaming. My live streaming is working fine.
Also, the chunks are getting created and the master playlist is also getting created as you can see in this image.
My config
application live {
live on; # Allows live input
exec_push /usr/bin/ffmpeg -i rtmp://localhost:1935/$app/$name
-force_key_frames "expr:gte(t,n_forced*3)" -c:v libx264 -vprofile baseline -vlevel 3.1 -s 640x360 -b:v 1200k -strict -2 -c:a aac -ar 44100 -ac 2 -b:a 96k -f flv rtmp://localhost/show/$name_hi
-force_key_frames "expr:gte(t,n_forced*3)" -c:v libx264 -vprofile baseline -vlevel 3.1 -s 240x360 -b:v 1200k -strict -2 -c:a aac -ar 44100 -ac 2 -b:a 96k -f flv rtmp://localhost/show/$name_low;
}
This is my master playlist
This is my each playlist m3u8 file
But when I point the master playlist to the videojs (hlsjs) added it is showing the quality
auto
undefinedp
But when I use some other test stream from online then it is showing me all available quality
using my live stream generated using nginx ffmpeg
using other live stream
You need to add the RESOLUTION attribute to your master playlist in the EXT-X-STREAM-INF tag. This is optional in https://www.rfc-editor.org/rfc/rfc8216#section-4.3.4.2 but it's required by the quality selector UI plugin.
See: https://github.com/chrisboustead/videojs-hls-quality-selector/issues/8
Nginx RTMP module config example:
hls_variant <variant_name> BANDWIDTH=<bandwidth>,RESOLUTION=<resolution>;
I've been attempting to transcode a stream produced by obs studio to my nginx server and send it off to youtube. Now I've made it work with twitch and I know these settings are actually transcoding it mostly correctly and is viewable. The problem being that youtube live picks it up as Bad video settings and tells me to change the current video container format. The other side effect that is probly unrelated is the stream looks really poorly on youtube. Looks like it was streamed at a poor bitrate and stuff but the real problem is the bad video settings error.
The ffmpeg command being used is as follows
ffmpeg -i rtmp://localhost/Private/Private1 -vb 6000k -minrate 6000k -maxrate 6000k -bufsize 6000k -s 1280x720 -c:v libx264 -preset faster -r 50 -g 100 -keyint_min 50 -x264opts nal-hrd=cbr:force-cfr=1 -sws_flags lanczos -tune film -pix_fmt yuv420p -c:a copy -f flv -threads 6 -strict normal rtmp://a.rtmp.youtube.com/live2/{key}
I've tried with different framerates and been googling for awhile and found nothing or interpreted everything wrongly. Either way I would be very happy for some help here.
System info.
OS: Ubuntu Server 16.04 LTS
Ram: 10gb
Processor: AMD Phenom(tm) II X6 1090T
GPU: Geforce GT 520
Internet.
Upload 15mbit
Download 150mbit
If you need any more info I will gladly send it. Thanks for reading.
Edit 1
After some googling about what I'm doing wrong I decided to try and change stuff slightly and came up with this command
ffmpeg -re -i rtmp://localhost/(app)/(key) -c:v libx264 -r 50 -g 100 -keyint_min 100 -x264opts "keyint=100:min-keyint=100:no-scenecut" -sws_flags lanczos -profile:v baseline -preset veryfast -vb 6000K -minrate 6000k -maxrate 6000k -bufsize 6000k -s 1280x720 -tune film,zerolatency -pix_fmt yuv420p -f flv -c:a copy -ac 1 -strict normal rtmp://(output site)/(output app)/(output key)
which as of my current testing seems to at least have a healthy stream for longer than 2 minutes if i only output to youtube live directly. Ive found output to my nginx server then youtube live breaks things.
my nginx rtmp settings are on this link https://pastebin.com/siE99Tv8
Edit 2
If I push the stream to a site like restream to stream it to youtube then it seems to be working. tested for 25 minutes with no change of them saying bad video container or anything. So I'm going to say nginx is partly to blame in how its distributing the files? Unsure what I'm doing wrong. I am pretty sure ffmpeg isn't to blame here at least
Seems YouTube does not like nginx. I found two solutions for this.
Solution 1
Add "meta copy;" to you nginx config as follow:
rtmp {
server {
listen 1935;
application youtube{
live on;
meta copy;
push rtmp://a.rtmp.youtube.com/live2/(key);
}
}
}
Solution 2
Modify nginx-rtmp-module/ngx_rtmp_codec_module.c and replace the line:
ngx_string("Server"),
with
ngx_string("xtradata"),
then recompile nginx.
I use arut nginx-rtmp-module (https://github.com/arut/nginx-rtmp-module) on the media server, then I tried to stream using FFmpeg to the dash application, then I test the stream by playing it using VLC.
And it waits around 30secs to start playing, and it plays from the beginning, not the current timestamp.
This is my current config on the RTMP block
rtmp {
server {
listen 1935;
application live {
live on;
exec ffmpeg -re -i rtmp://localhost:1935/live/$name
-c:a libfdk_aac -b:a 32k -c:v libx264 -b:v 128K -f flv rtmp://localhost:1935/hls/$name_low
-c:a libfdk_aac -b:a 64k -c:v libx264 -b:v 256k -f flv rtmp://localhost:1935/hls/$name_mid
-c:a libfdk_aac -b:a 128k -c:v libx264 -b:v 512K -f flv rtmp://localhost:1935/hls/$name_hi
-c:a libfdk_aac -b:a 128k -c:v libx264 -b:v 512K -f flv rtmp://localhost:1935/dash/$name_dash;
}
application hls {
live on;
hls on;
hls_path /tmp/hls;
hls_nested on;
hls_variant _low BANDWIDTH=160000;
hls_variant _mid BANDWIDTH=320000;
hls_variant _hi BANDWIDTH=640000;
}
application dash {
live on;
dash on;
dash_path /tmp/dash;
dash_nested on;
}
}
}
This is the command I use for streaming
ffmpeg -re -i 2014\ SPRING.mp4 -c copy -f flv
rtmp://52.221.221.163:1935/dash/spring
How can I reduce the delay, and make it play from the same timestamp as the streamer?
Can I achieve under 5s latency?
UPDATE
Tried to change the playlist length and fragment length, using this directive
dash_playlist_length 10s;
dash_fragment 2s;
But still got some latency problem, sometimes it's smaller than before, sometimes it's the same
Can I achieve under 5s latency?
No. DASH is a segmented protocol, meaning your media is chopped up into relatively large chunks. The player has to download some chunks before it can start playing them. Your encoder has to upload entire chunks before these chunks even appear in the manifest. This is the wrong tool for the job, and any attempts at reducing latency by cranking the chunk size down are adding massive overhead to your project. You're using the wrong tool for the job if latency is important to you.
How can I reduce the delay, and make it play from the same timestamp as the streamer?
You can't. Physics! It's impossible for you to play the same thing at the exact same time as it is being encoded. You're sending data over a packet-switched network, with many encoding/decoding steps in the way which all require a buffer as they work in chunks. The only way to playback what's coming in simultaneously is to go analog... at least there your only delay is the speed of light.
The best you can do is switch to a protocol designed for low latency, like WebRTC. Just be sure you understand the tradeoffs. Your codecs will be optimized for latency, not quality... so your quality will suffer. WebRTC over UDP (optional but common) means that some packets will get lost, causing your viewing experience to suffer. When you care about latency, it doesn't matter so much if you lose a chunk here or there, what matters is that you keep going. You can use WebRTC over TCP and keep your reliability at only a slight increase in latency.
Decide what really matters to you. In almost every case, it isn't actually low latency. You can't have it all ways. There are tradeoffs to every approach. You must decide what is best for your specific situation.
I also have the same issue with VLC media player. Most of the latency is by the client player, you can use the ffplayer with no buffer to check it.
ffplay -fflags nobuffer rtmp://192.168.1.66/myapp/live
Results of mine,
latency of VLC: 6~7s
latency of ffplay: 500ms
For more refer to comment of narlex of issue how to reduce latency on github
You may need to change the GOP size in ffmpeg command. The default GOP size for ffmpeg is 250 which means there will be a key frame every 250 frames. If your output is 25fps, then you will have a key frame every 10s in worst case (if scene cut detection is enabled, you may have shorter key frame interval).
For both HLS and DASH, the segments must start with a key frame. So you will have a lot of segments with 10s duration. You need to reduce the segment duration (the GOP size) in order to reduce latency.
Try to modify your ffmpeg command as follow to see if it helps
exec ffmpeg -re -i rtmp://localhost:1935/live/$name
-c:a libfdk_aac -b:a 32k -c:v libx264 -g 50 -b:v 128K -f flv rtmp://localhost:1935/hls/$name_low
-c:a libfdk_aac -b:a 64k -c:v libx264 -g 50 -b:v 256k -f flv rtmp://localhost:1935/hls/$name_mid
-c:a libfdk_aac -b:a 128k -c:v libx264 -g 50 -b:v 512K -f flv rtmp://localhost:1935/hls/$name_hi
-c:a libfdk_aac -b:a 128k -c:v libx264 -g 50 -b:v 512K -f flv rtmp://localhost:1935/dash/$name_dash;
I am using NGINX to receive rtmp and output to hls.
rtmp {
server {
listen 1935;
...
application rtmp {
live on;
...
exec ffmpeg -re -i rtmp://127.0.0.1/rtmp/$name -threads 1 -c:a aac -ac 1 -strict -2 -b:a 64k -c:v libx264 -profile:v baseline -g 10 -b:v 300K -s 480x240 -f flv rtmp://127.0.0.1/hls/$name;
}
application hls {
live on;
hls on;
hls_path /tmp/hls;
...
}
}
}
My stream comes from Flash Media Live Encoder. But sometimes I have flaky internet because my connection comes from mobile. Sometimes internet drops for 3-5 seconds every 5 minutes. But this is enough to disrupt the stream. Is it possible for me to make it run continuously even when my FMLE is disconnected?
I am thinking of executing an FFMPEG from the server box to stream continuously an image as a fallback when FMLE is disconnected, then combine the 2 RTMP streams. Perhaps favoring the one from FMLE if available, and the other as fallback. But I am not sure how to combine using FFMPEG.
Or is there another hack I can try?
I am using nginix web server and nginx-rtmp module for managing my video stream encoded in h264. Here is my nginx conf:
rtmp {
server {
listen 1935;
application big {
live on;
exec ffmpeg -re -i rtmp://localhost:1935/$app/$name -vcodec
libx264 -vprofile baseline -acodec libvo_aacenc -ac 1 -ar 441000
-f flv rtmp://localhost:1935/hls/${name};
}
}
application hls
{
live on;
hls_path /usr/local/nginx/html/video;
}
}
it works well in browser, however because my mobile client is Adobe Air it would only work on Android but not Apple, because Apple doesn't support H264 encoding through AIR applications, so I was trying to transcode the stream to something supported for example mpeg. And this is how I changed my ffmpeg:
exec ffmpeg -re -i rtmp://localhost:1935/$app/$name -vcodec
mpeg2video -acodec copy -b:v 10M -b:a 128k
-f mpegts rtmp://localhost:1935/hls/${name};
However it just won't show the video not in a browser nor on device, my assumption is that it probably failed to transcode.
Maybe I am missing something ? Any ideas are highly appreciated.
Thank you.
You probably got your answer already, but just in case:
You are not using the module properly,
1) On iOS you need to point your browser to http://localhost:80/hls/${name} to get the HLS stream.
2) You are missing in the config the http section to generate the HLS stream
See here for details: How can we transcode live rtmp stream to live hls stream using ffmpeg?