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

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

Show Video

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

Show Video

Other news