不说废话直接说正事。网易2018实习生招聘里的视频编解码开发实习生这个岗位很多人看到第一反应是是不是要熟背H.264标准文档、是不是得把FFmpeg源码倒背如流——说实话笔试真题出来以后你会发现它考的东西和三年前的背八股完全不是一回事。这个岗位考的是你能不能真正看懂一条视频码流能不能在代码层面和编解码标准之间来回切换。笔试考点覆盖C/C基础、H.264码流结构、编解码原理、多线程与内存管理、FFmpeg工具链等多个维度。适合正在准备音视频岗位校招的同学、刚转行进入流媒体领域的开发者以及想系统梳理编解码知识体系的人。这篇文章我会把笔试背后的考察逻辑、核心知识点逐一拆开再结合真实解码场景聊清楚考这些到底有什么用。1. 内容整体设计与思路拆解先说一个很多人没意识到的问题网易在当时国内互联网公司里算是比较早大规模落地视频相关业务的公司之一。云音乐有MV和直播严选有商品视频新闻客户端有信息流视频CC直播更不用说游戏事业部还有大量的游戏录屏和实时对战画面传输。这么多业务线摆在那里视频编解码开发实习生不是招来研究算法发paper的是招来写解码器集成、做转码服务、排查各种花屏绿屏卡顿问题的。所以笔试的题目设计有一个非常明确的导向考你在真实工程链路里最常碰到的技术点。这也就解释了为什么那张卷子里会出现大量C指针、内存布局、位操作、多线程同步相关的题目而不是单纯问你H.265比H.264压缩率提升多少这种概念题。1.1 这个岗位笔试的本质考动手前的眼光我见过很多准备校招的同学复习视频编解码就是拿一本《新一代视频压缩编码标准——H.264/AVC》从头啃把帧内预测、帧间预测、环路滤波、熵编码的概念背得滚瓜烂熟。但一拿到笔试题看到给一段二进制数据写出解析SPS中宽高的过程人就懵了。原因很简单从原理到码流中间隔着一层工程落地。标准文档告诉你pic_width_in_mbs_minus1是一个无符号指数哥伦布编码的语法元素但笔试考的是你知不知道在代码里怎么逐bit读出来、怎么处理字节对齐、怎么判断读到的是不是有效数据。这不是背概念能解决的需要真正写过码流解析代码或者至少认认真真读过FFmpeg里h264_parse.c这类文件。网易在2018年那个时间点考这些本质上是想筛掉只看过书的候选人留下能直接上手干活的人。视频编解码开发本身就是个工程属性极强的方向笔试只是把工程能力中最为核心的几个维度拆成了题目。1.2 从岗位JD反向推导考察范围把当年这个实习岗位的JD拆开来看基本要求是熟悉C/C了解H.264/H.265等视频编码标准熟悉FFmpeg/GStreamer等开源框架有音视频开发经验者优先。这几句话翻译成笔试考点就变成了下面这张对照表JD关键词笔试实际考察点出题形式熟悉C/C指针、内存布局、位操作、字节序代码阅读、输出结果题了解H.264/H.265码流结构、NAL单元、SPS/PPS解析给定二进制数据解析字段熟悉FFmpeg音视频解码基本流程、数据结构关系代码流程填空、API理解多线程/性能优化解码线程模型、帧缓存管理、并发冲突多线程编程题、死锁分析这里最容易被忽略的是第一行C/C基础。很多准备音视频岗的同学把大量时间花在看H.266/VVC的新特性上结果笔试第一道大题竟然是考memcpy和指针偏移。这不是出题老师在为难你而是因为视频编解码开发80%的日常都是在跟内存和二进制打交道。2. 核心细节解析与实操要点进到具体的知识点。我把当年笔试涉及的核心内容分成五个模块每个模块说明考点是什么、为什么考、怎么准备才有效。2.1 C/C与位操作解码器生存的第一技能视频编解码里有一类操作无处不在从一个连续的字节流里精确读出若干个bit。H.264的语法元素绝大部分都不是按字节对齐的比如SPS里的profile_idc占8bit但下一个字段就可能是连续的变长编码跨字节跨bit是常态。笔试里常考的Exp-Golomb指数哥伦布解码就是一个典型。标准里定义了解码过程读入连续的0直到遇到第一个1记0的个数为leadingZeroBits然后读取leadingZeroBits个bit作为后缀信息最终codeNum 2^leadingZeroBits - 1 后缀的值。这个逻辑本身不复杂但放到C/C代码里要写对就得考虑字节指针怎么移动、位缓冲区怎么维护、边界条件怎么处理。我当时自己练习时写过一个很小的解码头核心代码大概长这样// 从缓冲区中读取nbitsbs-p是当前字节指针bs-i_left是当前字节内剩余bit数 uint32_t bs_read_ue(bs_t* bs) { int32_t leading_zero_bits -1; for (int32_t b 0; !b; leading_zero_bits) { b bs_read_1(bs); } uint32_t suffix bs_read_bits(bs, leading_zero_bits); return (uint32_t)((1 leading_zero_bits) - 1 suffix); }这道题看起来简单但坑特别多。比如1 leading_zero_bits当leading_zero_bits等于32时是未定义行为标准里语法元素最大也就31位但你写代码的时候必须考虑这个边界。再比如位缓冲区的字节序Annex B格式的H.264裸流是big-endian逐bit读取的和x86机器的小端存储正好相反处理不好读出来的值全部是反的。注意做位操作题目的时候一定先画一张bit分布图再动手写代码。很多笔试题考察的不是你会不会位运算而是你能不能准确理解从第几个bit开始读、连续读几位、读出来的值落在什么范围。2.2 H.264码流结构与NAL单元视频开发者的通用语言H.264码流有一个分层结构视频编码层VCL负责存实际的图像数据网络抽象层NAL负责把数据打包成适合传输和存储的单元。笔试里常考的NAL头就是每个NAL单元开头的那个字节结构如下bit7forbidden_zero_bit必须为0bit6-5nal_ref_idc表示是否被其他帧参考非0表示可能被参考bit4-0nal_unit_type表示NAL单元类型nal_unit_type有几十种取值但对开发来说最核心的几个必须烂熟于心1表示非IDR的slice5表示IDR切片7表示SPS8表示PPS6表示SEI9表示AUD。笔试如果给你一个二进制流让你判断这个位置是不是关键帧本质就是让你检查当前slice是不是类型5。SPS的解析是笔试另一个高频考点。SPS里头有大量视频核心信息包括profile_idc、level_idc、pic_width_in_mbs_minus1、pic_height_in_map_units_minus1、frame_mbs_only_flag等。实际画面分辨率不是直接存进去的需要通过公式计算宽度 (pic_width_in_mbs_minus1 1) * 16高度需要结合frame_mbs_only_flag做二次换算。考这个知识点的时候出题人常会给出一段SPS的十六进制字节让你手算出分辨率。我自己在真实开发中有一次排查一个视频播放黑屏问题用码流分析工具切出来SPS一看分辨率算出来是1920x1088不是1920x1080。这就是因为某些编码器会把高度按宏块16对齐多出来的8行是padding。如果不懂SPS解析的细节对着日志看半天也不知道问题出在哪。2.3 变换、量化与熵编码理解压缩的定价逻辑这一部分偏向编码原理笔试通常不会要求你手推DCT公式但会从理解原理如何影响工程决策的角度出题。比如变换编码的核心思想把图像从像素域变换到频域能量集中到低频系数上高频系数大多接近0然后通过量化把这些接近0的系数置为0实现压缩。H.264用的是4x4整数变换是对DCT的整数近似好处是解码端和编码端不会因为浮点精度问题出现失配。笔试如果问为什么视频编码标准用整数变换而不是浮点DCT答案就是在不同实现之间保证一致性。量化是压缩率与画质的核心权衡点。H.264的量化参数QP范围是0到51QP越大量化步长越大压缩率越高但画质损失也越明显。有个经验关系QP每增加6量化步长大约翻一倍对应码率大约下降一半。笔试里可能给你一个QP变化让你推断码率和画质的大致变化方向这种题不需要精确计算但需要理解这层单调关系。熵编码部分CAVLC和CABAC是H.264的两种主要方案。CABAC压缩率比CAVLC高大约10%到15%但计算复杂度更高。笔试常考的是什么时候选用哪种这类工程判断题低延迟实时通信场景往往选CAVLC或对CABAC做简化离线转码追求高压缩率则选CABAC。2.4 内存管理、多线程与并行解码大型解码器的骨架视频解码器的复杂度不仅来自码流解析更来自对大量帧数据的组织和管理。一个1080p的YUV420帧原始数据大约是192010801.5字节约3MB。一个解码器要同时维护当前解码帧、参考帧列表、输出帧队列内存分配和释放的频率非常高。如果每次解码一帧就malloc一块3MB内存性能会非常难看。所以主流的解码器实现都会引入帧池frame pool机制初始化时一次性分配一批帧缓冲区解码过程中循环复用通过引用计数管理生命周期。网上的笔试题目很可能不会直接考帧池怎么设计但会考线程同步、共享数据访问这类底层问题。比如解码线程和渲染线程共享帧数据时怎么避免一边在写一边在读参考帧列表在解码过程中会被不断修改多个线程同时访问怎么保证安全一个生产者消费者模型里怎么设计缓冲区才能既不丢帧又不同步阻塞这些问题背后的工程思路和帧池、DPB解码图像缓冲区管理的逻辑完全一致。所以准备笔试的时候别光看视频编码标准把操作系统课本里的信号量、互斥锁、条件变量翻出来复习一遍作用非常大。2.5 FFmpeg与开源工具链不会用框架等于白学FFmpeg在音视频开发中的地位相当于OpenCV在图像处理领域中的地位。笔试即使不直接考FFmpeg API的拼写也大概率会给你一段代码让你分析av_read_frame、avcodec_send_packet、avcodec_receive_frame这三个函数组成的解码循环。理解FFmpeg的解码流程核心是记住几个关键结构体之间的层级关系AVFormatContext描述封装格式上下文AVCodecContext描述解码器上下文AVPacket存压缩数据AVFrame存解码后的原始数据。经典解码循环大致是avformat_open_input(fmt_ctx, filename, NULL, NULL); avformat_find_stream_info(fmt_ctx, NULL); for (int i 0; i fmt_ctx-nb_streams; i) { if (fmt_ctx-streams[i]-codecpar-codec_type AVMEDIA_TYPE_VIDEO) { video_stream_index i; break; } } avcodec_open2(codec_ctx, codec, NULL); while (av_read_frame(fmt_ctx, pkt) 0) { if (pkt-stream_index video_stream_index) { avcodec_send_packet(codec_ctx, pkt); while (avcodec_receive_frame(codec_ctx, frame) 0) { // 拿到一帧yuv数据 } } av_packet_unref(pkt); }为什么从FFmpeg 4.x开始官方推荐send_packet/receive_frame这种异步接口而不是老的decode直接调用因为这个接口设计把喂数据和取数据解耦了调用方不需要关心解码器内部是否有延迟帧、是否有多帧缓存只需要保持循环。笔试如果让你评价两种接口的优劣抓住这个点就能说出工程师真正关心的东西。3. 实操过程与核心环节实现把笔试知识转化为解码实战笔试只是门槛真正入职以后你会发现面试时候问的那些知识点会以非常具体的方式出现在你的工作里。我按自己踩过的坑梳理从拿到码流到排查出问题的完整链路你看完就知道准备笔试的时候该往哪个方向使劲。3.1 拿到一个H.264裸流第一件事做什么假设你现在接手一个任务某个视频文件在App里播放花屏需要定位是编码器的问题还是播放器的问题。第一步不是打开代码而是用工具把码流结构看清楚。命令行下用ffprobe就能拿到底层信息ffprobe -show_streams -select_streams v -print_format json input.mp4这条命令会输出视频流的编码格式、分辨率、帧率、profile、level、码率等信息。如果输出里显示codec_name是h264profile是Highlevel是40说明这是H.264 High Profile Level 4.0的流最大支持1080p30fps级别的解码。如果播放器宣称只支持Main Profile那这个流花屏就丝毫不奇怪了。拿到这些信息后再进一步看关键帧分布ffprobe -show_frames -select_streams v -print_format json input.mp4 | grep -E pict_type|key_frame | head -40这条命令输出每一帧的编码类型I帧、P帧、B帧的排列情况一目了然。如果发现长时间没有I帧或者两个IDR之间的间隔过大那么拖动进度条时就会出现长时间黑屏或花屏。这种问题如果不通过工具看码流靠肉眼盯播放画面是很难定位的。3.2 手工解析SPS从字节流里还原视频参数笔试考SPS解析很多人觉得是偏题。但实际写转码服务的时候你经常需要在不解码的情况下只读几个字节就知道这个视频的分辨率、帧率、profile。比如服务端要做按分辨率分发的逻辑先读SPS判断是高清还是标清决定走哪条转码链路。从Annex B格式的H.264裸流中提取SPS通常先搜索起始码00 00 00 01或者00 00 01然后检查NAL头字节如果低5位等于7说明后面跟的就是SPS。SPS的RBSP语法元素里第4个字节开始有profile_idc随后是constraint_set flags和level_idc。在实际解析过程中得处理那些在起始码之后可能出现的emulation prevention bytes0x03不然读出来的数据会错位。这里给出一个非常精简的定位SPS的步骤逐字节扫描码流找到00 00 01或00 00 00 01起始码读取起始码后的第一个字节转成二进制看低5位是否等于7如果等于7记录当前位置SPS的NAL单元从起始码之后开始根据NAL头长度字段如果是AVCC格式的话跳到下一个起始码SPS结束对中间的数据做去emulation prevention处理然后按SPS的语法表逐字段解析。这个过程中最容易出的bug是混淆Annex B和AVCC两种封装格式。Annex B用起始码分割NAL单元MP4的avcC box则用4字节长度字段分割。很多从MP4里提取H.264裸流的工具如果没做格式转换直接拿avcC格式的数据送到只认Annex B的解码器里就会出现SPS解析失败、解码器初始化报错。笔试如果考AVCC和Annex B的区别本质上就是问你能不能安全地在两种封装格式间切换。3.3 自己动手实现一个极简H.264解码练习很多人问我想入行视频编解码要不要自己从头写一个解码器我的观点非常明确不要从零写完整的H.264解码器那个工作量太大但一定要自己写一个能解析码流结构和SPS/PPS的工具。为什么强调这个度完整解码器涉及帧内预测、帧间运动补偿、环路滤波、CABAC/CAVLC全部模块没有两三个月拿不下来而且写出来的东西和x264、FFmpeg的成熟实现差距巨大工程上没有任何复用价值。但码流解析不一样它代码量不大却能逼你把NAL结构、Exp-Golomb、SPS语法这些笔试核心考点全部过一遍。我自己带过几个实习生给他们布置过一个小练习写一个命令行工具输入是H.264裸流文件输出是每一个NAL单元的类型、大小、关键帧位置、分辨率、帧率。这个任务大概花一到两周能完成完成后对码流的理解深度比啃三遍标准文档都管用。下面是解析NAL类型的一个极简代码片段#include stdio.h #include stdint.h int main(int argc, char* argv[]) { FILE* fp fopen(argv[1], rb); uint8_t buf[4] {0}; uint8_t nal_header; while (fread(buf, 1, 4, fp) 4) { // 查找起始码 if (buf[0] 0 buf[1] 0 buf[2] 1) { nal_header buf[3]; } else if (buf[0] 0 buf[1] 0 buf[2] 0 buf[3] 1) { fread(nal_header, 1, 1, fp); } else { continue; } int nal_type nal_header 0x1F; printf(NAL type: %d\n, nal_type); // 根据nal_type输出对应含义 } fclose(fp); return 0; }这只是一个非常粗糙的示意代码真实场景还需要处理多NAL单元聚合、字节流跨边界等情况但作为练习起步已经够了。做完这个练习你再回头做笔试题里的SPS解析题会发现手到擒来。3.4 从软解到硬解RK3588这类平台的解码开发思路笔试里不太会直接考某个芯片平台的API但视频编解码开发的工作内容里硬解是绕不开的。在RK3588这类带硬件编解码模块的平台上做开发核心逻辑通常是用V4L2或厂商私有接口打开硬件解码器把H.264/H.265的码流数据通过内存缓冲交给硬件解码模块硬件解码完成后输出YUV帧再走渲染或者后处理。实用经验是从软件解码切换到硬件解码时必须处理好几个问题输入格式硬件解码器对NAL单元的封装格式有严格约定通常要求Annex B格式MP4的avcC格式要先转换帧率控制硬解本身不负责帧率控制解码速度可能比实时快好几倍需要由上层根据PTS控制输出节奏内存对齐硬件解码器输出的YUV数据在宽高、stride上有对齐要求比如16或64字节对齐直接用原始分辨率去算行字节数会出错参考帧管理硬件解码模块内部会维护DPB但外部每次要保证输入帧的序号正确乱序输入会引发解码错误。这些经验是笔试和面试之间最后一公里的桥梁。笔试考你对解码原理的理解硬解开发则考你把原理落到具体平台上的能力。3.5 用FFmpeg命令行快速排查问题的几个组合拳当年笔试也有不少FFmpeg相关的选择题而真到了工作中命令行工具是最常被调用的调试手段。我把自己常用的几条命令分享出来属于高频使用场景# 查看视频流详细信息 ffprobe -v error -show_streams -select_streams v -show_entries streamcodec_name,width,height,r_frame_rate,avg_frame_rate,pix_fmt,profile,level input.mp4 # 提取某个时间段内的裸流便于分析 ffmpeg -i input.mp4 -ss 00:01:00 -t 00:00:10 -vcodec copy output.h264 # 查看每一帧的编码类型和大小 ffprobe -v error -select_streams v -show_frames -show_entries framepict_type,pkt_size input.mp4 # 把视频转成yuv原始数据供手工分析 ffmpeg -i input.mp4 -vcodec rawvideo -pix_fmt yuv420p output.yuv遇到解码报错时最实用的是加-loglevel debug参数跑一遍FFmpegffmpeg -v debug -i broken.mp4 -f null - 21 | grep -i h264日志里会打出每个NAL单元的处理情况哪一帧解析失败、哪里的比特流有误都能看出来。这条命令我调试视频文件时几乎必用比拿播放器反复播效率高得多。4. 常见问题与排查技巧实录准备这类笔试最容易踩的坑每年都有大量候选人挂在同一个地方不是不会而是练的方向偏了。下面这些坑是我在面试别人和实际工作中反复看到的整理成速查表你对照着自查。4.1 只背编码原理从不写码流解析代码典型表现后果正确做法能说出H.264的帧内预测有几种模式写不出从码流中解析出帧内预测模式的代码动手实现NAL单元解析和SPS读取知道CABAC比CAVLC压缩率高不理解为什么实时场景有时反而选CAVLC用FFmpeg分别跑两种熵编码对比耗时和码率能默写DPB管理流程笔试考多线程缓存管理还是懵自己实现一个简单的帧缓存队列加锁保护视频编解码开发本质上是一个二进制世界的活。所有高级概念最终都要落到从哪个bit开始读、读几位、怎么换算这一层。只看书不写码等于学游泳只看教学视频不下水。4.2 只跟FFmpeg命令不读源码FFmpeg的命令行确实很强大但如果你只停留在会用命令转格式的层面笔试题里稍微一深挖就会露馅。比如问你avcodec_receive_frame返回EAGAIN是什么意思如果你没读过源码或者没实际处理过这个返回值很可能回答成出错了但真实含义是解码器内部还没有完整的帧可以输出需要继续喂数据。这个区别就是用过和理解的差别。面试官看一眼你对这个错误码的解释就知道你是真的写过解码循环还是只在网上看过示例代码。建议抽个周末把FFmpeg的doc/examples/decode_video.c从头到尾读一遍每行都搞清楚在干什么收获会非常大。4.3 忽略封装格式只知道裸流很多准备笔试的人把大量时间花在H.264和H.265标准上对MP4、FLV、TS这些封装格式完全没概念。但实际开发中我们拿到手的视频90%以上都是带封装格式的文件。MP4的avcC box里有SPS和PPSFLV的VideoTagHeader里有CodecID和AVCPacketTypeTS流里有PES和PSI。如果笔试给你一个TS流文件问你如何定位到一个I帧你需要同时理解TS的包结构和H.264的NAL结构才能答对。封装格式这块至少掌握到给你一个MP4文件能说清楚moov box和mdat box的关系以及如何从moov中找到每个sample的偏移量这个程度就算过关。4.4 不重视代码输出结果的规范性笔试里有一种题很阴给你一段C代码让你写出输出。这种题在视频编解码岗位的笔试里出现频率极高而且坑很多。比如char buf[8]; uint32_t val 0x01020304; memcpy(buf, val, 4); printf(%02x %02x %02x %02x\n, buf[0] 0xff, buf[1] 0xff, buf[2] 0xff, buf[3] 0xff);在x86小端机器上输出是04 03 02 01。备考的时候很多人压根没想过字节序的问题看到这种题直接按大端顺序写了01 02 03 04白白丢分。视频编解码和字节序强相关因为码流标准里定义了bit传输顺序但不同的实现和平台又有各自的存储顺序偏好。建议做题前养成一个习惯凡是涉及多字节整数和bit级读取的先明确自己是按大端还是小端处理。4.5 准备笔试的实用清单与节奏建议结合我自己带人、面试和当年备考的经验给出一份实操清单按优先级排序用一周时间读懂FFmpeg的解码流程把decode_video.c的每一行注释掉并重新自己写一遍实现一个H.264裸流NAL解析工具输出每个NAL的类型、大小、偏移用真实视频文件验证手动解析至少三个真实H.264视频的SPS把profile、level、分辨率、帧率算出来用ffprobe的输出做对照刷C指针、内存、位操作、多线程相关的笔试题重点看字节序和结构体内存对齐的题目练习用ffmpeg和ffprobe命令排查一个给定的损坏视频文件形成自己的调试方法清单如果有余力读一下H.265的VPS/SPS/PPS结构和H.264的差异作为加分点。这套流程下来视频编解码笔试里90%的考点都能覆盖到而且每项练习的产出都可以写进简历比单纯写熟悉视频编解码有说服力得多。最后再分享一个我实际用的学习技巧平时看视频的时候养成打开播放器统计信息的习惯。暴风影音的CtrlJ、VLC的CtrlI、mpv的ShiftI都能看到当前视频的编码格式、分辨率、帧率、码率信息。看到这些参数后想一下如果我现在要解析这个文件的SPS会从哪里找到这些字段。把这个习惯保持一个月你对音视频参数的敏感度会明显超过那些只在书本上见过这些概念的人。我在实际面试过不少候选人之后最大的感受是视频编解码这个方向门槛不在难而在杂。知识链条特别长从C/C、操作系统、网络协议到编码标准、封装格式、开源框架哪一环断了都会出问题。笔试只是第一次过滤真正想在这个方向走远把上面这些基本功打扎实比追任何新概念都重要。
不说废话直接说正事。网易2018实习生招聘里的视频编解码开发实习生这个岗位很多人看到第一反应是是不是要熟背H.264标准文档、是不是得把FFmpeg源码倒背如流——说实话笔试真题出来以后你会发现它考的东西和三年前的背八股完全不是一回事。这个岗位考的是你能不能真正看懂一条视频码流能不能在代码层面和编解码标准之间来回切换。笔试考点覆盖C/C基础、H.264码流结构、编解码原理、多线程与内存管理、FFmpeg工具链等多个维度。适合正在准备音视频岗位校招的同学、刚转行进入流媒体领域的开发者以及想系统梳理编解码知识体系的人。这篇文章我会把笔试背后的考察逻辑、核心知识点逐一拆开再结合真实解码场景聊清楚考这些到底有什么用。1. 内容整体设计与思路拆解先说一个很多人没意识到的问题网易在当时国内互联网公司里算是比较早大规模落地视频相关业务的公司之一。云音乐有MV和直播严选有商品视频新闻客户端有信息流视频CC直播更不用说游戏事业部还有大量的游戏录屏和实时对战画面传输。这么多业务线摆在那里视频编解码开发实习生不是招来研究算法发paper的是招来写解码器集成、做转码服务、排查各种花屏绿屏卡顿问题的。所以笔试的题目设计有一个非常明确的导向考你在真实工程链路里最常碰到的技术点。这也就解释了为什么那张卷子里会出现大量C指针、内存布局、位操作、多线程同步相关的题目而不是单纯问你H.265比H.264压缩率提升多少这种概念题。1.1 这个岗位笔试的本质考动手前的眼光我见过很多准备校招的同学复习视频编解码就是拿一本《新一代视频压缩编码标准——H.264/AVC》从头啃把帧内预测、帧间预测、环路滤波、熵编码的概念背得滚瓜烂熟。但一拿到笔试题看到给一段二进制数据写出解析SPS中宽高的过程人就懵了。原因很简单从原理到码流中间隔着一层工程落地。标准文档告诉你pic_width_in_mbs_minus1是一个无符号指数哥伦布编码的语法元素但笔试考的是你知不知道在代码里怎么逐bit读出来、怎么处理字节对齐、怎么判断读到的是不是有效数据。这不是背概念能解决的需要真正写过码流解析代码或者至少认认真真读过FFmpeg里h264_parse.c这类文件。网易在2018年那个时间点考这些本质上是想筛掉只看过书的候选人留下能直接上手干活的人。视频编解码开发本身就是个工程属性极强的方向笔试只是把工程能力中最为核心的几个维度拆成了题目。1.2 从岗位JD反向推导考察范围把当年这个实习岗位的JD拆开来看基本要求是熟悉C/C了解H.264/H.265等视频编码标准熟悉FFmpeg/GStreamer等开源框架有音视频开发经验者优先。这几句话翻译成笔试考点就变成了下面这张对照表JD关键词笔试实际考察点出题形式熟悉C/C指针、内存布局、位操作、字节序代码阅读、输出结果题了解H.264/H.265码流结构、NAL单元、SPS/PPS解析给定二进制数据解析字段熟悉FFmpeg音视频解码基本流程、数据结构关系代码流程填空、API理解多线程/性能优化解码线程模型、帧缓存管理、并发冲突多线程编程题、死锁分析这里最容易被忽略的是第一行C/C基础。很多准备音视频岗的同学把大量时间花在看H.266/VVC的新特性上结果笔试第一道大题竟然是考memcpy和指针偏移。这不是出题老师在为难你而是因为视频编解码开发80%的日常都是在跟内存和二进制打交道。2. 核心细节解析与实操要点进到具体的知识点。我把当年笔试涉及的核心内容分成五个模块每个模块说明考点是什么、为什么考、怎么准备才有效。2.1 C/C与位操作解码器生存的第一技能视频编解码里有一类操作无处不在从一个连续的字节流里精确读出若干个bit。H.264的语法元素绝大部分都不是按字节对齐的比如SPS里的profile_idc占8bit但下一个字段就可能是连续的变长编码跨字节跨bit是常态。笔试里常考的Exp-Golomb指数哥伦布解码就是一个典型。标准里定义了解码过程读入连续的0直到遇到第一个1记0的个数为leadingZeroBits然后读取leadingZeroBits个bit作为后缀信息最终codeNum 2^leadingZeroBits - 1 后缀的值。这个逻辑本身不复杂但放到C/C代码里要写对就得考虑字节指针怎么移动、位缓冲区怎么维护、边界条件怎么处理。我当时自己练习时写过一个很小的解码头核心代码大概长这样// 从缓冲区中读取nbitsbs-p是当前字节指针bs-i_left是当前字节内剩余bit数 uint32_t bs_read_ue(bs_t* bs) { int32_t leading_zero_bits -1; for (int32_t b 0; !b; leading_zero_bits) { b bs_read_1(bs); } uint32_t suffix bs_read_bits(bs, leading_zero_bits); return (uint32_t)((1 leading_zero_bits) - 1 suffix); }这道题看起来简单但坑特别多。比如1 leading_zero_bits当leading_zero_bits等于32时是未定义行为标准里语法元素最大也就31位但你写代码的时候必须考虑这个边界。再比如位缓冲区的字节序Annex B格式的H.264裸流是big-endian逐bit读取的和x86机器的小端存储正好相反处理不好读出来的值全部是反的。注意做位操作题目的时候一定先画一张bit分布图再动手写代码。很多笔试题考察的不是你会不会位运算而是你能不能准确理解从第几个bit开始读、连续读几位、读出来的值落在什么范围。2.2 H.264码流结构与NAL单元视频开发者的通用语言H.264码流有一个分层结构视频编码层VCL负责存实际的图像数据网络抽象层NAL负责把数据打包成适合传输和存储的单元。笔试里常考的NAL头就是每个NAL单元开头的那个字节结构如下bit7forbidden_zero_bit必须为0bit6-5nal_ref_idc表示是否被其他帧参考非0表示可能被参考bit4-0nal_unit_type表示NAL单元类型nal_unit_type有几十种取值但对开发来说最核心的几个必须烂熟于心1表示非IDR的slice5表示IDR切片7表示SPS8表示PPS6表示SEI9表示AUD。笔试如果给你一个二进制流让你判断这个位置是不是关键帧本质就是让你检查当前slice是不是类型5。SPS的解析是笔试另一个高频考点。SPS里头有大量视频核心信息包括profile_idc、level_idc、pic_width_in_mbs_minus1、pic_height_in_map_units_minus1、frame_mbs_only_flag等。实际画面分辨率不是直接存进去的需要通过公式计算宽度 (pic_width_in_mbs_minus1 1) * 16高度需要结合frame_mbs_only_flag做二次换算。考这个知识点的时候出题人常会给出一段SPS的十六进制字节让你手算出分辨率。我自己在真实开发中有一次排查一个视频播放黑屏问题用码流分析工具切出来SPS一看分辨率算出来是1920x1088不是1920x1080。这就是因为某些编码器会把高度按宏块16对齐多出来的8行是padding。如果不懂SPS解析的细节对着日志看半天也不知道问题出在哪。2.3 变换、量化与熵编码理解压缩的定价逻辑这一部分偏向编码原理笔试通常不会要求你手推DCT公式但会从理解原理如何影响工程决策的角度出题。比如变换编码的核心思想把图像从像素域变换到频域能量集中到低频系数上高频系数大多接近0然后通过量化把这些接近0的系数置为0实现压缩。H.264用的是4x4整数变换是对DCT的整数近似好处是解码端和编码端不会因为浮点精度问题出现失配。笔试如果问为什么视频编码标准用整数变换而不是浮点DCT答案就是在不同实现之间保证一致性。量化是压缩率与画质的核心权衡点。H.264的量化参数QP范围是0到51QP越大量化步长越大压缩率越高但画质损失也越明显。有个经验关系QP每增加6量化步长大约翻一倍对应码率大约下降一半。笔试里可能给你一个QP变化让你推断码率和画质的大致变化方向这种题不需要精确计算但需要理解这层单调关系。熵编码部分CAVLC和CABAC是H.264的两种主要方案。CABAC压缩率比CAVLC高大约10%到15%但计算复杂度更高。笔试常考的是什么时候选用哪种这类工程判断题低延迟实时通信场景往往选CAVLC或对CABAC做简化离线转码追求高压缩率则选CABAC。2.4 内存管理、多线程与并行解码大型解码器的骨架视频解码器的复杂度不仅来自码流解析更来自对大量帧数据的组织和管理。一个1080p的YUV420帧原始数据大约是192010801.5字节约3MB。一个解码器要同时维护当前解码帧、参考帧列表、输出帧队列内存分配和释放的频率非常高。如果每次解码一帧就malloc一块3MB内存性能会非常难看。所以主流的解码器实现都会引入帧池frame pool机制初始化时一次性分配一批帧缓冲区解码过程中循环复用通过引用计数管理生命周期。网上的笔试题目很可能不会直接考帧池怎么设计但会考线程同步、共享数据访问这类底层问题。比如解码线程和渲染线程共享帧数据时怎么避免一边在写一边在读参考帧列表在解码过程中会被不断修改多个线程同时访问怎么保证安全一个生产者消费者模型里怎么设计缓冲区才能既不丢帧又不同步阻塞这些问题背后的工程思路和帧池、DPB解码图像缓冲区管理的逻辑完全一致。所以准备笔试的时候别光看视频编码标准把操作系统课本里的信号量、互斥锁、条件变量翻出来复习一遍作用非常大。2.5 FFmpeg与开源工具链不会用框架等于白学FFmpeg在音视频开发中的地位相当于OpenCV在图像处理领域中的地位。笔试即使不直接考FFmpeg API的拼写也大概率会给你一段代码让你分析av_read_frame、avcodec_send_packet、avcodec_receive_frame这三个函数组成的解码循环。理解FFmpeg的解码流程核心是记住几个关键结构体之间的层级关系AVFormatContext描述封装格式上下文AVCodecContext描述解码器上下文AVPacket存压缩数据AVFrame存解码后的原始数据。经典解码循环大致是avformat_open_input(fmt_ctx, filename, NULL, NULL); avformat_find_stream_info(fmt_ctx, NULL); for (int i 0; i fmt_ctx-nb_streams; i) { if (fmt_ctx-streams[i]-codecpar-codec_type AVMEDIA_TYPE_VIDEO) { video_stream_index i; break; } } avcodec_open2(codec_ctx, codec, NULL); while (av_read_frame(fmt_ctx, pkt) 0) { if (pkt-stream_index video_stream_index) { avcodec_send_packet(codec_ctx, pkt); while (avcodec_receive_frame(codec_ctx, frame) 0) { // 拿到一帧yuv数据 } } av_packet_unref(pkt); }为什么从FFmpeg 4.x开始官方推荐send_packet/receive_frame这种异步接口而不是老的decode直接调用因为这个接口设计把喂数据和取数据解耦了调用方不需要关心解码器内部是否有延迟帧、是否有多帧缓存只需要保持循环。笔试如果让你评价两种接口的优劣抓住这个点就能说出工程师真正关心的东西。3. 实操过程与核心环节实现把笔试知识转化为解码实战笔试只是门槛真正入职以后你会发现面试时候问的那些知识点会以非常具体的方式出现在你的工作里。我按自己踩过的坑梳理从拿到码流到排查出问题的完整链路你看完就知道准备笔试的时候该往哪个方向使劲。3.1 拿到一个H.264裸流第一件事做什么假设你现在接手一个任务某个视频文件在App里播放花屏需要定位是编码器的问题还是播放器的问题。第一步不是打开代码而是用工具把码流结构看清楚。命令行下用ffprobe就能拿到底层信息ffprobe -show_streams -select_streams v -print_format json input.mp4这条命令会输出视频流的编码格式、分辨率、帧率、profile、level、码率等信息。如果输出里显示codec_name是h264profile是Highlevel是40说明这是H.264 High Profile Level 4.0的流最大支持1080p30fps级别的解码。如果播放器宣称只支持Main Profile那这个流花屏就丝毫不奇怪了。拿到这些信息后再进一步看关键帧分布ffprobe -show_frames -select_streams v -print_format json input.mp4 | grep -E pict_type|key_frame | head -40这条命令输出每一帧的编码类型I帧、P帧、B帧的排列情况一目了然。如果发现长时间没有I帧或者两个IDR之间的间隔过大那么拖动进度条时就会出现长时间黑屏或花屏。这种问题如果不通过工具看码流靠肉眼盯播放画面是很难定位的。3.2 手工解析SPS从字节流里还原视频参数笔试考SPS解析很多人觉得是偏题。但实际写转码服务的时候你经常需要在不解码的情况下只读几个字节就知道这个视频的分辨率、帧率、profile。比如服务端要做按分辨率分发的逻辑先读SPS判断是高清还是标清决定走哪条转码链路。从Annex B格式的H.264裸流中提取SPS通常先搜索起始码00 00 00 01或者00 00 01然后检查NAL头字节如果低5位等于7说明后面跟的就是SPS。SPS的RBSP语法元素里第4个字节开始有profile_idc随后是constraint_set flags和level_idc。在实际解析过程中得处理那些在起始码之后可能出现的emulation prevention bytes0x03不然读出来的数据会错位。这里给出一个非常精简的定位SPS的步骤逐字节扫描码流找到00 00 01或00 00 00 01起始码读取起始码后的第一个字节转成二进制看低5位是否等于7如果等于7记录当前位置SPS的NAL单元从起始码之后开始根据NAL头长度字段如果是AVCC格式的话跳到下一个起始码SPS结束对中间的数据做去emulation prevention处理然后按SPS的语法表逐字段解析。这个过程中最容易出的bug是混淆Annex B和AVCC两种封装格式。Annex B用起始码分割NAL单元MP4的avcC box则用4字节长度字段分割。很多从MP4里提取H.264裸流的工具如果没做格式转换直接拿avcC格式的数据送到只认Annex B的解码器里就会出现SPS解析失败、解码器初始化报错。笔试如果考AVCC和Annex B的区别本质上就是问你能不能安全地在两种封装格式间切换。3.3 自己动手实现一个极简H.264解码练习很多人问我想入行视频编解码要不要自己从头写一个解码器我的观点非常明确不要从零写完整的H.264解码器那个工作量太大但一定要自己写一个能解析码流结构和SPS/PPS的工具。为什么强调这个度完整解码器涉及帧内预测、帧间运动补偿、环路滤波、CABAC/CAVLC全部模块没有两三个月拿不下来而且写出来的东西和x264、FFmpeg的成熟实现差距巨大工程上没有任何复用价值。但码流解析不一样它代码量不大却能逼你把NAL结构、Exp-Golomb、SPS语法这些笔试核心考点全部过一遍。我自己带过几个实习生给他们布置过一个小练习写一个命令行工具输入是H.264裸流文件输出是每一个NAL单元的类型、大小、关键帧位置、分辨率、帧率。这个任务大概花一到两周能完成完成后对码流的理解深度比啃三遍标准文档都管用。下面是解析NAL类型的一个极简代码片段#include stdio.h #include stdint.h int main(int argc, char* argv[]) { FILE* fp fopen(argv[1], rb); uint8_t buf[4] {0}; uint8_t nal_header; while (fread(buf, 1, 4, fp) 4) { // 查找起始码 if (buf[0] 0 buf[1] 0 buf[2] 1) { nal_header buf[3]; } else if (buf[0] 0 buf[1] 0 buf[2] 0 buf[3] 1) { fread(nal_header, 1, 1, fp); } else { continue; } int nal_type nal_header 0x1F; printf(NAL type: %d\n, nal_type); // 根据nal_type输出对应含义 } fclose(fp); return 0; }这只是一个非常粗糙的示意代码真实场景还需要处理多NAL单元聚合、字节流跨边界等情况但作为练习起步已经够了。做完这个练习你再回头做笔试题里的SPS解析题会发现手到擒来。3.4 从软解到硬解RK3588这类平台的解码开发思路笔试里不太会直接考某个芯片平台的API但视频编解码开发的工作内容里硬解是绕不开的。在RK3588这类带硬件编解码模块的平台上做开发核心逻辑通常是用V4L2或厂商私有接口打开硬件解码器把H.264/H.265的码流数据通过内存缓冲交给硬件解码模块硬件解码完成后输出YUV帧再走渲染或者后处理。实用经验是从软件解码切换到硬件解码时必须处理好几个问题输入格式硬件解码器对NAL单元的封装格式有严格约定通常要求Annex B格式MP4的avcC格式要先转换帧率控制硬解本身不负责帧率控制解码速度可能比实时快好几倍需要由上层根据PTS控制输出节奏内存对齐硬件解码器输出的YUV数据在宽高、stride上有对齐要求比如16或64字节对齐直接用原始分辨率去算行字节数会出错参考帧管理硬件解码模块内部会维护DPB但外部每次要保证输入帧的序号正确乱序输入会引发解码错误。这些经验是笔试和面试之间最后一公里的桥梁。笔试考你对解码原理的理解硬解开发则考你把原理落到具体平台上的能力。3.5 用FFmpeg命令行快速排查问题的几个组合拳当年笔试也有不少FFmpeg相关的选择题而真到了工作中命令行工具是最常被调用的调试手段。我把自己常用的几条命令分享出来属于高频使用场景# 查看视频流详细信息 ffprobe -v error -show_streams -select_streams v -show_entries streamcodec_name,width,height,r_frame_rate,avg_frame_rate,pix_fmt,profile,level input.mp4 # 提取某个时间段内的裸流便于分析 ffmpeg -i input.mp4 -ss 00:01:00 -t 00:00:10 -vcodec copy output.h264 # 查看每一帧的编码类型和大小 ffprobe -v error -select_streams v -show_frames -show_entries framepict_type,pkt_size input.mp4 # 把视频转成yuv原始数据供手工分析 ffmpeg -i input.mp4 -vcodec rawvideo -pix_fmt yuv420p output.yuv遇到解码报错时最实用的是加-loglevel debug参数跑一遍FFmpegffmpeg -v debug -i broken.mp4 -f null - 21 | grep -i h264日志里会打出每个NAL单元的处理情况哪一帧解析失败、哪里的比特流有误都能看出来。这条命令我调试视频文件时几乎必用比拿播放器反复播效率高得多。4. 常见问题与排查技巧实录准备这类笔试最容易踩的坑每年都有大量候选人挂在同一个地方不是不会而是练的方向偏了。下面这些坑是我在面试别人和实际工作中反复看到的整理成速查表你对照着自查。4.1 只背编码原理从不写码流解析代码典型表现后果正确做法能说出H.264的帧内预测有几种模式写不出从码流中解析出帧内预测模式的代码动手实现NAL单元解析和SPS读取知道CABAC比CAVLC压缩率高不理解为什么实时场景有时反而选CAVLC用FFmpeg分别跑两种熵编码对比耗时和码率能默写DPB管理流程笔试考多线程缓存管理还是懵自己实现一个简单的帧缓存队列加锁保护视频编解码开发本质上是一个二进制世界的活。所有高级概念最终都要落到从哪个bit开始读、读几位、怎么换算这一层。只看书不写码等于学游泳只看教学视频不下水。4.2 只跟FFmpeg命令不读源码FFmpeg的命令行确实很强大但如果你只停留在会用命令转格式的层面笔试题里稍微一深挖就会露馅。比如问你avcodec_receive_frame返回EAGAIN是什么意思如果你没读过源码或者没实际处理过这个返回值很可能回答成出错了但真实含义是解码器内部还没有完整的帧可以输出需要继续喂数据。这个区别就是用过和理解的差别。面试官看一眼你对这个错误码的解释就知道你是真的写过解码循环还是只在网上看过示例代码。建议抽个周末把FFmpeg的doc/examples/decode_video.c从头到尾读一遍每行都搞清楚在干什么收获会非常大。4.3 忽略封装格式只知道裸流很多准备笔试的人把大量时间花在H.264和H.265标准上对MP4、FLV、TS这些封装格式完全没概念。但实际开发中我们拿到手的视频90%以上都是带封装格式的文件。MP4的avcC box里有SPS和PPSFLV的VideoTagHeader里有CodecID和AVCPacketTypeTS流里有PES和PSI。如果笔试给你一个TS流文件问你如何定位到一个I帧你需要同时理解TS的包结构和H.264的NAL结构才能答对。封装格式这块至少掌握到给你一个MP4文件能说清楚moov box和mdat box的关系以及如何从moov中找到每个sample的偏移量这个程度就算过关。4.4 不重视代码输出结果的规范性笔试里有一种题很阴给你一段C代码让你写出输出。这种题在视频编解码岗位的笔试里出现频率极高而且坑很多。比如char buf[8]; uint32_t val 0x01020304; memcpy(buf, val, 4); printf(%02x %02x %02x %02x\n, buf[0] 0xff, buf[1] 0xff, buf[2] 0xff, buf[3] 0xff);在x86小端机器上输出是04 03 02 01。备考的时候很多人压根没想过字节序的问题看到这种题直接按大端顺序写了01 02 03 04白白丢分。视频编解码和字节序强相关因为码流标准里定义了bit传输顺序但不同的实现和平台又有各自的存储顺序偏好。建议做题前养成一个习惯凡是涉及多字节整数和bit级读取的先明确自己是按大端还是小端处理。4.5 准备笔试的实用清单与节奏建议结合我自己带人、面试和当年备考的经验给出一份实操清单按优先级排序用一周时间读懂FFmpeg的解码流程把decode_video.c的每一行注释掉并重新自己写一遍实现一个H.264裸流NAL解析工具输出每个NAL的类型、大小、偏移用真实视频文件验证手动解析至少三个真实H.264视频的SPS把profile、level、分辨率、帧率算出来用ffprobe的输出做对照刷C指针、内存、位操作、多线程相关的笔试题重点看字节序和结构体内存对齐的题目练习用ffmpeg和ffprobe命令排查一个给定的损坏视频文件形成自己的调试方法清单如果有余力读一下H.265的VPS/SPS/PPS结构和H.264的差异作为加分点。这套流程下来视频编解码笔试里90%的考点都能覆盖到而且每项练习的产出都可以写进简历比单纯写熟悉视频编解码有说服力得多。最后再分享一个我实际用的学习技巧平时看视频的时候养成打开播放器统计信息的习惯。暴风影音的CtrlJ、VLC的CtrlI、mpv的ShiftI都能看到当前视频的编码格式、分辨率、帧率、码率信息。看到这些参数后想一下如果我现在要解析这个文件的SPS会从哪里找到这些字段。把这个习惯保持一个月你对音视频参数的敏感度会明显超过那些只在书本上见过这些概念的人。我在实际面试过不少候选人之后最大的感受是视频编解码这个方向门槛不在难而在杂。知识链条特别长从C/C、操作系统、网络协议到编码标准、封装格式、开源框架哪一环断了都会出问题。笔试只是第一次过滤真正想在这个方向走远把上面这些基本功打扎实比追任何新概念都重要。
