Optimizing for video stream
-
I have recently started a video stream from my home network. I know that it will never have great quality running through youtube, but right now I've had to really set the frame rate very low to avoid dropped frames. I'm wondering if I can use traffic shaping to give the video stream a higher priority and be able to increase the frame rate to a higher level? How would I go about setting this up?
-
Don't prioritize video. Just give it a dedicated queue with sufficient bandwidth.
What's your video protocol (UDP, TCP)? How bigs are video packets? And what is desired packet rate per session?
-
It’s a YouTube live stream from OBS. My understanding is that this uses RTMP which should be TCP by default. I haven’t verified that though.
Currently video bitrate is 1250. I’d like to get it up to at least 1500.
Also have a P2P server running on this network with max upload bandwidth limited to 100KBps.
Speed test shows 233.04 Mbps down and 9.06 Mbps up for this network, so hopefully I should be able to improve the streaming if I set it up properly.
-
It’s a YouTube live stream from OBS. My understanding is that this uses RTMP which should be TCP by default. I haven’t verified that though.
Currently video bitrate is 1250. I’d like to get it up to at least 1500.
Also have a P2P server running on this network with max upload bandwidth limited to 100KBps.
Speed test shows 233.04 Mbps down and 9.06 Mbps up for this network, so hopefully I should be able to improve the streaming if I set it up properly.
So you'll need a queue, say, qStream, with bandwidth = 1500 Kbps, for the video stream (including ACKs of the stream). Put everything else to the default queue, qDefault.
If you use HFSC, the qStream should have a [real-time and link-share] service curve with [identical parameter] m2 = 1500Kb. Leave the parameters m1 and d unset.
Use pftop to determine actual packet rate, packet size, and bitrate of qStream.
If you still experience many packet drops and/or insufficient bitrate, try to improve latency by setting the parameters m1 and d for the curve.
For example, let's assume packet size is 12 Kb (kilobits). By setting bitrate m2 = 1500 Kbps you'll have guaranteed packet rate 1500/12 = 125 packets per second and delay D = 1/125 = 0.008 s = 8 ms. Furthermore, by setting m1 = 2*m2 = 3000 Kbps, d = D/2 = 4ms, you'll get latency improved to 4 ms (with the same bit rate and packet rate).
The trick with m1 and d works for a single session.
-
Thanks for the help. I’ll give that a try.
-
If you're still having issue, I recommend using FairQ+Codel or fq_codel(bit more complex right now and should be much easier to setup in 2.4.4)
-
It’s a YouTube live stream from OBS. My understanding is that this uses RTMP which should be TCP by default. I haven’t verified that though.
Currently video bitrate is 1250. I’d like to get it up to at least 1500.
Also have a P2P server running on this network with max upload bandwidth limited to 100KBps.
Speed test shows 233.04 Mbps down and 9.06 Mbps up for this network, so hopefully I should be able to improve the streaming if I set it up properly.
So you'll need a queue, say, qStream, with bandwidth = 1500 Kbps, for the video stream (including ACKs of the stream). Put everything else to the default queue, qDefault.
If you use HFSC, the qStream should have a [real-time and link-share] service curve with [identical parameter] m2 = 1500Kb. Leave the parameters m1 and d unset.
Use pftop to determine actual packet rate, packet size, and bitrate of qStream.
If you still experience many packet drops and/or insufficient bitrate, try to improve latency by setting the parameters m1 and d for the curve.
For example, let's assume packet size is 12 Kb (kilobits). By setting bitrate m2 = 1500 Kbps you'll have guaranteed packet rate 1500/12 = 125 packets per second and delay D = 1/125 = 0.008 s = 8 ms. Furthermore, by setting m1 = 2*m2 = 3000 Kbps, d = D/2 = 4ms, you'll get latency improved to 4 ms (with the same bit rate and packet rate).
The trick with m1 and d works for a single session.
I went through the wizard and used HFSC. Set RTMP to be queued higher with all others set to default. The wizard didn't give me the option to create a queue and I don't see qStream. Not sure where to enter the settings for m1.
-
I went through the wizard and used HFSC. Set RTMP to be queued higher with all others set to default. The wizard didn't give me the option to create a queue and I don't see qStream. Not sure where to enter the settings for m1.
Go to Firewall -> Rules and check out the Floating tab. There should be a rule for RTMP inbound and you should see the queue name. It's probably qOthersHigh and let's assume it is later on. Edit any other rule that use qOthersHigh and change them to use qDefault. Leave the RTMP inbound rule intact. (If there's no RTMP inbound rule, find the RTMP outbound rule instead and, also, make sure it includes WAN Interface and out Direction.)
Go to Firewall -> Traffic Shaper and edit the qOthersHigh. (Note that there are multiple queues under that same name and the specific queue you may want to edit is one under the WAN interface.) Tick the checkbox at "Real-Time" to enable the real-time service curve and set Bandwidth, Real-Time m2 and Link-Share m2 to the same desired value (1500 Kbps).
-
Thanks. Just want to confirm I got this correct. Had to boost the rate to 3000 and might have to go a little higher to keep the stream health in the green.
-
Thanks. Just want to confirm I got this correct.
The basic part of the rule is correct. I didn't see the Advanced part which specifies ack queue and data queue. qACK/qOthersHigh is good but may not be the best. qOtherHigh/qOtherHigh (or none/qOthersHigh which is the same) would be better.
Had to boost the rate to 3000 and might have to go a little higher to keep the stream health in the green.
And what is the actual rate of streaming transmission? If it is actually ~3000 Kbps, good. If not, reduce m2 and try m1 and d (assuming only one session, of course).
-
@dusan said in Optimizing for video stream:
Go to Firewall -> Rules and check out the Floating tab. There should be a rule for RTMP inbound and you should see the queue name. It's probably qOthersHigh and let's assume it is later on. Edit any other rule that use qOthersHigh and change them to use qDefault. Leave the RTMP inbound rule intact. (If there's no RTMP inbound rule, find the RTMP outbound rule instead and, also, make sure it includes WAN Interface and out Direction.)
My fault. Sorry. The Direction should be in. But any is also fine.
