[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Linphone-developers] Re: Video freeze after ~30 min (reproducible) (CAU
[Linphone-developers] Re: Video freeze after ~30 min (reproducible) (CAUSE + WORKAROUND)
Tue, 30 Jun 2009 02:11:59 +0200
What di you think about it?
Le 30 juin 09 à 00:31, Markus Hossner a écrit :
I found the cause for the ~30 min video picture freeze it lies in
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
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).
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
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
Nicer would be if the function could be fixed to do a real check if
queue timestamp is newer or equal the wanted timestamp.
I hope this helps
QuteCom-dev mailing list
- [Linphone-developers] Re: Video freeze after ~30 min (reproducible) (CAUSE + WORKAROUND),
Vadim Lebedev <=