Hi,
I found the cause for the ~30 min video picture freeze it lies in
rtp_getq_permissive (qutecom-2.2/wifo/ortp/src/rtpsession.c)
This function tests if the packet queue (video) is empty. If it is not
empty it checks if the first packet in the queue has a timestamp which
is newer than the timestamp that was hand over as parameter. In that
case the first packet in the queue is returned. If not no packet is
returned.
This is what the function should do. The problem is that the parameter
timestamp (wanted) and the packet timestamp (seen) have no connection.
At least it seems to me that there is no connection:
...
Timestamp 2305800000 wanted.
Seeing packet with ts=158855220
Timestamp 2305890000 wanted.
Seeing packet with ts=158862330
Timestamp 2305980000 wanted.
Seeing packet with ts=158869620
Timestamp 2306070000 wanted.
Seeing packet with ts=158876730
...
The two timestamps grow with different speed (t1: +90000, t2: +10).
The
wanted timestamp (t1) grows faster than the seen timestamp (t2). So
there should be no problem. t2 will always be newer than t1 (unless
there is a overflow). But the problem is how the test ist done. To do
this test the macro RTP_TIMESTAMP_IS_NEWER_THAN is used which uses the
following:
t1 - t2 < 1<<31
I don't know why this test is done like this. But as t1 grows faster
than t2 after some time (~30 min) t1 - t2 >= 1 << 31. And therefore no
more packets are taken from the full queue.
A easy workaround should be to just skip the strange timestamp is
newer
test.
Nicer would be if the function could be fixed to do a real check if
the
queue timestamp is newer or equal the wanted timestamp.
I hope this helps
Markus
_______________________________________________
QuteCom-dev mailing list
address@hidden
http://lists.qutecom.org/mailman/listinfo/qutecom-dev