Closed GoogleCodeExporter closed 9 years ago
Using imsdroid 302
Original comment by alison.v...@gmail.com
on 29 Oct 2010 at 6:32
Could you confirm that you are using CIF video size (e.g. H.264 BP20)?
On Android both canvas drawing (consumer) and video preview (producer) run on
the main event loop. This doesn't cause CPU overload but the video playback
rate go down. It's like the events are mixed and queued (FIFO).
I tried replacing basic canvas drawing by OpenGL ES which uses its own event
thread without success. Really think that it's due to Android video system
design.
The issue doesn't happen on one-way video mode even with QVGA, HVGA or WVGA
video resolutions.
Original comment by boss...@yahoo.fr
on 29 Oct 2010 at 7:09
It is receiving Baseline at qVGA
Original comment by chris.ve...@gmail.com
on 29 Oct 2010 at 8:58
OK, I think I've an idea on how to solve the issue. Will send you a test
version.
Original comment by boss...@yahoo.fr
on 29 Oct 2010 at 9:54
Ok. Let me know when you have a build and we will test
Original comment by chris.ve...@gmail.com
on 2 Nov 2010 at 11:43
Do you have the issue without sending video (one-way stream)?
Original comment by boss...@yahoo.fr
on 2 Nov 2010 at 4:53
Can't determine that as all tests require a 2-way RTP video stream
Original comment by chris.ve...@gmail.com
on 3 Nov 2010 at 3:25
A test version is available for download.
Original comment by boss...@yahoo.fr
on 4 Nov 2010 at 6:56
Now I get no incoming video using 320
Original comment by alison.v...@gmail.com
on 4 Nov 2010 at 3:32
Very strange. I haven't changed the video consumer. Is it possible to have the
network trace?
Original comment by boss...@yahoo.fr
on 4 Nov 2010 at 11:17
I will get a wireshark capture for you and attach to this Issue #
Original comment by chris.ve...@gmail.com
on 9 Nov 2010 at 4:04
I have a capture from the Nexus 1. Incoming Video worked for that call, but the
frame rate is still slow and delayed by ~10s
Original comment by chris.ve...@gmail.com
on 12 Nov 2010 at 2:00
Attachments:
Decoded video is about 8-10 seconds delayed from what far end is sending
Original comment by chris.ve...@gmail.com
on 15 Nov 2010 at 5:22
The delay gets longer as the call progresses
Original comment by chris.ve...@gmail.com
on 15 Nov 2010 at 5:29
This debug version should solve the problem:
http://imsdroid.googlecode.com/svn/trunk/debug/imsdroid-1.0.324-armv7-a.apk.
You must have a phone with at least an ARMv7-a (cortex-a8) processor (HTC EVO
is OK).
My test env:
- IMSDroid 1.0.324-armv7.a (Samsung Galaxy S with Android 2.1-update1)
- Linphone 3.3.0 as remote client (Windows Vista)
- Local SIP registrar without RTP proxy
- H.264 Base Profile 2.0 (2-way CIF video)
*) It could be interesting to make tests with both cameras (front and rear) as
they don't have (most likely) the same frame rate. To switch from front to rear
camera (vice-versa) while in call click on the "Answer" button.
*) Now, H.264 video (2-way, CIF) call on a 1GHz processor (e.g. Galaxy S) uses
less than 48% of the CPU. This should allow to play video smoothly.
*) X264 has been rebuilt with NEON optimizations which faster encoding.
*) Check that your client/server is sending the video stream at a reasonable
bit rate
Original comment by boss...@yahoo.fr
on 16 Nov 2010 at 2:32
imsdroid-1.0.324-armv7-a.apk works better. Still querky but will update new
issues later
Original comment by chris.ve...@gmail.com
on 16 Nov 2010 at 3:25
Fixed in 1.1.327
Original comment by boss...@yahoo.fr
on 22 Nov 2010 at 6:20
Original issue reported on code.google.com by
alison.v...@gmail.com
on 29 Oct 2010 at 6:32