Expected Behavior
Download a video from a remote server, and save it to the Photo gallery, then exit the app and open the Photo Gallery, the video should be there.
Actual Behavior
Download a video from a remote server, pass the this.response to a "save to Photo Gallery" statement, there no errors on the process, apparently the video has been saved to the photo gallery, exit the app, open the photo gallery, there are no video.
Test Case
//var mp4_path = 'http://www.eyejot.com/mediabits?t=4&u=davidg&g=0E15E94BE83D150000404089CD&f=3424725A1718F2FFFFCDAE1066'
//var mp4_path = 'http://www.mp4point.com/downloads/f4f0ea5981b3.mp4'
var mp4_path = 'http://daily3gp.com/vids/747.3gp';
//var mp4_path = 'http://images.developercenter.appcelerator.com.s3.amazonaws.com/support-admin_logo_graphic.png'
download_xhr = Ti.Network.createHTTPClient();
download_xhr.onload = function() {
Ti.API.info('lets save the file');
Titanium.Media.saveToPhotoGallery(this.responseData);
};
download_xhr.onerror = function() {
Logger.log ('[gallery_test:downloadMessage] onerror');
return;
};
download_xhr.open ('GET', mp4_path);
download_xhr.send();
}
Notes
If i use a jpeg, instead a video, the jpeg file it's saved and appears into the photo gallery
I use different remote videos to test.
NOTE: The downloaded video must be in a format supported by the device. Available media formats on specific devices are available in their spec sheets from Apple.
Updated test:
Fixed in 1.8 branch, awaiting 1.9 merge before marking resolved.
I tried the latest test case supplied here against the released 1.8.0.1 and did not find accepted behavior. Trying the test against the three MP4 files produced nothing and it appears as if the saveToPhotoGallery is entered but never returns and provides no status information in those cases. It's true that the 3GP example works, but the fact that valid MP4 files, that play normally, don't work suggests there's still a problem. This all worked extremely well in the 1.7.x era.
David - You are probably retrieving content from a website which is using a currently unsupported "Content-Type" header for the download. This ticket was for support for video with the MIME type "video/xxx". In this case you are probably downloading an "application/mp4" mimetype file, which is a type specifically reserved for MPEG-J and MPEG-7 with no video content (see [RFC 4337](http://www.rfc-editor.org/rfc/rfc4337.txt)). Unfortunately it appears that content providers frequently violate the RFC and provide content of this type which includes a video segment.
We need to add support for MIME type "application/mp4" as above, since plenty of services violate the RFC.
Stephen, when we try and pull our video from our site we deliver the MIME type video/mp4. Here's the output from retrieving http://www.eyejot.com/mediabits?t=4&u=davidg&g=0E15E94BE83D150000404089CD&f=3424725A1718F2FFFFCDAE1066 This was taken directly from Chrome's developer output. Content-Disposition:inline; filename=3424725A1718F2FFFFCDAE1066.mp4 Content-Length:5255124 Content-Range:bytes 44-5255167/5346565 Content-Type:video/mp4 Date:Tue, 27 Dec 2011 18:29:47 GMT Etag:1323544685000 Last-Modified:Sat, 10 Dec 2011 19:18:05 GMT Server:Apache-Coyote/1.1 My concern with this - and Titanium - is you guys keep moving the playing field. There has to be some consistency and willingness to retain backward compatibility. The easiest way it to add new methods that perform whatever new or corrected functionality you desire and leave the old stuff the way it was. This was working properly for 1.7.x and now, sadly, it's not.
Additionally, even if the MIME types were wrong (which they were not), the saveToPhotoGallery function shouldn't go off into la la land. Right not it doesn't even produce an error if it has a problem.
David - One of those links in the test did in fact resolve to an application/mp4 mimetype (the one with the .mp4 extension). I assumed that this was your issue. Using the above link, I was in fact able to save to the photo gallery in both 1.9.0 and 1.8.0.1 using the sample code provided. We do in fact fire both error and success messages for save completion, again as above in the test. It is recommended that you use the updated test I added to the ticket in the comments during resolution to confirm the fix.
Going to open a separate ticket for 'application/mp4' support.
Thanks Stephen. Since we really only care about the functionality working against our own platform, and we appear to be emitting the correct MIME time, I'll update our tests and confirm things are behaving as you suggest. Thank you for your quick replies.
Stephen - this stuff is still driving me crazy. My use case is to save the HTTP data into a file and THEN save it to the gallery. If I save the stream to a file and then attempt to pass in a TiBlob or TiFilesystemFile for that file the saveToGallery exhibits the same behavior or not working. If I save to a file and ALSO pass the this.responseData to saveToGallery it fails. Can you help me understand what's going on? The simple test case of save to the gallery directly from the HTTP call won't work for me and the documented behavior of saveToGallery is supposed to support saving both TiBlob and TiFilesystemFile objects. Is there something you can recommend?
David - You should be able to pass in a
TiFilesystemFilebut it has to be named appropriately (for mimetype identification, which appears to be fairly restrictive for us and may need to be updated). Can you provide me with some sample code, both for the direct-from-HTTP save and the save-from-file? Without a test case that proves this bug isn't resolved, or that there are additional issues, I can't reopen the ticket or create new ones since the tese case I wrote works for me (and the reviewers who accepted the fix).I didn't quite understand your request for a sample (the without a test case that proves part was confusing). But, I beat my code to death and discovered that if the file is named "name.mov" it WILL save to the gallery and if it's "name.mp4" it WILL not. Very, very frustrating model - especially since the documentation is practically non-existent. I suspect the TiBlob will work now with the file name changed to .mov. I'll test. I'll post some stuff in the QA group so others can benefit from this painful learning process. :) I do, though, appreciate your help. Can I send you a free redemption code for Eyejot on the iPhone?
David - I double-checked the mimetype info and we do not identify "mp4" extensions as an appropriate mimetype. I'll be filing a bug to resolve this and link it to this ticket. I'm still curious why you can't directly save the blob to the roll, however.
Closing issue Tested with Ti Studio 1.0.8.201201101928 Ti Mob SDK 1.9.0.v20120111233134 OSX Lion iPhone 4S, iPad 2 Expected behavior of video download over network, then being saved to photo gallery is shown