Anna PS wrote: >> 1. Why are you using a ContentProvider? > > Because that seemed to be the best way to get from a content URI > (returned from the Android video camera intent) to a byte stream. > Happy to do it another way, though.
Oh. I thought you had perhaps written the ContentProvider in question. > Once I've got the videoByteArray, I'm uploading it to a server, as a > FilePart within a multipart message. I can post the code for that if > it would be useful. > > It works well for files of less than 2MB. I suspect your problem is not in reading the InputStream, but rather in how FilePart does what it does. Since that isn't part of Android, it was probably developed without tight memory constraints in mind. If you hand it 1 KB chunks each time, it is probably going to allocate a 1 KB byte array, then a 2 KB byte array, then a 3 KB byte array, then a 4 KB byte array, and so on. You are hopelessly fragmenting your heap. Not to mention that FilePart might well wind up Base64 encoding the result, requiring another massive memory allocation. I would recommend rewriting your Web server. Use HTTP PUT instead of HTTP POST with multipart. Better yet, use HTTP PUT and support chunking on the Web server -- you do a PUT for every 1MB or so and the server stitches them together. If this is not your Web server, you're pretty much screwed AFAICT. Doing bigger chunks than 1 KB will help somewhat, and rewriting FilePart to minimize reallocations will help somewhat, but you'll still probably not get much past, say, 5MB that way. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Android Training in NYC: 30 April-2 May 2010: http://guruloft.com -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
