Re: [Linphone-developers] Re: Video freeze after ~30 min (reproducible) (CAUSE + WORKAROUND)

[Vadim Lebedev]

Markus,

Thinsking some more about this  issue:
The RTP timestamps for video stream are based on sampling rate of 90000
Samples/Sec
So for each captured video frame,  the timestap corresponds to the value
of  90KHZ clock at the
begining of the video frame.
The captured video frame is encoded and encoded stream is possiblly
split to multiple rtp packets.
The last packet in the sequence has M(ark) bit set
All timestamps in the sequence generated from same video frame must
have  same timestamp.

Taking all of the abouve into account it seems correct that give fps=10 
the timestamp should be incremented  by 90000/fps = 9000, which is
similar to what you observe.

So it seems our problem is on the reception side and not on the
transmission side

Thanks
Vadim



Markus Hossner wrote:
> Vadmin,
>
> analysing a "test call" with wireshark. H.263 packets:
>
> Incoming:
>
> TIME:       Info
> 252.453727  ... Seq=48517, Time=73170
> 252.533420  ... Seq=48518, Time=83880
> 252.653552  ... Seq=48519, Time=91080
>
> +0.0998                         +8955
>
> Outgoing:
> TIME:       Info
> 252.290001  ... Seq=78, Time=175410
> 252.409980  ... Seq=79, Time=182610
> 252.490346  ... Seq=80, Time=193320
>
> +0.1001                     +8955
>
> The packet timestamp grows with 8955 not with 90000. I guess TIME is
> in seconds so every 0.1 secs a new packet arrives.
>
> Markus
>
>
>
> Am 01.07.2009 18:48 Uhr, schrieb Vadim Lebedev:
>> Markus,
>>
>> I'd suggest that you examine the timestamps in the RTP streams
>> using wireshark, and tell us if you see somthing funny there.
>>
>> Thanks
>> Vadim
>> Markus Hossner wrote:
>>> Vadim,
>>>
>>> I've got no contact using QuteCom. I've tested it with the "Make test
>>> call". I don't know if this is more QuteCom<=>  QuteCom.
>>>
>>> The result:
>>>
>>> Timestamp 110160000 wanted.
>>> Seeing packet with ts=10983330
>>> t1 - t2<  1<<31 : 99176670<  2147483648
>>>
>>> Timestamp 110250000 wanted.
>>> Seeing packet with ts=10990800
>>>   t1 - t2<  1<<31 : 99259200<  2147483648
>>>
>>> Timestamp 110340000 wanted.
>>> Seeing packet with ts=11001060
>>>   t1 - t2<  1<<31 : 99338940<  2147483648
>>>
>>> Timestamp 110430000 wanted.
>>> Seeing packet with ts=11009430
>>>   t1 - t2<  1<<31 : 99420570<  2147483648
>>>
>>> Timestamp 110520000 wanted.
>>> Seeing packet with ts=11019330
>>>   t1 - t2<  1<<31 : 99500670<  2147483648
>>>
>>>
>>> Wanted timestamp grows with    +90000
>>> Seen timestamp grows with about +7500
>>>
>>>
>>> It's better than +10 to +90000, therefore t1 - t2 is growing less
>>> rapidly which means you can talk more than 30 min. About 32 min I
>>> guess.
>>>
>>> Markus
>>>
>>>
>>> Am 01.07.2009 17:44 Uhr, schrieb Vadim Lebedev:
>>>> Markus
>>>>
>>>> I undestand is that your setup is Wengophone<=>   QuteCom....
>>>> Can you test please QuteCom<=>   QuteCom
>>>>
>>>> Thanks
>>>> Vadim
>>>> Markus Hossner wrote:
>>>>> Hi
>>>>>
>>>>>
>>>>> Am 30.06.2009 12:40 Uhr, schrieb Simon Morlat:
>>>>>
>>>>>> The reason for the RTP_TIMESTAMP_NEWER_THAN macro is that
>>>>>> timestamps are
>>>>>> circular. Using  won't work in all cases. Indeed 0 is newer than
>>>>>> (2^31)+1.
>>>>>> It seems that the problem is that both timestamp don't grow
>>>>>> identically.
>>>>>> Having a video timestamp growing by +10 is problematic. It would
>>>>>> mean that
>>>>>> video frames are separated by 10/90000=1.1111e-04 s, so a framerate
>>>>>> of 9000
>>>>>> frame per second. Are you inventing a new VVHD standart (Very Very
>>>>>> High
>>>>>> Definition) -:) ?
>>>>>>
>>>>> So the problem lies in the packet timestamp. It should grow like the
>>>>> wanted timestamp to prevent a difference greater than 1<<   31.
>>>>>
>>>>>
>>>>> Markus
>>>>> _______________________________________________
>>>>> QuteCom-dev mailing list
>>>>> address@hidden
>>>>> http://lists.qutecom.org/mailman/listinfo/qutecom-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>