Livestream and Local Recording

[ubuntuaddicted]

I was wondering how easy/hard it would be to allow an option to not only livestream but also save a copy of the livestream locally as well. I stream to hitbox and sometimes their archiving is suspect and my livestream didn't get saved. So if i had a local copy of the livestream I wouldn't have to worry about hitbox not archiving my stream. Thanks

[MaartenBaert]

It's more complex than it sounds, ffmpeg wasn't really made for this. The easiest solution is to encode everything twice but that's just way too slow. I think I know a solution but I will have to redesign some parts of SSR, and it's not my highest priority.

If you're not too worried about upload/download usage, you can just download and save your own stream with rtmpdump. You can even do this on a separate computer.

[ubuntuaddicted]

i thought about that as a solution (using rtmpdump) but then I started thinking more, what if I wanted to record locally at a different bitrate. for youtube videos at 1080p i'd like a way higher bitrate than what I stream at (3,000Kbps). Can i run 2 instances of ssr? i use a facecam by using guvcview with "always on top" but what if I wanted the local recording to not have that facecam in the local recording? i know, it's getting really complicated now. probably out of the scope of the project. Just really itching for similar features as to what i use in windows when I stream using OBS.

[MaartenBaert]

You can do that, but if you want a different bitrate then you definitely have to re-encode. It could be doable if you use one of the faster preset for your file and a slower preset for streaming. But you will still need a powerful computer and lots of RAM.

You can run two instances of SSR. It's obviously less efficient than running a single instance that would capture once and encode twice, but the difference isn't huge.

[ubuntuaddicted]

ok, i'm a little confused on your response. my goal is to stream 3,000Kbps to hitbox with a facecam and record locally at 25,000 without a facecam. it's not possible with the current state of the software but are you saying it's possible if i run 2 instances of ssr? i don't see a way to not record the facecam unless i use opengl recording because then it's not a screen grab, it's actually recording before it draws the game to the screen.

My rig is an i5-4670k @ 4.0Ghz with 8GB of 2133Mhz G-Skill Sniper RAM.

[MaartenBaert]

I was simply referring to local recording. Clearly there's no way for SSR to see right through a window that you've placed there :).

You also can't record the same glinject stream with multiple instances of SSR, that will create conflicts.

[ubuntuaddicted]

i could use glinject for the local recording at 25,000Kbps (since it would only record the game correct?) and normal screen grab for game+facecam and stream that to hitbox at 3,000Kbps. should work right?

[MaartenBaert]

Yes, just use a fast preset (superfast or even ultrafast) for the local recording. But in that case it's a lot smarter to use the constant quality mode ('constant rate factor') for the local recording, there is no need to do a fixed bitrate in this case. Fixed bitrate encoding is almost always slower, larger and lower quality :).

[ubuntuaddicted]

the only reason to use the fixed bitrate encoding is because i get the bitrate i want. i am not sure what CRF factor to use to get around 25Mbps, do you?

[MaartenBaert]

If you can't even tell the difference, then why would you care?

You shouldn't care about bitrate. Bitrate is not the same as quality. Video with lots of fast movement will need a significantly higher bitrate than a video of a mostly static image. So don't look at the bitrate, just set a quality (23 is a good starting point, maybe use 20 or 17 if you want something better). Do a test with that setting, and if you like the result, keep it. All your video will have that same level of quality, regardless of the content.

If you still don't believe it, try this:

• Start SSR, record your entire screen in constant quality mode with crf 23.
• Open a terminal and maximize it.
• Look at the bitrate in SSR. It's going to be really low because nothing is moving.
• Now run 'cat /dev/urandom | base64' in your terminal. This simply prints an endless stream of random characters.
• Look at the bitrate again. It's now something like 40Mbps.
• Stop the terminal command with Ctrl+C.
• Look at the bitrate again. It will immediately drop.
• Watch the resulting video in your favorite video player. Pause it so you can look at the frames where the text in the terminal is scrolling by. They will be perfectly readable. If you want, you can try the same thing again with a fixed bitrate. Unless you use an insanely high bitrate for the entire video, the result will be blurry.

Constant bitrate is something invented by the movie and TV industry for practical reasons: Their cables have a fixed speed and they have already paid for it, so they have no reason not to use them at their highest speed all the time. It also makes sense for live streaming because you don't want huge bitrate spikes. And for some reason Twitch refuses to work properly not just if your bitrate is too high, but also if it is too low (which makes no sense at all, it's just wasteful), so in that case you have no choice. But it makes absolutely no sense when you are recording a video to a local file.

[ubuntuaddicted]

WOW, this is great information. I hadn't realized this regarding constant bitrate vs variable bitrate and how the use of a CRF factor keeps the quality constant but the bitrate changes based on the needs of the video output. This whole thing came to light because someone told me they record their titanfall gameplay at 25Mbps so that when they upload their 1080p video to youtube that youtube encodes/compresses it so much that it still has great quality BUT if they start with a source file that's only 8Mbps and then upload to youtube it will look not as good. I thought this didn't make sense because youtube will always re-encode your file to around 8Mbps for 1080p content. So i wanted to run a test by recording footage at 25Mbps and uploading to Youtube and then doing the same for 8Mbps and uploading. I did that and they both look the same to me. Here's the 2 videos 25,000Kbps bitrate set using ssr libx264 custom options: https://www.youtube.com/watch?v=rNl6Nh5JXTc 8,000Kbps bitrate set using ssr libx264 custom options: https://www.youtube.com/watch?v=xjEqHav3-Ls

So basically my question is that if youtube is going to compress/encode my video no matter what, does it pay to start with a really high bitrate source video versus just recording with a lower bitrate?

[MaartenBaert]

Every time you re-encode something, the quality degrades. You can't avoid this. Encoding adds compression artifacts. If you encode something twice, the second encoding adds its own artifacts on top of whatever artifacts already existed. If your first encoding was of a higher quality, it will introduce less artifacts, but it won't reduce the artifacts created by the second encoding. So yes, it helps to use a higher quality for the first encoding, but at some point the artifacts of the first encoding will become negligible compared to the artifacts created by the second encoding.

However, even when you encode the same video twice, bitrate is still not a good measure of quality. If you encode something at 8Mbps with preset=superfast, it will look significantly worse than when you do the same with preset=medium. I don't know what preset YouTube uses (in fact I don't even know whether they use x264, I've heard that they have their own modified version of x264), but it's probably a faster preset because they want to keep down their server costs.

Because of all these effects, it is really hard to predict how good a video is going to look if you use a fixed bitrate. That's why I encourage everyone to simply use CRF when possible.

[dubslow]

FWIW, I would also love to see some more livestreaming features added. For reference, OBS is a GPLd streaming program, for Windows only (if it weren't, neither I or ubuntuaddicted would ever have been here, I suspect :P).

Despite my lack of knowledge about video/audio/encoding/whatever, C++, and lack of time, I will try and slowly add stuff.... but my contributions would be minimal at best, unless they're basically copying from OBS :).