Is WebRTC right for Streaming? - Chris Wendt of Comcast

our next speaker to talk about WebRTC for streaming applications as a Chris went of Comcast he's not like one of those Comcast guys out there that don't don't throw your stuff at him as I had a waffle I was I was asking for a special number today cuz I outage but uh but I am like one of those Comcast guys chris is a he's a principal architect in charge of I P communications he's heavily involved in standards chairman super forum there too and and heavily involved in the IETF so I'll let you introduce yourself but uh you know please welcome Chris Lindh thanks Chad it's great to be here it's great to have such a great audience here and great facilities I was going to talk about WebRTC for broadcast so this is actually sort of a complex topic and I'm gonna do like a whirlwind tour of like streaming protocols and things like that but it's not necessarily to talk to you about protocols um it's more from a trying to give a little bit of understanding of a topic that sometimes isn't very intuitive and that is streaming so like normally when you look at video streaming unless you're in in deepen the protocols it's sort of like I get video from point A to point B and I'm done right so we'll talk about what to consider and what to think about and what WebRTC may or may not have to do with any of this so when we talk about broadcast sort of define what we're going to talk about broadcast usually it's one too many the question here is how many are we talking about usually broadcast is a one-way thing starting to become apps where maybe that's a little different like periscope where you have sort of this messaging back back channel but for the most part when we think about broadcast it's in one way and then broadcast you know it's real-time it's live what the question is how real-time do we want it to be I'm gonna sort of coin a term because I like to do that and this one just slipped off the tongue so well the trade-off triangle don't that so one thing to really think about when you're talking to thinking about streaming protocols is he trade-off between these three parameters and I think this covers most of the aspects there might be other dimensions that we might want to think about but for the most part it's how do you account for latency versus quality versus the scale so from a high level probably the most live broadcast things that people that experience uses technologies involving basically HTTP based streaming protocols so - happens to be the latest and greatest specified versions there's more proprietary versions that folks have used but they're all generally the same basic premise so you have a camera you have this unique a stream typically RTSP or rtmp is used and sent to an encoder that has the ability to encode multiple bit rates at one time it creates stream fragments for each of those and then it sends it to the origin server that takes these and in - it happens to be mpeg-2 transport stream or mp4 file fragments but it also has this mezzanine file that is essentially a list of URLs to all the different Stream fragments and that constantly gets updated the client grabs the latest version of the mezzanine file gets all the links and then it can adaptively switch streams as your bandwidth changes and as you probably know this has been highly adopted on both the web and mobile and it generally works really well but the trade-off triangle we need to think about latency quality and scale let's take a look so from a scale point of view you really can scale to potentially millions depending on the size of your CDN the the key thing here is the origin server doesn't get loaded it's the CDN pieces that get loaded it's all coordinated HTTP downloads the clients know when they need to start downloading the next fragment and it takes advantage of all the great HTTP tools that we use every day as Internet's and citizens from a latency point of view though generally larger fragments are better for quality and I'll talk about that little bit later I think the last time I looked at the spec 10 second fragments or sort of the recommended size although some people try to push it down to two or three seconds but there is this sort of chain that well not sort of chain there is a chain of latency that gets built up where you have from the camera to the encoders you're building a chunk of ten seconds and then to the origin server a chunk of ten seconds you create the mezzanine file then the CDN request start coming through and then the client is probably buffering another fragment so we have this chain of latency so really even in the best case we're at you know tens of seconds maybe even a minute for the quality side of the triangle this is mostly guided by the bitrate granularity available and clients can only really adapt on the fragment boundaries so if you have hiccups in the networks you really can only change every you know if I start downloading a ten second fragment I actually I have to actually finish downloading that ten second fragment to start the next one and HTTP is also a TCP protocol so there is congestion issues you know if there's hiccups in the network and you potentially get the derivative buffering overall it works usually pretty well but you know it from a quality point of view it's not fully saturating the channel so scale is the big thing here quality is still pretty good latency obviously drops off so I talked about our TSP and our TMP and some folks may be familiar with that Webber TC is related protocol to RTS B it uses some of the same underlying protocols but obviously there's a lot of new and interesting things in there but why why didn't those get adopted and to delve a little deeper into that it has to do with unicast and stream adaption so all these protocols are primarily unicast and what do I mean by that unicast and as I'm using it here means that it's tuned to deliver media content over the point-to-point Channel that from from client to client or server a client whatever the case is for your application and they tune the the delivery of the media based on the feedback channel so the clients are actually talking back to each other the actually this receiver is talking back to the sender to provide feedback on how are you doing how can I send more data can I send less data am i getting a lot of packet loss a lot of different media statistics that helps you adapt very quickly to different network conditions so this is a quick overview of the protocols our TSP and WebRTC use RTP or UDP RTC our tcp is the stream feedback protocol these are ITF defined protocols rtmp is for tcp but it also has a built-in feedback channel and - you can sort of think about that as a suit of feedback channel but there's actually no messaging going back it's purely just the client deciding which files to download based on on the bandwidth that it thinks it has available to it so what about WebRTC that is after all the main topic of this so you know what low hanging fruit why not why don't we use WebRTC instead of our tsp or rtmp I think some people are doing this it's pretty straightforward make some sense generally in any of these scenarios you want to make sure that you have good bandwidth available obviously the downstream will be affected if the the upstream I guess has bandwidth issues and you have some you know issues with the quality of the original stream but this is a definitely a valid way to approach things there's sort of a new thing going on in WebRTC and a network component called amman SFU of video bridge and essentially what this is is SFU selected 14 unit is I take my incoming RTP packets from WebRTC and I replicate them across multiple clients so I can create a video bridge you know hangouts there's a company called jitsi that was just acquired by Atlassian they're heavily involved in building SFU there's a number of people doing it seems to be the definitely the future of video conferencing why you know could we use this for a massive broadcast we have to go back to the trade-off triangle to make that determination so let's take a look latency so WebRTC as you probably know already it was built to be two-way communications or really anyway I guess if we talk about the SFU resource for the browser and mobile apps so it's really focused and the stack that you know Google and Firefox have built into the browser's have been very well tuned for low latency communications and video adoption so great for any conversations without the satellite delay effect so that you know latency is obviously incredibly important there however it really because we have latency low latency there could be some trade-offs for a broadcast so from a quality point of view like I said these protocols are great for optimizing adaptive transmission for the specific channel that peers are communicating on or really another way to think about that is it's shaping how the video encoding is happening to the network channel to sort of fill the bits into the the pipe they have available at the time that can be a detriment sometimes with when you consider broadcast quality so when you think about a good video experience you know watching a movie or or things like that it's often about constant video quality and constant frame rates and if you know anything about video encoders constant video quality can often be very peaky so like if there's a lot of motion or if there's complex scenes the video encoder bit rate goes up too if you know if you have the encoder set for constant quality so you have these huge Peaks valleys things like that and that is really not very friendly for low latency applications obviously you have a certain channel that you have to and if you have this peak you know it's gonna it's gonna be hard to push it through so the key thing to think about from a latency versus quality trade-off is that constant quality equals variable extremely variable bitrate and on the other side of the coin a constant bit rate equals extremely variable quality those are the two ends of the spectrum obviously most systems try to balance those things from a scale point of view that's sort of another interesting topic WebRTC has this feedback channel per stream so what are the implications for a conference call so you have this single video encoder and you're feeding it to n RTP stream or and n RTP endpoints you're also going to get an RTC PA from reports back and a single video encoder and chaos ensues so let's slowly video encoder to do well so in the standards there's a bunch of work I think Eric mentioned something about simulcast and SVC that's sort of the latest and greatest the jitsi guys who we work with pretty closely have an implementation of simulcast in the the video bridge we've been playing around with that SVC is another video encoder technology so both of these not unlike how - implements multiple bit streams have multiple layers so simulcast does it sort of explicitly excuse me explicitly where it creates multiple streams and sends them as different RTP streams SVC is a little more complex and well sometimes even a lot more complex in turn but it has a lot of flexibility so you can create multiple enhancement layers is what they call them so it's a single bit stream but it has multiple enhancement layers that you can subscribe to and that can be either both in quality or in frame rate so temporal versus spatial to use encoder terms and that can be adaptively shared among all the participants so if you have somebody on a very good connection they can subscribe to all the layers or the highest bitrate layer and get a great experience if you have somebody that's on a not so good connection they can downgrade and and and subscribe to the lowest layer and this makes the experience great for all depending on their connection but so this does enable larger the ability to provide a good experience to a larger audience but of course larger is relative from a scale point of view we're really talking about tens hundreds might be stretching it a little bit of participants at least in the near term depending on the capabilities of a of a PC or a mobile phone to encode multiple layers and it also it does have some impact to the SFU as well in terms of managing all the feedback coming to it so can I have my cake and eat it too well maybe so one thing we've been thinking about is hybrid broadcast solution and this has some interesting things but yes maybe we can have our cake and eat it too so the idea here would be that you know like from most broadcasts you know or at least the ones that people are doing generally aren't going to have the millions of viewers there gonna be a lot that are you know tens of participants or something like that so maybe start with low latency low participant count streams and then you know like a celebrity mode when somebody joins that everybody wants to see the threshold happens and then you switch to incorporate the larger latency dasher streams another use case for this could be corporate presentation or a call-in show so you know you reserved the WebRTC streams for the participants that are actually talking or or other things and then you know for the other listeners I mean latency is basically in the eye of the beholder so if it's delayed and I'm just listening in do I really know that it's delayed so that could be a pretty effective solution so point is when you think about your video streaming apps and what you require from this trade-off triangle whether your latency is important quality important or if you're trying to get good scale it's important to consider all these factors and pick the appropriate so after all all we have you know in the browser and mobile we have all these tools available we can build some cool apps and and build great experiences so thanks a lot thanks Chris do we do we have any questions for Chris so you mentioned the SFU as a way to bridge to multiple clients could you use that sort of as a CDN if you bridge them together or expanded that capability some people have talked about that now the feedback thing gets in the way I didn't go into all the details of why that would work or wouldn't work you there's a bunch of messages that come back things like requesting iframes and other things you may have to synchronize so I think people are looking into those architectures but it is a complex problem hopefully we can solve it fairly soon but you know again again I go back to the you know you don't you don't want to have a conference call with a million people in it you know obviously they'd have to tell everybody didn't to hit me all that stuff which is just a problem with ten people so yeah again it goes back to with WebRTC this feedback channel so there is techniques that are being looked at that can solve those things but if you're going to a thousand people you may just want to go the HTTP route hey Chris hey you a question about this great talk by the way I'm just curious if you thought much about the role of CD ends in this because they add so much latency with the whole HTTP or MPEG DASH and you know our approach to what we're trying to do is like actually leverage the existing cloud networks that are there and in clusters of servers together it would very low latency performance across and get large-scale plus the quality and basically flattening your triangle I'm just curious what do you think about that approach yeah I mean I I guess it's definitely a trade off so like the ease of delivering content is is the benefit of using CD ends now and maybe in reference to that his question is well like I think people are thinking about maybe ways of sort of combining some of the feedback coming from clients and maybe trying to get a more low latency experience using WebRTC but it's not so straightforward sometimes and the Devils in the details and you know it's actually could be an interesting you know I'm curious in WebRTC if they're we may want a more latent mode that is designed for broadcast sort of like RTSP actually supports generally there is a latent mode that allows packet retransmission and other things to get a better quality stream so there's a lot of things to think about but I think from a browser point of view probably some of the thought was we have tools that can do HTTP download we have tools now that can do WebRTC let's see how we can work with them together and you know maybe things will evolve to incorporate some of the things that you're talking about there great thanks Chris thanks

Channel: WebRTC Boston

Views: 11,127

Keywords: webrtc, webrtc boston, streaming

Id: OQPczSk3cjk

Length: 23min 57sec (1437 seconds)

Published: Sat Mar 05 2016