一对一直播相较于传统直播平台有更强的社交性和工具性（实在不知道怎么表达）。传统的直播可以作为独立软件平台去运营，面对的受众群体也十分广泛，可以说是“全民直播”。“直播+”的概念也已提出了好久，但真正的“直播+”解决方案却并没有像想象中应用的那么好。反观一对一直播，虽然受众群体有限，但却能很好的与社交平台相结合，使得很多传统的社交平台重获新生。而受网络视频直播熏陶的主播，似乎通过一对一直播找到了更好的“生财之道”，提供才艺展示、声音鉴赏、歌曲鉴赏、游戏陪玩等O2O 社交陪玩服务
直播APP系统开发。短视频1V1系统开发请联系邵生；135-3647-2774
短视频相比于文本数据而言，有着一些差异：
1.数据大小的差异。
比如一条美拍，经过视频压缩和清晰度的权衡，10s的视频大小1MB多，而一条5分钟视频的美拍甚至要达到几十M，相比与几十字节或者几百字节的文本要大得多。因为数据量要大得多，所以也会面临一些问题：如何上传、如何存放、以及如何播放的问题。
关于上传，要在手机上传这么一个视频，特别是弱网环境要上传这么一个文件，上传的成功率会比较低，晚高峰的时候，省际网络的拥塞情况下，要更为明显得多。所以针对上传，需要基于CDN走动态加速来优化网络链路（通过基调实测过对于提升稳定性和速度有一定帮助），同时对于比较大的视频需要做好分片上传，减少失败重传的成本和失败概率等来提升可用性。同时不同CDN厂商的链路状况在不同的运营商不同地区可能表现不一，所以也需要结合基调测试，选择一些比较适合自己的CDN厂商链路。
同时因为数据相对比较大，当数据量达到一定规模，存储容量会面临一些挑战，目前美拍的视频容量级别也达到PB级别的规模，所以要求存储本身能够具备比较强的线性扩展能力，并且有足够的资源冗余，而传统的Mysql等数据库比较难来支持这个场景，所以往往借助于专用的分布式对象存储，通过自建的服务或者云存储服务能够解决，得益于近几年云存储的发展，目前美拍主要还是使用云存储服务来解决。自身的分布式对象存储主要用于解决一些内部场景，比如对于数据隐私性和安全性要求比较高的场景。
关于对于播放，因为文件比较大，也容易受到网络的影响，所以为了规避卡顿，一些细节也需要处理。比如对于60s，300s的视频，需要考虑到文件比较大，同时有拖动的需求，所以一般使用httprange的方式，或者基于HLS的点播播放方式，基于前者比较简单粗暴，不过基于播放器的机制，也能够满足需求，也能实现点播拖动。而直接基于HLS的方式会更友好，特别是更长的一些视频，比如5分钟甚至更大的视频，不过这种需要单独的转码支持。之前美拍主要是短视频为主，所以更多使用httprange的方式。而后续随着5分钟或者更大视频的场景，也在逐步做一些尝试。同时对于播放而言，在弱化环境下，可能也会面临一些问题，比如播放时长卡顿的问题，这种一般通过网络链路优化；或者通过多码率的自适应优化，比如多路转码，然后根据特定算法模型量化用户网络情况进行选码率，网络差的用低码率的方式。
2.数据的格式标准差异
相比与文本数据，短视频本身是二进制数据，有比较固定的编码标准，比如H.264、H.265等，有着比较固定和通用的一些格式标准。
3.数据的处理需求
视频本身能够承载的信息比较多，所以会面临有大量的数据处理需求，比如水印、帧缩略图、转码等，以及短视频鉴黄等。而视频处理的操作是非常慢的，会带来巨大的资源开销。
美拍对于视频的处理，主要分为两块：
客户端处理，视频处理尽量往客户端靠，利用现有强大的手机处理性能来规避减少服务器压力，同时这也会面临一些低端机型的处理效率问题，不过特别低端的机型用于上传美拍本身比较少数，所以问题不算明显。客户端主要是对于视频的效果叠加、人脸识别和各种美颜美化算法的处理，我们这边客户端有实验室团队，在专门做这种效果算法的优化工作。同时客户端处理还会增加一些必要的转码和水印的视频处理。目前客户端的视频编解码方式，会有软编码和硬编码的方式，软编码主要是兼容性比较好，编码效果好些，不过缺点就是能耗高且慢些。而硬编码借助于显卡等，能够得到比较低的能耗并且更快，不过兼容和效果要差一些，特别是对于一些低配的机型。所以目前往往采用结合的方式。
服务端的处理，主要是进行视频的一些审核转码工作，也有一些抽帧生成截图的工作等，目前使用ffmpeg进行一些处理。服务端本身需要考虑的一些点，就是因为资源消耗比较高，所以需要机器数会多，所以在服务端做的视频处理操作，会尽量控制在一个合理的范围。同时因为可能美拍这种场景，也会遇到这些热点事件的突变峰值，所以转码服务集群本身需要具备可弹性伸缩和异步化消峰机制，以便来适应这种突增请求的场景。