New API: mp4 video files are not served *SOLVED*

[mikeschaekermann]

Hi folks,

I am experiencing an issue with the new devel-merge branch, where video files are not being served correctly via their public URLs.

This issue is independent from the storage adaptor I am using. I have tried out both cfs-filesystem and cfs-gridfs without success. Using cfs-filesystem, I could see that the correct video files landed in the folder they were supposed to end up in and dragging'n'dropping them right into a Chrome tab made the video play correctly.

When I enter the URL, return from the cfsFileUrl handlebars helper (using cfs-handlebars), the video is not presented. Files of type text/plain or image/jpeg are served correctly. My video is in mp4 format with H264 video and AAC audio encoding.

This is what the network tab in the Chrome developer tools presents to me when I try to view the mp4 file in the browser. As can be seen, there are 3 attempts to establish a connection. And actually the correct type "mp4" and file sizes are retrieved. The video is actually 2.8 MB big. However, when I click on the response tab for any of the connections, I get "This request has no response data available".

It would be great, if there was an easy solution to this issue! Or a hint, in what package a solution to the problem could be established! ;)

Thank you very much in advance!

[aldeed]

Do they download okay over DDP? Use the cfsDownloadButton helper or call FS.downloadQueue.downloadFile(myFSFile) to test.

[mikeschaekermann]

Yep, they download perfectly over DDP.

[mikeschaekermann]

@aldeed Do you have any idea what might cause this issue? What I also noticed is that both FS.File.toDataUrl(cb) and FS.File.toBinary(cb) never call the callback function passed to them, although the File is fully published to and subscribed by the client. I tested it with a sample callback function like:

myFile.toDataUrl(function (data) {
    console.log('data', data);
});

myFile.toBinary(function (data) {
    console.log('data', data);
});

Unfortunately, neither of them ever logged anything to the console.

Can anyone reproduce this behavior (just to exclude I'm not making another mistake somewhere else)?

Any help would be greatly appreciated! :)

[mikeschaekermann]

This issue turned out NOT to be related to the CollectionFS code base. Instead, it was a Chrome-specific bug, as pointed out on http://stackoverflow.com/questions/12431159/two-h-264-mp4-videos-one-plays-in-chrome-one-doesnt?rq=1.

To be more specific, the file was in mp4 format and was correctly downloaded when using wget in the console. Moreover, it was correctly served in other browsers (tested in Safari and Firefox). Chrome did also show the video in smaller resolutions. On the above link, you can find specific mp4 encoding settings that any videos should fulfill in order to be correctly played by iPhone and Chrome (, which are stated to use the same mp4 renderer for the HTML5 video tag).

I quote these encoding settings here for the sake of an easier read:

• Only use the H.264 Baseline Profile Level 3.0
• Resolution below 640 x 480 and framerate up to 30 fps
• B frames are not supported in the Baseline profile.
• bitrate limit of 900kb.

Hope, this'll help other people dealing with web compatible videos in the future!

[aldeed]

Fascinating. Thanks for the info!