DTS和PTS

一、先给最终结论（精确定义版）

送给 decoder 的数据：

• 输入顺序 = 编码顺序（decode order）

• 每个 access unit 携带的是 PTS（显示时间）

decoder 内部：

• 根据 bitstream（slice / reference / DPB）做 frame reorder

decoder 输出：

• 输出顺序 = 显示顺序（presentation order）

• 输出的 timestamp = 原来就带着的那个 PTS

不存在“把 DTS 转成 PTS”的过程
PTS 从来没有在 decoder 内部被计算或修改

---

二、你这句话哪里“对”，哪里“需要校正”

你说的是：

送给 decoder 的时候是按编码顺序给的（DTS）

✔ 对的部分

• 输入顺序确实是 decode order

• 对于含 B 帧的 H.264/H.265：

  • demuxer 会按 decode order 喂给 decoder

• 这是 decoder 能正常工作的前提

---

需要校正的部分

（DTS）

Android 并没有把 DTS 显式传给 decoder。

更准确的说法应该是：

送给 decoder 的是“按 DTS 排列的数据”，但携带的是 PTS

这是一个非常容易混淆、但必须区分的点。

---

三、用一个具体例子拆开（H.264 有 B 帧）

假设编码结构

显示顺序（PTS）：

I0   B1   B2   P3

解码顺序（DTS）：

I0   P3   B1   B2

Demux → Decoder 输入

输入顺序	AU 内容	携带时间戳
1	I0	PTS=0
2	P3	PTS=3
3	B1	PTS=1
4	B2	PTS=2

注意：

• 顺序 = decode order

• 时间戳 = display time

---

Decoder 内部

• 解码 I0、P3 后，reference frame ready

• B1 / B2 decode 完成

• 内部 DPB 决定哪些 frame 可以输出

---

Decoder 输出

输出顺序	Frame	PTS
1	I0	0
2	B1	1
3	B2	2
4	P3	3

PTS 从头到尾没有被修改过

四、为什么你会自然地说“按 DTS 给 decoder”？

因为在概念模型里：

• decode order ≈ DTS order

• display order ≈ PTS order

但在 Android Framework 的实现里：

• DTS 只是“排序依据”

• PTS 才是“携带的数据”

DTS 是“隐含信息”，PTS 是“显式字段”

---

五、对应到 Android / Codec2 的真实字段

Codec2

C2Work {
    input.buffers[]
    input.ordinal.timestamp  // PTS (us)
}

• 没有 DTS 字段

• reorder 完全由 component 内部完成

OMX（老）

OMX_BUFFERHEADERTYPE {
    nTimeStamp  // PTS
}

同样：

• 没有 DTS

• 只有 PTS