Hi,<br><br>I'm having some issues in an RTP application of mine (using VPMedia, which in turn uses the UCL common library for underlying RTP support) with smooth timing of incoming video. I have a low bitrate 30fps H.264 test video (which I can make available if need be) which when viewing with something like mplayer or similar looks fine, and the same goes for sending via RTP and receiving with gstreamer. Those don't look perfect, but look better than my app which is significantly choppier. vic seems to have the same issue.<br>
<br>I've ruled out any issues with rendering, as I've gotten my app to render at a pretty consistent 60fps, as well as the timing of the sending, which I've timed with gstreamer and is almost exactly 33ms between frames (also, the timestamps are very consistent). On the other hand, when I time the incoming frames in VPMedia (on the marker() call, before any decoding happens) every few seconds there will be a delayed frame (40-60ms since the last frame) and the next one will come in faster like they've been buffered.<br>
<br>I've been looking into where VPMedia interfaces with the common library - it looks like the main receiver code is here, in the iterate function:<br><br><pre> timeout.tv_sec = 0;<br> timeout.tv_usec = 10000;<br>
for (int i = 0; i < 1000 && rtp_recv(session, &timeout, _timestamp); i ++) {<br>
<br> timeout.tv_sec = 0;<br> timeout.tv_usec = 10;<br><br> } <br></pre>I'm not quite sure of the purpose of doing that loop - it seems like it's effectively doing a 10ms wait-for-data twice over. I've tried experimenting with this (1ms single call only, 1ms with loop, etc.) but it doesn't seem to make a difference with the frame delay. I call the iterate function that contains this code in a loop on a separate thread so that timing shouldn't be an issue. I assume that the RTP callback (which is where I'm effectively timing it) gets called from within rtp_recv, but I haven't dug deep enough into the UCL code to know for sure (I wasn't able to look past the select() call in udp_select() - anyone know the details on that?). I've also tried to profile it, but since there really aren't any CPU spikes (or any real CPU issues at all really) it doesn't tell me much. I've basically hit a dead end with this issue - any help with this would be greatly appreciated.<br>
<br>Thanks,<br>--Andrew<br>