We built an internet radio streamer utilizing an icecast server streaming MP3 to Firefox via html5 audio tag. However, sometimes the streamer will stop for whatever reason (disconnection, etc) and when you restart the streamer, it begins streaming from the beginning of the session, which leads us to believe that its playing what is in the browser cache.
The only way to get streamer to play the actual live stream is to delete the history in Firefox. This doesn't happen in other browsers. This also happens if using the flash fallback instead of the html5 audio tag.
Thought about using the following script but didn't think it would apply to this scenario.
<meta http-equiv="Cache-control" content="no-cache" />
Any insight would be helpful. Thanks.
Note: See #MosheL's answer for a modern solution.
Old Answer (and probably still needed for SHOUTcast):
I've found that with SHOUTcast/Icecast streams, the only way to guarantee that you won't be playing from cache is to use the old method of adding a cache-busting URL parameter.
If your original stream URL is this:
http://1.2.3.4/someMountPoint
Then use JavaScript to generate a URL like this when playing:
http://1.2.3.4/someMountPoint?nocache=123456789
This ensures that caching will not happen, as to the browser, they are different resources.
icecast.xml
<http-headers>
<header name="Cache-control" value="no-cache" />
</http-headers>
Update (3/2020): on Chrome we need to solve one more problem with buffering live streams:
<audio controls preload="false" autoplay="false" .....
Related
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.
On iOS, and I think Safari, we have Apples HTTP Live streaming, which can take a playlist of video files in a certain format, buffer them one by one, and play them seamlessly back to back.
Is there any way to achieve this in other browsers? I can of course detect the video finishing, and then start buffering and playing the next one, but I want to remove the buffering by downloading subsequent videos as each earlier video finishes. I do not want to hack this by stacking up video elements and switching between them. There are various serious consequences to this method.
Perhaps if there is a way to use javascript to download the files into in-memory buffers and somehow point the video element to play from these buffers?
I've seen swapping in video elements for each segment tried, and it's never smooth.
There is an HTML spec in the works that defines exactly the process you're describing, concatenating media segments into a buffer that can be fed into a media element.
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
This isn't available in browsers today but is working its way into Chrome/Safari. Even when it is, it will take a good amount of work to implement this process.
Your best bet if you need it now would be to use a Flash player that can handle HLS, like OSMF, JWplayer, and soon Video.js.
In html5, you can preload videos, preload the meta information, or not preload at all. The only problem, of course, will be with Internet Explorer which will download everything or nothing at all (and not even show the controls).
This is all controllable with javascript, too. If you want to play them back-to-back automatically, though, this would need to be done with javascript or some third-party tool. Reading where the file is playing is accessible through the API.
I am working on a project related to vintage web designs. I would like to embed and autoplay a midi file but:
It doesen't work on IOS (I tried with my ipad)
On Firefox, sometimes the tune is not played, I don't know why.
Does the midi player depends on the browser or a plugin?
Can I find a univeral alternative to play my tune?
I am using the <embed> tag this way:
<embed src="tune.mid" hidden="true" autostart="true" autoplay="true">
I've referenced this question before and fell upon the answer of using the library midijs.
However, since that lib now has a bitcoin miner included, I've made a variant without the mining code:
https://kitchwww.github.io/midi/midi.js
It can be included and used in exactly the same way:
<script type='text/javascript' src='https://kitchwww.github.io/midi/midi.js'></script>
<a href="#" onClick="function(){
MIDIjs.initAll();
MIDIjs.play('path/to/yoursong.midi');}">Play My Song</a>
EDIT: updated to include an init function to be called on a User Gesture, as all audio must now be initiated from one.
Yes, the embed tag is reserved for plugins, which Mobile Safari doesn't support.
Take a look at HTML5 audio tag, which is supported by most browsers.
But please don't play music on a webpage... it's annoying - most either listens to music, have the speakers turned off, or are at the office.
Your HTML is OK. The problem is that some lower class browsers have lost the ability to play midi files. They have to install an add on. Real Player used to be a good solution, but now they are pushing a cloud subscription. There are plenty of other midi players around, but the users have to install one.
Browsers dropped support for playing MIDI files natively over time. You might want to try MIDI.js, a JavaScript based cross browser library.
Add the MIDI.js script to your webpage:
<script type='text/javascript' src='http://www.midijs.net/lib/midi.js'></script>
And then add a link to start playing:
Play My Song
Take a look at http://www.midijs.net for details.
For mid, and kar files, I suggest using vanBasco midi player as your default player. See the source on http://midkar.com/blues/blues_01.html
To Embed;
embed src="musicfile.mid" width=144 height=60 autostart=true repeat=false loop=false
(replace the "musicfile.mid" with the name of your midi file)
Use the HTML5 Audio tag. But like The guy before me said.... please reconsider music on your page.
<audio src="example.midi" preload="auto" autoplay="autoplay"></audio>
Well, here it is Aug 13, 2017 and don't you know embedding a bg midi on a web page is still a mystery.
In fact I'm pretty certain it can't even be done anymore (except IE's bgsound src, which still works fine for me).
But as for Firefox and Chrome, the solution provided by jofeu is a great work-around.
I only wish there was a way to embed so the midi just starts playing on page load, without having to click anything. I guess those days are gone.
Can I click on some time and eventhough the video is not downlaoded till that time and the video starts playing from the time I clicked?
If yes, what would be a better option for viewing streamed video- HTML5 or flash player like JW player? WHich one will have less lag?
HTML5 browsers generally don't support this, however I believe the video tag in Safari will work with the Apple HTTP Streaming format for this functionality. For something that works across all browsers, Flash Player can do it using either RTMP streaming or HTTP Streaming (either with our without OSMF to support this). Probably the easiest place to start is with OSMF, which supports both RTMP and HTTP streaming of video.
I have tested this with Firefox and Firebug and while you can "seek" to a point in the video without having to watch video preceding the point you wish to seek, this still causes the entire video file to download.
Indeed, each time you seek in Firefox 4, the entire video downloads.
This may change and improve as HTML 5 video implementations become more mature and may differ based on the actual browser being used.
More information on the test here:
http://www.stevefenton.co.uk/Content/Blog/Date/201106/Blog/HTML-5-Video-In-Real-Life/
I am experiencing some strange behavior of embedded audio (wav file) on HTML page.
I've got a page https://server.com/listen-to-sound, and a Wav file embedded in it via <EMBED/> tag, like this:
<embed src='https://server.com/path-to-sound' hidden="true" autostart="true" />
The page https://server.com/listen-to-sound is opened in IE 6 SP3 on machine#1 - the sound is played in the headphones.
The same page is opened on another machine(#2), with exactly same IE 6 SP3 version, privacy and proxy settings - there's no sound.
Totally, from 6 machines the sound is played on 2 and not played on 4. From these 4 machines, when the page https://server.com/listen-to-sound is opened in Opera, the sound is played.
I've triple-checked headphone connections, volume settings and other possible hardware and software driver issues: the problem is definitely in IE settings.
I've also checked https://server.com/path.to.sound URL - the 4 machnies that do not play sound fail to open this link, failing with an error like "Failed to download page".
Cleaning IE caches, temporary internet files, SSL certificate caches did not solve the problem either.
Googling gave me nothing special but old Flash trick to use <OBJECT> tag and <EMBED> tag to be written in Object's comments.
What have I missed? Have you experienced similar or related problems? How were they solved?
Do you have any suggestions on where the trick is? Do you know some IE "features" that might affect execution(playing, showing) of embedded objects?
I think the main reason is acting different on each computer/browser you're using is because it is a non-standard tag.
Getting media to play inside a web page has always been a bit of a pain. You may try something like this:
<object type="audio/x-wav" data="data/test.wav" width="200" height="20">
<param name="src" value="data/test.wav">
<param name="autoplay" value="false">
<param name="autoStart" value="0">
alt : test.wav
</object>
The above was taken from this site explaining how to use the object tag.
I have not found the solution, but I can confirm that the likely problem is the https:. I have found that windows media player does not play files with a full url/src leading to https. However, quicktime will. So, computers with quicktime will successfully play the file back while those with only WMP will fail.
One "solution" is to link to the http: (non-secure) version of the file.
I could'nt find any informations on this, but have you tried playing sound from Javascript ? I don't know if it's a viable workaround for you but this might be a solution.
You can find different ways to do it here: http://www.phon.ucl.ac.uk/home/mark/audio/play.htm
Hope that will help you.
In regard to your comment to jamesh, I would advise to provide instead a link to the audio file: some computers (mine at work) have no sound, not everybody is using IE, embed isn't part of HTML (it is a hack supported by various browsers, it isn't defined in HTML 4.01 Transitional DTD for example) and chances are the visiting browser have no plug-in to play your sound.
As your tests show, it is prone to problems...
At worst, provide a <NOEMBED> tag to supply the said link. Or nest various methods, like <object>. At least, Flash is supported by nearly all browsers.
Somewhere along the way, browsers changed operations like using flash and playing audio. I have tried java, html embeded code none is exact.. the only thing i noticed is if you make a link on another page to the page that suppose to play the music it will work every time. but many times it wont play if you take and put your music page url in url box.. the link is reliable to the music page.. Don't know why?
I have been working for a while on it. and of course there the difference between all the various browsers. The embedded code embed src='https://server.com/path-to-sound' hidden="true" autostart="true" />you showed before should work as long a sound file is there and if placed as first line after body statement.