I knit a Rmd file (to html) with a chunk producing a mp4 movie :
```{r clock, fig.width=7, fig.height=6, fig.show='animate'}
par(mar = rep(3, 4))
for (i in seq(pi/2, -4/3 * pi, length = 12)) {
plot(0, 0, pch = 20, ann = FALSE, axes = FALSE)
arrows(0, 0, cos(i), sin(i))
axis(1, 0, "VI"); axis(2, 0, "IX")
axis(3, 0, "XII"); axis(4, 0, "III"); box()
}
```
knitrgenerates the following html code for embedding the mp4 movie :
<p><video controls="controls" loop="loop"><source src="figure/clock.mp4" type="video/mp4" />video of chunk clock</video></p>
The mp4 movie is well created in the figure subfolder but it does not appear in the html output when I open it with a Windows XP machine using either Chrome, Firefox or Explorer.
Here is a (temporary) example : http://stla.overblog.com/ellipse-chart-test - this is not the "clock" example but this is exactly the same rendering problem. I see the movie with Chrome on a Windows Vista machine, but not with my Windows XP machine.
What is the explanation ? Is it really a problem with the OS or with browser versions ?
tl;dr Browsers really use the OS to perform some media decoding tasks. Work around it by a) providing alternate media streams b) using the most compatible media format for your audience c) using a plugin (i.e. Flash), or d) recommend installing an MP4 plugin.
This is in fact a 'problem' with the OS. Many browsers, just as some other programs on a particular platform, use the operating system resources to acomplish a given task. This is particularly true when it comes to procedures protected by intellectual property rights.
Your codec (h.264 aka "MP4") happens to be a particulary fiercely fought over piece of IP. Thus, browsers don't go to lengths to licence the IP at hand, but rather use the licenced codecs of the host system.
In your case, Windows XP happens not to be able to decode the media format of your video, and the browser doesn't seem to be able to do that by itself.
Your alternatives now:
Give additional media streams with your video tag (see Wikipedia for an example)
Trying to find out what browser the majority of users is using on XP, then choose a natively supported format (either webm for Chrome or ogg for Firefox)
Just use Flash to play the MP4 (as in the pre-HTML5 days)
Telling users to install an OS-level plugin to play h.264; you could even do that in the fallback text. I won't recommend a specific product, but there are many.
Related
Goal: use MediaRecorder (or else) api to produce video files that are viewable cross platforms.
Fail: current api falls back to container/codec on google chrome which is only viewable on chrome and advanced desktop media players but not on Safari or mobile devices.
! Same code when running on safari generates a working video file on all platforms.
const mimeType = 'video/webm;codecs=H264'
rec = new MediaRecorder(stream.current, { mimeType })
rec.ondataavailable = e => blobs.push(e.data)
rec.onstop = async () => {
saveToFile(new Blob(blobs, { type: mimeType }))
}
Tried all different combinations of containers and codecs.
also tried to override the mimeType of the Blob with MP4 file container.
No success what so ever.
also tried:
https://github.com/streamproc/MediaStreamRecorder
https://github.com/muaz-khan/RecordRTC
Same issues. iI seems like chrome's container/codec combinations always fall back to a format that is only viewable out of the box on chrome or a powerful desktop video player like vlc.
The only cross platform working video for me is the one taken from safari browser and is the 5th from left in the picture above.
What is the correct container/codac to be used in MediaCapture api to make the output file playable cross platform.
Edit -
We ended up building a transcoding pipeline with AWS ElasticTranscoder, which takes the uploaded video and transcodes it with a general preset that is playable on all platforms thus creating a converted video file.
unfortunately the bounty I offered expired, but if someone answers the original question I would gladly reward him with the bounty again.
I think your problem may be in the first line:
const mimeType = 'video/webm;codecs=H264'
The container you are using is webm, which typically uses codecs VP8, VP9. H264 is a codec used in the mp4 container.
Chrome supports webm. Safari does not (and all iOS browsers are based on Safari - hence your mobile issue).
You say that run on Safari, this outputs a playable video. use ffprobe to see what codec/containers are outputted on Safari - I am guessing that there is a change in container/codec.
Since your video is h264, you must simply change the container to mp4, and it will play everywhere. This is a 'copy' from one container to the other, not a transcoding, but you'll still need ffmpeg :)
Here's a post that might help: Recording cross-platform (H.264?) videos using WebRTC MediaRecorder
I am trying to make a simple node-webkit app that lets you play .avi videos (which should work both on windows and mac). Is there a way to do this with node-webkit?
It is unlikely you will be able to just do this with Node-Webkit. Especially since the official webkit does not support AVI. Your best bet is to use an external application like libav (avplay) or use node to serve a webpage that has a player capable of playing the content and just let the users browser do the work. (Flash is likely still the best way to go, video.js is a good choice)
The alternative is to convert the video to one of the supported formats. I would recommend mp4. (Once again libav (avconv) comes in handy here.) This still assumes that Node-Webkit has implemented full HTML5 support. (I am not sure what they have completed but I am guessing it supports the video element)
Is AVI supported in Chrome (not Chromium) ?
If it is you have to change the libffmpegsumo.so in nw for the one in Chrome (try to use the same version).
libffmpegsumo.so is called ffmpegsumo.dll in Windows
The file file is in the same folder of the nw executable
to get the file download google chrome and go to %USER%/Google Chrome/ (or something like that) and you'll find the file in the same folder of the google-chrome executable
You can wcjs-player to play any format video which supported by VLC. It plays any video without any lags as in-built player.
To support my above claim, I have following points:
Building NW (by compiling source code) with various FFMPEG codec flags given at nw github site, doesn't help, in getting ffmpegsumo.dll which can play avi file format.
wcjs-player uses VLC libraries, which support all video played by VLC does.
Its better than using any nw plugin, as internally wcjs-player using VLC does similar job as HTML native video support .
Even if you suceed playing avi files, sometimes supported videos file format may not get played like most ironically mp4 file itself.
Apart from this, Teewe Theatre, Popcorn Time , Butter are among NW based media player using wcjs-player. It hardly increased 30 MB size of overall app size.
I have two different videos, both (as far as I know) generally captured in the same manner, that I'm trying to play using an HTML5 video tag in Chrome. Both videos open and play perfectly in VLC, so I don't think there's any issue with a corrupted file, and both are mp4's with an H.264 format, using YUV color space. However, when I try to play one in Chrome (Version 21.0.1180.89) it gives me a grayed-out play button, while the other works perfectly. For reference, my OS is Ubuntu 10.10, although I've seen the same problem in newer versions of the OS. This is whether I'm loading the video into the HTML5 tag, or navigating directly to the URL where the video is being stored. I'm somewhat at a loss here, does anyone know what direction I should go to find what the significant differences are between the two videos?
Edit:
This one works: https://dl.dropbox.com/u/100841270/1_G101_20120914_0139PM_Course_101.mp4
This one does not: https://dl.dropbox.com/u/100841270/1_G101_20120914_1156AM_Course_101.mp4
Update:
It appears to have nothing to do with OS, since I've seen the same problem in both Windows and Linux. Chrome 22 beta in Ubuntu didn't seem to work either.
We had this problem and found that encoding the files in accordance with iPhone's webview's standards created files that played fine in Chrome. Chrome and iPhone webview share the same render engine, and it appears they have similar HTML5 video requirements.
Not all H.264 encoded Mp4 files are supported by Chrome and slight differences in the encoding process can produce videos that do not work. Even if the EXACT same encoding settings were used, H.264 is a variable bit-rate encoder, so different videos may exceed bitrate limits.
The encoding settings that were successful for us were:
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.
Here is the reference we used to arrive at those settings. Likely not all of these are required for Chrome, but we stuck to these rules and found that all videos worked on both platforms. Further research could likely determine the exact setting that is/was causing Chrome to not play the video.
I am running Windows XP, and chrome doesn't like the second one either.
My best guess of the cause is that, the working one is only 6.4 MB, but the other one is about 21.7 MB. Chrome might just be refusing to directly play a video that big. Have you tried having YouTube host it, and embedding their player into your site? That may solve the problem. (If you are worried about random strangers watching the videos, why did you post them here? Why would anybody even want to watch them? Though, you can make videos private on YouTube, in case these are just two videos that demonstrate the same problem you are facing with the real videos.)
That may also be compounded by a different problem that exists with both videos, manifested when I try to use Windows' built-in player. Both videos appear distorted when I use my computer's video player, stretched like 300% horizontally.
Are there other videos you have that fail in exactly the same way? Since these are only test videos for the real thing, if this is the only video with that problem, I would not say that it really is a problem unless it recurs. The dysfunctional video may have just run into that one-in-a-million chance that it has just the right contents for it to not work.
Here's the deal, through a huge series of events, I am stuck using Safari on Windows for video playback in HTML5.
I can't use any other browser, Chrome is out of the question, I must use Safari and it has to be on Windows for hardware compatibility.
The best format I've found is a h.264 Quicktime file, but I'm still getting some frames dropped and a bit of tearing.
The video is being played in 1920x1080 resolution and I have tried down-sampling to 720p, which causes noticeable quality loss and no noticeable gain in performance.
I'm looking for one of the following two as a solution:
- A plugin for Safari (that's Windows compatible) to use something other than Quicktime for HTML5 video. I've looked and the WebM (VP8) plugin is only for OSX.
- Any video format configuration that will decode faster in Quicktime on Windows. I've even tried ProRes to no avail, it's even slower than h.264.
Update...
Ogg Theora can be played in Quicktime with XiphQT, but I've ran into many issues when trying to playback various Ogg video formats.
With h.264, if you are using x264 (eg: Handbrake) to transcode/encode video, the following can be set in advanced mode:
cabac=0:ref=1:me=umh:bframes=0:weightp=0:8x8dct=0:trellis=0:subq=6:tune=fastdecode
These parameters:
ref=1, set the reference frame limit to 1, using more reference frames requires more processing.
bframes=0, disables b-frames, not sure on this but I believe that forces P-frame which are faster
cabac=0, disables CABAC compression, which would make the output smaller but take more processing
tune=fastdecode, set's the tune preset to optimize the output specifically for decoding
The other options I am not as sure of and have yet to find solid evidence on their impact towards decoding, let alone if they have any impact on decoding. For example, the "me" setting is for subpixel strength in the transcoding process, it has an effect on video quality, but understanding how frames change, it could have an impact (in some videos) on the decoding process. That is something I do not know, but am stating for a better understanding of where I am coming from.
More about these settings can be found here:
http://mewiki.project357.com/wiki/X264_Settings
I have to play an ogg audio file in the background when the user hits a "Music On" button. Currently the page uses an AUDIO tag, and it works in Firefox, but not in IE (confirmed by this table).
Is there a really cross-browser way to play an ogg audio file, if possible without Flash?
I am aware of the existence of specific libraries like JPlayer or SoundManager, but do I really have to use one of them? After all, it is just to play a sound...
Forget about cross-browser. Stick with ogg. It's much better than mp3 in every way. Tell people to change their browser to one which supports ogg (e.g. Chrome, Firefox, Opera). If they don't want to change, then forget about them; they don't deserve to hear your audio. If your client doesn't understand this, leave him and let him waste money on one developer after another until he finds a "yes man" developer who will give him a terrible website that will be a nightmare to use and will need completely redeveloped in a year's time.
The Company I work for has dropped support for IE6 for apps and websites and dropped support for IE7 when it comes to apps. Personally, I don't want to be developing for IE at all until I met a friend of mine working elsewhere. She was allowed to work from home, but she had to use RDP (Remote Desktop Connection in Windows) thats supported as a web interface only via IE. Some companies use Windows Group policies to disable USB drives etc. The terminals in these companies can have IE only! So as much as I would hate to admit, cross browser compatibility is a serious issue.
Flash would be the number one choice of plugin to play ogg files. Now, the following scenarios may occur:
iOS (iPad and iPhone) : HTML5 Audio Tag
Android / Chrome / Safari : HTML5 Audio Tag
Opera
Firefox
IE
For 3, 4 and 5 it really depends on the user. Even if they have one of Real Player, QuickTime or Windows Media Player, the would be able to play ogg files. There is a case where the specific ogg codec is not installed. In this case they will get a prompt on the top of their browser, telling them to install the specific codec.
We are talking about people insisting on using IE or insisting on a really really old version of firefox and who don't have WMP (by default on Windows), RealPlayer or QuickTIme installed but have an Internet connection.
Even jQuery leaves out 0.0001% of users ! :-P
You can probably consider using a .wav file, but I'm not sure that works.
The simple answer: no, there's no way to do it without Flash. My approach: simply create a script that converts a single file to multiple encodings.