Python小恐龙快跑：PyGame游戏开发与有限状态机实战
2026/10/20 18:27:03
3D 视频怎么拍和怎么存
3D 视频的文件不是简单“多一张图”。它要保存同一时刻的左右视图，还要让播放器知道这两路图如何同步、如何排序、如何送到对应眼睛。
先看采集链路
这张图把 3D 视频从采集到显示串起来：采集阶段得到左右视图，编码/封装阶段保存排布或多视图关系，显示阶段再把左图只送左眼、右图只送右眼。
1. 3D 采集采的不是“两段视频”
3D 采集真正要拿到的是同一时刻、同一场景、几何可校正的两个视图。
| 数据 | 含义 | 为什么重要 |
|---|---|---|
| left view | 左视角画面 | 显示时送左眼 |
| right view | 右视角画面 | 显示时送右眼 |
| capture timestamp | 左右帧采集时刻 | 保证运动一致 |
| camera intrinsics | 焦距、主点、畸变 | 做左右画面校正 |
| camera extrinsics | 两相机相对位置和旋转 | 决定视差几何 |
| baseline | 左右相机间距 | 决定深度强度 |
| exposure / WB | 曝光和白平衡 | 保证两眼亮度和颜色一致 |
普通双机位“同时拍”不一定能做高质量 3D。没有硬件同步、没有标定、没有颜色匹配，后期会很痛苦。
2. 双相机为什么需要校正
两台相机不可能天然完全平行、同焦距、同畸变。3D 制作通常需要 rectification，把左右图校正到同一极线几何。
| 校正对象 | 目的 | 不处理的结果 |
|---|---|---|
| 畸变 | 去掉镜头边缘弯曲 | 左右眼边缘对不上 |
| 旋转 | 对齐左右相机姿态 | 出现垂直视差 |
| 焦距 | 统一投影尺度 | 一边大一边小 |
| 主点 | 对齐图像中心 | 深度分布偏移 |
| 颜色 | 匹配亮度和白平衡 | 两眼颜色不一致 |
| 时间 | 对齐帧时刻 | 运动物体错位 |
3D 里垂直视差比水平视差更危险，因为水平视差是深度来源，垂直视差基本只会增加融合负担。
3. 采集方式不止双相机
| 方式 | 采集形态 | 优点 | 风险 |
|---|---|---|---|
| 双相机 rig | 两台相机同步拍左右眼 | 质量上限高、基线可控 | 同步、标定、体积复杂 |
| 单机双镜头 | 一个设备集成双镜头 | 便携、厂商可统一标定 | 基线固定，创作自由度低 |
| 多相机阵列 | 多视角同时采集 | 可做多视点/光场 | 数据量和拼接复杂 |
| 2D 转 3D | 单目估深度再生成另一眼 | 可处理老片源 | 遮挡边缘、透明物体难处理 |
| 引擎双相机 | 3D 场景实时渲染左右眼 | 几何和同步完全可控 | 需要正确设置眼距和投影 |
2D 转 3D 的问题不在“能不能生成另一眼”，而在遮挡区域原本不存在信息。算法只能补，不能真正恢复被挡住的内容。
4. 文件怎么保存左右眼
4.1 Frame-compatible：拼成一个普通视频帧
这种方式兼容性好，很多播放器即使不懂 3D，也能把它当普通视频播出来。
| 排布 | 保存方式 | 单眼分辨率影响 | 播放器要知道什么 |
|---|---|---|---|
| SBS | 左右并排 | half-SBS 会损失水平分辨率 | 左右半区和 eye order |
| TB / OU | 上下排列 | half-TB 会损失垂直分辨率 | 上下半区和 eye order |
| checkerboard | 棋盘格交错 | 依赖显示设备还原 | 像素交错规则 |
| line interleaved | 行交错 | 垂直分辨率受影响 | 奇偶行对应哪只眼 |
| anaglyph | 颜色通道混合 | 色彩损失明显 | 眼镜颜色过滤规则 |
Frame-compatible 的核心缺点是：容器和 decoder 可能不知道它是 3D，renderer 必须靠 metadata、文件名规则或用户配置来识别。
4.2 Multi-view：编码层显式保存多视图
| 技术 | 所属体系 | 核心思想 | 工程门槛 |
|---|---|---|---|
| MVC | H.264 扩展 | base view + dependent view | 蓝光 3D 常见，移动端支持有限 |
| MV-HEVC | HEVC 扩展 | 多视图/多层编码 | 新设备和平台才更常见 |
| stereo pair tracks | 容器多轨 | 左右眼各一条轨道 | 同步和播放器支持要求高 |
| spatial video | 平台封装约定 | HEVC 多视图 + 元数据 | 依赖平台生态 |
多视图编码的优势是压缩效率和语义更清晰；问题是硬解、封装、编辑工具和播放器都要支持。
5. 编码时怎么处理左右眼
3D 编码不是把两路独立编码完事。更好的做法会利用左右眼相似性。
| 编码策略 | 说明 | 取舍 |
|---|---|---|
| independent encode | 左右眼各自编码 | 简单但码率高 |
| frame-compatible encode | 拼成一帧后按 2D 编码 | 兼容好但单眼分辨率受损 |
| inter-view prediction | 右眼参考左眼 | 压缩效率高但解码依赖更复杂 |
| asymmetric quality | 一眼质量略低 | 节省码率但可能引起视觉不适 |
| shared GOP | 左右眼关键帧对齐 | seek 和同步更稳定 |
实际工程里，左右眼 GOP、时间戳、关键帧位置最好保持一致，否则 seek、丢帧和恢复会非常麻烦。
6. 文件里必须留下哪些信息
| 信息 | 谁使用 | 用途 |
|---|---|---|
| stereo layout | renderer | 判断 SBS / TB / 多轨 / 多视图 |
| eye order | renderer / display | 判断哪路是左眼 |
| view count | demuxer / decoder | 多视图解码时知道视图数量 |
| view dependency | decoder | MVC / MV-HEVC 解析视图参考关系 |
| baseline / disparity hints | renderer / player | 舒适度策略、字幕深度参考 |
| projection | renderer | 立体 360 时还要知道球面投影 |
| color metadata | renderer | 左右眼颜色一致性 |
| timestamps | demuxer / decoder / renderer | 左右眼同步和 A/V sync |
如果这些信息缺失，用户常看到的不是报错，而是“并排两张图”“深度反了”“头晕但不知道为什么”。
7. 解码时用什么，显示时用什么
| 信息 | 解码阶段 | 显示阶段 |
|---|---|---|
| codec type | 选择普通解码器或多视图解码器 | 通常不直接用 |
| extradata | 初始化解码器，解析 profile / view info | 可能用于能力判断 |
| packet DTS | 决定输入顺序 | 间接影响队列 |
| frame PTS | 输出帧时间 | 左右眼同步显示 |
| stereo layout | 普通 SBS/TB 解码器可能不用 | 必须用于采样区域 |
| eye order | 不参与解码 | 必须用于左右眼分发 |
| view dependency | 多视图解码必须用 | 不直接用 |
| display device | 不参与解码 | 决定分眼输出格式 |
一句话总结
3D 视频文件的难点不是“多存一张图”，而是把左右视图的时间、几何、编码依赖和显示语义完整保存下来，并让每一层只消费自己该消费的信息。