What is a proper way to synchronize non-reliable stream?

Zbigniew KempczyƄski wegorz76 at gmail.com
Fri Jun 10 05:33:06 UTC 2016


Hello.

I'm working with... gstreamer-0.10, please be forgiving, it doesn't depend
on me.

I'm working on solving problem in which input stream is not realiable, I
mean:
- Input data comes from network RTP server, it provides RTP / MPEG-TS
stream,
- RTP timestamps are continues in 90KHz but sometimes source (network RTP
server) decides to stop streaming for few seconds, then it starts again.
RTP timestamps seems to be stopped during this <stop - start>.
- Same situation is in MPEG-TS PTS fields, they are stopped during <stop -
start>. This leads to the situation when sinks drops packets (audio/video).
- As pipeline is in PLAYING state shift occurs between source and receiver.

What is a proper way to solve such kind of situation? I tested two ways
(both works, but I'm not convinced they are proper solutions):
- on demultiplexer pads (audio / video) using gst_pad_add_buffer_probe
there's a callback which probes buffer timestamps, when I detect too much
shift (for example my running time is 00:10:00.000 and buffer timestamp is
00:09:58.000) I'm performing:
a) recalculating base time and redistribute it to sinks (base time = now()
- buffer timestamp + some delay [unfortunatelly arbitrary value, I've no
idea how to properly calculate it])
b) recalculating ts-offset and set them in sinks (ts offset = running_time
- buffer timestamp + some delay)

Would you be so kind and point me to the proper direction?

Thanks,
Zbigniew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160610/6572d7ff/attachment.html>


More information about the gstreamer-devel mailing list