Pieter-Jan: Hello and welcome everybody to this amazing webinar about supporting Tizen 2.4. Let's kick off!

Today we have two very amazing speakers, of course. One of them being Michel, who is sitting here next to me, our VP of Engineering. Michel, I'll let you introduce yourself.

Michel: VP of Engineering that sounds wonderful. Yes, at THEO for a while right now, and you have to talk with Pieter-Jan on Tizen 2.4.

Pieter-Jan: Yes, and I of course have been CTO at THEO for a while. And while we've been here together, we've seen quite a lot of challenges, especially surrounding smart TVs over the last few months and years. So, I assume that given that you are in this webinar as well that you would like to learn something about it so let's kick off.

Pieter-Jan: And let's see first should you actually move to smart TVs because that's always a good question.

Michel: That's the very good question. There are a few things if you look at smart TVs the title says it: “Tizen, more than ever the go-to platform.”. We are saying this since in the latest Conviva state of streaming reports you see that the growth in viewing time in the year of time on Smart TVs more than doubled. If you zoom into this a little bit more, you see that almost half of the Smart TV market is going to Samsung. Tizen being the Samsung operating system, I think it clearly shows this is more than ever your growth hack and the go-to platform. We have a few questions that we want to get answered today. Let's maybe first zoom into how we can bring our application to Tizen, Pieter-Jan.

Pieter-Jan: Yeah, and I'm going to make it quite easy for myself. Why? Well, we've actually written a pretty extensive report on this a while back where you can read all about it. But just so that everybody knows the highlights. I'm going to say something that people are going to mock me for, but Tizen is actually a relatively easy platform to reach, simply because it is pure HTML5. It's the same as your website, you can recycle business logic, you can reuse a lot of code that you have, you can actually reuse the MSE, EME players that you're using, or at least if they work correctly, but more on that later. You can actually have one code base to cover all of the Tizen versions. You could potentially even have one code base to cover other platforms as well, like webOS, your website, even set up boxes like RDK. All of that can be in scope for a single code base, and we have some customers who actually do this. But of course, it's not that easy. But if you want to read more on this, just go for it, it explains you how to make a bundled app, how to make a ThinApp, what kind of steps you have to take to get everything into the Tizen app store, because that is something on Tizen that you do have to take into account. It can take a few weeks to get through review, if you're lucky and it doesn't get rejected at least. But all in all, the thing to remember, it's all HTML5 and it can be relatively simple if you're using the right tools. But well the tools are a bit more tricky.

Maybe also important to know if you're looking at Tizen in general, there are a lot of different Tizen versions out there. The ones which are most often reviewed for people trying to build apps are Tizen 2.3 and up. But there is a very important note, Tizen 2.3 itself, you cannot really bring new apps there anymore, given that Samsung is no longer really supporting this, or at least not accepting new app store submissions for Tizen 2.3. But the nice thing is that all of these versions, Tizen 2.3 up to even Tizen 6, which was released in 2021, are reachable through HTML. 5. Tricky bit though, something that is always very important is that you might think - 2016 TVs, that's quite old, we won't see them in the field. Well, actually, you will see them in the field quite a lot. Keep in mind that the average smart TV still sits in a living room for about eight years. So that means that even though those devices are quite old, they will still stay in a relatively high relevance in the population until like 2024, which is still quite a long time. So that's quite important.

And well, Michel, I know that you've seen this with customers as well, that there are quite some old versions still in use in the market in general.

Michel: Yeah, absolutely! So, you see it's not just a Tizen platform, very big difference in different versions, mostly tied to the year they came out. If you what are the versions that big streaming providers are supporting, you also see that they support as of 2015 towards all the more recent models. And if you look at the ones that are, for example, not yet supporting the 2015-2016 models, they definitely have the ambition to do so in the near future. Also, most of these partners that are on here, they have their application even pre-installed on the Tizen platform. So really, it's pretty important that if you build a streaming service, these devices are still being used for that, and you need to be present next to all of these others.

If we zoom in a little bit further, I think Pieter-Jan already mentioned, these TVs are still out there for a while, not for the faint-hearted, let me explain that a little bit:

They're sold in 2016, they have an average lifetime of eight years as the main screen in the living room. That means they stick around until 2024. But if you look under the hood, what web engine they are using. You see, for example, the 2016 models are still using WebKit. If we look that up when, for example, this WebKit version on which they are running is released, you're at the 3rd of July in 2013. So that means that we are building up on technology which is engineered a pretty long time ago. For your application, that's doable, you can transpire to the older versions, and you can get your application like Pieter-Jan said pretty easily running there. But the playback technology under the hood is pretty ancient and if you question yourself what were you doing in 2013, I think you can imagine that it's not that simple to get people right now supporting you on getting playback, a video app working on this platform.

Michel: So, playback challenges, what are the options? We did an earlier session, right, Pieter-Jan?

Pieter-Jan: Yeah, we've indeed written a blog post on that as well in the past, but all in all, if you want to use that native pipeline that you were talking about, that was developed in 2013 for the 2016 TVs. That's definitely doable. It's actually very simple. There's Tizen's native AV player, very simple to use. You just load up the script and you basically make an element, give it a source and you hit play. It is extremely simple!

But as you mentioned, 2013, what were you doing back then? Well, you probably were not doing server-side ad insertion. Probably your technology stack looked a whole lot simpler: there was no key rotation, there were no multiple keys across different renditions that you're using. A very high opportunity that you weren't doing 4K, even though that these 2016 TVs usually support 4K and even HDR, but you probably weren't using it back then. So, there are quite a lot of challenges actually. We listed all of them in that blog post. We actually listed all of them in a separate blog post as well. And this is quite an extensive list of overviews.  I won't go through all of them, but the important thing here is that the limitations which are on the right-hand side, actually have to be added in on the left-hand side as well. And you can see that even in that 2020 category, which is quite recent, that list of limitations is still quite extensive. HLS support, MPEG-DASH support, they haven't really been updated that much on the Tizen platform itself.

And if you have to draw the line somewhere, I mean, probably around Tizen 3, Tizen 4 is somewhere where it started maturing more. But if you really look at it, it is quite painful if you want to support MPEG-DASH playback or HLS playback with all of the latest and greatest features with native playback. It's simply - I challenge you to do it, but I wouldn't want to be in your place if you try. That's at least my opinion on that.

If you look, however, at the other options that you have, there is MSE, media source extensions, and EME, encrypted media extensions on all of these platforms, even on the old WebKit versions. Even there, there were the initial drafts of MSE and EME available. And even though Samsung did manage to implement a number of bugs in them, and there are some very clear quirks and limitations there as well, you can actually start leveraging those to use a 'bring your own player' kind of approach. So, taking whatever video player you have today, if they are compatible with these drafts and if they implement all of these quirks, then you can start going there.

There is one relatively important side note that I have to make, I am saying that if they support these versions of MSE-EME, and if they support these quirks, then you're good to go. I must probably disappoint a lot of people because if you look for example at Dash.js, as a popular Dash player, it doesn't support these quirks, doesn't officially support the Tizen platform. For Shaka player it's a little bit better, there isn't official support, so if you really have an issue, you won't find support with the Shaka player team, but there is some community support left and right. Which means that, especially for more recent models, you can get something working, although it's again not really optimized. But If you don't have too complex of a use case, there are some options there. If you really want to get the bottom of the barrel, then well, I would advise you to wait for just a few more moments until we get a little bit further down the slideshow, because there definitely are ways to get all of the latest and greatest up and running.

Pieter-Jan: And of course, one of those important aspects, I have already mentioned it as well is: the multi-period part, the server-side ad insertion part, and there is a lot of importance there as well.

Michel: Absolutely! So, you on one hand can fix your playback, get playback running on these devices, but then there is the monetization aspect. So like Pieter-Jan says, indeed, you have the server-side, but you also have the client-side ad insertion as an option you can do. Knowing that 67% of the OTT providers right now make already use of some sort of advertisement approach, a VOD or a combo of that, this is a pretty important part!

If you look also at an analysis that was made, the stakes are also pretty high. So, if you have, for example, an ad not loading or you have five seconds of buffering, it's known that already 54% of the viewers will abandon your stream. So, I can only emphasize the stakes are very high, even on these old platforms. If you support it, you need to do it well.

If you now look at your options for advertisement, you could use Google IMA you would think, but also there, we need to disappoint you a little bit. Google, for example, doesn't officially support these platforms. They say it can work, but that's of course not what you want with these high stakes. So, if you want to have a one-stop shop for playback and monetization, stay tuned, because that's one of the things we will be talking about next.

Pieter-Jan: Yeah, and it's indeed, I mean, the monetization aspect, it's key. And there are a lot of, well, big challenges out there with Tizen 2.4. I mean, focusing on Tizen 2.4 specifically, because as mentioned, it's based on the WebKit version. It has an ancient version of MSE, ancient version of EME. And for a long time, if you even would search for getting DRM to work through MSE and EME, none of the search results would actually give you answers. The only thing that you can find is that you have to do what we call 'a hard reset in between periods', getting things to work in all kinds of weird ways. But actually, if you have to do a full reset of your decoder on Tizen, even on the more recent versions, it usually takes a few seconds.

The problem really is that it's all very obscure. Tizen, of course, is a black box, that's why there's a black box on this slide. It's not very easy to identify all of the quirks. There are a lot of undocumented things with Tizen, especially as mentioned, I mean, getting DRM to work. It is doable with EME, but there are some very big traps that you can fall into.

And we actually did a very deep dive here. We actually did the very time-consuming job of trying to reverse engineer Tizen 2.4. We had of course, some advantages here. We've been doing players for quite a long time. It's nine years at this point in time that the company has been around, but of course the people who are in the company, they've even been in media for a lot longer in some cases. That has really helped us to try and get some grip on what is going on here. But also tooling, we've been doing quite a lot, really built up our player from the ground so that we could really control every kind of work coming from the platform, trying to get work grounds in both for server side and for client side. And well, I think there's even still more things that we can further improve. But it definitely wasn't easy, and of course it was Michel's team who did most of this investigation. So, I'll leave it up to you to explain how we actually approached this.

Michel: Yes, how we approached the big black box. It's a very nice box, by the way, on the slide. So, removing the lid of the black box:

We had a number of challenges, we wouldn't think about the first one, which was to get the devices. It's an interesting scavenger hunt to get all of the devices here in our office, preferably multiple of one version to exclude that is something specific to a certain model. So that was one challenge. But going forward, we faced the challenges that we spoke about earlier - trying to find somebody who's able to support you or talk about these early implementations, and we couldn't find them. So, we reverted back to making sure we control the entire surrounding of the TV. What does that mean? We control the environment. So, we had to build our own streams so that we are able to change anything or influence anything which can make your stream different from codec levels, frame rates, bit rates, segment sizes, etc.

Not even talking about DRM in this case, because that's the other thing in the environment, making sure we can change every parameter on the DRM. I still remember very long days where we were trying to figure out what other parameter can we still change that would make a difference.

Thirdly, pretty important, with controlling the environment we could make the TV do different things. But then the question comes, okay, what just happened? So, building up our tooling and most importantly, also our test automation capabilities so that we're able to do exactly the same thing over and over again with exactly knowing what we changed on the other side. That's basically what the trick was: test automations, a controlled environment - tooling we control so that we're not having to rely fully on the tooling from the platform. The tooling, which also come with the same age as the platform itself, so not really equipped to the modern standards. That's what's allowed us to really control the TV and start looking at where are the differences. In this exercise, we haven't looked only at Tizen 2.4, but we took the whole lot, all Tizen versions, even webOS versions, checked different versions of the player, every time we changed something, okay, where is the difference? And then more importantly, remember the monetization aspect, we looked at this full feature. So, we were not happy just with playback, we took as of the start client-side, server-side, ad insertion, DRM, from the moment we started this exercise.

And then in the end it remains a needle in a haystack: lots of test runs, lots of analysis by our experts, what change could have caused this change in behavior, and countless hours of testing later. We found what makes a change. We saw, for example, that GOP structures, frame rates really makes difference, mostly in the SSAI use cases. That Tizen 2.4 requires a very, very specific DRM configuration. That's where the late nights come from. Tizen 2.4, this is probably something you can sort of Google a little bit - it uses separate audio and video licenses. If you look at server-side ad insertion, if you look at the quality of experience, which we talked about earlier. Enabling, disabling DRM is a must. But to be able to meet this quality of experience, doing some trickery with the decoder was essential. If you look at client-side ad insertion, which we took in from the start, also there we did a lot of optimizations. Quickly find multiple video elements, it's not a valid approach on these platforms. What Pieter-Jan already said, you need time to reset the decoder, etc. Which goes way beyond the quality of experience you need. So, it was an interesting finding out of countless hours of testing.

Michel: So, if you look back at it, where does it bring us, Pieter-Jan?

Pieter-Jan: I do definitely remember that we shouldn't cheer at first sight that there is something suddenly going well, because one of those very nasty things you mentioned it as well, can be device specific: a lot of bugs also in Tizen, we have some very weird false positives or even false negatives at some point as well, where suddenly everything stopped working. But definitely not something you should just talk about in a bar and say - hey, let's do this tomorrow, because well, you're going to be in for a pretty rough ride. A very fun ride if you ask me, but I drive on these kinds of things. I know you do as well, Michel, but yeah, definitely not something that is good for everybody.

I do think that our results are quite impressive actually. If you look at where we started, we started with the same where most people start. You start with getting clear playback to work. On Tizen 2.4 we didn't even have DRM-protected playback, that's quite painful to realize. You start with period transitions, which take five seconds, which of course is completely unacceptable if you ask me, to offer a real good quality of experience. But if you look at where we actually got after all of this work, it is quite impressive. You can check the comparisons with the other players as well. Because well, what Michel didn't say is that in the tooling that we've set up, we've not just been working on THEOplayer itself, but we've also added to our automation system, the capabilities to compare with Tizen's AVPlay, with Dash.js, with Shaka player, also with HLS.js and some other players out there.

We started basically at the same point where Dash.js and Shaka player started. Some things work, some things don't work. Of course you can argue - hey, but for Tizen 4, for example, SSAI is checkboxed, but shouldn't it be checkboxed as well for Tizen 3? Because you can make SSAI work on a Shaka player with Tizen 3. There the answer is yes, you can, but you get a horrible user experience. So, there for me at least, it was so bad on Tizen 3 that I wouldn't even give it a passing grade at the beginning. On Tizen 4 and 5, it becomes more acceptable. But especially on Tizen 2.4, it started out really, really bad.

But what were we able to do? Well, we actually were able, first of all, to get DRM working in an MSE-based player. I mean, knowing, learning which parameters we had to set, finding compatibility profiles with a lot of the partners that we work with. And I think I should probably give some special thanks to the people of EZDRM. 

Michel: And to our friends at Axinom.

Pieter-Jan: They both helped really a lot, allowing us to completely parameterize every request and every license that we were returning, which allowed us to really drill down, figure out what had to happen in the license, what we had to change on the player side to really make this work. But that I think was a first very big step that we did. But of course, we weren't done at that point in time.

There was also, as Michel mentioned, that decoder trickery - enabling, disabling DRM playback. If you look at a Tizen TV, it's an expensive device that you can have in your living room, but the chipset underneath, it's just so extremely limited. You can't decode two videos in parallel on most of these devices. As a result, you can't have a decoder spinning up to preload the content when you need to switch period. We really had quite an intensive rework of a part of our pipeline, or at least some very heavy optimizations that we had to do to make sure that we can just keep playing frame accurately, one frame after the other, in a completely 100% smooth way, turning DRM on and off, and as a result, also allowing for client-side ad insertion and server-side ad insertion to play back and to play without a five second delay or without even any noticeable delay at all.

Very big difference compared to where we were half a year ago and definitely a very strong foundation because we're talking here now about Tizen 2.4 but actually we've not just done this for Tizen 2.4. We've been doing this of course. with that same test automation system across basically every platform that our player supports. There's WebOS, but there's also Android TV. There's all kinds of other platforms out there. For all of them, we're running the same tooling, and for all of them, it's quite impressive. It's quite a good foundation that we've built here. Of course, we do have the advantage that we control the full aspect of the pipeline. So, I do think that there's a slight advantage that we have there.

But all in all, if you look at it, these results are pretty nice, being able to do a smooth playback, multi-period server-side ad insertion, client-side ad insertion. This is what I, as a viewer at least, would expect myself to be able to see.

Pieter-Jan: I don't know if you have any key learnings that you took away from this, Michel?

Michel: Well, the reward was great. It's frustrating platforms to work on, but the moment you start seeing it to work, to play, and you realize - hey, we did it and we can do it again! That is very rewarding. And also seeing down the road right now, the foundation we built with the tooling, with controlling the environment, with the ability to switch between different players, we realized that it's not only Tizen 2.4 that we're now supporting. We're really able to, in a few minutes, validate, is this working? Should this be working? How is it working? And even on that foundation, you see it right now already that we're working with customers and with partners to help them with their integration on these platforms, to give them tips, hints, how to work with the platform, give recommendations, what to do best. And it's pretty interesting to see all of that, all of these learnings come from the exercise that we did here. Also allowing our customers right now to build an application, it goes from Tizen 2.4 up until Tizen 6, without any issue.

Pieter-Jan: Yeah, and it's of course a very popular platform these days. I don't know how it is for all of the viewers in here, but definitely we're seeing it with all of our customers, some very big ones moving to Tizen, moving to WebOS, the smaller ones are starting to move as well. So, if history is going to repeat itself, same as with mobile, it will be a must have platform for everybody within a few months up to a year probably.

As mentioned, it's not a platform that's super easy to support, even though it appears to be very easy to support, given that it's all HTML5. You probably will have that product guy come to you and say, hey, let's get on Tizen. I heard it's all HTML5 because this guy mentioned it on a webinar. You can thank me for that later. But well, keep in mind that there might be some hurdles along the way, especially depending on what kind of use cases you have. But if you have any questions, don't hesitate. Let's get in touch. We're more than happy to help you. If you have specific needs on your use cases, we've gone through this exercise with a lot of different customers. We're helping quite a lot of people in this area. And as Michel mentioned, we have some awesome tooling in-house as well, which we can leverage to validate, to make sure that we can get your streams up and running with the right configurations, so that you can start using them really across all of the platforms. And not just reach the little screens but also get those big screens in your portfolio.

Pieter-Jan: I would say thank you all for joining. We will now be going into the Q&A session of the story. So, well, feel free to start asking some questions and let's jump into those. So, let's start publishing and let's start maybe with the questions asked during this session.

So, first question was:

“Can you get HEVC to work through MSE-based playback?”

The answer there is yes. Of course, there are some caveats. It, of course, depends a little bit on which platform or which Tizen version you are using exactly. But the nice thing about most of the big screen devices is actually that HEVC is supported pretty well. There are always caveats, you can do HDR on a TV that doesn't do HDR, for example, but for all of the Tizen versions, 2.3 and up, even HEVC is usually supported by default, so that's definitely in the books as an option.

Michel: The next one:

“For Tizen 2.4, does CSAI need the AD format to match the main video, or it can be a significant change, (as is typical)?”

Well, they don't have to match. The closer you can get them aligned, the better and the easier it gets. But you don't have to get the content which you're playing as the advertisement to entirely match the main content. But the closer you can align them, the better we see across the different models and the different versions.

Pieter-Jan: To link up to the previous question - if your content is in HEVC or using Dolby Atmos or something like that and that your advertisement isn't switching those codecs, it is possible. But on some platforms, or at least on some versions, it's, let's say, a bit more smooth compared to others. There is an impact, but the impact isn't that massive. You can make it work as well if it doesn't perfectly align. I think that's the most important part, which also is the case for server-side administration, by the way.

Pieter-Jan: Then the next question:

“The focus of this webinar is on Tizen 2.4, but are there benefits for all of the other platforms as well with the changes that THEO did?”

There the good news is yes, the changes that we did, they don't just impact everything that we did on Tizen. They don't even just impact the things that we did on our web SDK, they also impact to a certain extent or other SDKs even. And the good news is that you can actually use these capabilities across other platforms. We have some customers who are looking at RDK, we have some customers on devices like Hisense TVs or other TVs. There it's also possible, of course, with Chromecast, you will have to use the older Chromecast framework, because if you start to use GAF version 3, which is based on Shaka player, so there of course, those benefits aren't there. But if you use the THEOplayer version, which is based on the older Chromecast application framework, then that's all good and that will work as well.

Pieter-Jan: The next one is:

“About low latency on Tizen and WebOS. Is that possible?”

The answer is yes, it is possible to do low latency on Tizen and WebOS, but there are a few caveats. It depends on whether you want to do low latency HLS or low latency DASH. That's the first one. And also, it depends on the version of Tizen. If you look at the old Tizen versions, the WebKit-based one, also the old WebOS versions, there you have older Chrome versions that are being used. The older Chrome version isn't too bad, but the downside is that you cannot do streaming fetch. For those people who don't know what it means, it basically means that you cannot look at the data that you're receiving while you're receiving it. That's something that's quite important, especially for low latency DASH. For low latency HLS, it is not a hard requirement to have it if you're not running in a byte range mode, which is currently the most common. You just have parts which are files, so that's good.

So yes, you can do it, but the question will be which platforms and which protocols. If you have questions on it, let's talk about it later, because there's a whole other dimension that we can go into here.

Michel:

“Many of these TV models seem to have a rather poor network capabilities, but even with good download speeds we have seen a lot of micro interrupts. Do you have any experience with micro interrupts?”

Yes, absolutely! It sounds very familiar in the journey that we've gone through and in most cases the source can come from anywhere. Let me also add to this that although we're talking about Tizen 2.4, you can even see a totally different behavior on a WebOS 3., 3.5,  compared to a Tizen 3.0, worse or better. So that can be totally different with very different root causes. And that's where the tooling that we've built really helped us to start investigating what is the root cause of these things. Like network capabilities can contribute, but it's mostly not the reason. It has mostly to do with the way you append data to the buffer when you're able to touch the buffer and when you can't, because certain models will interact differently to it. The size of the buffer that you keep, there are many parameters that influence this. We've even seen, I think we mentioned it during the webinar, things like frame rates, GOP sizes, they also influence this.

So, the logical connection is micro interrupts. We learned that on these TVs, there are multiple reasons that can cause this. And even across every TV, it's a different scenario.

Pieter-Jan: Yeah, and something that people, of course, forget is these are usually not too cheap devices that you put in your living room. But the downside is that the cost is usually being spent on the actual screen. And not on the chipset or the memory underneath. So that's definitely a restriction. But we've done, thanks to the tools that we've developed, we've actually done these tests to compare this kind of things, like what kind of settings do work, what kind of settings don't work. We've compared this across, well, basically every kind of model, every kind of device that we have available, which is quite an extensive set of TVs at this point in time, where we know what kind of configurations work, what kind of configurations don't work. Well, especially the micro stalls, especially once you start going into DRM territory, that's when you need to start watching out.

Michel: Yeah, and there is an interesting thing that is - remind yourself that this is technology, which is engineered 10 years back, for example, but you have a very different landscape in what was, for example, more common and hardware supported than what is not. So, you get that you're trying to apply what is common right now, what is the standard right now on this old technology, where this old technology can start struggling with it or will have to do that all with his, yeah, in software, for example, without any acceleration. So, you can have multiple causes that to this problem.

Pieter-Jan: But the good news, I think even if you try to target a modern platform, you can reuse those streams and make it work. There's just a few things to keep in mind. That's the important part there.

Then we have two questions on the client-side ad insertion. So, let's start with the first one:

“What are the technical reasons that only THEOplayer supports client-side ad insertion across Tizen? Where all other platforms don't.”

There are multiple answers that I can give here, I fear. Let's first of all compare to the most commonly used client-side ad insertion library, which without a doubt is Google IMA. Google IMA doesn't officially support client-side ad insertion on Tizen. If you look at the website, it actually simply says, it may be supported. Not all features might work here. So that's somewhere to be expected, of course, if you try to use a library, an HTML5 library on a platform where it's not intended to be used. So that's one big point of comparison.

Another big point of comparison, of course, is that Dash.js, Shaka player, AVPlayer, they don't have like native client-side ad insertion capabilities. That's why they're usually used in combination with Google IMA. But even that combination simply doesn't work. With THEOplayer, of course, we have our own client-side ad insertion library as well. You can also use Google IMA. But of course, on Tizen, that's not something that we recommend, because we know that there are some problems there. But I think that that's the biggest reason why that's something that works with us and not the other places. It's simply because, well, it's not optimized to run on that platform. And that's something that's quite important for Tizen.

And similarly, there was the question like:

“How can you make this work if you cannot decode two videos in parallel?”

There are, again, multiple answers here. There are a lot of optimizations that we've done. One of those things, of course, is, well, we've gotten server-side ad insertion to work. Server-side ad insertion is actually very comparable to client-side ad insertion because you suddenly get different content with different encodings, different settings that you need to play. There suddenly isn't any DRM applied. So actually, from a player perspective - yes, that content is coming from a different source, but the way how you can handle that content doesn't have to be different per se. So that's also something where we've been optimizing quite a lot inside the player. Make sure that we can get that client-side data, well that app data that's inserted from the client side, get it upfront, make sure that we prepare it, that we prepare the decoder for that switch way ahead of time and that we can in one smooth sweep switch to the other one.

Michel:

“Can you enlighten us a bit about your aging tests, please?”

That's a good question. Well, this is a very broad question. Maybe let me answer it with how we are testing these devices. So, what we said earlier, we build up ourselves the capability to have all these models. So, if you would compare our office in a few months, all of a sudden, a zillion TV's pop up, TV walls are being built with cameras against it, etc. So, it's first getting ready for it. The second thing we did, which is a quite interesting approach, is that we built our own test framework that runs on these TVs where we basically isolate our players from the underlying platform so that we can build in tooling and hooks where needed to interact with our player, but also to interact with the platform. And that we can also get that data pretty efficiently out, meaning that we can centralize that somewhere in a cloud instance, being able to make dashboards on top of it, filter, and see what's happening, so that we can not only zoom into one TV where we can get it to work, but that we can look at the entire population of TVs, that we can run a test across 10, 15 at the same time with the same conditions. While I was saying TV, I just remember myself that we're now actually doing a test with more than 15 or 16 devices in different projects. So, we're applying that more and more.

What kind of tests are we doing that starts with the basics? So that starts with, like earlier said, getting basic playback to work. But pretty quickly, we lay out that on top. So, we added DRM with the simplest configuration on top of that, and then went further and further in that path, but always running the same simple test, repeat the same thing. Of course, meanwhile, on our other SDKs, we built a pretty extensive test library, regression tests that we typically do. With the test framework that I explained where we make an abstraction from the underlying platform, we're then also able to run the same tests. For example, regression tests with our Chrome browsers, we run them also against the Tizen TVs. From that, we were able to get to where we are right now.

Pieter-Jan: Then the next question:

“For HTML5 players utilizing more current versions of Tizen via MSE-EME, will it just work or will there still be a lot of issues?”

Will it just work? Yes and no. It depends a little bit on what kind of use cases you are looking at. If you take for example a TV that's been released this year, so a Tizen 6, will it work with Shaka player with Dash.js? Well, the answer is going to be yes. You will be able to do playback with DRM. Probably pretty good. It's probably going to be a pretty good experience with the multi-period experience. Even toggling DRM on and off in a lot of cases will work. It will not be 100% smooth in some cases, but it will be acceptable, I think.

The biggest problem that you will actually have is on the support side. Dash.js officially no support at all for Tizen. So, if you have an issue, you're well on your own or at least you're at the mercy of the community. The same goes with Shaka player. Although Shaka player is a slightly safer bet given that there is unofficial support for a Tizen, officially they also don't support it. But if you're really aiming for the Tizen 6 devices or Tizen 5.5 or Tizen 5 devices, then yes, you will be able to make this work with another player as well. The question will be, does this justify moving to Tizen? If you look at the percentage, the split across devices, which devices hold what kind of market share version-wise, then you see that all those old devices, definitely the ones where it won't work, Tizen 4, Tizen 3, Tizen 2.4, Tizen 2.3, have a market share which is quite significant - it's more than half of your Tizen devices. So, the question will be, does that justify the investment, yes or no? If the case is yes, then by all means, go ahead. If the answer is no, then well, probably a good idea to think about it and to see what makes sense and what doesn't make sense.

Michel: Yeah, to be honest on this, what you also most more often see is you have a few TVs next to you or you have one TV, you try to get it to work, you use another player and in most cases it will start to play but your challenge comes from all the different versions of Tizen, all the quirks you have. If you then like said earlier have a look at the viewing numbers, the market or the big range you need to support in these and have the good quality to keep your viewers there, that's what makes the biggest challenge. And then of course the feature set on top which you want to combine. So that is a long answer I think to a very simple question.

Pieter-Jan: Yeah, and then let's look at the next one:

“Can you support multiple audio?”

The answer there is yes. That's one of the things that we actually see as basic playback with our player. That's something that even with most other players, even AVPlayer has multi audio support. So that's something that you can achieve on Tizen relatively easily. If you want to add other accessibility features like subtitles, AVPlay probably isn't the right one for you. You will probably do a 'bring your own player' approach. But yeah multi audio, other accessibility features definitely something that's on the table.

Michel:

“Also, is there any specific reason that Google IMA support for advertising is not there with TizenOS?”

Well, I think this is also related to the different quirks that we were saying that we're explaining here. The Google IMA aims at a mass market at all the browsers. It's also a browser platform where you utilize certain practices which are there possible. If you advertise, like for example, Google, we support Tizen, then you need to support all these different versions. So, you also need to overcome the challenges that we said earlier with client-side ad insertion where you can't use multiple video elements, etc. So that's the reason, it might work, but we cannot guarantee it to always work.

Pieter-Jan: And I think a very important one there as well is that Google IMA is really built to wrap around the player. Because you can't use multiple decoders, multiple video elements on Tizen because it will mess with the other decoder that's running, that's probably also a reason here. For example, for Shaka player, I know that the team simply doesn't have a Tizen device. That's why they're not supporting it officially. I mean, they can probably get some if they really would want to. But it's as Michel says, it's not just one device that you need, you need a whole bunch of them. And well, from experience, I think we've learned that especially getting those old devices is not that easy. Well, we luckily havw some very good partners, where we were able to get those. But it takes a while to start building up a lab.

Michel: Yeah, and look, if you support these kinds of devices, you just, it's not just about doing it, but if you do it, then you do it well, and then you need to support all of them. And that's certainly the case here in the Google IMA question.

Pieter-Jan: And then:

“In your investigation, what kind of feature or logic would you say made the biggest difference moving from the client to the server side?”

Now, my question is, is there a question about ads or is there a question about features in general?

Michel: Yeah, because I think in functionality wise, if you use client side or server side, we're happy to test that with you because that just works.

Pieter-Jan: Yeah, that's not going to be the biggest challenge here, I think. In the end, yes, you can make everything work - client-side or server-side ads. The biggest question there is, what do you have as infrastructure? What is  the approach that you're most familiar or most comfortable with? We know that a lot of broadcasters, a lot of publishers, they prefer to stay on the client-side side of things, or operator customers, or let's call them digital native customers, they usually prefer to have server-side also out of fear for ad blockers, of course. I think for us, it doesn't really matter that much. We've done both approaches plenty of times. So, there's always a challenge, but I don't think that there has to be a difference from a user experience perspective.

Michel: Let me tackle this one:

“What can you tell us about the GOP configuration? What do you find work well for use cases involving DRM playback?”

Well, we were surprised to see some of the effects of GOP configurations. Initially, when we were investigating, we thought there was a much bigger impact of this on some of the issues we were seeing that appeared later to be more linked to the performance limitations of these devices, better to use technology that is linked, that was more common when they were engineered, those kinds of things. But if you look at GOP configuration, we did find some very strange things, is that once we get our SSAI running smoothly on these TVs, we sometimes all of a sudden saw that video and audio started to play desync or faster or slower than each other. We saw very strange things. And if we started to investigate that, we found that there is an impact of the GOP structure you are using here. 

Pieter-Jan: And it's often also the GOP structure itself. I think one of the most important aspects of the GOP structure is actually the size of your GOPs. Everybody knows that GOP size is important for low latency. Well, it's also important for smart TVs. If you keep in mind that these devices have a limited memory available, and don't just think memory as it's a six-megabit feed, that should be okay, but a lot of our customers are building a React Native-based app or a React-based app, which is hogging most of this memory, that will become a problem. So, keeping that memory footprint down usually is very important. And if you start having very big GOP sizes with B frames, with long references, that usually means that you have a lot of data, a lot of frames that you have to keep in your memory as well. It's those kinds of things that really make a difference. Of course, the longer your GOP, the worse it's going to be. We actually added specific APIs to clear memory to make sure that you can basically wipe segments from the past and that you can restrict the player to use a minimum amount of memory, but you cannot reduce it below your GOP size. So that's where GOP size is important. But also, of course, if you start using B frames, and if you have long pending references and very big mismatches between decoding time and presentation time, then you might be struggling on especially the older devices or even with newer devices. Keep in mind for Tizen, for example, you usually have like the standard series, and you have the premium series. Because even between the models, there are differences still. But yeah, that's definitely something to keep in mind.

Michel: There's even another link to it - you basically need to find the optimal configuration. Because if you talk about the older devices, you also see that they are not as well as equipped as modern devices to handle lower buffers. So, in some cases, you need to make sure that the device always keeps a certain buffer to be able to have a stable playback or you just get complete stalls, or you get the micro-stutters that we talked about earlier. Of course, you need to find a balance with also the startup of your stream. If you make it too big and you know that these devices, for example, need to first fill that buffer before the start, you also don't get a very good playback experience. So, yeah, I think typically here we helped already a few customers of us to do tests for them and then give them advice based on - what is the optimal config that we would recommend you to use to have a successful application on all the smart things.

Pieter-Jan: Yeah, and I see that we have one more question outstanding. I propose we still answer that one and then we try to wrap up, given that we're starting to go over the hour. and hope that we could still stay within the hour. But for any other questions, we'll make sure that we respond to them via email as well. Simply reach out to us, and we're happy to answer. So last question:

“How do you compare yourself against the Bitmovin player for Tizen?”

Of course, a very interesting question. The reason why we're mostly comparing to the open-source players and to the free players is that our test automation includes those. It doesn't include Bitmovin as a player. I actually expect that you will see the same things there that we see for Shaka player, for Dash.js, that we saw before we started this endeavor on our side as well. So, my expectation is that playback on Tizen will also be limited. I do know from Bitmovin specifically that they very heavily rely on AVPlay for the older versions especially. I don't know any MSE-based player that supports DRM playback other than our player on Tizen 2.4 at this point in time. There are some cases where you can find that very specific configurations have worked for Shaka Player, but that's about the only reference that I know that you can find. And even then, if you try to reach out to those people, to ask how they had done it, which is how we started the investigation as well. The answer usually is that it was never used in production because they found it too unstable. I think that's definitely a very big difference that we have and well beyond that. The optimizations that we've been doing on a multi-period transition and reconfiguring the decoders when there is DRM being turned on and off. I’m pretty sure that this is something that only we are doing on our side and that nobody else at this point in time is actually able to do.

So how do we compare ourselves? I think that's, for me at least, the answer at this point in time, we could always set it up, but we would need to integrate it in our testing framework.

Michel: We can also always have a chat with our colleagues. To include them in our test automation and do some tests with them, we're happy to do so. But, to repeat, I think certainly on SSAI what we did is pretty groundbreaking. Nobody else will be doing that. And it's also some feedback that we get from the market. So, I think we're pretty good here. Asking that to a guy from Antwerp is also very dangerous, because I would say we know we are the best. But let's find that out together with the people using us and with the project you want to do with us.

Pieter-Jan:  So, let's try to wrap up! I see that there are two more questions, but we'll reach out to you via email so that you also can get your answer. So, I hope that everybody enjoyed this. Thank you!