ZergShadow
Member
I want to know is it any difference in bitrate If I use TCP or UDP protocol?
I want to know is it any difference in bitrate If I use TCP or UDP protocol?
- Thread starter ZergShadow
- Start date
ZergShadow
Member
For example If I use 6000 for twitch with UDP and with TCP is this the same quality or not?
konsolenritter
Active Member
The quality is the same. Your content is encoding exactly the same way using the same bitrate.
All that is changed is the "envelope for transportation" around your encoded stream. TCP has more headover against UDP due to its nature of acknowledging packets, but this doesn't play a big role in sum. The bulk in the bill remains the net bitrate of encoding.
All that is changed is the "envelope for transportation" around your encoded stream. TCP has more headover against UDP due to its nature of acknowledging packets, but this doesn't play a big role in sum. The bulk in the bill remains the net bitrate of encoding.
ZergShadow
Member
So it's true that TCP protocol uses more bitrate over my stream bitrate than UDP?
I'm streaming to twitch with nearly 8500 bitrate and looking for maximum stable connection. I wonder if with UDP I can reach more stream bitrate.
konsolenritter
Active Member
Your net (encoding) bitrate stays all the same.
Even with udp there is an overhead (if slightly smaller one than with tcp)!
The encoded stream is muxed into an transport stream (...you guess right: a small overhead, bits and bytes here and then), then it has to be packet into udp or tcp packets. Overhead again (as is mentioned above). These packets then have to be encapsulated in generic ip packets. Well - ...a small overhead again... Then the encapsulation of your cable or dsl transmission line... - a small...
I think you got it. :)
It depends even on the question, into how many packets your muxed stream will be divided, given a handshaked and maximum allowed packet size each stage. It's generic for each kind of internet transportation and mostly outside of our scope. Depending on numerous constraints at each stage an overhead of 0.5 to 5% will be added to the (inner/former) net rate.
Thats why all serious folk recommends to leave headroom over the transmission line. A generic rule (just my two cents) would be to leave - even on a well-known 'stable' - connection 30-40% of headroom. To give an example: If you have a 6500kbps upstream capacity, you shall not go over 4500kbps net bitrate for encoding. Going for 5000 or even 5500 may be bold already. =D
This is a bit contradictory. Maximum connection stability is reached by not using more bitrate, as said. And TCP with its acknowledging mechanism gives more stability over long-looped buffering like the normal youtube latency (a couple of seconds), so there is a chance to resend (otherwise left-out) packets. On the other hand i don't have experience how twitch handles these things...
Even with udp there is an overhead (if slightly smaller one than with tcp)!
The encoded stream is muxed into an transport stream (...you guess right: a small overhead, bits and bytes here and then), then it has to be packet into udp or tcp packets. Overhead again (as is mentioned above). These packets then have to be encapsulated in generic ip packets. Well - ...a small overhead again... Then the encapsulation of your cable or dsl transmission line... - a small...
I think you got it. :)
It depends even on the question, into how many packets your muxed stream will be divided, given a handshaked and maximum allowed packet size each stage. It's generic for each kind of internet transportation and mostly outside of our scope. Depending on numerous constraints at each stage an overhead of 0.5 to 5% will be added to the (inner/former) net rate.
Thats why all serious folk recommends to leave headroom over the transmission line. A generic rule (just my two cents) would be to leave - even on a well-known 'stable' - connection 30-40% of headroom. To give an example: If you have a 6500kbps upstream capacity, you shall not go over 4500kbps net bitrate for encoding. Going for 5000 or even 5500 may be bold already. =D
This is a bit contradictory. Maximum connection stability is reached by not using more bitrate, as said. And TCP with its acknowledging mechanism gives more stability over long-looped buffering like the normal youtube latency (a couple of seconds), so there is a chance to resend (otherwise left-out) packets. On the other hand i don't have experience how twitch handles these things...
koala
Active Member
If you intend to use udp instead of tcp just for the purpose to get more bandwidth available for your video bitrate, this assumption is wrong. The overhead of tcp is negligible. And it happens on the opposite direction, not in the send direction, so it doesn't reduce the sending bandwidth.
All the common streaming providers don't offer udp in the first place, so you don't have a choice anyway.
All the common streaming providers don't offer udp in the first place, so you don't have a choice anyway.