[AG-DEV] UCL common lib rtp_recv & frame timing

[Andrew Ford]

Hi,

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.

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.

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:

  timeout.tv_sec = 0;
  timeout.tv_usec = 10000;
  for (int i = 0; i < 1000 && rtp_recv(session, &timeout, _timestamp); i ++) {


    timeout.tv_sec = 0;
    timeout.tv_usec = 10;

  }				

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.

Thanks,
--Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/ag-dev/attachments/20100727/1d446060/attachment.htm>