`
rcfalcon
  • 浏览: 228583 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

浅析架构之 Videologger

 
阅读更多

想了一下,还是将“欣赏”的字样改成“浅析”比较好,毕竟自己也不是专家,完全作为一个路人一样来谈谈自己对架构的看法。OK,之后这个系列的话题都叫做浅析架构。。

今天我们来欣赏大名鼎鼎的具有世界级领先搜索技术公司autonomy旗下virage系列产品的videologger架构。

videologger是一个视频处理平台,旨在为非结构性数据提供索引化平台,见如下功能示意结构图

在整个virage体系中,其属于核心位置。桥接外部各个组件,并且具有高度可扩充性。在来源、编解码器、处理业务上均具有可扩展性。并且提供私有的视频索引信息。

这样看来,整个videologger就是一个抽象的平台,其在各个部分提供抽象层接口以适应各种第三方软件集成或者定制化开发。

我觉得将视频这样集中化处理的好处是,将视频解码统一做了。然后可以方便的供各种插件使用,而这过程只需要解码一次。具体的EncoderInterface我没有仔细看它的文档,不过我还是很怀疑能否将各种解码器做到很好的兼顾共性和个性。比如ffmpeg和X264,编码参数可能差异很大,如何在抽象层接口统一定义,或者比如现在CUDA的各种特性,如何兼顾进来?

这里各种应用插件,可能是这个平台最吸引人的地方。而Autonomy官方提供的几个经典的比如有音频识别、人脸识别、字幕识别、关键帧技术等,这些无一不用到了如今模式识别前沿的研究技术,当然,这就跟我们今天要讨论的videologger架构无关了。(就像基于windows平台的一款游戏和windows平台本身的概念差异一样。)

这样我又联想到,视频解码本身就是一个比较耗资源的活(比如解H.264还是需要占一点计算能力的),如果把这份数据又同时进几个上述的这种应用插件,假设同样很耗资源(比如人脸识别和语音识别),那么一个部署的工作站的计算能力可想而知必须多强大了。而服务器的价格和性价比的函数应该是一个导数小于0的(我觉得,某种 程度上应该是)。那么这种集中式工作站的投入很可能将会大于分布式的投入(比如将录制、人脸识别、语音识别分开在三台比较差的工作站上)。

可能有人说,我可以使用三个videologger来实现部署在较差的工作站上。那么这样的话,videologger这个统一处理平台就完全失去了意义和优势。

还有不知道videologger的软件授权模式是怎样,若是按台来算,上述想法果真是赔了夫人又折兵的想法。

我们注意到有个Remote Control的功能,这个是virage实现分布式处理的方法。其开放一堆调度接口,可以由control center调度videologger集群工作。我很好奇这里有没有类似map/reduce的方法可以使用集群同时对一个源进行处理(待调研)。

所以我觉得这个架构下,最适合自己将上下游插件开发得极度丰富,然后卖整套解决方案给客户。而不那么适合作为一个想要自主研发的团队依赖的架构,因为:

1. 团队得适应videologger接口和架构来开发,需要学习;因为其足够抽象,所以相信也更通用,更通用的代价是更难以学习;

2. 即使完全掌握vl的开发,想要做新东西,同样不省事,甚至要实现它的插件集成接口,更耗时;

3. 即使作为插件集成进来,好处也只是可以用到编解码及下游的一些便利,还不如自己设计;

4. 集中式工作站投入太大,license也是额外开支。

除非团队确实要用到autonomy现成提供的插件技术,我不推荐依赖于这个架构。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics