NETINT - Choosing the Right Technology for Low-Latency Streaming: WebRTC, LL HLS/DASH, and H5Live

NETINT - Choosing the Right Technology for Low-Latency Streaming: WebRTC, LL HLS/DASH, and H5Live

Show Video

Good morning, good afternoon. Good wherever  you are. I'm Jan Ozer. Thanks for coming to   NETINT Voices of Video, where we explore  critical streaming related topics with the   experts who are creating and implementing  new streaming related technologies.  If you're watching and have questions, please  post them as a comment to whatever platform you're   watching. We'll answer them live if time permits.  Today's episode is all about low-latency streaming   and we speak with Oliver Lietz, engineer, founder  and CEO of nanocosmos, a Berlin based company with   more than two decades of experience in streaming. The company's flagship product is nanoStream   Cloud, an industry reference for reliable B2B  interactive live streaming on any device. Oliver,   thanks for joining us. Tell us a little bit about  your company, how long you've been in business,  

your products and services, that type of stuff. Very good introduction already. It's going back   25 years actually now. We are celebrating this  year, which was amazing. Not even digital cameras   existed in that time and we were starting with  digital videos 1998. And we have grown from an   engineering company formally providing codecs  and software tools for the broadcast industry,   now to provide a full live-streaming platform  for interactive use cases. Which means that  

the latency between the camera and the viewer  needs to be very low, ultra low as we say. Around   one second end-to-end, to enable this real-time  interaction between the camera and the viewers.  Okay. I was going to ask you about a typical  customer, but we got a free NABK study today   and it talked about a conference that you helped  produce called the Future Investment Initiative.  

Why don't you describe what that is and  what was involved and what your role was   in getting all that set up and operating? Well, that was an big conference show in   Saudi Arabia with several thousand attendees,  10,000 attendees on the location and around   15,000 in the virtual space. There was high value  people speaking on the stage, celebrities but also   important politicians, investment people talking  about renewable energy investment policies. A   really high profile event which was held there. And they needed a reliable solution for  

interactive live stream, which means  they wanted to have a global audience   anywhere in the world, directly available in  the browser. And have that reliable working   for interaction with the audience and the panels.  To be able to communicate with chat feedback from   the audience to ask questions for this event. Several channels were set up for that. And we   were getting the stream from  the production setup venue,   picking that up to our CDN, do the whole delivery  worldwide. And also running the player on the  

browser which was running with adaptive bit rate  to accommodate on all different quality levels.   You have a running livestream for interactive  purposes on every device. And that needed to stay   very stable and 100% reliable for these shows. Were you the whole streaming   component or just a piece of it? We were the core of the streaming components,   but there were also several channels sent out to  social media platforms like YouTube and Facebook,   but the primary stream was run through our system. Give us a sense of why low-latency was important.   Were videos coming back from the  audience or was the chat function   where it needed to be interactive? Or why was  slow-latency important in that application?  With interactive streaming, we understand that  there is a kind of feedback from the audience   back to the presenters. Which in almost all  cases is not video based but text based. It   can be a voting, a chat, a question Q&A, any  kind of action which is triggered by someone   in the audience. And then on the other  hand, gets some interaction back. That,  

in these cases, can be like chat Q&A questions.  And this enables the interaction only if you   have real time streaming, low-latency streaming to  have the delay very low between the both parties.  Looking outside of that particular application,  are there any applications that you serve where   interactive video is a major component of that? We see two major scenarios for that. One is  

similar to on what you just mentioned,  enterprise space, large event space where   we also have corporate customers who are doing  town hall meetings with Q&A. Which all needs   to be accessible directly in the browser so  you don't need to set up any kind of the Zoom   client or so and can directly watch the stream  on every device. Majority of our clients are   using mobile phones so it needs directly be  accessible on every handset you are using.  And then you have the interaction elements on  separate to the video or on top of the video to   ask questions, give any kind of feedback. It can  be for this corporate space. But on the other end,  

there is also the large space of monetized video  content, which is like betting, gaming, auctions.   Live auctions is quite large. We have a revenue  channel directly based on this video stream and   can't use the application without real-time video. I mean lower latency is always better but   there are trade-offs associated with  latency. Can you talk about those?  There are certain applications which really  require low latencies. In the auction space,   you can't go higher than two seconds end-to-end.  It must be very low, otherwise you can't also  

legally keep up with the live auction with the  real people sitting on the venue for example.  And this requires complete control of the whole  workflow and adaption to the livestream which   you get to the devices. Very important is that you  have a good adaptive bit rate control system which   requires right coding of the right bit rate level  to send out the right bit stream to the receiver. 

And that means that it's not always the best  to have the highest quality, like 4K or full   HD sent out to the clients. It can be as small as  whatever, 320 times to 40. At least you have the   live content in real time and can enable this  interaction on your monetized revenue channel.  You're saying that quality or  resolution may suffer if you try   and make the latency as low as possible? Not necessarily, but everybody's running   in all kinds of different networks. You  may have hostile environments where you   are on commuting or any remote locations. Network  availability varies. Especially on mobile, you go   in a whatever location where network quality  drops suddenly and then you need to adjust.  To keep up the quality as high as possible  means not only highest video quality but also   the whole quality of experience. That means the  interaction needs to stay active, it can't buffer,  

things like that. Needs to adjust to the network  conditions you are using. And if you have a small   bandwidth network like 3G with 500 kilobits per  second max, it just needs to be a low quality   video. But and at least you have a signal  and you can keep up the application running.  What technologies are available  for low-latency streaming that   can operate in the sub-two second realm? When we started that there was not much   available actually. Everything was shifting  towards edgeless and DASH. And people were   surprised to suddenly see these large latency  values of 30 seconds, one minute, several   minutes. It was quite surprising, too many people  who wanted to have interactive videos somehow.  These use cases were somehow not covered by the  traditional CDNs and still are not. Traditional   CDNs based on HLS and DASH are still buffering  things. And you need to keep these things  

under control to keep latency very low, which  can go maybe 2, 3, 4 seconds based on these   approaches. But then you are really fighting  with the closest challenges you can get there.  That's why in the end, we decided we need to  create something on our own and technology   which really keeps the latency in the second  range. Which has the server side under control   but also the player side under control. It's  an active connection between the player and   the server and not an HLS or DASH just  passively watching a stream and buffering   whatever is coming from that. So that the whole  technical challenge is a bit different there. 

There are also other cases like WebRTC based  which are created for real time interaction but   which originally were created more for smaller  groups in a video meeting like we are now.   And guests might come into this video  meeting as well. But if you want to   enlarge this group to have everybody available  on all mobile devices and all mobile networks,   WebRTC also gets very challenging. That's why we  decided to create our own technology around that.  And what we noticed also is that there are many  technologies available for all certain kinds of   use cases, but technology is not leading anymore  in these decisions. It's more like the whole   complete platform, the complete application. There  are things like adaptive bit rate, transcoding,  

analytics, the player, the  whole CDN, the network, ingest.  It's keeping that everything under control. It's  not only the streaming technology but the whole   platform. And that's quite challenging  for business customers who want to focus   on getting their business accomplished. You're saying that low-latency HLS and   low-latency DASH, I mean what's the lowest latency  you can achieve reliably with those technologies?  With HLS and DASH, you can go down maybe  two, three seconds or something, which   is higher than the ultra low-latency real time  activity I mentioned. If it goes back and forth,   it's already six seconds then, so there's no  interaction possible anymore. And then you also  

only have the best case. It needs complete control  on both ends, on the CDN, on the player side   to keep that under control. And that's why the  technology approach we do is a bit different here.  And you're saying that once you look  at the ultra low-latency technologies,   the people you're dealing with, they don't care  whether it's WebRTC or any other technology, they   just want I guess a solution, a turnkey solution  that works overall. Why don't you talk about the   solution that you guys offer in that respect? We offer the complete CDN, the network, the ingest   points globally so you can ingest livestream from  anywhere in the world you want. We do the delivery  

or we do the transcoding in the first place first  to several bit rates. We provide quality levels   for every network of the clients. And we do the  distribution around the world with several edge   locations also globally available. And we have  the player software and which our customers   install on their webpages and which picks up  the livestream from the closest edge location.  It's a complete auto low-latency CDN plus  the live transcoding plus the player as an   integrated product. And on top of that, we also  have an analytics platform which is very valuable,   which is more and more required by our  customers. Which gives more insight  

into the quality of experience of the whole  workflow. Which can identify potential issues   on any part of the video streaming workflow. If latency goes up or if it's buffering or   if you have network connection problems, you need  to have a kind of identification of every part of   the workflow and need to track this down to these  things. Plus you have, of course, the option to  

get business intelligence to see in which part of  the world which things are playing, how much the   volume, how large the volume is, et cetera. You talked about adaptive bit rate delivery.   Is that unusual in the ultra  low-latency technology realm?   I mean does WebRTC do that or is that possible? WebRTC has some kind of scalable mode included,   I'm not sure about the details here of how has  that gone yet. It's different to traditional   adaptive bit rate. We do a hybrid approach like  on traditional HLS, DASH scenarios. You send   something to us, we create a bit rate ladder and  create several bit streams out of that. And then  

we do that or based on our low-latency protocol.  Send it out to the edge locations and to the   players to keep the right quality up and running. It's a layer-based approach.   And I think WebRTC, it's a bit different managed.  That's also challenging to get the player under   control to have the compatibility stream running  the same time on all devices. WebRTC here is also  

I would say a beast from the standard here. It  has created or has grown from the initial beta   version and the Chrome browser which is  now available on every device. But still,   every browser does it a bit differently.  And the whole handling is quite complex, so   getting that under control is quite challenging. What does that mean from a... If I implement your   technology, how do I integrate my player?  I guess I send you a stream into the cloud   and you handle the distribution. What's the  playback side look like? How do I integrate   that into my whatever application is that  I'm building for that event or that program?  It's like other player vendors are doing that.  We have a JavaScript code snippet which you can  

put into your player page. You also have an  iframe which you can easily use or dashboard   directly website where you can watch the stream. It's different levels for integration which you   can use. Copy-paste the code snippet  to your webpage and then you directly  

have the livestream integrated. And the adaptive  bit rate handing and the connection handing to   the closest location and the right network,  et cetera, that's all done by the player.  That's the intelligence which is in the player  library and which makes it more valuable than   just a player. And then you need to connect it to  a third party CDN and towards third party encoder,   et cetera. It's more the complete integrated  approach which also creates a value here. 

The program we talked about a  few minutes ago, I think they had   15,000 remote viewers. What's the largest audience  size you've supported with your technology?  It's not like in the CDN environments where you  can directly go to millions. At least what some   vendors claim. But it goes usually about 100,000,  200,000 concurrent streams. It's sufficient for   on all the applications we are using until  now. If there is need for larger growth you   can scale up to other services as well  here. That's an indication of the scale  

you can reach with this technology. And you talk about your own CDN. Do   you have your own build out of a CDN  or are you working with third party   CDNs and just integrating your technology  stack as necessary into their technology?  We're working with third party partners  but not CDNs because when you have a   CDN you already have this caching approach  with these HLS trunk file transfer things.   That's why we need software control on our own. We  make that based on our own virtual or bare metal  

machines which we run on our partners networks. It's a kind of multi-provider approach. It's   Amazon but also other providers and also has a  multi-failover system built in. Our goal really   to reach 100% stability and no downtime. Which  we enabled by automatic failover to a data center   from another vendor, if something's going down or  something's going wrong. And we put high effort  

into that to keep that system up and running. There are a lot of challenges. And we are quite   happy that we have complete control over  the system and insight and can tune the   knobs if required on these systems. How do you typically charge for an   event? Is it by audience, is it by  delivery streams? How does that work?  It's a rough indication of the volume  you will want to have. But in the end,   it's volume based then like other providers. The  bites going through the system, traffic-based.   The larger the audiences, the larger the volume  will be and there can be some packages prepared. 

Usually, we have self-service packages which  start 500 bucks per month. But usually, it's   customized quotes and offerings which we discuss  with the customers, with our partners. They have   the right package for them available. And  then they can scale up easily. Based on the  

smaller packages, they can grow as they need. And can instantly livestream at more streams,   at more transcodes, et cetera. It's a self-service  system, when it's one started. And then you can   grow by yourself based on your demands. What's the codecs side look like? Are you   stuck on H.264 or are you starting to extend  out into other codecs? Where are you with that?  We are still with H.264 because that's the most  compatible format which is running on all devices  

for the distribution side. We are working on also  other codecs of course, like HEVC but also AV1,   which then have also challenges again  for the realtime encoding mode. And then,   there come interesting solutions in place like  the net end solution, which makes realtime   encoding more efficient on the server side. Picking up the stream in the right format for SI   quality as possible still based on H.264, it can  be 2K, 4K whatever, but could also be H.265, AV1,   et cetera. And then we transcode it to  the formats which are available on devices  

which are still H.264 on the delivery side. Why the delay in HEVC? I mean transcoding has been   available for our product came out in, gosh, '18  or '19. Why it's so slow? Is it the decoder side,   the whole Chrome thing or what delayed that? Yeah, HEVC is maybe comparable to H.264 and   these things, if you set up the right  profiles. It's a bit more complex. We  

have more profiles available for HEVC encoding  than for H.264. You even have more profiles for   AV1 and then it's getting also difficult. It's  buffers a bit more also on the encoding side.  That's trade-offs we consider, which is  always the question based on the customer   requirements is whatever, 100, 500 milliseconds  more. Would that be sufficient or not trade-off   compared to the quality you get then? That's  things which depend very much on the use case.  Have you done experiments that  showed how much bandwidth reduction   you can achieve with HEVC or AV1? That's very dependent on the encoders.   As every video expert knows but maybe not  everybody in the industry knows this, that   the encoding results and the quality results are  very much dependent on which encoder brand you are   using, which configuration you set to the encoder. There are things like baseline profile, main  

profile, which decide on the quality. But there  are also implementation details on the encoders,   which create higher or lower quality. And there  are standard encoders available but there are   also software encoders, hardware encoders,  all kinds of encoders available. Where,   if quality is key, you need to check if  the quality results are really comparable.  And also when you compare them, H.264 to H.265  or HEVC or whatever, you need to be sure that   you compare apples to apples and not a different  profile to another profile which doesn't match.  

In the end there is, of course, a benefit but  that's not easy to get that under control and to   find the right profile for the right distribution. For HEVC there are numbers. You know that better   than me, 20%, 50%, whatever benefit. But  that's not deciding in all cases because   the whole handling also needs to be under control. How much of the charge to the customer relates to   the bandwidth that you distribute? Is that a major  component of it or is that just an afterthought?  We charge basically based on the bandwidth.  Which is then decided on the player side. If  

you are on a low bandwidth network then you can't  go up with the bandwidth anymore. You need to go   to the limits what the audience has. We have a question from Mark Kogan.   Like all his questions, I think it's going to lead  to another question but let me throw this out at   you. Is it a must-have for the segment generation  to be in direct sync on the incoming timestamps   from the encoder with frame accuracy and sync?  Can you answer that or is that too vague?  That's very technical and that's the details we  really don't care too much about. And in the end,   it doesn't matter what we get. You  can configure your encoder even with   one seconds, four seconds, corp size, we still  make a low-latency stream out of that. And that's  

the challenges I meant when and you want to handle  these things yourself. You need to worry about all   these details. How long is the job size? How  in sync are the segments to your distribution,   et cetera? And that's what we try to hide below  our APIs to make it as easy as possible to use.  Let's cover the implementation side. If  I'm running a low-latency event with your   technology. And I guess I wasn't aware that it  was available on a... Turnkey is a bad word. But   I can go to your website, I can sign up  for it, I don't need to talk to a human.  

I can just send you a stream and integrate the  player and then I'm done. I mean is that, what   percent of your customers are actually doing that? Many customers are starting with that. Our   approach has always been to provide an honest  and transparent way to use our technology, make   it easy to use. And follow the approach seeing  is believing, which means you can try it out,   you can directly sign up, you use it directly for  your system. There's even a seven-day free trial.  We believe in what we do and what we can  provide so it's very easy to get started.   And that's also the nice thing about that, that  you directly get a live stream as a result and you   get a visible picture. You can play with it and  even run the open source software, OBS, to start  

from your webcam and get low-latency results with  this. And don't need to have any specific hardware   set up on your end and camera set up. It directly  works out of the box with webcams as well.  And starting with that, you can then  grow and add more professional equipment,   et cetera. And integrate the player on your page,  et cetera. And that makes it very easy to start   from very basic things and grow from there. Let's walk through the implementation. I want   to do a live event, call it an auction, a  celebrity or charity auction. How does it  

work from an integration standpoint? You said I  can use a webcam. But if I've got a camera set   up, you just provide a RTMP type link that  I need to send to or how does that work?  You need to have an encoder on your side. Based  on your camera, you need to have a live encoder   and be a software. As I said, OBS, it can also  be a hardware encoder. We partnered also with   companies like Osprey Video, who integrate our  encoding URLs directly into their hardware boxes. 

But it's basically an RTMP URL which you put  into the system into your encoder. You configure   the stream for the right bit rate, which you on  your end need to decide on your own how high the   quality shall be. Whether it's a full HD stream  with whatever, three or four megabits per second.   And then you send us the stream, we give you  an interest URL. We take care about the rest.  That's the setup you need to do on your end  is keep things under control on your network,   that the network bandwidth is available for  this upstream. And then we do the delivery   and you will have a player on the webpage which  you can put on your own webpage and have the   livestream then end-to-end on your application. Now it's not only RTMP, of course. We also can   work with SRT, which is a more and more prominent  protocol used everywhere in the broadcast industry   and has advantages in unstable network situations.  For the upstream, we are also providing a web  

integration now, WebRTC ingest protocol, which  is in a similar level like the SRT. Will make   it easier in hostile environments. Whatever is  sent to us then, we take care about the delivery   worldwide and the delivery then to the process. What are the analytics I care about from a   stability standpoint? That I'm going to  get stream count and number of viewers   and all that stuff. But from a reliability or a  stream viability perspective, what information  

do you give me that lets me know things are  either working well or about to go wrong?  Yeah, of course. Things like you said  based on the volume, the stream volume,   the number of viewers, you have a  geo-based vault map, you can see where's   playing what. And in terms of the streaming  integration, what kind of errors can happen?  Latency can go up, the error rate can go up, like  buffering ratio. Networks can go off if you get   lost in whatever network situations. There might  be larger customers running in corporate spaces  

where you directly have connections through  small bandwidth connections only to the server.  That's things you notice only when you  have metrics collections from the server   side but also from the player side. And we  can aggregate all that to make that visible.  Hang on. We have a question from a Paul Connell.  If I'm comparing your system to a WebRTC-based   system, what are the five points of comparison  that I care most about? What do I look at when   I'm comparing you with the WebRTC-based system? I don't know if you can count to five now,   but I can try to list some things, some  differences. WebRTC is usually browser-based.   When you create a WebRTC stream, you would usually  do that from the browser. It's originally created   for realtime interaction. And that means that only  smaller bit rate profiles were allowed in WebRTC. 

I think it's still only baseline in the Chrome  browser which is allowed. And you can go much   higher in the ingest quality when you do a  studio-based protocol, like SRT or RTMP. Up   to whatever, 10 bit, four to two 4K stream you can  send. Which is not possible in WebRTC. And on the   distribution side, it's also there are platform  providers who use that and cover that another to   stay ahead of the complexity. But if you want  to do that yourself, it's really challenging.  It's a big difference between creating a  small WebRTC kind of prototype end-to-end   which is working well and create a complete  platform which is working then for thousands.   Because even a WebRTC, it can go, it can  buffer, the buffer can go up. You need to  

get that under control, you need to measure  that somehow, make that visible et cetera.  You need to have the adaption of the bit  rate if suddenly network goes down. What   do you do then with your skip frames, drop  frames, will video go off, audio, go on,   et cetera? It's quite challenging to make that on  your own. And the platforms who are using that,   of course, have similar challenges as we do. We consider our solution quite stable and   usable for any device and any browser because  it's based on HTTPS and website delivery. Which  

was much more lightweight and easier getting  under control. And doesn't need to have any   kind of third party protocols, firewall  openings, et cetera available. It can go   through the standard HTTPS ports, et cetera. It's going to be the quality of the incoming  

stream and then the robustness of the delivery  mechanism? Were those the two key ones?  Yeah. Also the scale somehow. To get to the scale  of thousands of viewers that try use WebRTC if   you want to make it yourself. If you have a  platform, I don't tell anything about other   vendors who are doing that. But as we learn from  our customers, they are very satisfied with how we   do. It's very lightweight and easy to use and  which makes it more seamless and integrated. 

There are newer things like WebRTC is still under  development. Things like Google, Apple, other   browser vendors are still working on improvement  and improving the technology. We are also looking   at that, of course, and see what what's the  best technology going forward in the future.  And that's the things which we then cover  also by integrating in our player or APIs   to decide on what is best for the use case,  what is best for the user experience and   for integrating into the whole product. And try  to cover the technical complexity around that.  We've got a question from a Mark Ritzman. What  about close captioning for your application?  Yeah, that's a good question. The demand actually  for doing close captioning for our applications is  

rather low so we don't do that. Usually, there  are ways to use that as a separate channel.   It's in the real time interaction space usually  not so much required to do that because you   directly interact with the presenter and the  audience. And don't have that requirement for   these kinds of applications, at least  how we see it. That answer is no,   but there's a reason for doing that. Getting into the inner workings   of the transcoding capability in your  system, where did you start in terms of   getting a stream in, you need to transcode it to  encoding ladders. Did you start with software? Did   you start with GPUs? I know you're looking at our  technology, I'm not going to ask you a lot about   that. But talk to us about the transcoding side,  where you started, where you think it's headed. 

Transcoding is challenging generally, as you  know. You need to have the right balance between   performance, quality and overall throughput. With  the software, of course, as everybody else also   probably starts with software encoding first.  See how that works and getting many channels,   many parallel channels on a server running. Trying  to increase the number of calls on the server   using larger machines. Then tuning the bits and  knobs of the encoder to use efficient profiles and  

find the balance between quality and the results. It's always a trade-off somehow. As everybody   knows when you go to a livestream in the live  stream, we just can't get 4K quality on a low   bandwidths mobile network. In the end, you need  to compress something. And you will see the   compression results to make that as efficient as  possible as part of the encode and the transcoder.  And there are efficient software solutions  which we use. Based on our history, we created   software encoders ourselves so we know what  it's about. And there are things like H.264,   which is open source based. Built into  things like FFMB. There are things like  

Gstreamer. There are things like hardware  acceleration on Quicksand, inter machines,   AMD machines, there are ASIC solutions like NETINT  provides, which makes encoding very efficient.  But there are also a wide range of solutions  which you have here and which you can control   and change. And finding the sweet spot is  quite challenging. And the more volume you get,   the more challenging it gets  to find the right applications. 

And in the end, it's also a question how large  the business value is to have the highest quality.   With software encoding you can go very high  with quality, you can create overloading CPO   load with that for one channel of 4K encoding  if you use the wrong profile. But you can also   make a decision. That's also part of the trade  of you need to control on the software side.  What's the typical encoding ladder? I mean  if you get a 1080p stream in, what are you   sending out from a ladder perspective? Typically, for our applications the   bit rates are rather medium or low. When we  get 1080p in, it's something like three or four  

megabits only. And then it goes down to either a  second 1080p profile, like two megabits or already   720p profile, which is then the standard HD and  delivery. And we have low profiles like 480 and   even 320 so it can go very low to keep up the  quality on low bandwidth networks and devices.  But also usually, it's not more like three or  four steps of the ladder in ultra low-latency   because you need to decide on the player's  side very quickly if you need to change.   Making that too complex and making the  ladder too large is also not optimal.  

That's the rough operating points we are working. And there are more and more questions about   getting the quality higher, at least  for premium streams going to 4K,   et cetera. We also enable that and then increase  the ladder a bit to the full HD profiles as well.  This is a question, as we test internally,  one of the questions we have is how far you   want to push the server. We think we can  push our hardware to 95% and not really  

worry about anything crashing. If you're running  transcoding on a regular computer using software,   what CPU utilization level starts to get  you scared that you may have a crash?  Yeah, it's gradually somehow. It starts already  getting impact with 70, 80%. Usually, you should   be very careful about that. It's interesting to  learn also about the kind of things which create   that kind of load. The whole processing pipeline  loads the whole system. It's not only CPU,   it's also the memory load. It's also things  like scaling. You know what I'm talking about.  Another question from Mark. Let me try and repeat  this word for word. Is it HTTP/2 based or how  

about compared to QIC. Or QUIC oriented? I guess  he wants you to discuss those input protocols.  No, that's more on the delivery side. HTTP is  available several versions. The current standard   almost everywhere is used 1.1. There is HTTP/2  and HTTP/3. And part of that is the QUIC you   mentioned, so it's UDP-based. There are challenges  around that as well. We are working on that to   make that available also on the large scale. But there are even networks which don't allow   that. It's challenging also to go through all  networks for that because it has compression and  

encryption built in, in the protocol which not  every provider and not every legislation likes.   There are things around that. If you can use  it or not, that's not on our decision but we   enable these things to make it, yeah, to give  the quality and the latency as low as possible. 

And it's a good point because generally,  theoretically UDP-based protocols   create less traction and less latency in  the system, even on the network level.   Because on TCPO need to acknowledge every packet  and on UDP you can just type it through. But   there are a lot of challenges around that. Ricardo Ferrera is asking if the stream will   be shared afterwards. I feel safe in saying that  there's nowhere you can go where you won't see   copies of this stream. LinkedIn, Facebook, our  website, wherever, it will be available afterward.  

Go to the Voices of Video page on NETINT and  I'm sure it'll be up there hopefully with the   transcript within the next few days. Oliver, did  you have anything for me? I know you talked about   that in our initial meeting or you decide to  take pity on me and let me go on with my day.  If you want to mention some of your challenges you  see so we can see if we can match that somehow.  Some of the challenges? Actually one of the  big ones is one you're in the middle of. Talk   to us about the efficiency of FFmpeg. Not  to go totally wonky on the audience but  

multi-threaded efficiency of Ffmpeg. And I don't  know how much you've experienced that or how much   you've compared it with Gstreamer, but any... That's been a big challenge for us. We've just,   we've had great performance with high  CPU utilization. And then we throw   a complex encoding run, maybe 4K or maybe  different things trigger it. But then we see   throughput stop. But CPU utilization is still  pretty modest. It's in the 40 to 50% range and   utilization of our cards is still pretty  modest. We see this issue with Ffmpeg. How  

much have you encountered that and how much have  you played with Gstreamer as a way to avoid that?  Yeah, that's a great question. That goes really  in the deep details of coding and video coding   and software coding. And that's typically  when you use tools like Ffmpeg or Gstreamer,   they're working quite well so they're  quite efficient. They have gotten very  

stable in the last years and doing a good job. But when it comes to really high performance   and large throughput, you need to get into  the details. And need to maybe do your own   software development or your own configuration and  find the right spot to make that really scalable   on the server side. And that's also a great  effort and I agree that that's challenging. 

Switching the software from Ffmpeg to  Gstreamer creates completely different results.   Tuning things in Ffmpeg and changing buffers and  profiles also changes results. That's interesting   to learn and that's a process which is ongoing,  of course, and to make it more and more efficient.  Have you played with Ffmpeg 6 in that regard? Not yet. We just moved to the latest 5 version  

but looking forward to see how 6 is  performing. The announcement was saying   that there seems to be a improved trading  behavior there but we didn't verify that yet.  I did some very simplistic tests. I had one of  the command strings that I talked about that   really crashed our system. In all systems, Ffmpeg  and software or with our hardware. And I ran it  

with 5 and I ran it with 6 and I saw absolutely  no difference. And I do that with two of those,   so there could be a switch that I'm missing.  It's in front of our engineering team at this   point. We're trying to figure out what's  available with 6 that wasn't available.  The thing about Ffmpeg is it's  really easy to use and there are   plenty of examples out there. Gstreamer is a  little bit harder. And then if you go to the SDK,  

you've got complete flexibility with how you  approach our encoder. But it's a lot more work.   I mean it's not challenging work. Most of our  customers at scale are using the SDK. But all of   our demos and all of our quick starts are Ffmpeg. And it just really hurts when you can get up to a  

certain performance level and then you just  hit this wall. Yeah, I had high hopes for 6,   but don't see any quick resolution to those  issues. Looks like I'll be learning Gstreaming.  Yeah. And we keep working  with it so that's what we do.  We're done with questions. I'll let you go on with  your day. I appreciate you spending time with us.  

It's interesting to hear about new technology. I  learned a lot of stuff that I didn't know about   it. And I appreciate you taking the time. Thank you very much.  Okay. We're going to sign off. Everybody,  thanks for coming and we'll see you next time.

2023-04-01 09:51

Show Video

Other news