IMSDroid video not working on HTC EVO

[GoogleCodeExporter]

http://groups.google.com/group/doubango/browse_thread/thread/723f5a39c50ba9bf

Original issue reported on code.google.com by boss...@yahoo.fr on 5 Aug 2010 at 9:16

[GoogleCodeExporter]

Why do you need to add three callback buffers?
1024*768 is too big, you should choose something close to CIF or re-size the 
buffer before sending it to the native world . Which are the supported picture 
sizes?
I have added new version (revision 264) with full ARMv5TE optimizations. This 
version should use less CPU cycles. As you are using Android 2.1 you can 
rebuild FFmpeg with ARMv6 optimizations and x264 with ARM Cortex opt.
Could you also send the trace (SIP + RTP)?

Original comment by boss...@yahoo.fr on 16 Aug 2010 at 8:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have 3 callback buffers to see if that helped the delay, it didn't.
It doesn't matter if I use 1024x768 or else. I had tried 400x400 and heavy 
delay on inbound video still resulted.
The supported picture sizes on my HTC EVO: 
3264x2448,3264x1952,2592x1952,2592x1552,2048x1536,2048x1216,1600x1200,1280x960,1
280x768,1024x768,640x480,640x384,512x384,400x400,272x272
Where do I rebuild FFMpeg from and how to do it? I have not seen any official 
FFMpeg porting to Android.

Wireshark trace attached for a call to Bria with picture size set to 400x400. 
Callback buffer size is also based on 400x400 as well.

Original comment by whg...@gmail.com on 16 Aug 2010 at 9:40

Attachments:

• [IMSDroid to Bria (H263).pcap](https://storage.googleapis.com/google-code-attachments/imsdroid/issue-21/comment-54/IMSDroid to Bria %28H263%29.pcap)

[GoogleCodeExporter]

Have you tried with the revision 264?
I will send you "libtinyWRAP.so" with AMRv6 optimization.

Original comment by boss...@yahoo.fr on 17 Aug 2010 at 1:22

[GoogleCodeExporter]

I updated my source tree to the latest from SVN.
The latest did not help softened up the delay on CIF video calls. that was done 
without the addCallbackBuffer implementation.
Worst yet, when I plugged my the addCallbackBuffer calls, the CIF video call 
scenario stopped working. When I pressed "Send Video", it sent H.263 RTP 
packets from 1-2 secs and then it stopped sending. But QCIF video call works 
though.
What could possibly be the bottleneck for CIF video calls? I don't think its 
the CPU. Its more likely resource management. 

Original comment by whg...@gmail.com on 17 Aug 2010 at 2:55

[GoogleCodeExporter]

Very strange. Unfortunately I cannot test it on a 2.1 device.
Do you have the problem without addCallbackBuffer?
Have you tried with a picture size power of 2 (e.g. 512x512) instead of 400x400?
Do you have warnings or errors in the logs?
BTW, I think have I identified the problem about the delay and if all is OK the 
fix will be part of the next release.

Original comment by boss...@yahoo.fr on 17 Aug 2010 at 7:04

[GoogleCodeExporter]

Without using addCallbackBuffer, both QCIF & CIF video call works fine, only 
that there are heavy delay when in CIF mode.
It will be great news if you could get the delay issue fixed. Looking forward 
to the new release.

Original comment by whg...@gmail.com on 17 Aug 2010 at 7:15

[GoogleCodeExporter]

Hello whglee, We did test with the latest SVN trunk code on an HTC EVO with 
Android 2.2. It looks like when we perform video call the webcam is still not 
grabbed. Is your code already integrated in the trunk ?

Original comment by didier.c...@gmail.com on 20 Aug 2010 at 8:57

[GoogleCodeExporter]

I will not integrate the source code as it will only work on Android 2.1 and 
later.
The problem is that the HTC camera does not support standard QCIF and CIF 
sizes. It's easy to solve the problem: See comment 8 and 9 but instead of 
1024x768 use 272x272.
The supported picture sizes are listed at comment 54.

Original comment by boss...@yahoo.fr on 20 Aug 2010 at 11:19

[GoogleCodeExporter]

We performed new test with whglee VideoProducer.java the webcam is now grabbed. 
There are a couple of optimization to perform like being able to display 
correctly CIF and QCIF received video, we may work together on that ?
Our tests worked in h263 and h263+, does this version is able to encode h264 
flow ?

Original comment by didier.c...@gmail.com on 20 Aug 2010 at 1:46

[GoogleCodeExporter]

Is there a problem on displaying QCIF or CIF? If you are using the attached 
"VideoProducer.java" you should change the video size to something reasonable 
(e.g. 272x272).
I'm open to all suggestions. All ideas are welcome.
Yes H.264 is supported.

Original comment by boss...@yahoo.fr on 20 Aug 2010 at 1:54

[GoogleCodeExporter]

I also have another issue on my HTC EVO. The camera capturing of myself is 
rotated by 90 degree. As a result, remote side see the video rotated by 90 
degree as well. Take a look at the screen capture and notice the self view down 
at the bottom left. Any ideas?

Original comment by whg...@gmail.com on 20 Aug 2010 at 7:15

Attachments:

• selfview.png

[GoogleCodeExporter]

Have pushed pre-release version which should support front facing camera on HTC 
EVO.
It's available here: 
http://imsdroid.googlecode.com/svn/trunk/debug/imsdroid-1.0.pre.apk
Appreciate any feedback.

Original comment by boss...@yahoo.fr on 14 Sep 2010 at 9:56

[GoogleCodeExporter]

I did test with version v1.0.285 the front camera is grabbed but there's one 
limitation :

  -The image grabed by the front camera is in the right direction only when the phone is placed vertically while when the phone is place vertically the image received is flattened. It's quiet difficult to use it.

I also noticed that h264 codec consum too much CPU in high quality and when I 
decrease the quality to low then the application crash.

Original comment by didier.c...@gmail.com on 22 Sep 2010 at 8:24

[GoogleCodeExporter]

- How many CPU is consumed? Which process takes more CPU, encoding or decoding?
- Is it possible to have a screenshot of the image?
- For the crash you can send the log using "Log collector" from the market

You should know that the Android video system is the worst one I have never 
seen.
There are two big design errors (even more) on the video system:
1- The preview callback will always create, marshal (C->Java) and destroy each 
picture. This will consume both CPU and memory. It's amazing!
2- Both the capture+preview callback and the canvas drawing operations are 
called on the main event loop. I let you imagine what happen when use canvas 
operations while capturing at high resolution.
Because of the issue 2 you will have delay on the display for high quality mode 
even if the CPU usage is at 2%.

I have started developing on Android 4 months ago and my conclusion is that 
it's far (very far) from being a good OS compared to iOS or Symbian.

Original comment by boss...@yahoo.fr on 22 Sep 2010 at 1:09

[GoogleCodeExporter]

This beta version should resolve all 
problems:http://imsdroid.googlecode.com/svn/trunk/debug/imsdroid-1.0.324-armv7-a
.apk.

You must have a phone with at least ARMv7-a (Cortex-a8) processor.

Issues:
 - 90° rotation on HTC EVO (Options->General->Flip video)
 - H.264 Delay for CIF video stream
 - H.264 codec should consume -50% CPU compared to the online version
 -...

Original comment by boss...@yahoo.fr on 16 Nov 2010 at 2:41

[GoogleCodeExporter]

Original comment by boss...@yahoo.fr on 22 Nov 2010 at 7:07

• Changed state: Fixed