Closed GoogleCodeExporter closed 9 years ago
wrong packets number :
41,42,43 -> 9,10,11
267 -> 223
Original comment by nicolas....@gmail.com
on 21 Feb 2011 at 1:55
The client will always send 3 "blank" packets when the session get connected.
These packets are sent to open a pinhole in the NAT.
For more information: http://code.google.com/p/imsdroid/issues/detail?id=103#c1
Original comment by boss...@yahoo.fr
on 21 Feb 2011 at 2:08
3 blank packets for pinhole NAT issue: OK
but the timestamps of the first right packet is NOK !
Thanks
Nicolas nbouche
Original comment by nicolas....@gmail.com
on 21 Feb 2011 at 2:28
How to detect that these packets could not be decoded ?
Thank in advance
Nicolas nbouche
Original comment by nicolas....@gmail.com
on 21 Feb 2011 at 2:31
The RTP manager will not generate the timestamps using the local time. This
means that if the negotiated framerate is 15fps then delay between packets will
always be 66.66ms.
Your client must be prepared to handle these kind of issues.
These packets are blank packet (zeros) but the payload is valid. You should get
a green image after decode().
Original comment by boss...@yahoo.fr
on 21 Feb 2011 at 2:41
Ok understand but how to detect that these packets are "blank" ?
Thank in advance
Nicolas
Original comment by nicolas....@gmail.com
on 21 Feb 2011 at 2:41
You don't need to. Just decode them as any other packet.
Why to you need to detect them?
Original comment by boss...@yahoo.fr
on 21 Feb 2011 at 3:00
Ok for blank packet (green picture) but the timestamps of first "not blank"
packet must be linked to the previous packet.
your RTP manager must set timestamps according to the true time: I mean the
time when the frame is created (from local Webcam). It's important to have
the creation time of pictures to be able to remove the jitter of the
transmission in the player.
Thank
Nicolas
Original comment by nicolas....@gmail.com
on 21 Feb 2011 at 3:24
Original issue reported on code.google.com by
nicolas....@gmail.com
on 21 Feb 2011 at 1:19