Gstreamer 切换问题分析

gstreamer linux gtk glibc

目标

降低或去除 pipline 中 element 切换的延迟时间。

分析

刚翻过 Basic Tutorial 了解有限。

计量参考

现有延迟时间的计量方法，可能产生不同的结果。如果存在偏差，更可能是基准上有区别，相对延迟量一致。

可能的计量起点：

• GST_MESSAGE_STREAM_EOS

可能的计量终点：

• GST_MESSAGE_STREAM_START

理想结果的资源需求

追求段落切换的时间片内，输出画面的连续性为目标。

集中考虑 sink -> demuxer -> decoder -> resizer 的段落。

• resizer 的尺寸切换大概不会增加多少时间。暂不考虑。
• decoder 的切换意味着，同时至少需要两个 decoder 资源。
• demuxer 与上游，更可能是 ARM 核的通用处理，调整容易应已解决。暂不考虑。

需要集中关注 decoder -> resizer 的段落，更关注 decoder 环节。

在 ARM 核上，图像帧 Buffer 是否 a)可直接管理 b)可直接编辑 将对这里的资源需求有决定性影响。

decoder

对 decoder 来说，开始输入流，到拿到第一个正确配置了属性的图像 Buffer 必然有个 gap 。这个时间片应被纳入计量。

追求画面连续性，就是要保证下游 pipeline 的 Buffer 连续流动。

在 decoder -> resizer 环节，切换的时候就要提前准备 decoder' 的数据。

• 如果考虑动态做这个事情，考虑在中间加个 queue 分离线程可能容易些。
  
  • 进而，实现个 multiqueue 或许更加方便。
• decoder 可以出第一个 Buffer 这个事件应该很有用。或者找到可以准确预期它的事件也许可以代替。

其它可能需要注意的地方

• 监控切换前片段的播放剩余时间，以便提前准备 decoder' 模块。

  • 即使不是动态调整 pipeline 也需要这个。
  • 静态的方式，提前确认准备过程需要多长时间。

• 看看有没有 playlist 类的 element ，可能有帮助。

• request pad 的存在性证明 pipeline 大概率是可以动态调整的。只是可能需要一个类似 queue 之类的 element 隔离它们。

• 动态管理通过 queue 分开的各个线程时，注意对齐时钟。