debug

d2201 debug codec video decoder

Video Decode and Output

present

loop:
    if nng_recv_queue.empty():
        continue
    pkt = nng_recv_queue.pop()
    ... some pts manner and maybe delay ...
    decoder_write(pkt)
    free(pkt)

to-be

pkt = NULL
pts_next = 0
pts_last = 0
while RUNNING:
    if pkt:
        // fps control
        local pts_this = pkt.pts
        local pts_step = pts_this - pts_last
        pts_step -= 1ms
        if pts_step > const_window_size:
            pts_next = get_now() - pts_step / 4
        local pts_delta = get_now() - pts_next
        while pts_delta > const_min_delay:
            if not RUNNING:
                ... force quit ...
            else if pts_delta > const_window_size:
                pts_next = get_now() - pts_step / 4
            else:
                ... short sleep, maybe 10 ms ...
            pts_delta = get_now() - pts_next
        pts_next += pts_step
        pts_last = pts_this
        decoder_write(pkt)
        free(pkt)
        continue
    if nng_recv_queue.empty():
        sleep 10 ms
        continue
    pkt = nng_recv_queue.pop()
if pkt:
    free(pkt)

原理要点

• 编码侧时间戳用 this - step = last 表征，解码侧用 now() - next = delta 控制。如果处于 $[0,{\tt min\_delay}]$ 就送解，否则等待。
• 强制同步，即重设 next ，条件为：
  
  1. 第 11 行，step 超限。比如初始化或中间网络断流一段时间。
  2. 第 17 行，delta 超限。比如进程挂起一段时间后继续运行。
• 第 10 行，强制减小一点 step ，以避免设备间时钟差异导致延迟。

可能的缺陷

需要稳定的帧间时间

如果编码帧时间戳按时间顺序分别是 $$t_{k-1},~t_k,~t_{k+1},~...$$ 此时，令 $$\begin{align*}d_k &= t_k - t_{k-1}\\d_{k+1} &= t_{k+1} - t_k\end{align*}$$ 即：

$d_k$ 表示在播放第 $k$ 帧之前，应该等待多久。

$d_{k+1}$ 表示在播放第 $k+1$ 帧之前，应该等待多久。

然而算法中，使用 $d_k$ 拿来当作播放第 $k$ 帧后的等待时间。
这在 $d_n$ 序列产生较大突变的时候可能会引入问题。幸运的是编码侧帧率最终由硬件时钟驱动，稳定性不错。暂时应可无视此问题。