Question / Help Two streams from 1 obs? Any ideas?

[Sou]

Hello:) I have a huge problem with Twitch since their tech support forbidden me streaming in 3500+ bitrate (I was streaming in 6000kb/s). I know that streaming in two different qualities is possible using Xsplit and it is not supported by OBS (maybe it will be someday?). Anyone know how to bypass it? I got 1 computer with i7 only for streaming (I am grabbing video via hdmi and avermedia).

Maybe some local streaming server would help? I heard about this kind of software utilizing windows server or something like that. But there is any way to run it on windows (7) ?

my computer > streaming computer > Streaming HD > local streaming server > streaming to Twitch in 3500
------------------------------------------------ > saving HD files

Thx for help ;)

 

[Sapiens]

https://obsproject.com/forum/resources/how-to-set-up-your-own-private-rtmp-server-using-nginx.50/

 

[Sou]

Thank you Sapiens, I followed your link and after few hours of trying to make it run I got nginx on windows and this in my config file:

"
#user nobody;
worker_processes 1;
error_log logs/error.log debug;
events {
worker_connections 1024;
}
rtmp {
server {
listen 1935;
chunk_size 4096;

application live1 {
live on;
record off;
exec avconv -i rtmp://localhost/live1/test1 -c:v libx264 -preset veryfast -b:v 3500k -minrate 3500k -maxrate 3500k -bufsize 3500k -g:v 120 -c:a copy -s 1280x720 -r 60 -f flv rtmp://localhost/live2/test2;

}
application live2 {
live on;
record off;
push rtmp://live-prg.twitch.tv/app/STREMKEY;
}

}
}
"

So "exec" command is not working, I tried \usr\bin etc but it didn't help. So I decided to run avconv manually and it worked! But only in VLC player, Twitch.tv is receiving "something" (stream is "LIVE" but always "loading...") but I cannot get it work :/

If anyone know how to fix this I would be glad :)

P.s Simple push command in "live1" is working fine so there must be something wrong with the transcoded video :/

 

[GodlessGeek]

"exec" is for the Linux version. It will not work on Windows. You can create a batch file and start avconv manually, after starting your stream. If you wish to spread the avconv command across multiple lines in the batch file, for easier reading, use the caret (^) character to indicate line continuation.

@echo off
cls

avconv -i rtmp://localhost/live1/test1 -c:v libx264 -preset veryfast -b:v 3500k -minrate 3500k -maxrate 3500k ^
-bufsize 3500k -g:v 120 -c:a copy -s 1280x720 -r 60 -f flv rtmp://localhost/live2/test2

pause

The path to avconv will either have to be in your Windows PATH environment variable, or you can give the full path to it in the batch file.

I have not tested this particular setup. I now use ffmpeg and the Linux version. I only stream to one destination, so I only use one application and encode directly to Twitch.

I recommend viewing the series of videos put out by Jack0r. Here are a couple, for starters:

nginx Configuration: http://www.helping-squad.com/nginx-rtmp-configuration-and-possible-solutions/
Two streams: http://www.helping-squad.com/how-to-easily-stream-to-two-or-more-locations/

 

[Sou]

I have not tested this particular setup. I now use ffmpeg and the Linux version. I only stream to one destination, so I only use one application and encode directly to Twitch.

I recommend viewing the series of videos put out by Jack0r. Here are a couple, for starters:

Thx for answer, I made my file thanks to Jack0r tutorial :) BUT as u can see it was made for linux ;) Anyway is it possible for you to paste here you ffmpeg line? Maybe it could work for me after small changes:)

 

[Sou]

Ok this one is worked for me: "ffmpeg -i rtmp://localhost/live1/test1 -c:v libx264 -preset veryfast -pix_fmt yuv420p -g 120 -s 1280x720 -b 3500k -minrate 3500k -maxrate 3500k -bufsize 3500k -c:a copy -threads 0 -f flv rtmp://localhost/live2/test2" but I can't get 3500k bitrate and a lot of frames (I checked it with video stats on Twitch) are dropped:/

I still can't get any video from "avconv -i rtmp://localhost/live1/test1 -c:v libx264 -preset veryfast -pix_fmt yuv420p -b 3500k -minrate 3500k -maxrate 3500k -bufsize 3500k -g 120 -s 1280x720 -r 60 -c:a copy -threads 0 -f flv rtmp://localhost/live2/test2"

EDIT: I downloaded different (64bit) version of avconv and it is working o_O

 

[Sou]

OK so today I spend another 5 hours trying to make it work:/

Problems that I have now:

Cannot send correct stream with "push" in nginx. In VLC application is running ok, constant fps etc. On Twitch/Hitbox every few seconds fps is dropped from 60 to ~5 and again to 60.

So I deleted "push" from my nginx config and tried to use only ffmpeg:

ffmpeg -i rtmp://localhost/live1/test1 -c:v libx264 -preset veryfast -vsync cfr -pix_fmt yuv420p -g 120 -s 1280x720 -b:v 3500k -minrate 3500k -maxrate 3500k -bufsize 3500k -c:a copy -threads 0 -f flv rtmp://Live-lhr.Twitch.TV/app/KEY

It seems like ffmpeg cannot transcode the source from nginx/obs (10000kb/s, 60fps, 1280x720) on time, fps are jumping, bitrate is not 3500 etc. CPU use is ~40%...

Maybe it is normal with ffmpeg:/

 

[Jack0r]

Hmm different versions of ffmpeg (older versions especially) had problems with rtmp streaming. You mentioned downloading avconv earlier, now ffmpeg.
I assume the initial OBS stream to nginx works without dropped frames?

One thing about your commandline that bugs me, why are you using "-threads 0"?

 

[Sou]

I downloaded ffmpeg from here: https://www.ffmpeg.org/download.html

OBS streaming to nginx works fine, I can watch it witch VLC on local and it is ok but If i "push" it with nginx, stream on Twitch got lag (dropped frame) everey few second. I got -threads 0 from some other ppls configs;) It should tell ffmpeg to use all cores of my processor I assume...

 

[Jack0r]

Assuming 0 unlimits the threads, but I would recommend to keep it to the x264 to decide, it normally does a decent job, maybe remove that part. You now mentioned push with nginx, but earlier mentioned that ffmpeg shows inconsistent frames/bitrates. We have to sort this a bit.

Now assume we run OBS to stream to nginx (10mb/s/60fps/720p), that works fine. Start ffmpeg and just let it save to a file, instead of streaming back to nginx. Use the settings as you would let it stream, but just record for 5 minutes. Then check the file and see how ffmpeg acted.

If everything went smooth, next test, ffmpeg this time streams to nginx (but no push to twitch), then try watching the ffmpeg stream with vlc like you did earlier with the OBS stream :)

If everything went smooth, add the push directive to nginx, so you run ffmpeg but nginx does the push to twitch. Dont watch the stream on twitch, just stream for 5 minutes and then download the vod and only check the download file. You will notice if dropped frames occured (the picture will be distorted or stop).

If that did not go smooth, you could last but not least run ffmpeg yourself but this last time let it stream to twitch directly, always check "how" ffmpeg acts, fps/bitrate/etc. and then again download the recorded video from twitch.
(Checking it live depends too much on the twitch servers, but if you download the recorded video you can then run it from your harddisk and any network problems are ruled out, but if you had problems sending the packages to twitch, the video will show this)

 

[Sou]

Ok so this are results:


1. I starter nginx and OBS, I run: "ffmpeg -i rtmp://localhost/live1/test1 -c:v libx264 -preset veryfast -vsync cfr -pix_fmt yuv420p -g 120 -s:v 1280x720 -b:v 3500k -minrate 3500k -maxrate 3500k -bufsize 3500k -c:a copy -f flv out.flv

and file looks ok, ffmpeg "cmd" is showing ~60fps and q=~30, bitrate ~3500

2. VLC might not be the best tool, I watched "live1" and it was laggy than VLC had error, without changing anything I run VLC again after few minutes and everyhing looks fine on live1... I run It again and it was again laggy, I decided to keep it open and run ffmpeg to file from live1. . The out.flv was ok.... So I decided to not use VLC anymore :p

3. I changed ffmpeg to send everything to rtmp not to the file "ffmpeg -i rtmp://localhost/live1/test1 -c:v libx264 -preset veryfast -vsync cfr -pix_fmt yuv420p -g 120 -s:v 1280x720 -b:v 3500k -minrate 3500k -maxrate 3500k -bufsize 3500k -c:a copy -f flv out.flv"

fps was ~45 and jumping, q= was jumping a lot, bitrate was ~2000 and it crashed o_O

I check it again and it crashed again.

So here is ffmpeg working when it is saving to file (ffmpeg -i rtmp://localhost/live1/test1 -c:v libx264 -preset veryfast -vsync cfr -pix_fmt yuv420p -g 120 -s:v 1280x720 -b:v 3500k -minrate 3500k -maxrate 3500k -bufsize 3500k -c:a copy -f flv out.flv)


ffmpeg streaming to rtmp (ffmpeg -i rtmp://localhost/live1/test1 -c:v libx264 -preset veryfast -vsync cfr -pix_fmt yuv420p -g 120 -s:v 1280x720 -b:v 3500k -minrate 3500k -maxrate 3500k -bufsize 3500k -c:a copy -f flv rtmp://Live-lhr.Twitch.TV/app/live_72207403_QXuRvFUGzanARowXk66ymIGNmoLeXB)


4. I decided to try obs > nginx > live1 >ffmpeg > live2 > nginx > Twitch

"ffmpeg -i rtmp://localhost/live1/test1 -c:v libx264 -preset veryfast -vsync cfr -pix_fmt yuv420p -g 120 -s:v 1280x720 -b:v 3500k -minrate 3500k -maxrate 3500k -bufsize 3500k -c:a copy -f flv rtmp://localhost/live2/test2"

"
#user nobody;
worker_processes 1;

error_log logs/error.log;
error_log logs/error.log notice;
error_log logs/error.log info;

#pid logs/nginx.pid;


events {
worker_connections 1024;
}


rtmp {
server {
listen 1935;
chunk_size 4096;

application live1 {
live on;
}
application live2 {
live on;
push rtmp://Live-lhr.Twitch.TV/app/KEY;
}
}
}"

Ffmpeg during stream:


Result on Twitch.tv:

http://www.twitch.tv/sstesttest/c/5222191 (hope it works, just wait few seconds, Twitch highlight tool sucks ;)

I checked it in VLC and it was not so bad like on Twitch but I saw some artifacts (even on live1). I checked it again and it was ok... (WTF VLC?!).

At the end I decided to just run another ffmpeg and save live1 and live2 to file. Both were OK!


5. Last test, simple "push" (live1) command and OBS stream in 3500kb/s

result (very bad): http://www.twitch.tv/sstesttest/b/574159806


CONCLUSION

Everything saved by ffmpeg in file was ok, live1, live2 after ffmpeg transcoding etc. Something is wrong with sending to rtmp (in ffmpeg and also in nginx when Im "pushing" the stream).


Thx for help :)

 

[Sou]

Anyone?:(

 

[GodlessGeek]

Anyone?:(

I wish I could help you more but I was also having problems like this on Windows and couldn't solve them. I dual-boot with Linux so I tried switching my nginx / ffmpeg setup to that OS and my problems went away. I've been using Linux for my streaming ever since.

 

[Sou]

I wish I could help you more but I was also having problems like this on Windows and couldn't solve them. I dual-boot with Linux so I tried switching my nginx / ffmpeg setup to that OS and my problems went away. I've been using Linux for my streaming ever since.

Do u think using "virtual" linux would work?

 

[Timothy003]

I've also encountered this issue on Windows Server 2008 R2 (which shares the same code with Windows 7), and I discovered that the send window was too small, bottlenecking FFmpeg. Neither FFmpeg nor nginx-rtmp allow you to adjust their send windows, so I changed Windows's default send window (no pun intended).

I've attached the registration entry for your convenience. It sets the default send window to 64K. Apply the entry and restart your computer. FFmpeg should then be able to stream to Twitch at full speed.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters]
"DefaultSendWindow"=dword:00010000

By the way, you probably don't want '-vsync cfr'. This will force FFmpeg to duplicate frames in case of frame drops.

 

[Jack0r]

Hmm, a bigger sendwindow or receivewindow might help, assuming for some reason the ACK takes too long, and it will probably use less ACK's as well.
I found "-vsync cfr" being the only option to force a constant framerate out of ffmpeg, so I use that option as well.

 

[Sou]

Timothy003, THAT WAS IT!!! You guys are awesome!:) Now I will have to work with the ffmpeg settings and obs settings to run it both on i7 wihout lags;) Thank you guys!:)

 

[Timothy003]

Hmm, a bigger sendwindow or receivewindow might help, assuming for some reason the ACK takes too long, and it will probably use less ACK's as well.
I found "-vsync cfr" being the only option to force a constant framerate out of ffmpeg, so I use that option as well.

The problem isn't with ACK timing; it's the tiny default send window of 8 KiB. With a 50 ms RTT, this translates to: 8192 B / 0.05 s = 1310 kb/s maximum throughput. OBS explicitly sets the send window to 64 KiB and scales it up as the congestion window increases, while FFmpeg and nginx-rtmp rely on the OS to adjust the send window for them. Technically, Windows 7 features automatic send window adjustment, but it doesn't kick in because librtmp makes very small sends.

Live streaming inherently has a variable frame rate, since frames are dropped if they're delayed for too long. In the event of dropped frames, FFmpeg will fill in the missing frames with duplicates. This stalls the pipeline and will potentially cause nginx-rtmp to drop even more frames. What are you trying to solve by forcing a constant frame rate?

Timothy003, THAT WAS IT!!! You guys are awesome!:) Now I will have to work with the ffmpeg settings and obs settings to run it both on i7 wihout lags;) Thank you guys!:)

That's great! Good luck on tuning your settings. Hardware encoders are perfect for this.

 

[Jack0r]

Its mainly compatibility for Premiere/Vegas etc, they always seemed to have problems with variable framerates and audio sync. So if you wanted to edit parts of your stream later, you had a problem if cfr was off.
(Thanks for the clarification about the send window :))

 

[Timothy003]

You can find the original solution here:

http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=657&start=60

Thankfully, the default send window in Windows 8 is 64 KiB, so most apps will work out-of-the-box in the future.

My understanding was that you'd be using the high-quality recordings for editing, which was the point of this setup. You don't edit the footage you send to Twitch.