I’ve tried several combinations of types and setting in (the excellent) mediaplayer.js, but cannot get BBC Radio 3 to play in Chrome. The stream URL is here, and the playlist from which it is taken is here.
The tag is:
<audio src="http://bbcmedia.ic.llnwd.net/stream/bbcmedia_intl_lc_radio3_p?s=1362261751&e=1362276151&h=47e8b2755e05d1a5ceeb665f116984de" type="audio/mp4" id="player"></audio>
Looking at Chrome’s inspector, I see that the network is calling the stream, but it just loads indefinitely, without audio starting.
Other streams are working fine (demo), but this particular one is problematic, and I assume it has to do with the AAC+ format.
Edit: The instantiation code is here, figure it’s clearer than pasting the whole thing in.
Edit 2: It works in Safari (Mac)! Which I assume is related to Quicktime. Which is why I believe that AAC+ is the issue.
See https://groups.google.com/forum/m/#!msg/jplayer/9Ks2Crfjwrg/jDCDBgv3qr0J. It seems that AAC+ support is somewhat odd. It also seems that AAC+ can be placed in various containers. like m4a and FLV. Also see stackoverflow.com/questions/4018596/aac-streaming-from-shoutcast-in-flash.
Firstly, which OS, which Chrome version did you test with?
AAC+ is covered by software patents so it isn't going to be available if your OS has disabled it in the ffmpeg library that Chrome depends on (on OS where Chrome doesn't bundle its own ffmpeg). If you are running something like debian or ubuntu it might be disabled by default for legal reasons. On Windows Chrome may have removed support from the bundled ffmpeg themselves to avoid liability issues.
Alternatively since AAC+ supports DRM it might be an issue with BBC encrypting or blocking the stream in a way that Chrome doesn't support.
If I'm right then there's probably no good solutions since you can fix it on your machine (with a custom Chrome/FFMpeg build) but not on your end-users side where it really matters. Flash supports AAC so you could fallback to a flash player using the codec fallback techniques described here but you might run into the crossdomain/licensing issues described here.
The MDN codec page claims Chrome 3.0 (but not Chromium) supports AAC in MP4 containers but it does not clarify whether that support extends to AAC+ (unless that's what they mean by "main only").
html audio player plays aac+ file in chrome browser.
<audio id="audio1" controls autoplay>
<source src="test.aac"></source>
</audio>
it does play aac+ streams if it is from SHOUTCAST v2.
(sometime crossdomain.xml must be exist in shoutcast folder for audition)
Related
So I'm putting together a very video-heavy project with self-hosted videos in HTML5. I've got my videos encoded in both H.264/AAC MP4 and WebM formats, and they work beautifully in Chrome, Firefox, Safari, Mobile Safari etc. All good.
This is the most basic version of my code (in the production site I'm running it with VideoJS on top, however whether it's there or not, this problem occurs so I've removed the code for it from this example):
<video preload="true" width="720" height="406" controls="true">
<source src="/55.mp4" type="video/mp4">
<source src="/55.webm" type="video/webm">
</video>
But Internet Explorer refuses to play ball. When I load up the page in IE 11, I just get a video decoding error:
In Internet Explorer's developer tools, I can see that it's getting a content type of video/mp4, and just to completely eliminate server issues I've tried it on both my local Apache install and my web hosting. If I use the console to get the playback error, I get MEDIA_ERR_DECODE : 3, which, according to the site I just linked to, means
An error has occurred in the decoding of the media resource, after the resource was established to be usable.
This tells me that there's a problem with the video encoding... but I can't see it.
The video files were originally exported as QuickTime videos from Adobe Premier or Final Cut Pro (I'm not sure which the video guy uses), and then run through Miro Video Converter to output MP4 and WebM formats. When I open the MP4 files up in VLC, it shows me the following information about the codecs in use:
I can't see anything wrong there; it looks exactly like every reference I've found online says MP4 video should be for maximum compatibility - H.264/AVC video and AAC audio.
Can anyone see anything wrong with what I'm doing? I'd love to be able to post an example video, however I can't due to privacy reasons. All the same any help would be greatly appreciated.
So this is somewhat embarrassing, but I did eventually figure it out.
The problem wasn't so much with Internet Explorer as it was the VM I was using to run Windows to test in Internet Explorer.
Essentially, I was running Windows 7 inside of a VirtualBox VM. When I (in desperation) sought out an actual physical machine running Windows... lo and behold it played!
I can only assume that the video drivers provided by VirtualBox didn't like decoding MP4 or something. The videos played fine in other browsers, but I'm guessing they decode/render video differently to how IE does.
I had the same issue recently with VirtualBox running Windows7 on MacOS. Solved by enabling 3D acceleration in the "Display" settings for the problematic VM.
The OP is a genius. I was struggling with this same issue for days and could only test on a windows machine today. This led me to change the configuration of my Parallels Desktop v15.
Im running IE 11 on Windows 8.1 and changed in the Graphics > Resolution > Advanced settings > Vertical synchronization should be ticked off.
Maybe this will help other people.
Maybe worth a shot: Rebooting Windows 7 within VMWare Fusion solved it for me.
I want to show a video on my website. I have created a .mp4 file and using the HTML5 video tag to add it to the html.
The problem is that it is not being displayed in chrome. I would also like to know how I can replay it again and again.
I too had the same issue. I changed the codec to H264-MPEG-4 AVC and the videos started working in HTML5/Chrome.
Option selected in converter: H264-MPEG-4 AVC, Codec visible in VLC player: H264-MPEG-4 AVC (part 10) (avc1)
Hope it helps...
After running into the same issue - here're some of my thoughts:
due to Chrome removing support for h264, on some machines, mp4 videos
encoded with it will either not work (throwing an Parser error when
viewing under Firebug/Network tab - consistent with issue submitted
here), or crash the browser, depending upon the encoding settings
it isn't consistent - it entirely depends upon the codecs installed
on the computer - while I didn't encounter this issue on my machine,
we did have one in the office where the issue occurred (and thus we
used this one for testing)
it might to do with Quicktime / divX settings (the machine in
question had an older version of Quicktime than my native one - we
didn't want to loose our testing pc though, so we didn't update it).
As it affects only Chrome (other browsers work fine with VideoForEverybody solution) the solution I've used is:
for every mp4 file, create a Theora encoded mp4 file (example.mp4 -> example_c.mp4)
apply following js:
if (window.chrome)
$("[type=video\\\/mp4]").each(function()
{
$(this).attr('src', $(this).attr('src').replace(".mp4", "_c.mp4"));
});
Unfortunately it's a bad Chrome hack, but hey, at least it works.
Source: user: eithedog
This also can help: chrome could play html5 mp4 video but html5test said chrome did not support mp4 video codec
Also check your version of crome here: html5test
(#Alston posted this as a comment, and it worked for me, and 9 others who also upvoted, so posting this as an answer to get more eyeballs on it:)
Simply re-encoding the video file with this FFMPEG command solves it:
ffmpeg -i input.mp4 -vcodec h264 output.mp4
This started out as an attempt to cast video from my pc to a tv (with subtitles) eventually using Chromecast. And I ended up in this "does not play mp4" situation. However I seemed to have proved that Chrome will play (exactly the same) mp4 as long as it isn't wrapped in html(5)
So here is what I have constructed. I have made a webpage under localhost and in there is a default.htm which contains:-
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<video controls >
<source src="sample.mp4" type="video/mp4">
<track kind="subtitles" src="sample.vtt" label="gcsubs" srclang="eng">
</video>
</body>
</html>
the video and subtitle files are stored in the same folder as default.htm
I have the very latest version of Chrome (just updated this morning)
When I type the appropriate localhost... into my Chrome browser a black square appears with a "GO" arrow and an elapsed time bar, a mute button and an icon which says "CC". If I hit the go arrow, nothing happens (it doesn't change to "pause", the elapsed time doesn't move, and the timer sticks at 0:00. There are no error messages - nothing!
(note that if I input localhost.. to IE11 the video plays!!!!
In Chrome if I enter the disc address of sample.mp4 (i.e. C:\webstore\sample.mp4 then Chrome will play the video fine?.
This last bit is probably a working solution for Chromecast except that I cannot see any subtitles. I really want a solution with working subtitles.
I just don't understand what is different in Chrome between the two methods of playing mp4
Encountering the same problem, I solved this by reconverting the file with default mp4 settings in iMovie.
I was actually running into some strange errors with mp4's a while ago. What fixed it for me was re-encoding the video using known supported codecs (H.264 & MP3).
I actually used the VLC player to do so and it worked fine afterward. I converted using the mentioned codecs H.264/MP3. That solved it for me.
Maybe the problem is not in the format but in the JavaScript implementation of the play/ pause methods. May I suggest visiting the following link where Google developer explains it in a good way?
Additionally, you could choose to use the newer webp format, which Chrome supports out of the box, but be careful with other browsers. Check the support for it before implementation. Here's a link that describes the mentioned format.
On that note: I've created a small script that easily converts all standard formats to webp. You can easily configure it to fit your needs. Here's the Github repo of the same projects.
Over a year ago we added an video page on our site. At the time OGV wasn't very good, and there was no good WebM encoders available, so we decided to use HTML5 and h.264 for webkit browsers (Chrome, Safari, etc.) and then fallback to Flash for other browsers (using the same h.264 source file.)
This has been working great for a while. Recently (month or two maybe, so over multiple Chrome versions - currently Version 24.0.1312.52 m) we discovered Chrome really lagging on the playback. We thought it was a server issue, so we upgraded the server, and it is still behaving the same. I remembered reading that Google wanted to drop h.264 and move everyone to WebM, and thought this performance was part of that. We converted some videos to WebM and tested them with Chrome and they lag just as bad. Same video (WebM) streams beautifully in FireFox, and the MP4 streams great in FireFox via the Flash plug in.
I went to YouTube and turned on the HTML5 video support, and found the videos to lag in Chrome too (when running at HD) while they play fine in Flash mode. (Even when HTML5 is enabled, some videos still play via Flash.)
Tested on both Windows 8 and Mountain Lion.
I've talked to co-workers and they are seeing the same issues. So it isn't just me. So my question is:
Is this an issue with our video encoding?
Is it a bug with Chrome?
Or is it just localized to us?
Is there a way to deal with this besides switching back to Flash?
This is the flag I mean. If the flag is disabled, the browser tries to use hw-accelerated video decoding, which I can grant provokes wrong and slow video renderization in some devices. If enabled, hw-accelerated video decode is never used, but the above mentioned problems disappear. It theorically increases decoding time in devices actually able to use such acceleration, but I've been working around this field for almost a year and I still didn't realize any difference in that matter. Still didn't get to know how to identify if a device will behave properly (the availability of this feature doesn't seem to grant its proper behavior) with such acceleration without testing, though.
According to this question, WebRTC is apparently already partly implemented on a development versions of FireFox, Chrome and Opera.
However, I read that video recording from device is not yet supported in the Chrome Canary build. Are there any implementations that allow for that at this stage?
A very late answer but alot is happening in this area so I thought I could give an update to those (like me) that finds this question by searching.
You can try using
RecordRTC
The video can be save to disk by using the saveToDisk function described in the link below:
http://muaz-khan.blogspot.se/2012/10/save-files-on-disk-using-javascript-or.html
The API for this is still up in the air, and as a result, isn't on Chrome's WebRTC v1 feature list. See http://blog.chromium.org/2012/01/real-time-communications-in-chrome.html
Full disclosure: I work for Ziggeo.
Ziggeo has a video recording api. We use WebRTC for recording on Chrome, Opera and Firefox, fall back to Flash on other desktop browsers and use input capture on mobile devices.
You can also roll your own WebRTC solution:
on Chrome and Opera, you have to record audio and video separately and encode them yourself in JS; then, send them to your servers and transcode them using e.g. ffmpeg to mp4s and other target formats
on Firefox, you can get a webm object for video and audio combined and send it to your servers.
You are looking for PeerConnection support, which lets you send audio/video (and other data) to peers (such as servers or other users.)
WebRTC PeerConnection support (without flags) landed in Chrome 23 as detailed in this Chromium blog post from October 2012.
At the moment only OpenTok and Lynckia are providing (beta-versions of) servers/services to record video with WebRTC.
From the existing major streaming servers only Wowza indicated that they are monitoring WebRTC but don't yet have plans for implementing it.
The answer, for now it seems, is "No". Chrome Canary is the furthest when it comes to implementing WebRTC, and they haven't built it either .
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.