STREAMER Synchronizing multiple sources to a common receiver
Locked
STREAMER Synchronizing multiple sources to a common receiver
 
|
Re: STREAMER Synchronizing multiple sources to a common receiver
|
|
On Sa, 2016-05-07 at 14:25 -0400, thiyagesh viswanathan wrote:
> > Questions I want to be answered: > 1.Is my pipeline structure correct? Yes, the properties on rtpbin not so much though. Use ntp-time-source=ntp (or unix). These two are going to use your system clock, the setting you used will use the pipeline clock. The pipeline clock is not going to be synchronized between all your devices. You might want to use rtcp-sync-send-time=false if both senders of you have different latencies (camera, encoder, etc). You might have to adjust the receiver pipeline latency to be high enough for both senders. See gst_pipeline_set_latency(). ntp-sync=true and buffer-mode=synced are correct for your case. Independent of that you need to ensure that RTCP between sender and receiver is actually working, and synchronization will only be correct after the first RTCP packet is received at the receiver. By default after about 5 seconds. It can happen immediately if you set rtp-profile=avpf on the rtpbin (well, not immediately but at some point in the first second). > 2.I am not modifying the pipeline clocks at all. Just assuming that > the pipeline clocks of senders and receivers will be If your system clocks are synchronized via NTP, then that's indeed not necessarily needed. > 3.synchronized once we sync the devices through NTP. Is this > assumption correct? > 4.Should I have just one rtpbin or separate rtpbin for each sender? You can have one rtpbin for multiple sessions, and those sessions are then all synced together. If you use multiple rtpbins instead, there won't be any inter-session synchronization happening inside rtpbin. > 5.Should i USE RTPJITTERBUFFER? if yes, should the mode be synced? rtpbin contains an rtpjitterbuffer already. Don't put a separate on into your pipeline, otherwise you have two and the behaviour is not very well then. Does this all work better then? What is the behaviour you're seeing now? Also does using one sender at a time result in smooth playback? -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
signature.asc (968 bytes)
Re: STREAMER Synchronizing multiple sources to a common receiver
|
|
Re: STREAMER Synchronizing multiple sources to a common receiver
|
|
On Mi, 2016-05-11 at 02:12 -0400, thiyagesh viswanathan wrote:
> Thank you for the quick response. I tested it out and it works very > well. Though there are little latency variations. It remains < 30 ms > most of the time.Though sometime it extends to more that 60 Frame > rate is 15). The video playback is smooth. I still have few > questions though, 66ms would be one frame in your framerate, so what you get there seems quite good already. You can get better than that, but going below 1 frame also requires good support from the display system and especially rendering the right frame properly synchronized to vsync. > 1.Will my situation improve even more if I sync pipeline clocks? Only if your NTP time synchronization is worse than that. You will have to measure it. And in general you will have to measure how accurate things are at the various steps (NTP synchronization, RTP timestamp to pipeline clock timestamps to system time, rendering of a frame until it gets on the screen, etc). > 2, Is there any way to calculate the relative latency between the > streams from both sources? I am assuming that I have to create my own > plugin. What methods does streamer allow to achieve what I want. Even > better if there is an existing plugin which I can study. The sinks of each pipeline query the latency with the LATENCY query, and those are the values you can use. For the *sender* latency of each individual sender. On top of that there is also the network and receiver latency of course. > 3. For the set_pipeline_latency() element, I just set the rtpbin > latency in my pipeline to 500 ms. Is that fine? I mean I am not using > c code for now. Just playing with the pipelines. As long as you don't want to get the "perfect" latency configuration all this is fine, yes. -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: STREAMER Synchronizing multiple sources to a common receiver
|
|
Re: STREAMER Synchronizing multiple sources to a common receiver
|
|
On Mon, 2016-11-28 at 07:20 -0800, LC wrote:
> This is quite relevant to my needs. > > It looks good enough to try. > > Actually, I need synchronization to ms of 10^3. > > Is it possible to achieve it by here described solution or i need > something more accurate like rfc7273-sync ? You can achieve ms-accurate synchronization in either case, RFC7273 just gives you a way of advertising which clocks are used and allows you to use them automatically without further configuration. There are also various other ways how you can achieve synchronization, it all depends on your setup. The accuracy however mostly depends on a) how accurate you can synchronize to a clock shared between the senders and receivers, and b) how accurate the capture time measurements are, and c) how well the latency of the different parts on the receiver are taken into account (e.g. if you have two different display paths, you will only get synchronization in the best case as good as the latency measurement error between the two). > And if i should use rfc7273-sync, how it changes the use of rtpbin. See my other reply to your other mail :) > Can i use the same session mechanism ? What session mechanism do you mean? -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: STREAMER Synchronizing multiple sources to a common receiver
|
|
Re: STREAMER Synchronizing multiple sources to a common receiver
|
|
| Free forum by Nabble | Edit this page |