NETINT Technologies about Greening of Streaming: Uniting the Industry for Energy Efficiency

Welcome to NETINT's Voices and Video, where we explore critical streaming-related topics with the experts who create and implement new streaming media technologies. One issue that should be paramount to all participants in the streaming media ecosystem, producers, engineers, product and service providers, consumers, is power consumption. An organization called Greening of Streaming was recently created to address growing concerns about the energy impact of the streaming sector. Today, we're speaking with Dom Robinson, who is the founder of Greening of Streaming and Chief Business Development officer of id3as.
Hi Dom, thanks for joining us. Hey Jan, how you doing? I'm good. So some housekeeping notes, if you're watching and have a question, please post them as a comment on whatever platform you're watching, and we'll answer those live as time permits. If we don't get to them live, we'll get to them via email after the show. Okay, Dom, what's going on with you? How are you? I'm good. I'm finally in my office, sat down for the first time in about seven weeks, just doing normal day's work at my desk, which is good.
Listen, why don't you, you've been in the industry probably as long as I have. Tell us about Greening of Streaming and how it was formed, when, who was involved, how did it all come about? Sure. So you may remember for a while I was running the content delivery summit for Streaming Media Magazine, and conversations in that group started amongst the network architects and CDN architects and strips of encoding cloud architects, started up about their sustainability and so on, and that over a couple of years, that grew into its own event. And as I was standing up that event, I thought, "This is really big. Let's maybe set up a trade association." And what was once a sideline conversation, the conference has now become a fairly fully fledged members' association. We've got about 25,
30 members, growing monthly at the moment, and it's keeping me very busy. That is for sure work. The main objectives of the organization's to foster collaboration across the industry, looking at energy efficiency principally and the result of how we deploy streaming architectures to address that energy efficiency. What is the LESS Accord? I've heard that
mentioned both by you and by some other people. As the organization really got to the end of its first year, we were having some discussions about, in the sidelines of IBC last year, about what was good enough, what would a good enough streaming quality be? If you were to optimize around that good enough quality, could you actually get to economies of scale where you were being energy efficient as well? We originally called it a Gold Button model because we wanted to offer the idea to the consumer instead of opting into green was given green or given an energy efficient service, but could opt into a higher quality by pressing a gold button or some sort of interaction notionally. Apparently, gold buttons don't translate to America very well. They apparently get gold buttons for winning spelling bees. So we decided to rebrand it to the
Low Energy Sustainable Streaming Accord, which has the catchy title LESS, and caught the imagination. So it's quite a mouthful to really explain what it's all about, but there are lots of silos of work across the industry looking at energy efficiency in atomic scenarios of specific workflow processes. We are very concerned that we look at it systemically and that we're not just passing energy problems up and down the whole supply chain. And so the LESS Accord is an attempt to align everyone's thinking around specific areas of effort so that we can get all the best engineers to focus on the right problems and collectively and create some direction of travel for everyone together rather than just lots of spidering and slightly random walks into the new innovation space of making streaming energy efficient.
Can you give us an example of what you might reduce to reduce energy? I mean, are you talking resolution, you talking bitrate you talking... I mean, what do you reduce to save energy and reduce quality? That is the billion-dollar question at the moment. There are lots of assumptions that it's as simple as reducing bitrate. There's also a lot of conflation about what you mean when you reduce bitrate. Reducing bitrate for somebody doing encoding work means something different to reducing bitrate when you are transmitting data across a network. Not in terms of bitrate as bitrate, but in terms of the
effect it has on your power environment. So it's not as simple as reducing bitrate. One of the big experiments that we've been carrying out in what we call Working Group Four has been looking at whether we can actually correlate energy bumps in operators' platforms with traffic bumps. And so far, we've found very little correlation at all, which makes it complicated when everybody's immediately talking about this correlation between gigabytes and carbon or gigabytes and kilowatts.
It certainly isn't a linear relationship, if there is a direct relationship at all in the transmission networks. And obviously, your world, more your world, the encoding world, obviously if you're not encoding you're not using power. If you're encoding, you are using power to some extent. And so there's definite volatility in encoding and decoding and those ends we're paying particular attention to. But also,
we have hardware optimizations and strategies around how we use hardware resources on a more macro scale that can make big differences as well. So we're exploring all those things at the moment. One of the presentations I think you saw at Mile High with me was from a different organization that was looking at power on TV power consumption. I know that there are some standards organizations looking at power consumption. How are you going to work with them? How's that all going to shake out?
So Greening of Streaming is expressly not a standards organization, there's lots of them, they're very good at what they do. We would be in their world considered a news group. So we do have a working group within Greening of Streaming specifically focusing on driving energy as a KPI into protocol and standards development. So by means, an example, the pioneering project we're trying there is with the SVTA. They have their open caching system and within open caching and there's a routing or essentially a routing protocol called Capacity Insights. And
what we're doing is we're exploring where we can find energy data sources, energy mix data sources, one of the places where we do talk about carbon, that we can feed into the decision making tree. So anecdotally, if you are in Iceland trying to decide which cache you're going to pull a piece of content from, whether it's London or New York, everything's equal in price to performance, but the New York cache is solar-powered and then London one's fossil powered, then it might be interesting to weight the load and the demand onto that New York cache. Of course at this stage, that's moot as to whether it would save any energy, but we might be able to determine its use by energy mix the input into the system that's hosting those caches or whatever it may be. There's lots of really interesting explorations like that going on. So if you meet somebody on a plane or in an elevator or offhand and they say, "What are the top X things I can do right away to reduce my power consumption?" And say they're a streaming video producer that goes all the way through. They've got their own encoding farm, they've got
their own player, they broadcast around the world with CDNs. What are the top X things they can do to really make an impact as soon as possible? I'd say explore rather than do. As Greening of Streaming, we're a long way from having best practice that we can recommend. There's so many divergent and complex strategies going on at the moment. It's very difficult to actually say, "This is the best thing to do," because there's just a lot of, "Depends," around any answer like that. But in simple terms, the obvious thing is turn stuff off that you don't need.
That underpins a whole discussion about redundancy strategy, so if you're a live engineer, I'll give you an example, there isn't a lot of conversation between a cloud and what you might run on the cloud. Yes, if you use a SaaS service from the cloud, like their own home-hosted encoding service, you might find things are different. But if you just simply use a vanilla cloud computer to run your own encoding process, the cloud host has no idea what you're doing. So if you then need to set up a second one for redundancy, well, that's very traditional thing to do in a live-streaming environment. What we've found in talking to cloud hosts is they have no idea what the application is. So they see an engineer spin up a computer, they don't know what it is, but they want to offer four nines on that availability. So they spin up a hot spare.
Then the engineer spins up a second transcoder, and the cloud goes, "Oh I don't know what they're doing, but we'll give them a hot spare." So you've actually got four computers hot when you're only trying to run one workload, which might have an outage of a few seconds. So we have to think in... That's just a very simplistic example of where we might be over provisioning redundancy.
And think about SLA. SLA is, the networks themselves aren't that congested, they're just reserved so that people can hit SLAs. And so think about SLA, think about whether you really need nine nines availability for live-streaming your kids' birthday party or something. There are
certain degrees of over provisioning that have become natural because they're very commoditized and affordable, but they might be unnecessary and you might be able to halve your energy footprint simply by not using half of your infrastructure. And that goes down into codex as well, and there's going to be, and there is an endless discussion about quality and whether we need 2K, 4K, 8K, 16K and so on. And I think it's an interesting debate. There's not a great deal of clarity actually about what power those decisions make in terms of the distribution network. In terms of encoding, can
be quite vanilla. You can completely immediately see if you do less bitrates or if you do lower bitrates or if you do higher compression even, and produce lower bitrates sometimes, you might have a different energy profile. But that's probably only a small part of the picture. If you save 500 watts on your encoder, it may be that something you've done has put 5% more energy on all the decoders, and you've suddenly got 30 million viewers consuming another 30, another God knows how many megawatts off the grid for the sake of your half kilowatt saving at the core of the network. So we have to be really complete in the picture before we can really say, "Do this." But those are the areas that people should be exploring and understanding within their workflow.
Is there a simple answer to, "Does it take less energy to transmit lower bitrates versus higher bitrates?" Or do you have to look at the decode side again, as you just mentioned? It's not a simple answer. It really isn't a simple answer. The network is not provisioned against bitrate, it's provisioned against expected peak capacity. So when you don't send data you don't save any energy in the transmission network. So the bitrate doesn't matter to the telco or the CDM. The CDM caches are stuffed full. It's just how quickly you recycle things that you don't.... By not storing stuff in a CDN, you don't reduce your caches. But when it comes to the consumer device, you can set a flag in a codec which trips a decode on a laptop from GPU to CPU and see your fans go on just because something's changed. That might be bitrate, it might be you've switched HDR
on, it might be you've changed your frame rate, it might be any number of factors that just incompatible with the target device. So it's a minefield to come up with the best practice, and it's certainly a complex... There isn't really a, "Do this." But what I would say though is, don't overproduce. If you produce 3000 runs in a ladder, you're probably going a bit far, in my opinion. One of the things we talked about that was surprising to me in terms of your challenges was agreeing on measurable objectives. Can you go into that? There is a macro picture of how much of a problem are we trying to address and how can we measure success in that? So that tends to have the headline-grabbing figures that I'm very terse about using these days. But the macro and the IEA produce a figure that 1% of the global final electricity supply is currently being used by data centers. That 1.5% is being used by telco,
and 6% of global final electricity supply is being used by ICT but that ICT figure includes the telco and the data center energy consumption. So at a top level, we're probably, if streaming is 60, 70% of the network, we're probably, and this is conjectural, we're probably using 2-3% of global final electricity supply. So in terms of measurable success for Greening of Streaming, if we could feel that in five years' time, three years' time, we've changed that trajectory and we're looking at something more like 1, 1.5% of global final electricity supply, we're probably doing the right thing. Especially if everyone's still entertained and getting a great experience. In terms of the smaller, more microscopic measurable elements, I've touched on this correlation between gigabytes and carbon, and we're in caution about making any direct correlation there. We are looking at different measurement techniques for the different... But basically, it's a bit like deep physics,
it depends on perspective. If you measure a system that's used by many different shared services, you have to try to work out how you can report on any one of those services in terms of its energy. And the models vary extensively. We are tending to try to take global top-level systems energy, i.e. comparable to what your electricity supplier would be billing you, and look for fluctuations in that based on load. So that encompasses a lot of the baseline energy,
which is really being burned in order to make streaming possible. The problem comes when you want to really say, "Well, how much did my stream use through that system?" And you have to apportion it. As soon as you set up an apportionment model and you get into deep complexity about when systems are being used and who by, and what the other processes are and so on. And it becomes extremely difficult to come up with a clear-cut way to say how much energy any one particular stream is using. It might be a different exercise and one we're kicking around in one of our projects that's come out of the LESS Accord to explore what well, we all kindly nicknamed the breadcrumb model, where as a file passes through an encoder you put a meter in the file, and you start the clock, and you're reading the kilowatt-hours as you start the encode and you read it again at the end of the encode. And even if there's other encoding processes going on, that is the energy that's being used in creating that file and you record that increment of kilowatt-hours. As it moves into storage, you repeat the process and add it,
and so by the time the file gets to its destination, you've got a cumulative clock of how much energy has actually been consumed by the computers that have got that file to you. The problem is if you have two files that come in parallel through that workflow, they're going to cumulate the energy twice. So it's going to give a very skewed picture of what we think the energy going into the system is. So perspective is complicated, and
it means that there's no one simple answer. Yeah. One of the things that you've spoken about here and we spoke about in our meeting was the whole measuring the systemic load. Can you load that image that you had? And I'm not sure how well it's going to show up in the zoom, but I think you've been talking about how challenging it is and I think that was a great illustration of exactly what you're talking about. So why don't you assume that people can see the outline but not the detail, and just take two minutes and walk through this. I think I can zoom in a little bit like that as well. So basically, once we'd formed the group and we were having our first meetings to talk about what the group wanted to form as working groups, I'd been reading a lot of the science which was trying to relate streaming to climate science. And
one of the things that stood out, I didn't feel people had a complete picture of what was going on, and so the first thing I thought was useful is to do an exercise where I redrew a live stream as I've looked after for what, 30 years now, from a perspective of every box that might go wrong, that might break the link, i.e. if I didn't have an internet, what boxes would I need to plug in to recreate a single point-to-point livestream? So that's what this diagram seeks to represent. And it also separates it into things like network layers, people talk about Layer 3 and Layer 4. This is the network layer view. I've also sectioned it as we go along so you can look at where people are talking about contribution feeds or access loops or whatever. Some of the terminologies matched against those different stages of the network as we go right through. So following from the top left where we've got usually two encoders, two to emphasize that it's usually a dual path. You're feeding into typically maybe straight into
some sort of system, sometimes you're feeding into some sort of local digital asset management process, into switches, out of your router into your first mile, if you like, up to your local exchange. You might go through some authentication up in Layer 4. And then you go all the way up into the core exchange where you might encounter something. I drew this box on because I think it's probably best explained if you think of a point of aggregation like maybe YouTube Live's hub in or a point of origin. Notionally, that's a point of origin. And then that feeds into your CDN. Obviously that would normally be a big cloud. But in order to stream in and out of CDN, potentially you might be able to hit the local edge and bounce back out of just one box, so keeping things to a minimum. The network carries on, have your exchange caching, you might even have some much deeper caching in the system, and if I just move the video window right over on the right-hand side, you're into the access loop.
Funny, a lot of people who are involved in Greening of Streaming and beyond, I don't think they'd seen it really drawn out as a physical map before and thought about it in those terms. That's what it looks like behind the code, when it all gets delivered. And that gives some idea of the amount of kit that's actually getting the stream from A to B when you actually include Layer 2 in the internet, the physical layer underneath the internet. One of the things that's really important about this diagram is on the right-hand side, that last-mile router, and the set-top box highlighted in orange, the thing that's going to do the donkey work of decoding in the facility or in the home. That orange box goes on and off. It's probably on, if it's a domestic box, maybe four hours a day or something. But everything else pretty much, maybe the display goes off, but everything else pretty much stays on 24/7. So if you'd start to
look at the energy involved, everything else is, you're taking integral over time, so it's on a lot of the time relative to the set-top box. The set-top box is probably computationally doing more work than anything in the network apart from maybe if there's some transcoding going on in some of these early stages, but that's not really what we're trying to represent in this. It's more of a true internet end-to-end model here. So really, the compute cycles are going on in
the encoder and the decoder, but everything else is on. And also, everything else is on and quite scaled up. So for example, here where I am, outside of my home, the first amplifier at the top of the telegraph pole, which splits my proper line from me and my neighbors, that's running 400 watts, and then the first cabinet's running a kilowatt at least, depending on how many ports they put in it. So you start to rack up quite a lot of energy in that infrastructure. Although it's shared, I take the point, but in terms of proportionality for a single user, really the weight of the energy's off on the left here, into the core of the network. So you've described this, I'll call it a big elephant, how do you take a first bite? How do you approach it to start making progress? Again, returning back to the LESS Accord, in fact I'm going to share something again, if it's all right, because I think this is the time to talk about it. So after talking to a really broad cross section in the industry's
engineers about what their intuition is, about where they think the energy savings might be, one of the key ones is summarized there as our intelligent distribution model shifting. So it's a bit of a mouthful, but we have these camps of unicast and multicast. Networks are using their energy in capacity, and the capacity is provisioned to cater for their largest peaks. So anything that can help mitigate those peaks is useful, and those peaks are almost invariably big live and typically football games or sports events that are really big, hard-hitting impacts that networks really, really get paid a lot of money to guarantee delivery of and they really provision themselves so that they can handle it. But there's these models like multicast and even peer to peer, which appear every now and then and claim, purport to be able to scale live-streaming much more efficiently. Now, efficiency is a big moot word. Efficiency in data, efficiency in economics and efficiency in energy are three related but not connected things. So simply saying
any one's efficient over another is a complicated thing. What we're going to set about doing is one of our key LESS Accord projects over the next 12 months is getting some energy measurements of, as close to possible, some apples-to-apples comparisons between those different models at different scales, to try to provide a bit of information which operators haven't yet had, which is when to choose to use those different models. Because honestly, deploying a little bit of compute to everybody's home router or in every DSL exchange or wherever the fan-out points are, in order to enable stuff like application like multicasting or peer to peer, or whatever it may be, those will increment the energy used in all those relay points.
And if you're doing that across your whole network because you might have 30 people watching a stream, then it's clearly not as energy efficient as sitting with something that might be extensively less energy efficient like brute force unicasting. However, once you get up into the hundreds of thousands or millions, it's much more complicated. You have to look at the regions, you have to look at the network access critically, you have to understand the devices and so on. So that's a big area of research to look into, which are the big scaling models that can... Or what are the energy decisions around when you use those big scaling models? So I think that's a big area of interest. Codex and compression and network optimization is obviously ongoing. It's a big school of discipline within the streaming industry,
and rightly so. It's where we use a lot of energy in encoding [inaudible 00:26:57], which I know you know about at NETINT, and we use a lot of energy in decoding the set-top box in the TV environment. That's much more complicated in bring-your-own-device era, but it's still an area we need to get much deeper understanding of. Most of the work on set-top boxes to date has been done under lab conditions. There's very little which has been done on the,
particularly in the bring-your-own-device environment, in anything like a real user measurement environment. So there's a lot of research to be done in that space. Measurement itself, I've mentioned the breadcrumb model is an another key area that when we really need to come to a little bit more consensus over. However, I think part of the reason there isn't much consensus is because there hasn't been that much practical experimentation in the network. So everyone's waiting for an academic decision that they can implement, but the academics don't have enough data from industry yet to really have those ideas refined. So we need to close that loop, and measurement is really the central conversation in that discussion. And then finally, the hardware and infrastructure optimization. Atomically, we can do quite a lot
easily in lab conditions, we can measure things, but cool things like immersion cooling and fundamentally changing how we design our build out of data centers and storage requirements and what expectations we have and how those affect those architectural decisions at scale, there's still quite a lot of discussion to be had there and there's some fun projects in that space as well. That's big iron stuff, that's where we get to play with the telcos. So those I think are the hotspots. Those are really the hotspots that we're really focusing on. I think that there are other hotspots in every sector, every standards body has its own domain where they're the experts. What we're hoping is we can wave in our flags and say, "Hey folks, latency is pretty boring. There's loads of other innovation around energy to do."
And get the engineers to start focusing on doing exactly what they're doing today with exactly the same latency, but doing it with half the energy. That's a great area to start. One of the discussions that got hot on LinkedIn maybe 18 months ago was VVC versus H.264, or the advanced codex that required so much more energy to encode, going to put... Was it going to increase power or decrease power because of the reduced bitrates that they were delivering in? I know it's challenging looking at the entire ecosystem, but what are your off-the-cuff thoughts about the more advanced codecs that are much more difficult to encode and probably decode? I think the one thing that really stands out for me about codec deployment is, churning out kits to support something new probably takes many, many, many years of [inaudible 00:30:09] in terms of an operational performance to replace. If everybody goes, "Well, I'm going to have AV4, so I'm going
to bin my laptop, I'm going to bin everything that runs AV1 because it doesn't run AV4," and churn it all out, and my stuff doesn't get recycled properly and ends up in endless landfills, so just being inefficient somewhere else. That has to be part of the equation. So it's never as simple as, "This is a 5% more energy efficient codec." There is a strong argument that H.264 is probably so ubiquitous and does the job sufficiently well enough that, do we need anything more? And are we actually focusing on the wrong problems? We are being challenging and purposefully wanting to ruffle feathers. Is the return on investment into codecs It's really worth it when we could be investing in energy efficiency.
I'm reminded of looking at buying an electric car and someone saying the best thing you can do to save electricity is to keep using your own car and not buy a new one. Correct. We could sidetrack into that, but buying a two-and-a-half-ton SUV electric hasn't really saved the problem. You've probably used half the planet in building the car itself. We have
to think about those embedded emissions, although Greening of Streaming doesn't talk about carbon, we have hardware vendors and chip manufacturers and 10 infrastructure providers in all our working groups, and they're constantly sitting there thinking about the physical resource because it's a very complicated argument as well. And one of the most subtle ones is actually driving... There is an argument that driving more bandwidth onto the networks drives innovation, and at different stages of innovation, we can get exponentially more efficient with real terms reductions in power. And you can see it in fiber networks at the moment, as you go from one generation of fiber to another, you're quite often getting a hundred fold increase in capacity. And in real terms of 0.75 reduction in power. So the question becomes, how quickly can you migrate everyone off the old stuff and recycle the old tin? Which means you need traffic to drive the economy to invest in that churn, and you'll actually reduce the energy, even though the capacity will go up. It's not following Jevon's paradox in its simplest where
normally like 3G... Sorry 4G. With 5G, we've actually had a real terms increase in power of about fourfold, and no traffic's moved into the 5G network. So we've got a potentially more efficient network, but there's nothing going on. So the efficiency's not really valid until we're basically 100% utilization, or at least comparable utilization to the previous network, at which point today, we're just investing more power and not really getting any gains. So yeah, and I think those innovation cycles themselves are not simplistic, and churning codecs, if you can massively reduce the power in your data center, that's probably a good thing, but if your data center's consuming what 30 megawatts but you've just put 150 megawatts on everyone's decoding because of all those little set-top boxes working that much harder or having to be binned and replaced, you've got to think hard about that. One of the things we talked about in our planning meeting was a player control that a consumer would have that would increase the quality at an increased cost. Could you go into that? Is
that something that's soon to be appearing, is appearing now, is on the long-term roadmap? Yes. So I think that's referring really to the Gold Button idea that we were talking about. So this is the idea that... It's probably worth going a little bit more specifically into the human side of that. Last summer when we did our public launch over here, we did a survey around that to find out how much the consumer was aware that streaming used energy.
And in that awareness, whether they felt empowered to act or to do anything about it. We looked at whether eco-mode, green button, those opt-in services had any uptake, and really don't. When people get eco-mode, their TV's shipped in eco-mode and it's the first thing they do is turn it off and put the brightness up and [inaudible 00:35:02]. They just bought this high performance
TV, they don't want a dull, cripple picture in the name of eco. It's just not the way it is. And there was a clear sense that the industry had to take leadership here, take responsibility in many ways, and put a menu of energy-efficient options in front of the consumer. So rather than having a green button, which you opted into if you you're environmentally socially responsible, the idea was we ship you a green stream, and because we are the internet we don't have to take away consumer choice. So all the people who go, "Ah, panic, consumer choice has been in infringed," well, it hasn't. We've given you a great big orange button, or a switch, or some sort of interaction of any sort you want, which basically allows you to upscale or upgrade or boost your signal for the duration of the match or the duration of the box set viewing or evening view, because you are sitting there getting value from it.
And while I want to save energy, I'm also a human. When I want to coffee, I boil a kettle. But what I don't do is I don't leave my kettle boiling all day just in case I want a coffee. That doesn't have efficiency [inaudible 00:36:21]. And what we are doing in real terms with a lot of broadcast and streaming technology strategies is we push everyone up to the highest possible run on the ladder. So my boy is dribbling on the carpet watching Peppa
Pig at UHD. If that's got a eightfold increase in traffic and energy impacts and who knows what, do we have to stop at some point and say, "Do we need to be by default offering my boy Peppa Pig in UHD?" I'm sure he'll put up with it in 2K. And so I think it's, not an existential argument, it's a directional argument that we have to ask ourselves as a whole, "When we are over engineering, why don't we divert that resource to doing either more energy efficiency or just brutally better engineering anyway?" So I think those are the key questions and that that's really what the Gold Button idea. What's upcoming? What are the milestones
you see hitting in terms of meeting and formulating and announcing and releasing specifications and best practices? So after pretty much seven weeks on the road as of today, I'm chilling out writing a couple of papers and then having a little bit of a break in August because it has been immensely full on the last few weeks, few months actually. What I'm hoping to do though by writing those papers is get them out to project leads. We're trying to isolate project leads for those four projects that I showed you a minute ago. We've got basically volunteers for all of them. And then to go through those papers and just agree to project scope and
project plan. And hopefully those project leads will engage with the members and some guests, because we've got gaps in our memberships and guests who are going to help fill the gaps and so that we can stand those projects up. And so what we hope to do is come to IBC this autumn and, fingers crossed, IBC are going to fit us into the program somewhere so that we can stand up and say, "Right, these are the four projects, this is what we're testing and this is how we're going to go about testing those," as a little bit of an opportunity again for the industry to say, "You've missed something," or, "We think this," just keep that feedback coming in. Transparency is important here. And then in providing that, we feel that we are onto the right thing. Then through October, I hope the projects will start to form, the technical work will start to frame itself out. And then the aspiration is in Q4 and Q1 when the streaming's busiest
in Northern Europe and America, we're going to get some real testing underway, and that should bring data into our academic community's hands [inaudible 00:39:19] by the beginning of Q2. But by the end of Q2, if we are lucky, we might be able to actually give some guidance in a model scenario, but the core system will be as near to production as possible. What will be modeled still at that point will be the client devices that will all be going into test facilities, because it's going to be too complicated if we do everything in one go. But as we finish that project, we should have finalized the planning for some research grants which we're looking to collaborate on, which will then hopefully take the whole project to the next stage over the following year, and go into an exploration of what's really going on in the consumer premises equipment environment.
So the player, the set-top box and the TV, the media player, the laptop, smartphone, all of those. We want to go from lab to real-world measurement model from summer next year forward. So that we can take our core models that we've hopefully settled on, and test them in real user environments and actually check that by the time we bring this into a OTT bring-your-own-device world, that those attempts to bring down the energy of our systems actually really work in the wild. So it's a bit of a two-year plan, but it's also changing and full on on a day-by-day basis. Email by email, it's quite intense at the moment. So that's the plan for from Greening of Streaming's point of view. Tell us who's in Greening of Streaming now and where to go to... What it costs to join, I guess,
and where to get more information. So these are our current members. So there's a couple of different groupings in there. The top two rows are our founder members. They came in on day one. And then scattered, well it's in order that they joined, basically, and then scattered amongst the members thereafter, a few public service broadcasters who can join and get involved for free as long as they're participants. And then likewise, more recently, we've extended that to affiliations with other peer industry groups like the Digital Television Group and IABM, and there's a few others coming in as well. So we just
swap one secretariat membership so that we can keep an ear to the ground on what we're all doing and make sure that there's good collaboration between the organizations. So it depends on turnover. We don't really mean to test, but I think it's, people just play the honest card. So over 10 million turnover, it's 12,000 pounds UK a year, and it drops down to under a million turnover, which is about 2,000 pounds a year. So we're by our own admission not a cheap organization to join, and that was by design. We did not want to become a green badge which people could buy and be non-participatory, and tick the box and say, "I've done the Greening of Streaming thing, I'm now green." We have a fundamental rule in the
organization of no greenwashing, and that applies to membership as well. [inaudible 00:42:48] specifically. So we want organizations to stop and think before they get involved, and get some groundswell of support from across the organization. So all of the 25 organizations we've got involved, there's about 130 signed up on [inaudible 00:43:04] people. And then in the background as well, it's always worth mentioning that I have about a dozen volunteers secretariat. So we don't have an individual member class but there are some really good consultants and experts who are really well-connected across the industry or have retired from leading jobs in the sector, who help me on a day-to-day basis with lots of the admin, lots of the group leadership and setting up meetings and those sort of things. And they're invaluable. So for people who are
exceptionally keen to get involved and bring a lot of network, bring a lot of skill, expertise, running all these sort of organizations, because I sure as hell am making up as I go, then I do welcome people interested in getting involved in secretariat, but I do ask you to do stuff for it. So yeah, that's big picture at the moment. I guess on a personal note, how are you... id3as is launching their first product or their first major product north now? How are you balancing, I mean, you're the chief... What are you, chief product officer? Chief- Chief biz dev officer. So Greening of Streaming has definitely taken over my time. I thought for
the first year of running it that I could run at arm length and hire a friend who is a management consultant to run it, and he did a really good job, but he didn't know the sector, and so there was so much referral back to me that we had to make a bit of a decision last year. And part of my role with id3as used to be our marketing, and we used to take a bit of a black ops, special ops approach to finding really specialized, big, scaled-up live-streaming platforms in the FinTech and sports ready to help. That was cool that they came in, but that had a lot of professional services on it, and we wanted to really scale up the core licensable technology in id3as, which is what's nuanced. So we've slightly repositioned the business,
and I'm a good gorilla marketing guy, I'm not necessarily a brand marketing guy, and we thought Eric, who obviously you know well, was the man for that. He's seen every pitch under the sun and would probably guide us well out out of the darkness and he's doing a great job in helping us brand Norsk. And at the moment, a lot of the effort is on raising that awareness on the marketing side of it. At the end of the day, I wear an id3as T-shirt because that's part of my day job and everyone knows that id3as is a member, just as much as the other contributors to Greening of Streaming members. I happen to wear the hat of running it at the moment because we've kicked it off and that's the way the cookie's crumbled at the moment. But it is a members-led organization and we will be looking to make sure that I'm not dictator in chief and not letting anyone else have a go in due course. So I fully expect to return to id3as over time,
but at the moment, I have the capacity, four days a week, to be doing Greening of Streaming and keep my eye on the biz dev as we're starting to build out our new product set. And it is full on, it's very, very... I really thought Greening of Streaming was going to be a sideline conversation. I had no idea it would be two full-time jobs in one. And I think it's just of the moment, and a bit of serendipity, which is good. Okay, question coming in, not seeing a lot of telcos on the membership slide.
No. We're definitely weak on telco operators. We'd love more. And we've got access to broadcasters through the [inaudible 00:46:54] a bit of a flagship content provider amongst our midst, and a lot of our testing is we're returning them to source. But yeah, we definitely want more engagement from telco operator, and we got good relationship with content where we need it, but we are always interested in talking to content providers from the top line down Question, what are the challenges of an organization that can issue recommendations only but not enforce them? So I guess you're going to come up with a bunch of recommendations. What happens then? So I think in practice, you can't really enforce technical standards anyway, so I don't even think of the standards body as being enforcers. Maybe they protect patents and stop people deploying things, but I've never really thought you can force standards down people's throat unless you're Apple and you decide HLS is the way the world... And so on. By engaging the big oil tankers like Akamai, Intel, AMD, there's loads of them among
that group, and by engaging more and more of them, I think we can change the culture of the industry. And they used to call it, what was it, in public affairs terms, they used to call it self-regulation. That term tends to be favored more by... Or the term industry-led reform tends to actually be more favored in... Greening of Streaming definitely wants to
lead the engineers to think in a better way. I don't think they need to be told what to do. Most engineers I know are intelligent and they love a problem. Even if they're nutcase climate deniers, in practical terms, they also like making profits. So we sit on the fence with that. In practical terms, if you are all about lowering your bottom line by reducing energy, then fine, Greening of Streaming's for you. If you're all about saving the environment by reducing energy,
then fine, Greening of Streaming's for you. Doesn't really matter. We can't force it on anyone, but what we can do is make the culture of the industry sit there and go, "You know what? That's really energy inefficient. I'm not going to tell the boss we can do that." And that direct action from the engineering floor will change things very directly. Certainly it's a worthwhile cause. Couldn't have the better leader for at least the
initiation phase of it, and- I'm sure everyone will get tired of me soon, I'm sure. I appreciate you taking time out of your busy dual- No, not at all. This is my busy job, so this is a pleasure. Okay, cool. Good to see you again, and we'll be talking I'm sure in the near term. Speak soon.
2023-07-06 13:18