百度云视频CDN面试总结

第一个博客，竟然是这么一个伤心的故事，哈哈哈。

10月30号，参加百度面试

先记一把流水账：

开始进入面试的节奏很快，坐着后还没怎么热身，就开始了

首先就是自我介绍，这个千篇一律，我的自我介绍也没什么亮点，基本就是毕业哪里，在学校期间研究的啥（现在回想起来在学校没有潜下心研究某一个方向，真是浪费太多时间了），现在在哪里干，工作内容大概包括哪些（按照时间轴理一理），然后此部分就结束了，面试的帅哥感觉基本没听，手里拿着估计是hr整理的简历看了看。

第二部分就是开始专业方向的面试了

面（面试官）： 目前工作都是使用的什么协议

我： DASH、HLS。

面： 大致介绍一下DASH的工作流程吧

我： DASH可以由标准的web服务器提供服务，终端请求的时候要依次请求mpd、init分片、媒体分片，其中mpd中描述了各个码率的视频和音频，记录init分片和媒体分片的url格式；init中描述了视频和音频的元信息，最重要的包括编码格式、参数等等；媒体分片中记录了详细的帧信息。对于直播场景的话，客户端会不断的请求mpd从而刷新最新的分片信息。

面： DASH只支持MP4格式吗

我： 不是，ts也是同样支持的

面： 简单介绍一些mp4的封装格式吧

我： mp4格式是由一个个box组成，box之间可以嵌套，基本的box包括size、type和数据字段，full box还会包括version和flags信息。其中box中比较关键的box如mvhd、moov、tkhd、mvhd、minf、stbl、stsd等。其中stsd中会记录编码的方式和参数等

面： 那你知道sps、 pps这些信息是保存在哪个box里的吗

我： 嗯。。。，sps和pps应该是放在stsd中（有点印象，却又拿不准，回来后查阅了一下资料，一般264编码的都是放在NALU header中的，这个NALU header是和帧放在一起的，但是MP4是将sps、pps放在stsd->avcc这个box中）。

面： 你知道dash和hls的播放要求是什么吗，比如下载多少个分片的时候才可以播放。

我： 额。。。这个不清楚（这个是一般是在协议里会说明，协议还是要多看看，平常只看了部分的dash协议，hls的基本没看，这个失误比较大，hls的市场占有率最高，但是自己却基本不知道基本的协议）

面： 影响直播观看体验的的指标包括哪些，如何针对做优化呢？

我： 典型的指标包括起播时延、卡顿、花屏等等，以起播时延来说，可以在服务端处理完请求后，以比较快的速率进行发包。（这里忘记了直播场景最重要的一个指标--端到端时延，囧啊）

面： 能说下hls和dash相比一些不同点吗？

额。。。一下子蒙了，平常没咋考虑过这个问题，一下子只说出无关痛痒的相同点，确实很像，面试官还提示了一下，可以从封装格式等方面考虑。（后来查阅一下资料，大概包括以下几点：1、dash的端到端时延小，切换码率的时候也比较快，hls的协议建议10s分片，但是dash没有，可以任意长度，因此端到端时延，hls至少会超过10s，甚至几十s都有可能，但是dash的分片如果切得比较短，可以使得dash的端到端时延降低，同时切换的时候也可以更快的下载到播放所需要的分片；2、dash的不同码率的视频和音频可以自由组合。dash中的视频和音频分都可以有不同的码率，因此客户端可以根据网络情况自行决定使用什么码率的视频和音频，但是hls的视频和音频是揉在一起的形成分片，因此切换码率的时候是视频和音频同时切换；3、mp4封装的视频格式冗余数据比较少，ts因为会有很多相同的PAT、PMT等信息，使得本来188个字节的ts包会有大量的头信息，导致真正的媒体信息较少，会造成比较大的流量浪费；但换个角度来说，这同样也是它的优点，因为ts最开始是使用在广电领域，需要媒体能很快播放，每个ts包里都携带了播放视频的元信息，因此仅需要少量的ts包即可播放，但是mp4是以box为单位，moov和moof必须完整收到后才能播放，否则是无法解析的；综合来说，各有利弊吧，可能需要参考具体的使用场景。4、在切iso时，因为mp4和iso封装的时候基础环境比较相似，所以切片的成本比较低，但是ts的成本就比较高；5、ts天生就是为了流式播放而生，因此播放的时候不会有画面间断等问题，但是mp4的封装难以做到无缝衔接，可能会有影响体验的问题）。

面： dash的音视频分离的优点？

我： 一方面音视频的码率可以自由组合，另一方面可能存在仅需要音频或者仅需要视频的场景，这样dash就可以节省带宽

面： 知道客户端切换码率的算法吗？

我： 不知道。。。（好尴尬，只知道影响因素包括带宽、丢包率、响应时间等）

面： hls是不是也可以做音视频分离？（这个问题记不清面试官问没问了，反正我在这里问一下自己吧，全当记录一下了）

我： v3版本的是音视频mux的，但是v4版本支持音视频分离

面： ts封装格式清楚吗？

我： 额。。。基本不知道。。。。

面： 没用过C++是吧，那你就用C实现一个小算法，将矩阵顺时针旋转一下，尽量将实现写得详细一点

刚拿到这个题，脑袋依然有点蒙，一下子没反应过来，简单在纸上画了画，从外圈到里圈，一层层去旋转，旋转的方法就是数值交换，换了第一行后，发现这个矩阵变乱了，顿时怀疑自己方向错了，然后又紧张起来，和面试官交流了下，看看有没有提示之类的，面试官说按照你刚才那个思路就挺好的，继续往下走走看。然后我就继续硬着交换，快把一圈交换完的时候豁然开朗了。但是来来回回已经浪费太多时间，所以理清楚了思路之后就和面试官说一下大致思路，balabala，然后这道题就这么算了，面试官也就没有让我具体在纸上徒手写代码了。

面：多线程写过吧，实现一个容器，要是线程安全的，包括向容器里添加新值的put方法和取出值的get方法，同时要求如果容器满的话，调用put方法的线程要阻塞，直到容器非满时恢复线程。

本来不是多复杂的题，但是一开始想想由于C++不熟，不知道容器怎么用，因此和面试官交流了下，涉及到基本容器的部分能不能用简单的方法表示，并且使用queue表示队列，得到肯定的答案后就开始考虑put和get方法。主要思路就是先要定义两个锁，put锁和get锁（实际写的时候忘记锁初始化了），put的时候先将put锁锁住，然后检查queue是否为空指针，然后检查queue是否已满，如果已满，则循环等待、检查，要加上usleep，并且设置超时时间；如果非满，则入队，解锁，同时需要注意异常返回的时候需要解锁；get方法类似，首先将get锁枷锁，然后检查队列是否为空指针，然后检查大小是否为0，非0的话则出队一个元素返回，最后解锁，同样需要在异常场景解锁。但是实际写在纸上的代码由于没有完全考虑异常场景，导致代码比较乱，这一点做的很不好。

刚写完的时候外面有个兄弟说这个会议室是他们定的，然后我们就要转战另一个会议室，然后我就给面试官讲我的实现，面试官始终没说什么，一直是嗯嗯嗯，我也猜不透。。。

说完实现之后，面试官就告诉我说今天的面试就到此结束了，你先回去吧（忧伤一下下）

和面试官一起下楼的时候，和面试官聊了一下，通过面试，觉得哪些地方还需要加强，面试官说深度还不够，还需要再努把力。

流水账到此结束。

总结一下吧：

1、视频行业专业性比较强，需要有一定的知识储备才行，基本的hls、dash协议、mp4、ts格式，编解码格式，他们的演进历史、区别，优缺点等等，还是要好好看看，并总结、对比一下的。虽说自己已经在某厂的视频cdn部门干了一年多，但是实际接触到视频的时间可能只有3、4个月，很多时间都是在做无用功，对于很多东西都是浅尝辄止，蜻蜓点水般，这一点对于做技术的人来说，已经很致命了，很容易就导致自己沦为打杂的。

2、对于第一题算法题，本来是挺简单的题目，但是因为考虑了过程中问题变复杂了，然后就怀疑自己的思路错了，没有坚持走完一遍，差点导致放弃做这一题。

3、最后一题的多线程题，一方面自己的实现不完整，另一方面锁都忘记初始化了。这两点其实可以从平常的工作中就能找到原因： 在厂里工作，基本上所有的需求，都可以在已有的代码上复制、粘贴、修改修改即可，这就是另外一个致命的问题，比如复制了100行代码，可能其中30行是自己写的，但是另外70行都是别人的，而且可能复制的部分都是最关键的，这就导致代码复制完了，只知道其中一小部分的实现，整体的实现似懂非懂；在厂里工作，基本的字符串、数据结构、线程的操作都是封装好的，我们只需要调用宏很或者方法即可，这就会导致另外两个问题：1、 基本的glibc的函数可能都不知道叫啥名字，离开了这些封装好的方法，我们可能都不会写代码了；2、高手在封装这些方法的时候可能使用了很多的技巧，但是我们却对这些技巧不可见。因此，在之后的写代码的过程中，还是尽量少copy代码，老代码尽管是稳定，好用，但是不利于自己编码水平的至发展，至少也要是自己先实现一遍了，然后再对比一下才能知道出别人实现的优势。说到这个问题，还可以再扩展一下，就是如何对待开源代码的问题，开源大法固然好，但是副作用也不小，需要自己把握这里面的度。

以上总结就是自己面试失败的一点拙见。

这一课就叫抬头看路吧