SMW '19: Tulix谈论低延迟流

以下是采访全文:

Tim Siglin: 欢迎回来，流媒体西部2019第一天即将结束. I'm Tim Siglin, 流媒体杂志的特约编辑和非营利组织“帮助我”的创始执行董事! Stream. 今天我请来了乔治，他是Tulix的创始人之一. 乔治，有些观众可能不知道，Tulix是什么?

乔治·Bokuchava: Tulix是一家位于佐治亚州亚特兰大的完整软件流媒体解决方案公司. 我们做生意已经很多年了. 很多年，我说的是20多年.

Tim Siglin: Right.

乔治·Bokuchava: 我们的基础是互联网知识. 很多年前，我们是互联网的先驱之一. 大约10年前，我们决定专注于流媒体.

Tim Siglin: Okay.

乔治·Bokuchava: 流媒体服务. 我们在互联网方面的背景、知识和经验使我们在构建健壮的解决方案方面具有巨大的优势, 哪些是具有成本效益的，哪些是用户友好的. 如果我们可以说圆.你可能还记得 .公司纷纷进入互联网的时代?

Tim Siglin: H-hmm.

乔治·Bokuchava: 我们来自那个时代. 我们是幸存者中的一员, 在这一点上运用我们所有的经验和知识, 我们建立的基础设施. 人们会在我们身边呆上二十年甚至更久. 这就是... 管理我们的公司. 其中一个特点，或者值得一提的是我们有20多年的历史. 我们有些客户在我们这里呆了15年以上. 也许这是有原因的.

Tim Siglin: 当你说端到端解决方案时, 这包括:编码, trans-coding, 内容分发播放器支持?

乔治·Bokuchava: Absolutely. 我们有一个非常有趣的方法. 我不知道是否还有其他公司存在. 但是我们有更有趣的方法. 我们有一个所谓的默认设置. Default setup, 我们正在使用一些第三方产品，这些产品的成本效益非常高，而且它们的质量足以满足大约80%的客户. 现在，在一些情况下，我们有非常具体的要求. 在这种情况下，我们会很高兴，或者我们会升级任何组件. 它是编码，是CDN，还是完整的OGD解决方案的任何其他部分. 只是，我们正在用市场上最好的解决方案进行升级吗. 我们讨论的是从最小最便宜的解决方案扩展到最昂贵的解决方案，并为市场提供最好的解决方案. 只要适合客户.

Tim Siglin: 我知道你和我曾经讨论过的一件事就是延迟有多重要. 看起来这个行业终于, 在经历了几年的, 让我们用碎片来衡量, and chunking, 这从本质上增加了交付的延迟, 现在我们真的在担心低延迟流媒体的问题吗. 正如你所说，你已经在这里工作了20年，对延迟的推动是新的东西吗? 或者我们把自己困在一个角落里，用支离破碎的解决方案，我们正在尝试如何走出这个角落，回到低延迟的交付?

乔治·Bokuchava: 有趣的是. 这也是一个非常大的问题或话题. 有趣的是, 在分块视频解决方案之前, like HLS, DASH, CMAF, 还有所谓的RTMP, RTSP. 或者实际上EMBONE，当你谈到多播是互联网上的解决方案. 我们说的是几乎没有延迟或者说没有人提到的明显的延迟. 现在，因为cdn的便利性，因为一些特定的硬件产品. 就像苹果，会有一个这样的公司. 有所谓的基于块的HTTP协议. 方便很好. 实际上，节省成本对cdn来说是很好的，这显然会转移到客户身上. 但是突然之间，低延迟的问题出现了. 这是一个真正的问题，因为从你的角度来看，延迟不仅与原始流相比. 但还有一个问题，你看到怀斯在同一个房间里，而我们一直在玩不同的游戏

Tim Siglin: 没有同步.

乔治·Bokuchava: 是的，没有同步. 想象一下，即使是在工程方面或监控方面，也可能会产生困难. So, 实际上是我们的定倍解, 我们处于非常有利的位置，因为我们有一个基础设施，我们有一个优化的路线，我们有几个更大的音符, 我们可以推进任何协议. 这是任何协议. 可以是任何东西, actually, 包括我们和客户之间的纠错协议，或者那些也能做到这一点的球员. 但很明显，我们要看到，我们花了半天的时间来实现. 我们即将看到其中一个节目的小样.

Tim Siglin: Sure.

乔治·Bokuchava: 但另一方面, 显然，我们的合作伙伴和合作伙伴正在推动我们获得延迟解决方案. 但我的回答是，让我们等待最大的家伙. 那些大人物会想出解决办法的. 这种解决方案可能会成为一种标准. 现在，没有人确切知道，但我认为最近的活动之一是由苹果公司完成的. 他们想出了更低的延迟.

Tim Siglin: Right.

乔治·Bokuchava: HTTP或HLS协议，但解决方案. 我认为很有可能会有一个好的解决方案. 如果不是这样，在我看来，其他一些东西将会出现，这些东西将由大公司推动. 这样我们就不需要所有的小解. 比如，我们公司有五种不同的解决方案，协议. 而且它们都是专有的. 你可以命名，但你知道，它实际上有五种不同的解. 我宁愿等到主电源出现并全力支持.

Tim Siglin: 你提到了WebRTC, of course, just like RTMP, WebRTC有一个规模问题, 不需要使用内容传递网络之类的东西. 那么，像WebRTC这样的低延迟和像HLS和DASH这样的可扩展解决方案之间的平衡在哪里呢? 你觉得这两者之间有中间地带吗? 还是会越来越接近WebRTC的延迟? 而不是我们在分块解决方案中遇到的多秒冷却?

乔治·Bokuchava: 在我看来，我们即将看到更大的问题. Just my opinion. 不仅仅是可扩展性. 由于我们活动的性质，我们要处理很多不同的平台.

Tim Siglin: Okay.

乔治·Bokuchava: 从智能电视开始，再到亚马逊Fire、苹果电视等等. 几乎任何可以播放的设备. 在很多情况下，我们有条件访问, 在许多情况下，我们有数字版权管理, 你知道，想出一个几乎基于实验室的解决方案很容易，你可以在一个设备或几个设备上获得一个流. 而且很干净... 但一旦进入全面生产模式, 那你就得撑住, I don't know, 好莱坞工作室的东西. 我无法想象我们现在看到的是什么，对于任何解决方案来说都是足够的.

Tim Siglin: 对于大型现场体育赛事来说，盗版是一个大问题，认证也是一个大问题.

乔治·Bokuchava: 为了更接近我认为的响应，那将是一个基于块的协议, 哪个会被修改，哪个会被调整. 不仅仅是通过减少频道的大小，而是任何技术的出现. 这里的方法是使它尽可能接近实时. 或者它可能是一个全新的协议，但它将是, in my opinion, 实施起来要痛苦得多. (蒂姆笑)因为我们看到了各种各样的东西

Tim Siglin: Sure.

乔治·Bokuchava: 再说一遍，你可以做任何你想做的. 假设我有五种不同的协议，其中一种最初是由亚特兰大的一家公司完成的，我们在那里运营. 他们有自己的解决方案，被用于世界上最大的拍卖行之一.

Tim Siglin: Okay.

乔治·Bokuchava: 但是，这只是一个解. 将解决方案纳入主流，我的看法是另一回事.

Tim Siglin: All right. 乔治，一如既往地感谢你的宝贵时间. 我们马上回来，可能会在今天结束前再进行一次采访.

乔治·Bokuchava: 非常感谢.