search

zjzhang-cn / imsdroid

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

can receive but not send H263+ video #79

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Make an H263+ call to a Tandberg EX-90 from an HTC EVO.  Press send video.

What is the expected output? What do you see instead?
Audio works. IMSdroid shows incoming video.
As soon as you press "send video", RTP packets are sent but the tandberg is 
unable to decode them.

Two errors are repeated many times in the android logs:

"invalid parameter" on line 483 of src/tmedia_codec.c
"103 is not a valid payload for this session" on line 62 of 
src/video/tdav_session_video.c

Apparently neg_codecs is null.  Not sure why negotiation would turn up empty 
since video works in the other direction.

What version of the product are you using? On what operating system?
svn: imsdroid-read-only@310

Original issue reported on code.google.com by pulpo...@gmail.com on 18 Oct 2010 at 1:38

Attachments:

GoogleCodeExporter commented 9 years ago 
The capture file is incomplete. Could you please attach another capture with 
both INVITE and 200 OK frames?

Original comment by boss...@yahoo.fr on 18 Oct 2010 at 4:45

GoogleCodeExporter commented 9 years ago 
pardon...

Original comment by pulpo...@gmail.com on 18 Oct 2010 at 5:37

Attachments:

GoogleCodeExporter commented 9 years ago 
What is the role of the UPDATE request? If this request reach IMSdroid, then 
H263-1998 codec will be removed from the session (see the SDP content).
What is the IP address of the client?
Do you have the same issue with H263, H264 or theora?
Could you also send the android log?
The error is related to the incoming packets not the outgoing.

Original comment by boss...@yahoo.fr on 19 Oct 2010 at 5:34

GoogleCodeExporter commented 9 years ago 
In the "broken2" capture, the remote endpoint is 10.194.60.187, the proxy is 
10.194.60.49, and the android phone is 171.68.123.32.  The capture was done on 
the 10.194.60 subnet.

I had assumed that the problem was related to the outgoing packets because (1) 
there are no errors until I press "send video" and (2) my phone displays the 
remote video fine, but the remote endpoint does not display any video sent from 
my phone.  I didn't notice the UPDATE.  Notice how it comes after the first few 
frames are sent by IMSdroid, and then that stream stops.  Is it possible the 
Tandberg is sending this because it does not like the frames coming in?

H263 does work.  H264 does not show video in either direction.  I'll do a 
capture of that for you as well.

Original comment by pulpo...@gmail.com on 19 Oct 2010 at 6:41

GoogleCodeExporter commented 9 years ago 
Log (repeats for duration of session, once "send video" is pressed)

D/QualcommCameraHardware( 3785): startPreview X

I/CameraService( 3785): [Camera KPI] 1st preview frame

W/InputManagerService( 3819): Window already focused, ignoring focus gain of: 
com.android.internal.view.IInputMethodClient$Stub$Proxy@46309268

E/tinyWRAP( 4954): ***ERROR: function: "tmedia_codec_find_by_format()" 

E/tinyWRAP( 4954): file: "src/tmedia_codec.c" 

E/tinyWRAP( 4954): line: "483" 

E/tinyWRAP( 4954): MSG: Inalid parameter

E/tinyWRAP( 4954): ***ERROR: function: "tdav_session_video_rtp_cb()" 

E/tinyWRAP( 4954): file: "src/video/tdav_session_video.c" 

E/tinyWRAP( 4954): line: "62" 

E/tinyWRAP( 4954): MSG: 103 is not a valid payload for this session

E/tinyWRAP( 4954): ***ERROR: function: "tdav_session_video_producer_cb()" 

E/tinyWRAP( 4954): file: "src/video/tdav_session_video.c" 

E/tinyWRAP( 4954): line: "175" 

E/tinyWRAP( 4954): MSG: Failed to find a valid codec

Original comment by pulpo...@gmail.com on 19 Oct 2010 at 8:32

GoogleCodeExporter commented 9 years ago 
Ok here are some more captures.

Today we commented out the various H263+ annex flags in the C code because some 
of them were giving us trouble with other equipment which doesn't support (and 
doesn't request) them, especially annex S.  So the RTP looks a little different 
than the previous capture I sent you.  Same symptoms though.

All were done on high bandwidth except H264bp2 and bp3 which were low bandwidth 
(though I know they behave the same on high).

Behavior on screens:
H263+: good quality video on android, with ok latency.  Not showing up at all 
on remote.  Same as before.
H264bp10: no video shown on either screen
H264bp20: video shown on both screens with some quality and latency issues.
H264bp30: no video shown on either screen

Various errors in the logs, also attached.

Personally I'm mostly concerned with the H263+ case because it looks like we'll 
be able to get a good quality connection with this hardware, once we get past 
these compatibility issues.  H264 is maybe not practical for my phone.

Note that in some cases the first invite wasn't captured so you'll see a bye 
and a second invite.

I will look at these in more depth tomorrow, wanted you to have them in the 
meantime.

Original comment by pulpo...@gmail.com on 20 Oct 2010 at 2:11

Attachments:

GoogleCodeExporter commented 9 years ago 
From broken2:
According to comment4, the IP address of the Android phone is "171.68.123.32" 
which means that the UPDATE request (frame 664) is going to reach IMSDroid. As 
the SDP content from the UPDATE request doesn't contain H263-1998 codec it's 
normal to get this error. Try to make the call from your client to IMSDroid to 
see if you get the same issue.

For the video display:
On many NATted networks the network connection is opened only when both parties 
start sending RTP packets. Could you confirm that the Android device receive 
the H263-1998 packets before you press "Start video"? 

H264 issue:
I have seen the issue with some non-FFmpeg client. Enabling/disabling some 
options should solve the problem.

Test to do:
Using the same network options, try to make video calls from IMSDroid to 
another SIP client (Linphone, Ekiga, SIP Communicator, ...) to see if you have 
the same issue or not.

Original comment by boss...@yahoo.fr on 20 Oct 2010 at 6:43

GoogleCodeExporter commented 9 years ago 
Yes, I can confirm that it has never been necessary to press "send video" 
before seeing a signal.  In all test cases where I saw the remote video on the 
phone at all, it appeared before that, very soon after the call connected.  I 
don't believe there's a NAT issue here.

Regarding H264, are you suggesting that I remove some of the flags similar to 
the H263+ annex flags I adjusted, or are there other options available 
somewhere else in the code that I should be aware of?

Original comment by pulpo...@gmail.com on 20 Oct 2010 at 7:03

GoogleCodeExporter commented 9 years ago 
If there is no NAT issue this means that the problem is caused by the UPDATE 
request.
Could you please do the same test with another client or disable this options?
Could you also try to make the call from your client to IMSDroid?

Original comment by boss...@yahoo.fr on 20 Oct 2010 at 7:08

GoogleCodeExporter commented 9 years ago

Original comment by boss...@yahoo.fr on 26 Oct 2010 at 9:35