视频上传的两种方案

短视频是近两年的趋势,主流的内容生产平台都加入了这个功能。知乎也在 2017 下半年逐步开始运营视频创作相关的活动。略去视频运营相关的工作,个人对公司视频上传的业务接入实现是存在质疑的。

以撰写想法为例,创建一条包含视频的想法过程如下:

  1. 想法编辑器内选择视频
  2. 用户点击发送按钮,客户端本地压缩视频
  3. 客户端将视频上传到视频后端,拿到 sessionId 和 videoId
  4. 客户端通过 sessionId 轮询视频后端,检查转码审核状态
  5. 轮询状态如果成功,则将想法草稿连同 videoId 发送到想法后端
  6. 想法后端负责分发相关的工作

其中关键的地方在于,通过 sessionId 轮询视频状态是否需要客户端来实现。这就涉及到客户端和后端的业务划分问题了,一般来说客户端着重负责展现和交互,而数据处理则会交给后端。站在客户端角度上,凡是需要「轮询」实现的方案都不是优雅的方案,当然不是说这样做不行。

实际上据我所知,当时做视频的时候工期紧,需求大,因此具体实现不是很好。但现在看来实际上公司是想把视频作为一种产品来运营,而不是各个业务的基础设施。出发点不同采取的技术实现会不同,例如上述视频上传过程。如果视频作为一种基础设施,想法接入视频上传的一种可能过程如下:

  1. 想法编辑器内选择视频
  2. 用户点击发送按钮,客户端本地压缩视频
  3. 客户端将视频上传到视频后端,拿到 sessionId 和 videoId
  4. 客户端将想法草稿,连同 sessionId 和 videoId 发送到想法后端
  5. 想法后端将 sessionId 和 videoId 委托给视频后端
  6. 视频后端自己负责状态检查,完成后通知想法后端创建成功
  7. 想法后端负责分发相关的工作

对比两种方案,区别在于视频后端如果能提供一种类似客户端轮询的消息中间层,那么各个业务接入就很方便了。而现在导致的结果就是,一旦有新的业务接入视频后端,都要自己重新实现一遍轮训过程,这是十分 dirty 的。

另外我也有了解过,为什么不能在客户端压缩的过程中直接转码呢?当然有的公司是这么做的,但是一种较为可信的说法是,客户端自己压缩转码是不可靠的,不同手机的硬件不同,有的手机甚至没有硬解只能软解,可能导致最后产出的视频在有的手机上无法播放。当然这又是另一个话题了。微信的小视频上传这么快,究竟是为什么呢?

返回