I am trying to use video.js to play an mp4 file. It will not play in IE9. It plays fine in Firefox and Chrome. If I open the video in windows media player, it plays fine as well (perhaps IE9 and windows media player use the same codecs?). I have now confirmed that IE9 is not even requesting the file.
See example here: http://devonline.northcarolina.edu/lcl/ded_prod/exams/video/jstest.html
<html>
<link href="video-js/video-js.css" rel="stylesheet">
<script src="video-js/video.js"></script>
<script>
videojs.options.flash.swf = "video-js/video-js.swf"
</script>
<body>
Video should be here:
<video id="example_video_1" class="video-js vjs-default-skin"
controls preload="auto" width="640" height="264" >
<source src="http://devonline.northcarolina.edu/lcl/ded_prod/exams/video/student/invite.mp4" type='video/mp4' />
</video>
</body>
</html>
Two things to try.
Try putting the full path to the video in the src attribute, e.g.
src="http://www.mywebsite.com/path/to/the/video.mp4" as sometimes
IE needs this.
Failing that try re-encoding the video using something like Miro
Video Converter as not all MP4 files are the same and what one
browser can play another may not be able to.
This issue also exists in IE10.
There's something going on with HTTP compression in your example. If you use Fiddler to remove the outbound Accept-Encoding request header, your server properly avoids using GZIP compression on the response. Then IE has no problem playing back your video.
Generally speaking, you should avoid having your server GZIP MP4 content before returning it; it's bad for performance and rarely saves a significant number of bytes (since mp4 content is already highly compressed).
I figured it out. It was that the request was going through the CMS I was using. The CMS can't handle requests for partial files, so it just outputs the entire thing each time. So, in my .htaccess I made it so that my mp4 files would not be routed through the CMS anymore and it started working.
Related
<html>
<body>
<audio controls>
<source src="one.wav" type="audio/wav">
</audio>
</body>
</html>
We are compressing the audio files(.wav) files using sox api. It's playing(.wav) perfectly fine when its not compressed. After compressing it's playing only in safari browser and not working in other browsers.The same audio file i can play with any audio player.Is there anything we need to do in order to work this in all browsers?
we are using following sox command to compress file
sox source.wav -e ima-adpcm target.wav
Unfortunately there is no set of codecs that browsers are required to support. If one browser is capable of decoding a file it does not guarantee that another browser can do that as well. The only thing that helps is testing, testing and testing...
There is for example AreWePlayingYet which is an old site from SoundCloud which has basic checks for various formats. Although it only checks for uncompressed wav.
The good news is that you can always provide fallbacks by specifying more than one <source/> within your <audio/> tag. The browser will go through the list until it finds a file it can decode.
So what I'm trying to do is to play a HLS m3u8 file from an Backblaze B2 bucket that I have (via B2's S3 API) . The problem that I have is an HLS file is made up of both the .m3u8 file which keeps track of all the .ts files which are the parts that the .m3u8 file needs to play. So the problem I have is when putting the .m3u8 file into an HTML video tag nothing happens even in a browser where HLS files are compatible i.e Google Chrome.
I have checked other similar questions, but none of them seem to work, because the ts files are always missing.
I know the problem is the .ts files are missing but I have no clue how to reference them as well from my web server. Is there any way I can somehow play a HLS file and all its parts from a HTML video tag?
My current code is like so:
<video width="1920" height="1080" controls>
<source src="https://f002.backblazeb2.com/file/ARandomBucket/index.m3u8" type="application/x-mpegURL">
Your browser does not support the video tag.
</video>
Different browser have different support for video files and streaming formats.
Currently Desktop Safari and Edge latest version support 'native' HLS support but Desktop Chrome does not. You can see uptodate support info in a number places such as:
https://html5test.com/compare/feature/streaming.type.hls.html
By 'native' in this context, it means the browser can recognise the streaming format or file type when it is included as the 'source' attribute within the HTML5 tag and play it without any further code or plugins etc.
To allow you play your file back on Chrome at this time the usual approach is to use a Javascript Video player which will use the browsers support for Media Source Extensions (MSE) to interpret and prepare the HLS steam for playback. Some common open source examples include:
Video.js (https://github.com/videojs/video.js)
Shakaplayer (https://github.com/google/shaka-player/)
There are plugins available also for Chrome to play HLS if you do not want to use one of the above players for some reason for your solution, but these require the user to have installed the plugin, whereas the above players should work on any up to date browser release for the major Desktop browsers.
Okay so I've found a solution to my problem using video.js + video.js http streaming.
I needed to set my CORS rules on my Backblaze B2 Bucket, it's a setting on the screen with all your buckets to "Share everything in this bucket with all origins."
Next I just used this code segment using both video.js and the plugin for it for hls streaming for all major browsers with it which is video streaming https. Both of them just require a simple script tag from their respective cdns.
The documentation you need is found here: https://videojs.com/getting-started/ and here: https://github.com/videojs/http-streaming and you need both as they perform different functions.
So the code that I found finally works in my case is:
<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
<meta charset="utf-8">
<title>My Video</title>
<link href="https://vjs.zencdn.net/7.7.6/video-js.css" rel="stylesheet" />
<!-- For IE8 (for Video.js versions prior to v7)
<script src="https://vjs.zencdn.net/ie8/1.1.2/videojs-ie8.min.js"></script>
-->
</head>
<body>
<h1>My Video</h1>
<video-js id="my_video_1" class="vjs-default-skin" controls preload="auto" width="640" height="268">
<source src="https://f002.backblazeb2.com/file/ARandomBucket/index.m3u8" type="application/x-mpegURL">
</video-js>
<!--This is for Video.js by itself -->
<script src="https://unpkg.com/video.js/dist/video.js"></script>
<!--This is for HLS compatibility with all major browsers-->
<script src = "https://unpkg.com/browse/#videojs/http-streaming#1.13.3/dist/videojs-http-streaming.min.js"></script>
<script>
var player = videojs('my_video_1');
</script>
</body>
</html>
I have the following HTML5 video element in my test page:
<video width="1280" height="720" loop="loop">
<source src="http://d1dsyb3mv0b0i6.cloudfront.net/test/lines.mp4" type="video/mp4" />
Your browser does not support the video element.
</video>
I want it to loop its playback, so I set the loop="loop" (and I also tried simply loop), but for some reason Chrome 23 does not restart the video when it ends. I specifically moved the video to a Cloudfront Download distribution to get the partial content request support on the server, which is supposedly needed for Chrome to perform looped playback, but unfortunately that does not seem to make a difference. Note that in Safari all works fine. Then again, Safari has no trouble looping even a local video file, so it does not need a server with partial content request support.
It seems to be Cloudfront-related, since this movie does loop correctly: http://media.w3.org/2010/05/sintel/trailer.mp4.
Anyone any ideas?
You need to properly set the content-type metadata on the S3 object to reflect the correct MIME type of the file. Chrome tends to be more picky about this than other browsers.
I have uploaded trailer.mp4 to Cloudfront (S3) as well and that does work. This mp4 even works from the local file system, so unlike what I thought, I don't specifically need to play the video from a server that supports partial content requests. So it seems that the lines.mp4 video is somehow different from the trailer.mp4 video. I'm very curious to find what the difference is that makes this video not loopable by Chrome, whereas it loops fine in Safari...
Loop worked for me, but try replacing loop with the commands:
autoplay onended="this.currentTime=0"
or
autoplay onended="this.load()"
The second option results in flicker during the reload. The first ran smoothly, but currentTime can behave differently, depending on other settings. Hope that works.
I am trying to use Flowplayer to allow HTML5 video where available and use the flash fallback when it is not supported.
This works fine in Firefox and Chrome, however in IE9 it cannot find the video and below IE9 it just doesn't support the video.
Am I doing something wrong or is flowplayer not supported by IE?
Solution Summary
I was running into a similar issue and I think I have solved it, so perhaps this will fix it for you as well. My problem ended up being the MIME type for my .mp4 video file was being served as video/mpeg. When the video is served as video/mp4, it will load correctly on IE9. I did not test an .ogg file, but I have a feeling that the problem is similar.
Analysis:
I was a little puzzled because I was seeing the video work (in all browsers) on the main flowplayer demos page and also on this HTML5 Video Player Comparison page. However, I was feeling a little vindicated because their own developers were having trouble getting a consistent load, has been filed as part of a bug report, and their "fix" demo was not working for me either (but their main demo was!).
Deduction:
After completely mirroring their setup and following the setup documentation, my player was still not working in IE9, but was working in Firefox, Chrome, and IE8 (with flash fallback).
I decided to try loading their video, from their server, and it worked instantly. I inspected the network pane in IE9 and discovered the MIME type discrepancy. My servers were serving .mp4 files as "video/mpeg" when the flowplayer servers were serving the .mp4 file as "video/mp4". I know that the .mp4 file type is simply a container, and a video file depends on the underlying encoding scheme, but I had a feeling that IE9 is just picky on trying to decode video based on MIME type—it won't even attempt to play it if it isn't something it recognizes as playable. I had the network administrators change the MIME type and the same video which was failing earlier now works perfectly.
For reference, this is how I had my HTML set up:
in the head
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>
<script src="http://releases.flowplayer.org/5.1.1/flowplayer.min.js"></script>
in the body
<div class="flowplayer is-splash">
<video preload="none">
<source src="http://stream.flowplayer.org/black/470x250.mp4" type="video/mp4" />
</video>
</div>
Right here is a solution that seems to work for me....
Basically the flash fallback for flowplayer seems to just not work in IE...
The solution is to use the old Flowplayer flash plugin and use IE conditional tags like this:
<!--[if IE]>
<a href="videos/file.mp4"
style="display:block;width:520px;height:330px"
id="player">
</a>
<script>
flowplayer("player", "/swf/flowplayer-3.2.15.swf");
</script>
<![endif]-->
<!--[if !IE]><!-->
<div class="flowplayer" data-swf="swf/flowplayer.swf" data-ratio="0.417">
<video>
<source type="video/mp4" src="videos/file.mp4"/>
<source type="video/ogg" src="videos/file.ogv"/>
</video>
</div>
<!--<![endif]-->
After doing a lot of research and unable to add the header tag to force compatibility mode (because my video is inside a modal). I got it to work for IE9 by changing the source tag from
<source type="video/mp4" src="video.mp4"></source>
to
<source type="text/html" src="video.mp4"></source>
I saw that when the video was not being played in IE9, the mp4 file was being redered as text/html and not video/mp4... so I just tried changing the tag and it worked!
I know this does not make any sense... but since when IE makes sense?! So, if you cant set the header in your php file header('X-UA-Compatible: IE=EmulateIE8'); like in my situation, try setting the mp4 type to text/html
Is it possible to play a shoutcast/icecast stream using HTML5?
If so, how should I implement it?
2020 update
Modern browsers don't need any special treatment or server-side workarounds to play audio. Simply use an audio tag with a direct link to one or more stream sources (not a playlist):
<audio>
<source src="http://relay.publicdomainradio.org/classical.mp3" type="audio/mpeg">
</audio>
From MDN:
The HTML <audio> element is used to embed sound content in documents. It may contain one or more audio sources, represented using the src attribute or the <source> element: the browser will choose the most suitable one.
Browsers support flac, mp3, vorbis, aac, opus and wav. More details on caniuse.com.
Original post
Add a semicolon to the end of the http request. It IS the protocol set forth by shoutcast to override it's browser detection. Like this:
<audio controls src="http://shoutcast.internet-radio.org.uk:10272/;"></audio>
There is a big problem with SHOUTcast, which I suspect is responsible for it not working even in Chrome which is supposed to support MP3.
SHOUTcast can serve three different types of response:
a native-SHOUTcast “ICY” protocol streaming audio response. It decides to do this if the player accessing the stream includes an icy-metadata: 1 header.
a plain-HTTP streaming audio response, without extra metadata, for media players with no ICY support.
the “SHOUTcast D.N.A.S. Status” page and other pages on the web interface.
How does it decide whether to serve a web page instead of an audio stream? It guesses whether you're using a web browser. By looking to see whether the User-Agent header starts with Mozilla/.... Because all web browsers are Mozilla, right? Jeez, SHOUTcast.
So when Chrome tries to fetch the audio stream to play, SHOUTcast thinks it's a web browser (well... it is) and refuses to give it the audio stream to put in the audio tag. Instead it gets the admin web page.
(I would guess Safari is passing the icy-metadata header to avoid the problem, having specific support for SHOUTcast. I can't test it at the moment as Safari won't play audio or video. Maybe it wants me to install QuickTime for that. Maybe it can go get stuffed.)
So you'll probably need to add a Flash audio player as fallback.
<audio src="http://85.25.108.20:8090/;" controls autoplay></audio>
This should work fine, but make sure /; is there after the stream URL and port. If you don't need autoplay, remove the "autoplay" tag.
Yes. But its only work in Safari
<!DOCTYPE html>
<audio controls src="http://shoutcast.internet-radio.org.uk:10272/"></audio>
Cause Opera and Firefox did not support non free Codecs
see here: Is it possible to play shoutcast internet radio streams with html5?
On redirecting problems with <audio> tag in Browsers try to add "/stream" at the end of the stream URL for preventing redirecting.
example:
not working:
http://live-radio01.xxxxxx.com/2TJW/mp3
working:
http://live-radio01.xxxxxx.com/2TJW/mp3/stream
I use Icecast with Easystream for streaming to both mac and pc. A Script Sets up the audio player called MP3 Sticky Player. swf
With the documentation support files the player just loads as below in both cases.
PC
<ul id="playlist" style="display:none;">
<li data-path="http://99.250.117.109:8000/stream" data-thumbpath="thumbnail of whatever" data-downloadable="no" data-duration="00:00">
</li>
</ul>
MAC
<audio style="width: 100%" controls="controls" autoplay="autoplay" src="http://99.250.117.109:8000/stream">
Your browser does not support the <code>audio</code> element.
</audio>
As we have removed images from any mp3 metadata we use a image loader that grabs the Icy-MetaData (FYI you will need at least PHP 5.4 to run correctly) and matches a directory of cover art for each players song that streams.
On Chrome 9x If your website works over https Your link for shoutcast stream url must be a https url, for example:
<audio controls src='https://ssl-1.radiohost.pl:7028/stream' type='audio/mpeg' align='cemnter'>
Your browser does not support the audio element.
</audio>