Two Things Missing Before I Can Use This Software...
- Thread starter Jaxel
- Start date
I'll just hijack this thread in order to leave my thanks for this great project. I don't have the best PC, just a casual laptop, and OBS worked pretty damn well for me. My ultimate goal is to use this for console streaming so I'm hoping that Haupaugge support is added in the future. I just wanted to say thanks for creating this freeware that already worked better for me than the most popular software out there. In the long run, if OBS allows me to stream my console games readers of my site, I'll be very thankful.
Thanks Jim!
Thanks Jim!
Fire said:
Not to throw in a 'me too', but I think people would click GPU assisted (or lan) encoding in droves and those that don't know what it is would also cast their vote for it after they figure out how much better it would make their streaming experience. Not just that, but it would also be a huge adoption point for OBS as no other streaming software has it. Although I know that something like that would probably take quite awhile to implement.
I can dream of a day when everyone can stream equally and it wont feel like I have weights attached to my feet while streaming. And then feel bad for upgrading my computer when I could've simply added a $20 video card to it.
Bensam123 said:
I think you're overestimating the performance increase of GPU accelerated encoding just a tad ;)
Network encoding is a pretty cool though, however it gets a bit unfeasible at much higher than 720p unless your internal network and network cards are 10gbit links, if memory serves, and I'm not sure it would even give a true performance bonus on a realtime stream.
Network encoding would need 663Mbit (so less than 1Gbit) for 720p 60fps. 1080p 30fps would need 746Mbit (so also less than 1Gbit, but keep overhead and cheap network equipment in mind -- this is pushing it); double that for 60fps. So it's all definitely less than 10Gbit (even 1080p60 RGB24 would only need about 3Gbit).Fire said:
Muf said:
I was thinking about raw RBG network transfer ( 720p60 rgb24 requires roughly double that, ~1.3gbps ), you're talking about YUV420. Overhead's going to add quite a bit more than you'd like to admit, and then you add the encoded stream being sent back to the master node on top of that ( Not very much all I admit ). Way too much network traffic and will very very quickly congest networks ( especially on consumer hardware ), that's not even mentioning the extra system load from dealing with that much traffic ( varies by hardware, physical cards deal with it way better than integrated )
I've personally only dealt with 1 and 10 gig links, so that's why I said 10 :p pretty sure there's some fives floating around, but you'd also need switches that support the higher speed, further increasing the cost to bolster the network bandwidth ( Unless your hardware is fancy enough to support bonding, but that's a whole other can of worms )
Yeah, lan encoding wasn't talking purely about pushing the raw frames across the network (although that's a option with enough bandwidth), but doing some very light encoding to make it manageable or changing the format and then pushing it across the network. 1Gbps is quite a bit of bandwidth to work with, the important part is getting the encoding workload off of the computer it's on.
All a normal streamer would have is some internet traffic cruising around their internal network, this wouldn't make it unusable at all. It's entirely possible to segment networks too, such as using a dedicated device for the encoding network or putting it on a subnet, there are a lot of options here. I've used a gig network for ages to transfer files between a server and my normal desktop, this doesn't have nearly as much of a impact as you're making it out to be and even IF the network becomes congested ethernet is quite robust at dealing with situations like that (such as QoS and prioritization). The network isn't just going to explode and start on fire (perhaps in the days of hubs and 10mb half-duplex).
Now GPU encoding would also most definitely make a huge difference. From early results from the doom9 forums using GPU assisted encoding to using Avermedia Live Gamer HD you're talking about huge improvements in performance and fluidity. Obviously the doom9 results only relate to x264 encoding, but from people I've talked to who use the Live Gamer HD and xsplit, that removes all of about 3% of the workload from your processor.
Getting rid of the encoding workload is really the huge kicker, you definitely can feel it operating in the background even with a reduced workload. So getting OBS down from 35% processor usage during streaming to 3% would be a huge deal. Even if 20% of your processor isn't being used (such as when I stream NS2), it definitely has a big impact on fluidity. That 'free space' isn't really free either. Turning up my res to native increases that workload by about another 10%, so I have 10% free and while it makes sense that it would feel the same as there is still a buffer, it doesn't. It reduces the framerate in game and the fluidity because the processor still has to deal with and manage the workloads.
Even if the whole thing couldn't be offloaded right away, if the workload can be moved off of the processor in any shape or form it's worth pursuing. I've looked at capture cards and in addition to reduced quality you basically end up in a setup similar to a lan encoding setup. Paying a $200 premium just to get hardware assisted encoding (Live Gamer HD) shouldn't be a option for anyone. I'd rather pay a extra $200 for a hexa-core and simply switch OBS's affinity to the last two cores and leave my games on the first four.
Ideally though, that can simply be done with a $20 graphics card pretty much every single streamer can simply put into their computer if they don't already have a processor with a IGP. We're talking about people with low end computers that couldn't stream before being able to. I've actually heard this quite a few times. Some people want to stream, but they can't because their hardware sucks and they don't have the money to upgrade. This is actually quite common and there is a pretty big entry fee to get into streaming unless you already have the latest and greatest computer.
I barely made that cut with my i7-860, which is pretty beefy, but three years old. I still ended up upgrading because the performance was agonizing, especially in more demanding games. Honestly if I hadn't been able to stream semi-fluidly on my older computer I would've simply given up and moved on. At the time I didn't expect I would be buying a new system just to try and improve things. I'm sure a lot of people who stream can relate to this.
All a normal streamer would have is some internet traffic cruising around their internal network, this wouldn't make it unusable at all. It's entirely possible to segment networks too, such as using a dedicated device for the encoding network or putting it on a subnet, there are a lot of options here. I've used a gig network for ages to transfer files between a server and my normal desktop, this doesn't have nearly as much of a impact as you're making it out to be and even IF the network becomes congested ethernet is quite robust at dealing with situations like that (such as QoS and prioritization). The network isn't just going to explode and start on fire (perhaps in the days of hubs and 10mb half-duplex).
Now GPU encoding would also most definitely make a huge difference. From early results from the doom9 forums using GPU assisted encoding to using Avermedia Live Gamer HD you're talking about huge improvements in performance and fluidity. Obviously the doom9 results only relate to x264 encoding, but from people I've talked to who use the Live Gamer HD and xsplit, that removes all of about 3% of the workload from your processor.
Getting rid of the encoding workload is really the huge kicker, you definitely can feel it operating in the background even with a reduced workload. So getting OBS down from 35% processor usage during streaming to 3% would be a huge deal. Even if 20% of your processor isn't being used (such as when I stream NS2), it definitely has a big impact on fluidity. That 'free space' isn't really free either. Turning up my res to native increases that workload by about another 10%, so I have 10% free and while it makes sense that it would feel the same as there is still a buffer, it doesn't. It reduces the framerate in game and the fluidity because the processor still has to deal with and manage the workloads.
Even if the whole thing couldn't be offloaded right away, if the workload can be moved off of the processor in any shape or form it's worth pursuing. I've looked at capture cards and in addition to reduced quality you basically end up in a setup similar to a lan encoding setup. Paying a $200 premium just to get hardware assisted encoding (Live Gamer HD) shouldn't be a option for anyone. I'd rather pay a extra $200 for a hexa-core and simply switch OBS's affinity to the last two cores and leave my games on the first four.
Ideally though, that can simply be done with a $20 graphics card pretty much every single streamer can simply put into their computer if they don't already have a processor with a IGP. We're talking about people with low end computers that couldn't stream before being able to. I've actually heard this quite a few times. Some people want to stream, but they can't because their hardware sucks and they don't have the money to upgrade. This is actually quite common and there is a pretty big entry fee to get into streaming unless you already have the latest and greatest computer.
I barely made that cut with my i7-860, which is pretty beefy, but three years old. I still ended up upgrading because the performance was agonizing, especially in more demanding games. Honestly if I hadn't been able to stream semi-fluidly on my older computer I would've simply given up and moved on. At the time I didn't expect I would be buying a new system just to try and improve things. I'm sure a lot of people who stream can relate to this.
Bensam123 said:
Your file transfers ( at least with windows! ) are not even getting close to the type of throughput we're talking about, nor are they as extended. 600+mbit can very easily overload a standard consumer router ( Have you ever put your hand on one of those things? They're hot as is, and they get even hotter when they're dealing with a lot of traffic. Doing that for a greatly extended period of time...? You do the math )
You can't compare the live gamer to gpu encoding at all, the live gamer is a hardware encoding card, as in it's an h264 encoder built into a chip and it takes the entire workload away from the processor. You don't get to configure anything remotely like you can with x264, and avermedia's encoder is extremely bandwidth in-efficient on top of it's quality loss ( It deals absolutely horribly with static scenes, plus ye olde "h264 pulse" ).
Streambox setups with multiple computers are very common and very good, you remove the workload from your machine entirely by simply cloning your gpu's secondary output to a capture card on another machine. This does not reduce quality unless you're using a bad capture card.
x264 benefits from multiple cores. With a hexacore you'd be better off letting both it and your game use all six cores instead of letting it overload the last two cores ( Which it probably will if you're encoding something hard enough that you'd need a hexacore in the first place ) trying to push a workload with intentionally limited resources.
You're not going to get the kind of performance via opencl out of a $20 card as you will out of QuickSync in an IGP. Low end graphics chips are usually just rebrands of the previous era ( which in turn are rebrands of the previous era, etc 8600GT -> 9500GT -> GT 150 ), have most of the features you'd need disabled or otherwise hamstrung ( See, Here, You might not be able to offload anything useful at all ), and their clock speeds are intentionally reduced most if not all of the time.
Quicksync and what's being built into the newer AMD chips is probably the best bet for an increase in performance here as it's something that most people streaming are already going to have but obviously won't be using ( Because they have discrete graphics chips! ).
The general idea however, regardless of if you're talking about network encoding, gpu acceleration, or offloading things to the IGP ( Technically GPU acceleration still..? ), it not to offload everything, but just to provide any performance boost. If you could offload even a quarter of the rendering cost to another machine on the network you'd still be far better off performance wise.
I do have to admit that my favorite "solution" though is still a streambox, mainly because they're built for a specific use case, and as such they're cheaper to build since the only thing they're doing is encoding a stream instead of trying to upgrade your machine to be strong enough to encode the stream and play the game at full framerate.
The barrier of entry to streaming does exist, and if you're running older hardware it is pretty harsh. That's one of the reasons why so many external capture/streaming devices are coming out ( Roxio, Elgato, even Avermedia is releasing a portable Live Gamer HD ). It caters to people who don't have the money for a full system upgrade or simply can't upgrade at all ( Hello laptops! Congratulations on your ability to finally stream at decent rates! ).
I feel like I'm just rambling at this point covering all of these points, and I'm sure I've made a couple mistakes here and there.
endnote: reducing cpu load is the end goal, but making better use of the load you already create is the more important goal on the way there. Efficiency is key.
I don't understand how transferring 10GB over the network (at close to peak speeds, 955~Mbps) while playing games doesn't qualify as thoroughput? Or for that matter having a backup going in the background with Acronis doing similar things. I think that most definitely qualifies as sustained transfers too. I'm assuming you have a gigabit lan at home, most devices hit over 900Mbps with nothing special (you can do this yourself). Consumers with SSDs now days easily hit the gigabit cap. I'm still using the same gigabit switch I bought when consumer gigabit hit the market close to 10 years ago.
Network devices don't heat up and explode and they do handle sustained transfers quite well. The only time I've heard of this being a issue is with shotty routers that aim for the bottom line, but this has nothing to do with routers (there aren't many gigabit routers available for sale as well). You could simply install another NIC in each computer and run a cable between the two too... There are many different opportunities to fix a issue like this... Cheap too and that's what appeals to streamers who are primarily just your average gamer.
Yup, I'm well aware of the the quality loss associated with the Gamer HD as well as with GPU encoding (not GPU assisted encoding). The fact is that when it operates, it takes all but 3% of the load off your CPU. In other words removing the encoding workload presents a huge benefit to the person using the computer. I never said this was a good option or one that everyone should use, only that it offers a case to removing the encoding workload and moving it else where offers a significant benefit to whomever is streaming.
Quality, price, and feasibility is what I'm trying to address by suggesting lan and GPU assisted encoding. Compared to other alternatives such as the Live Gamer HD, a capture card, or a hexa-core processor they're most definitely superior.
I've looked at, read up, and even experimented with capture cards, they most definitely reduce the quality. The very fact that it turns into a video signal and it has to be turned back into a raw format changes how it looks. A testament to this is that all capture cards aren't the same. You can't buy a $100 capture card and hope it to perform as well as a $1000 capture card? Why is that? Because they actually have to interpret and adjust the image, software completely aside. So in order to get a good quality picture you're reaching into the $1000 price range which is also pretty ludicrous for joe the average gamer.
When you look at the input from the capture card it should look identical to your screen (even before you do a encode on it). This should be pixel perfect, because that's what I get by using DXtory or screencap and OBS, I expect no less from another solution. You're still stuck with having to setup another computer as well. I admit it's a creative solution, but it's like taping a bunch of things together that should be done in a all in one solution and call it good. Lan encoding simply skips this duct tape fix all together.
You wouldn't lose quality with lan encoding vs capture, you wouldn't need to buy a capture card, and if you don't have a gigabit network it's very easy to come by. Pretty much every computer made in the last 6-7 years has built in gigabit so all you need is a cable (gigabit does automatic crossover). Conversely gigabit switches are about $20 compared to a $1000 good capture card or a $500 decent one. Capture cards under $200 are junk.
Also, please keep in mind that 'capture card computers' are so common because CPU usage for encoding is such a huge issue for gamers. This isn't the sign of a solution, it's a symptom of the problem.
The thing is with cores and streaming is you can still tell it's operating on your processor. Even if your processor isn't getting pegged you definitely can feel it operating in the background and you take a FPS hit even with it going from 80% usage to 90% usage. I already tried messing with affinity and three cores isn't enough for most video games now days, especially if it intelligently figures out you have four and tries to balance itself out based on how many threads it sees. That can lead to some really wanky results if you try to put a game on three cores and put encoding on the fourth core. Most games are made for four cores now, so even if you have six, it'll still max out at four. So that leaves the last two for encoding. Adjusting affinity has nothing to do with load balancing and has everything to do with keeping encoding from influencing gaming.
Ideally I'd like to skip the whole notion of this as it's another $500 solution that most people would rather not buy. Yet, some streamers actually do purchase hexacore processors or server grade processors in order to deal with the encoder workload. I contemplated buying a Xeon or a Opteron JUST for streaming to alleviate these issues, even though I'd run into slower performance due to lower clocks. This is another brute force solution that isn't elegant at all.
Quicksync is GPU encoding, not GPU assisted encoding. You wont get the same performance out of GPU assisted encoding with OpenCL, but the point wasn't to get the same performance out of it, but rather reduce processor strain while maintaining the same level of quality we've come to expect from normal encoding via OBS and dxtory/gamecapture. Also from what I read when reading up on GPU encoding/Quicksync is the APIs are utter garbage and not well documented at all. GPU makers, Intel/AMD/Nvidia, just wanted to add the GPU encoding 'badge' to their processors without putting any real work into it.
Maybe $20 is too cheap, but you can get some really decent low end GPUs for around that price point with MIRs or even under $50. AMD low end solutions aren't rebrands of previous gen cards. They have legitimate low end offerings and you can get still get cheap Nvidia cards. All of them support OpenCL though. The point was it's a lot cheaper then all the other solutions.
I really don't know why we're discussing low end GPU specs though, this would be a secondary card in addition to a discrete primary graphics card. I'm sure there is a baseline as to how fast they would need to be in order to do realtime encoding, but chances are that's not going to be that big of a deal since GPUs are awesome at parallelized tasks. If there is something that can't be offloaded to a GPU it still can be done on the processor, but the take home from this is it would elevate a lot of the work from the processor and it does indeed help a lot.
Alpha experimentation with x264 GPU assisted encoding can be read about here:
http://forum.doom9.org/showthread.php?t=164960
Quicksync and GPU encoding is not a solution just the same as using a capture PC or Live Gamer HD isn't. The quality hit isn't worth it (nor is the price for a good capture card). I don't understand why you'd be for GPU encoding (Quicksync), but not for GPU assisted encoding with OpenCL. Hardware that already supports Quicksync also supports OpenCL, you wouldn't suffer a quality hit with OpenCL, and there are more devices that support OpenCL then Quicksync-ish GPU encoding (AMD and Nvidia have their own versions).
Just to clarify, when I talk about GPU assisted encoding, I'm referring to using OpenCL to assist in encoding, not use built in GPU encoding such as Quicksync.
I finally got to the bottom of your post and it seems different then the top. Originally you made it seem like GPU assisted encoding or lan encoding was a bad idea and unfeasible, then at the end you say Quicksync is a good idea and moving any amount of load off your CPU is a good idea (which is what I was saying with lan encoding and GPU assisted encoding). :l
This is the original suggestion I brought up a month or so ago when I started using OBS:
viewtopic.php?f=7&t=329
Anyway, I took this opportunity to bring it up again because I think this would be a very important feature for anyone streaming and a milestone for OBS if Jim chooses to look into this. Obviously I'm very animate about this as I am a hardcore gamer and when my hardware holds me back it really rubs me the wrong way. $500 is a lot to drop on something just so I can stream well (which isn't even guaranteed), so I'm most definitely torn.
Network devices don't heat up and explode and they do handle sustained transfers quite well. The only time I've heard of this being a issue is with shotty routers that aim for the bottom line, but this has nothing to do with routers (there aren't many gigabit routers available for sale as well). You could simply install another NIC in each computer and run a cable between the two too... There are many different opportunities to fix a issue like this... Cheap too and that's what appeals to streamers who are primarily just your average gamer.
Yup, I'm well aware of the the quality loss associated with the Gamer HD as well as with GPU encoding (not GPU assisted encoding). The fact is that when it operates, it takes all but 3% of the load off your CPU. In other words removing the encoding workload presents a huge benefit to the person using the computer. I never said this was a good option or one that everyone should use, only that it offers a case to removing the encoding workload and moving it else where offers a significant benefit to whomever is streaming.
Quality, price, and feasibility is what I'm trying to address by suggesting lan and GPU assisted encoding. Compared to other alternatives such as the Live Gamer HD, a capture card, or a hexa-core processor they're most definitely superior.
I've looked at, read up, and even experimented with capture cards, they most definitely reduce the quality. The very fact that it turns into a video signal and it has to be turned back into a raw format changes how it looks. A testament to this is that all capture cards aren't the same. You can't buy a $100 capture card and hope it to perform as well as a $1000 capture card? Why is that? Because they actually have to interpret and adjust the image, software completely aside. So in order to get a good quality picture you're reaching into the $1000 price range which is also pretty ludicrous for joe the average gamer.
When you look at the input from the capture card it should look identical to your screen (even before you do a encode on it). This should be pixel perfect, because that's what I get by using DXtory or screencap and OBS, I expect no less from another solution. You're still stuck with having to setup another computer as well. I admit it's a creative solution, but it's like taping a bunch of things together that should be done in a all in one solution and call it good. Lan encoding simply skips this duct tape fix all together.
You wouldn't lose quality with lan encoding vs capture, you wouldn't need to buy a capture card, and if you don't have a gigabit network it's very easy to come by. Pretty much every computer made in the last 6-7 years has built in gigabit so all you need is a cable (gigabit does automatic crossover). Conversely gigabit switches are about $20 compared to a $1000 good capture card or a $500 decent one. Capture cards under $200 are junk.
Also, please keep in mind that 'capture card computers' are so common because CPU usage for encoding is such a huge issue for gamers. This isn't the sign of a solution, it's a symptom of the problem.
The thing is with cores and streaming is you can still tell it's operating on your processor. Even if your processor isn't getting pegged you definitely can feel it operating in the background and you take a FPS hit even with it going from 80% usage to 90% usage. I already tried messing with affinity and three cores isn't enough for most video games now days, especially if it intelligently figures out you have four and tries to balance itself out based on how many threads it sees. That can lead to some really wanky results if you try to put a game on three cores and put encoding on the fourth core. Most games are made for four cores now, so even if you have six, it'll still max out at four. So that leaves the last two for encoding. Adjusting affinity has nothing to do with load balancing and has everything to do with keeping encoding from influencing gaming.
Ideally I'd like to skip the whole notion of this as it's another $500 solution that most people would rather not buy. Yet, some streamers actually do purchase hexacore processors or server grade processors in order to deal with the encoder workload. I contemplated buying a Xeon or a Opteron JUST for streaming to alleviate these issues, even though I'd run into slower performance due to lower clocks. This is another brute force solution that isn't elegant at all.
Quicksync is GPU encoding, not GPU assisted encoding. You wont get the same performance out of GPU assisted encoding with OpenCL, but the point wasn't to get the same performance out of it, but rather reduce processor strain while maintaining the same level of quality we've come to expect from normal encoding via OBS and dxtory/gamecapture. Also from what I read when reading up on GPU encoding/Quicksync is the APIs are utter garbage and not well documented at all. GPU makers, Intel/AMD/Nvidia, just wanted to add the GPU encoding 'badge' to their processors without putting any real work into it.
Maybe $20 is too cheap, but you can get some really decent low end GPUs for around that price point with MIRs or even under $50. AMD low end solutions aren't rebrands of previous gen cards. They have legitimate low end offerings and you can get still get cheap Nvidia cards. All of them support OpenCL though. The point was it's a lot cheaper then all the other solutions.
I really don't know why we're discussing low end GPU specs though, this would be a secondary card in addition to a discrete primary graphics card. I'm sure there is a baseline as to how fast they would need to be in order to do realtime encoding, but chances are that's not going to be that big of a deal since GPUs are awesome at parallelized tasks. If there is something that can't be offloaded to a GPU it still can be done on the processor, but the take home from this is it would elevate a lot of the work from the processor and it does indeed help a lot.
Alpha experimentation with x264 GPU assisted encoding can be read about here:
http://forum.doom9.org/showthread.php?t=164960
Quicksync and GPU encoding is not a solution just the same as using a capture PC or Live Gamer HD isn't. The quality hit isn't worth it (nor is the price for a good capture card). I don't understand why you'd be for GPU encoding (Quicksync), but not for GPU assisted encoding with OpenCL. Hardware that already supports Quicksync also supports OpenCL, you wouldn't suffer a quality hit with OpenCL, and there are more devices that support OpenCL then Quicksync-ish GPU encoding (AMD and Nvidia have their own versions).
Just to clarify, when I talk about GPU assisted encoding, I'm referring to using OpenCL to assist in encoding, not use built in GPU encoding such as Quicksync.
I finally got to the bottom of your post and it seems different then the top. Originally you made it seem like GPU assisted encoding or lan encoding was a bad idea and unfeasible, then at the end you say Quicksync is a good idea and moving any amount of load off your CPU is a good idea (which is what I was saying with lan encoding and GPU assisted encoding). :l
This is the original suggestion I brought up a month or so ago when I started using OBS:
viewtopic.php?f=7&t=329
Anyway, I took this opportunity to bring it up again because I think this would be a very important feature for anyone streaming and a milestone for OBS if Jim chooses to look into this. Obviously I'm very animate about this as I am a hardcore gamer and when my hardware holds me back it really rubs me the wrong way. $500 is a lot to drop on something just so I can stream well (which isn't even guaranteed), so I'm most definitely torn.
Warchamp7
Forum Admin
Jaxel said:
Not yet, other things have taken priority, mostly stability up until recently. I believe multiple outputs is planned next, and Jim has mentioned some code for it is already there, but don't quote me on that.
As for pixel precision, you can move sources using the arrow keys now, and if you want to use numbers, you can always manually edit the scenes file.
I'm sure eventually UI options will be added for size, x y positions and cropping will make their way in. There are only so many developers, with Jim being the main one, and he can't do everything, as much as he'd love to.
Jaxel
Member
Okay... if the multiple outputs thing is coming... I can't wait...
There is another feature I would like if possible. The ability to have multiple audio tracks.
When I stream, I want to stream with this:
Video + Mic-in (single audio track)
When I record video I want it like this:
Video + Mic-in + Line-in (secondary audio track).
Would something like this be possible?
There is another feature I would like if possible. The ability to have multiple audio tracks.
When I stream, I want to stream with this:
Video + Mic-in (single audio track)
When I record video I want it like this:
Video + Mic-in + Line-in (secondary audio track).
Would something like this be possible?
Boildown
Active Member
You can run multiple instances of OBS with the -multi switch added to the command line to open OBS. Then you can start and stop the capture to disk at will while you continue to stream, and even capture to disk at a different quality/bitrate. Downside is that its more CPU intensive since OBS has to run twice. Upside is that capturing at Superfast with a high bitrate doesn't add much more CPU usage and is a lot higher quality than just saving what you'd be sending to Twitch.
Jaxel
Member
Okay.. so the new version of OBS now has start/stop recording... However, its start/stop recording at the same bitrate as the live stream; so it's kind of worthless.
Think of it this way... if I am broadcasting at an event that doesn't have good internet and I am forced to stream on a bad 4G, I have to stream at around 1.5mbps. But at the same time I am on-the-fly recording for youtube. With the way it is set up now, those youtube recordings are also at 1.5mbps. I need to be able to broadcast at 1.5mbps and save files at 6mbps for posterity.
Even more so... I need to be able to broadcast at 1.5mbps at 720x540 and record at 6mbps at 1280x720.
Think of it this way... if I am broadcasting at an event that doesn't have good internet and I am forced to stream on a bad 4G, I have to stream at around 1.5mbps. But at the same time I am on-the-fly recording for youtube. With the way it is set up now, those youtube recordings are also at 1.5mbps. I need to be able to broadcast at 1.5mbps and save files at 6mbps for posterity.
Even more so... I need to be able to broadcast at 1.5mbps at 720x540 and record at 6mbps at 1280x720.
We understand that's what people want. As I said, it will be possible in the rewrite. But we wanted to give people the ability to control the recording and stream separately at least in the current version of OBS so that the recording wouldn't stop if the stream connection died.