<div dir="ltr"><div><div>What is the resolution? At higher resolutions and/or encoding qualities the encoder/decoder may require multiple calls to pump out the frame. I assume that you are sticking with a simple base profile specifically to avoid B frames. (Bidirectional predictive B frames would require latency obviously). <br>
<br></div>To synchronize, you have to be at the mercy of the slowest stream. Of course MJPEG with it's every frame standing on it's own, would avoid the problem but have much higher bandwidth. <br><br></div><div>Other little things. The smaller the packet the lower the latency. Which is why transport streams have such tiny 188(or 204) byte packets. This allows mixing streams at a finer grainularity and assemble them as soon as you get all the info from multiple streams at once. (each network packet of MTU 1400 can contain parts of multiple streams so it appears more parallel to the next level up code.)<br>
<br></div><div>The transport UDP/TCP choice can effect latency if a data is lost and needs to be re-sent(TCP) UDP could drop and move on. Therefor less latency.<br><br></div><div>How is it encoded? Software or Hardware/firmware?  Software can be improved with GPU encodeing. (The Raspi may have this avail)<br>
</div><div>Software may be improved by periodic intra-refresh. Stock H264 can have large Key frames that require a chunk of work to handle.<br><br></div><div>Whoa? did I hear you correctly? stdin? I cannot even speculate how you can quantify stdin timing. (try sockets, shared memory)<br>
<br></div><div>Make sure you create your timestamps at end of image capture/beginning of encoding time. Since you are the source, the timestamps can be based all off the same clock. <br><br></div><div>Other idea. While normally the first substream of a video stream is the audio, perhaps you could create a stream with n substreams each a video. Then they are synced?<br>
</div><div><div><div><div><br> <br></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 26, 2014 at 7:02 AM, Mark Theunissen <span dir="ltr"><<a href="mailto:mark.theunissen@gmail.com" target="_blank">mark.theunissen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div>I have three Raspi cameras pushing out h264 elementary streams, which I'm reading from stdin and sending out using live555's RTSP server. All works great.</div>


<div><br></div><div>The only problem is that the three camera feeds can sometimes have different bitrates depending on what they're looking at - I want them syncronized. It seems that the cameras with the higher bitrates are closer to real-time, and the lower bitrates lag more. I expect this is because there is some fixed-size buffer somewhere, and the higher the bitrate, the faster the buffer is filled and the more realtime the stream is.</div>



<div><br></div><div>If I manually limit the bitrate so that all cameras are the same, they syncronize perfectly.</div><div><br></div><div>However, I'd like to rather allow them to have different bitrates, but still be syncronized. </div>



<div><br></div><div>Can anyone help with this? Is there a setting in live555 somewhere? Perhaps variable buffer size or rather, no buffer so that video is sent ASAP? Gstreamer manages extremely low latency, but uses too much CPU for my application.</div>



<div><br></div><div>I'm just using the test app modified to read from stdin.</div><div><br></div><div>Thanks</div><span class="HOEnZb"><font color="#888888"><span><font color="#888888"><div>Mark</div></font></span></font></span></div>

</div><br></div>
<br>_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br>
<br></blockquote></div><br></div>