Your Rocket.Chat version: demo instance via Electron client as well as Chrome


Video in question: http://up.frd.mn/4BuzWg2FmY.mov
Same for rocket.chat version 0.32:
Text in page-source in Chrome (Windows) / Safari (OSX) for .3gp: "Your browser does not support this video element."
Ok this looks like System/Browser problem, but what about .mov - video in Safari/OSX:
If a link to above .mov-video is pasted in R.C (embedded URL), it can be played, but if the same .mov is uploaded to Rocket.Chat within a message/channel, it is not played.
Would be great if R.C/Electron would cover at least 3 video formats 3gp, mp4 and mov since they seem to be widely used by mobile devices (.mov - iphone codec should be actually H264 mpeg-4 AVC, because quicktime can have many codecs, 3gp uses also H.264 codec).
Recording and playing a video is is a very common use case.
Camcorder videos recorded on an up-to-date Android / Cyanogenmod (by clicking the paper-clip sign and then the camcorder icon) can not be played on the same device, neither in the RC App nor in the Firefox or Chrome browser on the same device or on a Linux desktop. The reason is that 3gp is simply not supported in video html5 due to patent issues.
PROPOSAL FOR FIX: Convert any 3gp video on the server.
This worked for me and saves a lot of bandwidth (the webm file was 20 times smaller than the 3gp):
ffmpeg -i VID_20160614_195849.3gp VID_20160614_195849.webm
So we may need to use something other then the html5 video element.
https://github.com/flowplayer/flowplayer is GPLv3
EDIT: after some further research, flowplayer does not really support 3gp. As it does not do any transcoding, it relies on what browsers support: http://demos.flowplayer.org/videotest/canplay.html
So ffmpeg transcoding on the server seems to be the only option. Here is a sketch for the steps:
ffmpeg -i inputfile.3gp outputfile.webm when an 3gp file has been uploadedI don't think we're going to want to introduce ffmpeg transcoding into the stack. The likely solution here is if the browser can play the video we'll show it. Otherwise we'll offer it as a file to download.
Think of the case where you are running on a single core server and someone uploads a big video file that needs transcoded. They will be sharing that single core. My experience with video conversion... It takes up a lot of CPU. Then the Rocket.Chat server will suffer and your users will not be happy.
Well, rendering certainly depends on your hosting environment, you could lower the nice value not to interfere with other services on the same machine.
Offering a download for 3gp is also a good idea, then it is played with the device's video player.
We should handle amr audiofiles similar, they are recorded on Android with the standard audio recorder, but can't be played within an HTML5 audio tag.
Now with the integrated browser-based-recorder since version 0.40 webm is produced and can be played on Android, iOS and web browser. So this ticket could be closed. However, webm may never play on a Windows Phone, in case anybody will get Rocket.Chat running on that specific mobile OS.
webm seems not to be played on Safari, though. See https://www.w3schools.com/html/html5_video.asp
Closing. Please let us know if it is still a problem for you.
Most helpful comment
https://github.com/flowplayer/flowplayer is GPLv3
EDIT: after some further research, flowplayer does not really support 3gp. As it does not do any transcoding, it relies on what browsers support: http://demos.flowplayer.org/videotest/canplay.html