在互联网行业，大部分工程师在进入职场后都是从普通业务开发开始做起的。服务端也好，前端、客户端也好，业务开发的门槛通常在于对编程语言、平台 API、工程框架和公司工程开发环境的掌握程度。在此基础上去处理业务逻辑，通常并不是那么难，这主要得益于业务数据协议的易读性。
目前使用最多的业务数据格式是 JSON，随便给一段 JSON 格式的业务数据，就算没有上下文，通常也能对它理解个十之五六。比如下面这段数据，你很容易就能猜到它大概的含义：
{
"squadName" : "Super hero squad",
"homeTown" : "Metro City",
"formed" : 2016,
"secretBase" : "Super tower",
"active" : true,
"members" : [
{
"name" : "Molecule Man",
"age" : 29,
"secretIdentity" : "Dan Jukes",
"powers" : [
"Radiation resistance",
"Turning tiny",
"Radiation blast"
]
},
{
"name" : "Madame Uppercut",
"age" : 39,
"secretIdentity" : "Jane Wilson",
"powers" : [
"Million tonne punch",
"Damage resistance",
"Superhuman reflexes"
]
}
]
}
一个工程师，有一定的编程语言、系统 API 和开发环境的基础知识，基本上就能开始上手处理常规的业务需求，因为业务数据是 human-readable 的，用编程语言组织逻辑来操作这些数据是一件很好理解的事情。
这就是业务数据协议的重要性，它越是易读，越是能降低开发人员的理解成本、逻辑开发成本和测试调试成本，从而提升开发效率。
当然，如果开发过程中，所编写程序的即时可见性越好，一句代码敲完，能有对应的可视化 UI 就随之反馈变化，那就是更友好的开发体验了。这也是为什么通常来讲我们入门前端、客户端的难度低于后端的原因之一。
相较而言，音视频开发人员面对的数据就没那么友好了，大部分是形如：
[图片上传失败...(image-8ffde2-1655022547156)]
对人不友好的二进制、十六进制数据。对着这堆熟悉又陌生的数字，如果给你提个需求：把当前 Box 的类型取出来。你会不会有点感觉无从下手？
从编码格式到封装格式，再到媒体传输协议格式，通常都是在字节的粒度上来制定协议规范，这样的好处是占用空间小、能更好的压缩数据，但是基本上也失去了对人的易读性。如果没有仔细研究对应的格式标准，你基本上无法知道一堆 0 和 1 的序列到底代表着什么。这就使得一个工程师在开始学习音视频开发时，即使有同样的基础开发技能，由于不理解当前操作的数据是什么，也就不能随心所欲的发挥自己的编程技能了。所以，我觉得学习音视频开发的最大门槛其实就是音视频相关数据格式协议的不易读性。
设想一下，我们把上面图中的 MP4 ftyp Box 数据示例 的格式转换为 JSON：
{
"type" : "ftyp",
"major_brand" : "isom",
"minor_version" : 512,
"compatible_brands" : [
"isom",
"iso2",
"avc1",
"mp41"
]
}
当你再去面对『把当前 Box 的类型取出来』这个需求时，是不是好像也没那么难了？因为这时候，就算你没有读过一篇 MP4 格式规范说明，你也大概能理解如何操作上面的数据。
以上就是我对音视频学习门槛的一点看法，这也是我在这个公众号发布一系列专栏文章原因：介绍音视频相关的基础概念知识，帮助大家理解音视频的编码、封装、传输协议格式规范，在理解了我们处理的数据对象是什么后，才能让我们的编程能力在音视频技术领域有用武之地。
如果你觉得有那么一点道理，你不妨看看我们的音视频基础概念知识主题专栏的系列文章。当然，我的看法也不一定对，欢迎大家留言指正。
此外，如果你对音视频方向感兴趣，或者符合下面的情况：
- 在校大学生 → 学习音视频开发
- iOS/Android 客户端开发 → 转入音视频领域
- 直播/短视频业务开发 → 深入音视频底层 SDK 开发
- 音视频 SDK 开发 → 提升技能，解决优化瓶颈
我们创建了一个音视频社群，vx 搜索『gjzkeyframe』 关注『关键帧Keyframe』咨询，或知识星球搜『关键帧的音视频开发圈』，了解一下这个社群，根据自己的情况按需加入。
网友评论