NETINT - Choosing the Right Technology for Low-Latency Streaming: WebRTC, LL HLS/DASH, and H5Live
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
