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 [email protected] http://lists.qutecom.org/mailman/listinfo/qutecom-dev
