视频应用在区块链上的应用

视频类应用在区块链上的应用

1.用户
2.视频
3.视频存储
4.评论/弹幕
5.标签
6.赞/打赏
7.ipfs 直播
8.分类目录
9.专辑
备注

本文阐述视频应用在区块链上的应用的个人想法和观点。

2种结构的数据：

文件存储
主要引用IPFS的概念：基于文件内容的寻址，分布式存储。不存在全节点，即使存在（创造）意义不大。
资源索引
主要引用eth的感念：分布式、p2p，挖矿，内容是同步的。每个全节点拥有完全一致的数据和状态变量。
即一致性数据和非一致性数据集。

例子：
以下内容为学习solidity时的见解，其他描述语言可以雷同.

1.用户

在区块链中无法分辨用户，识别个体采用地址，因此在此一个地址即为一个用户。用户需要有自己的描述属性，即【昵称】【简介】【头像】，在此笔者尝试了2种实现方式，
① address => ipfs object.
将头像文件上传到ipfs空间上得到hash值，或者头像做base64编码，组合到一个用户对象（json字符串），将用户对象上传到ipfs空间上，得到一个ipfs的hash，储存到eth网络中。看起来像：

或

② address => struct.将头像文件上传到ipfs空间上得到hash值，其他文本摘要保存到eth数据库里。

当然也可以将图片二进制文件直接丢进eth数据库，但是在实践过程中2K大小的头像加一些说明文字，储存一个用户实例旷工费超过0.0007eth,（按照当前汇率已经超过1美元）。
其实用户个体出现在区块链中，目的还是要与用户对于起来，更具有人性化，毕竟这些应用都是服务于人的。

2.视频

视频检索可以参考优酷等视频网站的数据结构，但是也要考虑传统数据库的优势和区块链的劣势，因此将结构定制成以下这样：
id自增=>视频结构
视频结构：
1.视频文件：ipfs对象；
2.视频文件的描述：(此内容冗余，可以直接读取ipfs获得)，比如文件大小，内容格式、媒体内容的宽高，时长；
3.视频描述：视频的标题，描述，封面，时间戳，缩略图
4.应用数据：作者地址、评论、标签、打赏
同理，在此也使用上述用户结构的描述方法，将部分索引变量、储存变量置换位置。
在这里要思考一个问题：尽可能的将数据放到检索变量上还是储存变量上。
所有用户都是不可信任的，在协议中规定要提交ipfs对象，在eth中如果提交非ipfs对象也能记录，eth无法调取ipfs端去验证真伪（话说eos呢？在索引协议中是否可以调取储存网络上的信息？未来一定会实现的。）
写本文时作者未能实现在协议（合约）内去调取ipfs对象，封面可以自定义（最好的情况是在视频时间内截取）
缩略图对象包含2部分，1 缩略图的图片文件，

2该图片的描述。

{宽：高：横向切片数量：纵向切片数量：时间：{第一切片：0秒第二切片：1分钟第三切片：2分钟}
}

在播放器加载时可以在进度条加载该资源进行预览。
为了更好的统一协议，第一切片应该被描述成横向第N块，纵向第M块，或者直接坐标点（x，y，w，h）或者（x1，y2，x2，y2）

3.视频存储

视频存储需要考虑到多个方面：
1.同一个视频资源内容，应该对应多个质量（即360P、720P、1080P、4K、60FPS、以及不同码率）
2.同一个视频资源内容，应该对应多种封装容器（mkv容器、mp4容器、mov容器、flv容器、f4v容器、ts切片）和编码（h264编码、h265编码、aac编码、flac编码）
3.上文视频结构定义中的视频描述应该适合视频存储的整个对象。
这里列举2种方案：

这是一种错误的示范↑。

注意：目前支持原生ipfs协议的软件并不多，因此要特别注意网关转换，让不支持ipfs的软件能从http(https)网关处拿到数据。协议的迭代是不容易的，一旦完成协议部署，或者未来升级，都要考虑到对旧数据的兼容和包容，因此在在以上图示中应该包容那种错误的示范，在初期应用阶段也应该判断是否为错误架构，并作出相应的对待。
视频存储需要做到诚实，同一个资源的不同编码、封装、质量，其对于是同一个内容，同一时间点的截屏应该完全相同。
注意：本文只涉及到协议（合约）部分，不包括前端调用，但是要为前端调用做好充足的准备，比如要为窄带网用户提供低码率或者低分辨率的视频流，在协议普及过程中（推广、分享），势必通过ipfs网关转http传输协议来完成，也要为网页用户提供视频流。
注意：上文图示中多个视频流的描述方法并非首选，应该使用视频编码器、音频编码器、视频像素、比特率来描述视频的清晰程度，但由于此类参数过于专业化，使用者无法立即理解其中的含义，因此要做好易用性和专业性的平衡。

4.评论/弹幕

这里的评论也指代弹幕功能，不仅仅存储文本信息，需要完成简单富文本格式，还要包括弹幕的位置等。针对回复评论，需要得到回复给哪条评论，所以评论包含以下几类信息。
1.评论内容
2.弹幕数据（弹幕类型、颜色等信息）
3.时间（①评论的UTC时间；②评论在视频的第几秒时间）
4.是否回复之前的评论

关于直播的弹幕和评论也应该符合以上结构

5.标签

标签主要作用是订阅、分类、投票，单个视频可以有多个标签，每个标签应该包含投票是数量，比如一个视频的标签为【短视频】15票；【搞笑】80票；【游戏】1票，可以使用标签分辨出该视频属于什么类别？它是一个搞笑的短视频。但是【游戏】标签有1票，有人给他打了游戏的标签，但如果视频内容不是游戏，它也仅仅只有一票，算不了什么。

6.赞/打赏

这是内容提供者的主要经济（代币）收入，内容质量决定一切。

7.ipfs 直播

ipfs 直播功能很好的利用了ipfs pubsub pub 和ipfs pubsub sub。
这里着重要解释一下回看：其实可以合并当前分片和历史分片的m3u8信息，广播一次即可，但是这样做一定会对ipfs空间造成浪费，广播当前ts分片hash和广播历史分片hash可以选择不同的频率、或者广播历史分片hash可以做订阅，由客户端发送一个广播，我需要获取历史hash，处理进程再发送一个历史分片的hash也可以。
在回看过程中发的互动信息，由于是过去时间，不应该显示给主播看，或者展示给主播看到是回看发的信息，但这些信息需要存入自己记录的这份视频文件中，因为在直播结束或者直播过去时状态下可以发布视频，这回车记录弹幕。

8.分类目录

到这里，所有视频都是平行的，并不进行分类。分类的功能并不包含在协议中，在Dapp应用中，如果有中心组织去设置分类，将破坏Dapp的规则。
使用标签作为分类依据，这一点很好的提现了民主。

9.专辑

这一点和大多数视频应用一样，也需要专辑（分组视频）的结构，其中要实现：
1.分组的名称、简介、封面、分组的封面
2.引用的视频的id

备注

对于区块链应用编程思想来说：
1.可以不设计删除、更改功能，因为数据是依赖于日志写入生成的，而非当前状态，这意味着，想看到删除之前的状态变量非常容易，需要消耗的资源量不比重新发布一个新的要少。
2.内容监管，这一点希望evm这样的虚拟机环境能提供或者调取判断资源合法性的接口，协议本身能保证数据合法性，无法保证内容合法性。特别是储存类区块链，这里建议采用中心化的核审模式。