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

2种结构的数据：

1. 文件存储
   主要引用IPFS的概念：基于文件内容的寻址，分布式存储。不存在全节点，即使存在（创造）意义不大。
2. 资源索引
   主要引用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这样的虚拟机环境能提供或者调取判断资源合法性的接口，协议本身能保证数据合法性，无法保证内容合法性。特别是储存类区块链，这里建议采用中心化的核审模式。

最后

以上就是孝顺野狼为你收集整理的视频应用在区块链上的应用的全部内容，希望文章能够帮你解决视频应用在区块链上的应用所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。