The nightmare of server-driven streaming is that you have to have workarounds for every client bug baked in. Also the client knows things that you don’t know. The nightmare of client-driven streaming is that your streaming architecture becomes inflexible, since you can’t break old clients, so iteration time grinds to a halt. Also the server knows things that you don’t know. At YouTube, we want to simultaneously go fast and micro-optimize the shit out of everything. Introducing new protocols like ultra-low is no mean feat on its own, but what happens when you need to fix a bug that breaks old clients using the protocols? What if you have a new optimization that requires an update? Also, where do you put all that SWEET MACHINE LEARNING you have dripping from every TPU in the fleet? We realized that each of our clients is basically a giant steaming pile of workarounds anyway. Our experience with the HTML5 player is that you can do quite a few workarounds if you write efficient JavaScript and carefully layer things out – we have one player that runs every feature, on every device, scaling from the newest high-end game consoles to the worst 2012 TVs and smartphones, and it’s fine. So basically we’re building a cleaner, leaner Media Source into our native clients, plugging in a JavaScript workaround layer on top, then building a protocol engine in JS on top of that which is tightly coupled to server releases and can be updated in sync with new protocol revs. This gives us the flexibility to slosh whatever ML sauce we come up with, where-ever we need it to go. This is a super forward looking talk. I don’t have any numbers, and probably won’t have anything even by the time I write the talk. So be warned. Narrator: He probably will have the numbers… Presented at Demuxed 2019 in San Francisco.