Pushing WebRTC Up That Broadcast Hill

Transcript

1. Streaming Tech Sweden 2023 Pushing WebRTC Up That Broadcast Hill Dan Jenkins
2. Dan Jenkins WebRTC & Real Time Media Geek @dan_jenkins
 @danjenkins@fosstodon.org Founder - Everycast Labs / Nimble Ape Organiser CommCon (19-23 June - UK)
3. Broadcast Bridge - bring remote collaborators into your professional work fl ow @everycastlabs broadcastbridge.app everycastlabs.uk
4. Pushing WebRTC Up That Broadcast Hill
5. WebRTC Is Now 12 Years Old.
6. And It Has Barely Been A "Thing" Inside Broadcast Media.
7. So First... Let's Define WebRTC
8. WebRTC Allows Two Peers behind NATs To Connect to One Another
9. It Uses an ICE Process To Make Those Connections.
10. WebRTC Allows for Media and Data To Be Sent Over a Peer Connection
11. WebRTC Is Encrypted by Default.
12. A Peer Doesn't Need To Be a Client
13. An SFU or MCU Is Also a Peer.
14. WebRTC Media Is Sent as RTP
15. Which Allows for RTP Extensions To Be Used.
16. RTX
17. Absolute Capture Time
18. Audio Levels
19. Absolute Send Time
20. Video Orientation
21. Playout Delay
22. Video Content Type
23. That's Just a Few.
24. It's a Fantastic Toolset To Have at Your Fingertips.
25. Some May Say It's Rather Prosumer https://twitter.com/OpenBroadcastSy/status/1662075098172358657
26. But In Order To Understand Some Of The Whys...
27. We Need To Look at WebRTCs Past
28. Google Acquired Global IP Solutions...
29. And Then Open Sourced WebRTC (YAY!)
30. The IETF And The W3C Were Then Involved With Standardisation
31. But at its Core...
32. WebRTC Was Designed for Conference Calls
33. "Real Time Media on the Web"
34. And the IETF Process Was Led by VoIP People
35. Real Time Media = (Web) Real Time Media
36. And This Led to Decisions.
37. Like Using SDP To Handle Negotiation of a Session.
38. But The Biggest* Decision Was Having No Standard Signalling Method. (*At Least in my mind)
39. People Could Use What They Wanted.
40. JSON Over Websocket
41. SIP Over Websocket
42. XMPP
43. GraphQL
44. Some Proprietary Binary Format Over Websocket
45. *N
46. You Could Do It Your Way
47. Whatever Made Sense for Your Application
48. Include SDP? Sure!
49. Get Rid Of SDP And Fill It In Later?
50. That Works Too!
51. But No Standard Signalling Isn't Ecosystem Friendly
52. SRT, RTMP, NDI, HLS & DASH (And many others)
53. They Just Work (Mostly)
54. The Lack of a Common Signalling Layer Was Both Great and Terrible
55. Now...
56. The Lack Of Common Signalling Wasn't The Only Issue.
57. Lack Of Controllable Latency
58. Lack Of Encode/ Decode Control In A Browser
59. Lack Of Control Generally.
60. Pray Be To The Browser Gods.
61. But.
62. WebRTC Has Its Own Superpowers
64. WebRTCs Superpower Is That It Works on Billions of Devices
65. Without Installing A Thing
66. Use The Right Tool For The Right Job.
67. WebRTC In A Browser Is The Right Tool.
68. For The Right Job.
69. It Might Just Be A Different Job Than You Expected.
70. Now...
71. Let's Take A Look at WebRTCs Present
72. Works In All Browsers Yes, even on Mobile (Safari, Chrome, Firefox - Edge is a clone)
73. Supports New Codecs (AV1, H265)
74. OPUS RED.
75. More Than Just libWebRTC (Pion, WebRTC.rs, aiortc, |pipe| to name a few)
76. SVC (One Video encoded once resulting in one stream with multiple qualities)
77. ...But Different Support in Every Browser
78. Simulcast (Multiple encoded videos sent independently as multiple streams) (Now includes VP9 and AV1 in Chrome)
79. ...But Different Support in Every Browser
80. X & Y Features
81. ...But Different Support in Every Browser
82. Scaling Isn't Simple
83. Scaling To 100,000s Of Connections
84. It's Tricky
85. And Expensive
86. So WebRTCs Present Is Just Tricky.
87. However.
88. Something Is Becoming Simpler...
89. Standardised & Simple Signalling
90. WHIP (WebRTC HTTP Ingest Protocol)
91. WHEP (WebRTC HTTP Egress Protocol) https://eyevinntechnology.medium.com/whip-whpp-for-webrtc-based-broadcast-streaming-2cf469e95299
92. They Go Hand In Hand.
93. Let's Take A Look At WHIP
94. At The Heart Of Both Is A HTTP POST Request/ Response
95. POST /whip/endpoint/test HTTP/1.1 Host: localhost:7080 Content-Type: application/sdp Authorization: Bearer verysecret Accept-Encoding: gzip, de fl ate Connection: Keep-Alive Content-Length: 1162 v=0 [..sdp] (WHIP) POST with an OFFER
96. HTTP/1.1 201 Created Location: /whip/resource/test Content-Type: application/sdp Connection: keep-alive Transfer-Encoding: chunked Content-Length: 569 v=0 [..sdp] (WHIP) POST RESPONSE WITH ANSWER
97. WHEP Is the SAME
98. Super Simple.
99. And Finally Means Ecosystem Friendliness
100. Both WHIP and WHEP Are Getting Industry Support
101. Dolby.io
102. Cloudflare
103. Osprey Talon Encoders
104. OBS
105. Flowcaster
106. LiveU
107. And Lastly...
108. Broadcast Bridge
109. What's Coming in WebRTCs Future?
110. Or...
111. What Do I Hope We Will See Soon?
112. WebCodec Support
113. DRED (Deep Audio Redundancy)
114. Bringing All Browsers Up To The Same Spec
115. LOL.
116. This Is a Web Problem Generally.
117. So What's In It For You?
118. Lack of Control?
119. Issues Scaling?
120. You're Not Selling Me on This Dan...
121. But Seriously.
122. Use WebRTC Right...
123. And It Will Work Well for You.
124. WebRTC Isn't Right for Broadcasting to 100,000 People
125. WebRTC Isn't Right for Broadcasting to 100,000 People (Usually)
126. WebRTC Is Not Right for Transporting Media Inside a Studio.
127. WebRTC Is Right for Real Time Collaboration
128. Where You Need the Lowest Friction
129. WebRTC Is Right for Weird Network Scenarios
130. It Is a Tool in the Toolbelt.
131. And Even Though Web Browsers Frustrate Me
132. A LOT.
133. It Is Only Because of the Web Browser That WebRTC Has Its Superpower
134. It Works Everywhere
135. Not Everything Is a Nail Needing a Hammer.
136. I've Seen Stranger Things Than WebRTC Being Used in Broadcast
137. That's Me!
138. Cheers!
139. Thanks! We're hiring in the UK! https://jobs.everycastlabs.uk @dan_jenkins @danjenkins@fosstodon.org @everycastlabs