One thing to note. RTMP is very useful for youtube still. I know that even if I drop frames while live, eventually my encoder / the tcp stack will send up the missing packets (if possible and successful). UA-cam then in post processing re-inserts the missing frames. I know this because I once was down for almost two minutes due to an ISP issue, then when I watched the replay, nothing was missing at the drop of the outage. I was shocked.
@@wassagtmanndazu yes. That’s right. The point was that srt just drops it and doesn’t re-attempt to send it, but rtmp will retry. It’s important for vods. Yes, live viewers will still see buffering during the show. If the dropped frames are not re-sent, then the vod will have skips where srt didn’t care to resend the data.
Amen and amen. This one is good, and definitely shouldn't raise hackles from the "engineers" in the audience. I dare say the engineers "story telling" ability cannot hold a candle to this video.
Great explanation. A big YES to more like this. I think this kind off short video is very helpful for a base knowledge to allow you to go deeper into the subject. There are surely many videos out there that will go very deep, but it can be a bit overwhelming.
Great simplistic overview. Very helpful to those without a networking background. Thanks. Going into issues of how routers handle video streams without QOS tagging would be really getting into the weeds a bit, but might help people understand the differences between running video over a LAN vs through the actual internet.
This is an ABSOLUTELY amazing explanation. Instead of making my own video explaining this, I'm just going to recommend this video to my customers when they have questions. I may also embed it, with your permission, on website FAQs. Thank you!
Good stuff AP. I knew this but was still riveted by your explanation. Now, when people do not understand my explanation, I can send them you way better Bill Nye version. #Mahalo See you in a couple days at NAB. #Aloha 🤙🏽
I work as a principal engineer and this video was sent to me by a junior and genuinely feel it’s so good I’m gonna be sending it to anyone who asks me this questions at work to get them started with the concepts
Great description. I would describe SRT is latency aware rather than video aware - it knows nothing about the data and can be used to transport things other than video. I'm surprised there hasn't been a more video aware transport gain traction - e.g. one that knows when link is congested to prioritise audio, then 'I' frames, then other frames - ideally linked to the encoder to automatically adjust compression levels when needed. I guess there are solutions, just not open ones.
That's fair, there are also some other simplifications I made in the description, so don't go write your SRT code in your video encoder based on what you heard in this video, but overall I think it gets the point across 😃 That would be very cool to have an even more video-aware protocol though!
thank you for explaining the differences! now it would also be nice if drones and apps in general also add support for SRT. that being said, as a YBP user I guess even if they add SRT support, it will likely not support h265. which begs the question, is there a negotiation when an SRT connection is established which codecs both sides support or does this need to be manually configured? Edit: oh and it would be amazing to explain the differences to NDI next.
A very good summary. Thank you. It is striking that the advertising for SRT often emphasizes that better quality would be possible. And then visual examples are used to compare it with an RTSP (!) live stream with packet loss. With RTSP (protocol from the 90s) there are many blocking artifacts and it looks bad, with SRT it looks good. However, live streams are very rarely transmitted via RTSP these days (still a good option for IP cameras, for example). In addition, there is usually very little or no packet loss. RTMP therefore transmits absolutely smoothly in most cases and 99% of all live streams worldwide run via RTMP. However, if you transmit via mobile network or from one continent to another, SRT has noticeable advantages. In normal everyday life, however, it makes virtually no difference. Assuming there is only 4 mbit/s upload available and a FullHD stream is to be transmitted at 3.8 mbit/s, then there are potential problems with RTMP. And SRT can be the deciding factor. In this case, it would be far better not to think about SRT or RTMP, but to optimize the stream to 3 mbits. Or better yet, both. But if an upload of 50 or even 100 mbit/s is normal today, and UA-cam re-encodes the FullHD live stream at 5 to 8 mbit/s anyway if you deliver with a higher data rate (but with the original stream if it is transmitted at 8 mbit/s), these data rates run super smoothly through the line using RTMP.
I've been curious about SRT for a while now. This video has proven most informative. I've just ordered up a Yolobox Ultra to replace my Pro edition. Perhaps a video on the specifics of SRT transmission via Yolobox Ultra could be produced ?
Just one question: If I use SRT method in OBS Studio to send to my Laptop OBS Studio using Teleport plugin. Just want to know if I can stream to multiple RTMP feeds up to like 6 when received via SRT. Now I use, SRT with ip link to send feed but it struggles and glitches while my laptop gets overheated.
I agree with @trackdayguy, great explanation. Also been in I.T. over 30 years and this was a good refresher. I do IRL streaming on Twitch. I'll be setting up my own SRT server so I can use OBS scenes and whatnot instead of just going with IRL Pro only on the phone. SRT with H.265 is the way to go if you are an IRL Streamer IMO. Cheers!
Some platforms accept SRT streams as an alternative to RTMP ingestion. It depends on the platform. UA-cam is rolling it out slowly now, I have beta access to it at the moment. I assume eventually it will be available to everyone. Other platforms might already support it broadly.
@@aaronpk Thanks Aaron. Are there any specific ways that you use it consistently over RTMP on a daily/weekly basis? I have the 4K Live U Solo Pro that we send our streams through with Restream in the middle.
Nice explanation. Now, can you dig a little deeper and talk about multiple SRT synchronisation (WMS Panel, timecoded, NTP/SEI), maybe with Dante? And SRTLA, OpenMPTCP, network bonding?
i would like to see a video from you where you use a Magewell mini or a Yolobox Ultra to send a remote livestream using srt to an hdmi or sdi input on a Blackmagic mini. It would have an explanation of port forwarding and and using something like Wireguard to protect that open port. I believe this would be better than making a personal rtmp server. Thanks for any consideration.
Question, if you stream h265, does that mean the viewers player needs to be a h265 decoder or does the streaming server usually transcode it? What about HLS?
Usually when we talk about streaming encoding we're talking about the link from the encoder to the platform like UA-cam, and the platform will convert that to a suitable format for distributing to viewers. Most of the time that's converting it to HLS segments, usually h264
@@aaronpk HLS is always h.264. It cannot be h.265 and, for example, not webm. For a free (advertising-financed) service, this is not important to the user. Wherever a customer pays for the service, it is relevant, because converting from h265 to h264 is complex and costs CPU cores. Or a server with a powerful GPU has to be paid for.
@@aaronpk Thanks, I didn't know that. According to the specification, it is designed for h.264. And I have more experience with HLS transmission from the server to the viewers. I didn't know that UA-cam allows ingest via HLS including HEVC or h.265.
Excellent explanation. I've been in IT for 30 years and haven't heard TCP, UDP and RTMP described that clearly. Wow!
One thing to note. RTMP is very useful for youtube still. I know that even if I drop frames while live, eventually my encoder / the tcp stack will send up the missing packets (if possible and successful). UA-cam then in post processing re-inserts the missing frames. I know this because I once was down for almost two minutes due to an ISP issue, then when I watched the replay, nothing was missing at the drop of the outage. I was shocked.
Great point David!
Any decent streaming server can do that. But for the live viewers, the stream was still interrupted or stalled.
@@wassagtmanndazu yes. That’s right. The point was that srt just drops it and doesn’t re-attempt to send it, but rtmp will retry. It’s important for vods. Yes, live viewers will still see buffering during the show. If the dropped frames are not re-sent, then the vod will have skips where srt didn’t care to resend the data.
It was truly a university-quality lecture on the topic. Well Done! - I heard a lecture on this that lasted 90 minutes and you did it in 9!
Great breakdown of the technical aspects - more please!
This is exactly what I've needed to know! Thanks!
You are the GOAT. Yes we need more and longer
Great explainer! I feel like I'm already pretty familiar with SRT and still learned a few things!
Please do more of these...they are great to share to people.
Amen and amen. This one is good, and definitely shouldn't raise hackles from the "engineers" in the audience. I dare say the engineers "story telling" ability cannot hold a candle to this video.
Great explanation. A big YES to more like this. I think this kind off short video is very helpful for a base knowledge to allow you to go deeper into the subject. There are surely many videos out there that will go very deep, but it can be a bit overwhelming.
Great simplistic overview. Very helpful to those without a networking background. Thanks. Going into issues of how routers handle video streams without QOS tagging would be really getting into the weeds a bit, but might help people understand the differences between running video over a LAN vs through the actual internet.
Well done! Good balance of technical depth without losing the audience.
Thank you. Especially for that analogy.
Really explantation of the benefits of SRT over RTMP - thank you.
This is an ABSOLUTELY amazing explanation. Instead of making my own video explaining this, I'm just going to recommend this video to my customers when they have questions. I may also embed it, with your permission, on website FAQs. Thank you!
Thank you! Yes feel free to embed it!
Good stuff AP. I knew this but was still riveted by your explanation. Now, when people do not understand my explanation, I can send them you way better Bill Nye version. #Mahalo
See you in a couple days at NAB. #Aloha 🤙🏽
See you soon! 🕺
I work as a principal engineer and this video was sent to me by a junior and genuinely feel it’s so good I’m gonna be sending it to anyone who asks me this questions at work to get them started with the concepts
Great description. I would describe SRT is latency aware rather than video aware - it knows nothing about the data and can be used to transport things other than video. I'm surprised there hasn't been a more video aware transport gain traction - e.g. one that knows when link is congested to prioritise audio, then 'I' frames, then other frames - ideally linked to the encoder to automatically adjust compression levels when needed. I guess there are solutions, just not open ones.
That's fair, there are also some other simplifications I made in the description, so don't go write your SRT code in your video encoder based on what you heard in this video, but overall I think it gets the point across 😃
That would be very cool to have an even more video-aware protocol though!
Excellent info Aaron. Thank you for sharing! Yes, please continue to make content that explains the technical goodies! 😊
thank you for explaining the differences! now it would also be nice if drones and apps in general also add support for SRT.
that being said, as a YBP user I guess even if they add SRT support, it will likely not support h265. which begs the question, is there a negotiation when an SRT connection is established which codecs both sides support or does this need to be manually configured?
Edit: oh and it would be amazing to explain the differences to NDI next.
A very good summary. Thank you.
It is striking that the advertising for SRT often emphasizes that better quality would be possible. And then visual examples are used to compare it with an RTSP (!) live stream with packet loss. With RTSP (protocol from the 90s) there are many blocking artifacts and it looks bad, with SRT it looks good.
However, live streams are very rarely transmitted via RTSP these days (still a good option for IP cameras, for example). In addition, there is usually very little or no packet loss. RTMP therefore transmits absolutely smoothly in most cases and 99% of all live streams worldwide run via RTMP.
However, if you transmit via mobile network or from one continent to another, SRT has noticeable advantages. In normal everyday life, however, it makes virtually no difference.
Assuming there is only 4 mbit/s upload available and a FullHD stream is to be transmitted at 3.8 mbit/s, then there are potential problems with RTMP. And SRT can be the deciding factor. In this case, it would be far better not to think about SRT or RTMP, but to optimize the stream to 3 mbits. Or better yet, both.
But if an upload of 50 or even 100 mbit/s is normal today, and UA-cam re-encodes the FullHD live stream at 5 to 8 mbit/s anyway if you deliver with a higher data rate (but with the original stream if it is transmitted at 8 mbit/s), these data rates run super smoothly through the line using RTMP.
Bravo 👏 great job. So many professionals do not understand this.
Thank you for this top notch explanation. Really well done!
This was an excellent explanation, even a newbie could understand! Thank you Aaron
So helpful!
Great explanation, thank you Aaron!!
Very clearly described Aaron. Thanks for this informative video
Excellent video. Thank you
Absolutely fantastic video, thank you!
Thank you very much for making this easy to understand video for older people like me
Great explanation. I would love to see more videos like this.
Thanks Aaron, needed this.
Happy to help!
Aaron you are better than ChatGPT. Thank you man!!
Well done sir!
Wow! Great Explanation
I would like to see more videos like this
I've been curious about SRT for a while now. This video has proven most informative. I've just ordered up a Yolobox Ultra to replace my Pro edition. Perhaps a video on the specifics of SRT transmission via Yolobox Ultra could be produced ?
Great explanation, very informative, thank you.
Excellent explanation! Thank you! 😁
Just one question: If I use SRT method in OBS Studio to send to my Laptop OBS Studio using Teleport plugin. Just want to know if I can stream to multiple RTMP feeds up to like 6 when received via SRT. Now I use, SRT with ip link to send feed but it struggles and glitches while my laptop gets overheated.
I agree with @trackdayguy, great explanation. Also been in I.T. over 30 years and this was a good refresher. I do IRL streaming on Twitch. I'll be setting up my own SRT server so I can use OBS scenes and whatnot instead of just going with IRL Pro only on the phone. SRT with H.265 is the way to go if you are an IRL Streamer IMO. Cheers!
Thanks Aaron. Really helpful 👍🏼
Clear explanation, thank you.
i’m gonna go get my kids some ice cream after school and think about this again. Lol thanks for the analogy.
Nice explanation, Big thanks 😊
As I livestream more events, where do I begin to send my SRT streams? What platforms support SRT? How wouldI use it for a client?
Some platforms accept SRT streams as an alternative to RTMP ingestion. It depends on the platform. UA-cam is rolling it out slowly now, I have beta access to it at the moment. I assume eventually it will be available to everyone. Other platforms might already support it broadly.
@@aaronpk Thanks Aaron. Are there any specific ways that you use it consistently over RTMP on a daily/weekly basis? I have the 4K Live U Solo Pro that we send our streams through with Restream in the middle.
Very well explained!
Nice explanation. Now, can you dig a little deeper and talk about multiple SRT synchronisation (WMS Panel, timecoded, NTP/SEI), maybe with Dante? And SRTLA, OpenMPTCP, network bonding?
That is a lot deeper! I'll see what I can do 😄
very good explanation I like it
Isn't also SRT low latency a big advantage over RTMP especially for real time communication like remote video contribution?
Thanks for this video
@aaron
Since you are on NAB. Any news or rumors from BMD about SRT implementation in ATEM lineup and Streaming Bridge?
Great video 👌🏽👌🏽👌🏽
i would like to see a video from you where you use a Magewell mini or a Yolobox Ultra to send a remote livestream using srt to an hdmi or sdi input on a Blackmagic mini. It would have an explanation of port forwarding and and using something like Wireguard to protect that open port. I believe this would be better than making a personal rtmp server. Thanks for any consideration.
Thanks! That's definitely on my list!
@@aaronpk +1 on a Chaos Router shoot out of SRT vs. RTMP (and use OBS as your RTMP encoder and SRT encoder, keep the hardware outta the loop).
Question, if you stream h265, does that mean the viewers player needs to be a h265 decoder or does the streaming server usually transcode it? What about HLS?
Usually when we talk about streaming encoding we're talking about the link from the encoder to the platform like UA-cam, and the platform will convert that to a suitable format for distributing to viewers. Most of the time that's converting it to HLS segments, usually h264
@@aaronpk okay cool. Thanks for your response.
@@aaronpk HLS is always h.264. It cannot be h.265 and, for example, not webm.
For a free (advertising-financed) service, this is not important to the user. Wherever a customer pays for the service, it is relevant, because converting from h265 to h264 is complex and costs CPU cores. Or a server with a powerful GPU has to be paid for.
@@wassagtmanndazu UA-cam can ingest h265 over HLS: support.google.com/youtube/answer/10349430?hl=en
@@aaronpk Thanks, I didn't know that.
According to the specification, it is designed for h.264. And I have more experience with HLS transmission from the server to the viewers. I didn't know that UA-cam allows ingest via HLS including HEVC or h.265.
very good!
Awesome & Thanks :)
tl;dw - SRT handles h.265, so it can be way more efficient, plus it drops fewer frames.
So helpful!
Thanks for this video