Gstreamer多路流同步(翻译自part-synchronisation.txt) 该篇文档描述了gstreamer多路流的同步技术的概要。 GstPipeline的同步用如下的3个组件完成: 1)GstClock,在GstPipeline中对所有元素来说是全局的。 2)GstBuffer的Timestamps。 3)在发送buffer(数据流)之前的NEW_SEGMENT。 A GstClock ~~~~~~~~~~ GstClock单位是纳秒,一个计数器,描述了当前的时间,该值也是绝对时间。 如下的几个源可以提供时间计数器: 1)系统时间,微妙级的精度,用g_get_current_time函数获取。 2)音频设备(基于采样率)。 3)一个网络源,例如RTP源,RTP包中带有时间戳。 ...... 在Gstreamer中,任何元素提供的GstClock对象都可以用到pipeline中。GstPipeline对象将从时钟提供者中选择一个分发给所有其它的元素。 GstClock总是向上递增的,不一定要从0开始。 Running time ~~~~~~~~~~~~ 当pipeline选择了一个时钟,它将基于选定的时钟维护running_time,running_time表示处于PLAYING状态的总的时间,按照如下方式计算: 1)如果pipeline的状态是NULL/READY,running_time是未定义的。 2)在PAUSED状态,running_time保持在暂停的时间。如果pipeline是第一次暂停,running_time是0。 3)在PLAYING状态,running_time是absolute_time和base_time的差值。当处于PLAYING状态时, base_time = absolute_time - running_time。 4)在执行了flushing seek,running_time被设置成0,base_time被重新设置,相当于重新开始。 当pipeline从PLAYING -> PAUSED状态时,保存住running_time;当恢复成PLAYING状态时,重新开始计算running_time。当pipeline是 PAUSED状态时,不论选定时钟是否继续稳步增加,都不会影响到running_time的计算。 时钟和pipeline用running_time为所有的元素进行同步。在PLAYING状态下,running_time能够在每一个元素中被观察到,计算公式如下: C.running_time = absolute_time - base_time C.running_time也就是running_time,该值以时钟的速率单调递增。 Timestamps ~~~~~~~~~~ GstBuffer timestamps和在buffer(数据流)之前的NEW_SEGMENT event定义了一个转换从buffer timestamps到running_time,计算如下: 定义: B.running_time:running_time B: GstBuffer - B.timestamp:buffer timestamp (GST_BUFFER_TIMESTAMP) NS: NEWSEGMENT event - NS.start: start field in the NEWSEGMENT event - NS.stop: stop field in the NEWSEGMENT event - NS.rate: rate field of NEWSEGMENT event - NS.abs_rate: absolute value of rate field of NEWSEGMENT event - NS.time: time field in the NEWSEGMENT event - NS.accum: total accumulated time of all previous NEWSEGMENT events. This field is kept in the GstSegment structure. 满足B.timestamp >= NS.start && B.timestamp <= NS.stop的GstBuffer实例是有效的,在这个范围之外的其它buffer将被丢弃。 B.timestamp到B.running_time的转换公式如下: if (NS.rate > 0.0) B.running_time = (B.timestamp - NS.start) / NS.abs_rate + NS.accum else B.running_time = (NS.stop - B.timestamp) / NS.abs_rate + NS.accum 由于B.running_time就是running_time,所以running_time是从NEWSEGMENT event和buffer而来的。 所以根据第一个有效地buffer计算出来的running_time为0,既然B.timestamp == NS.start and NS.accum == 0。 Synchronisation ~~~~~~~~~~~~~~~ 我们可以用如下方法得到running_time: 1)用选定的时钟和元素的base_time: C.running_time = absolute_time - base_time 2)用buffer timestamp和之前的NEWSEGMENT event(假定播放速率为正): B.running_time = (B.timestamp - NS.start) / NS.abs_rate + NS.accum running_time的前缀C和B表示两种不同的计算方法。 同步播放就是要确保:当播放一个时间戳是B.running_time的buffer时,时钟必须达到了C.running_time,也就是说当: B.running_time = C.running_time时, 播放buffer里面的数据。因此可以扩展到如下的公式: B.running_time = absolute_time - base_time 或者 absolute_time = B.running_time + base_time 记B.sync_time为buffer应该被播放时的绝对时间,因此得到: B.sync_time = B.running_time + base_time 对于多路流来说,拥有同样的running_time的buffers将被同时播放。demuxer元素在它的所有的src pad上发送NEWSEGMENT消息来确保同步的buffer具有同样的时间戳。 Stream time ~~~~~~~~~~~ Stream time是流的位置,值介于0和媒体文件的长度(时间为单位)。有如下作用: 1)POSITION查询 2)seek事件中的position的设置 3)the position used to synchronize controller values 可以按照如下的方式来计算stream time,推导过程如下: C.running_time = absolute_time - base_time B.running_time = (B.timestamp - NS.start) / NS.abs_rate + NS.accum => (B.timestamp - NS.start) / NS.abs_rate + NS.accum = absolute_time - base_time; => (B.timestamp - NS.start) / NS.abs_rate = absolute_time - base_time - NS.accum; => (B.timestamp - NS.start) = (absolute_time - base_time - NS.accum) * NS.abs_rate 又因为 stream_time = (B.timestamp - NS.start) * NS.abs_applied_rate + NS.time => stream_time = (absolute_time - base_time - NS.accum) * NS.abs_rate * NS.abs_applied_rate + NS.time 最后得到的公式常被用来在sink元素中查询当前播放的位置。 需要注意的是:stream time从来没有参与多路流的时钟同步。 |
|