search

chitranshmathur01 / imsdroid

Automatically exported from code.google.com/p/imsdroid
0 stars 0 forks source link

imsdroid sends several incorrect video packets before we have click on "Send video" button. #182

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.Start imsdroid and select video codec H.263-1998
2.Start Linphone (http://www.linphone.org/)with H.263-1998 
3.Make visio call beetween linphone client and imsdroid 

What is the expected output?
No video before the click on "Send video" button of imsdroid
What do you see instead?
imsdroid sends several (41,42,43) H263+ video packets before the click
these packets are incorrect (not pictures)
the RTP timestamp of the first correct video packet (267) is not correct:
True delay between packet n°267 and n°43 = 7 seconds
delay from RTP timestamp between these packets (267 and 43) = 66.67ms   
What version of the product are you using? On what operating system?
imsdroid V1.2.355 (dobango r542)

Please provide any additional information below.
-> wireshark

Original issue reported on code.google.com by nicolas....@gmail.com on 21 Feb 2011 at 1:19

Attachments:

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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