I have a thing I'm doing where I need a webpage to stream a series of images from the local client computer. I have a very simple run here: http://jsbin.com/idowi/34
The code is extremely simple
setTimeout ( "refreshImage()", 100 );
function refreshImage(){
var date = new Date()
var ticks = date.getTime()
$('#image').attr('src','http://127.0.0.1:2723/signature?'+ticks.toString());
setTimeout ("refreshImage()", 100 );
}
Basically I have a signature pad being used on the client machine. We want for the signature to show up in the web page and for them to see themselves signing it within the web page(the pad does not have an LCD to show it to them right there). So I setup a simple local HTTP server which grabs an image of what the current state of the signature pad looks like and it gets sent to the browser.
This has no problems in any browser(tested in IE7, 8, and Chrome) but Firefox where it is extremely laggy and jumpy and doesn't keep with the 10 FPS rate. Does anyone have any ideas on how to fix this? I've tried creating very simple double buffering in javascript but that just made things worse.
Also for a bit more information it seems that Firefox is executing the javascript at the correct framerate as on the server the requests are coming in at a constant speed. But the images are only refreshed inconsistently ranging from 5 times per second all the way down to 0 times per second(taking 2 seconds to do a refresh)
Also I have tried using different image formats all with the same results. The formats I've tried include bitmaps, PNGs, and GIFs (GIFs caused a minor problem in Chrome with flicker though)
Could it be possible that Firefox is somehow caching my images causing a slight lag? I send these headers though:
Pragma-directive: no-cache
Cache-directive: no-cache
Cache-control: no-cache
Pragma: no-cache
Expires: 0
The lag may be caused by the way Firefox handles DNS queries and support for IPv6.
Try turning off IPv6 lookups and see if that solves the lag.
Ok so turns out this is one of the many leaks of Firefox. I had my firefox session running for days. I restarted it just now and opened up the page and it(and other javascript stuff) ran up to speed. With it being restarted I can now get down to even 50ms refresh rates, though it's not required.
So there isn't really a "fix" to this problem other than to restart firefox every once in a while.
Maybe you've tried this; you said you'd tried "double buffering", but this wouldn't be quite the same. Instead of having one <img> tag whose "src" you update, have several (10, maybe). Start them off all "display: none". Handler the "load" event on the <img> tags with a function that hides every other <img> except itself. Have your interval timer (which should be an interval timer, probably, and not a series of timeouts like that) iterate through the list of tags, much like it does now.
Will that smooth things out? I'm not sure. I'd certainly try it.
Related
I am using video.js to show video content. I have a program that handles the streaming requests so the source of the video tag is set to a program which serves up the requested bytes.
The issue is that Chrome is requesting the entire video, range header on the GET request:
Range:bytes=0-
What I need to happen is that Chrome requests the minimum amount of bytes in order to start playback. I understand that this could lead to a lag due to the high number of requests being made, but it's what I need :(
Does anyone know how I could limit the buffer Chrome uses for this element?
There is a similar question here: HTML5 audio/video stop buffer
I've tried setting preload to none. This works in that it prevents the initial buffering from taking place, before the user has click play. But once it starts, it requests the entire range :(((
Many thanks,
Arvy
Got it. The 206 Partial Content can be responded to with however many bytes you need to supply. The client (Chrome in my case) asks for more anyways as it didn't receive a full range the first time.
For example, here is the request header Range:bytes=1000048- This means that the client has requested the rest of the file starting at byte 1000048. The program does not need to respond with the full range, in my case I am returning only 500000 bytes, so I take the 1000048 and add 499999 to get the end byte and format the headers accordingly. Seems to work fine. Hope it helps someone.
I'm trying to play an mp3 file and I want to jump to specific location in the file. In Chrome 33 on Windows, the file jumps the correct position (as compared with VLC playing the mp3 locally) but in Firefox 28 on Windows it plays too far forward and in Internet Explorer 11 it plays too far behind.
It used to work correctly in Firefox 27 and earlier.
Is there a better way of doing this?
EDIT: The problem doesn't even require SoundManager2. You can replicate the same issue with just the <audio> tag in Firefox. These two lines are all the code you need to reproduce it:
<audio autoplay id="audio" src="http://ivdemo.chaseits.co.uk/enron/20050204-4026(7550490)a.mp3" controls preload></audio>
<button onclick="javascript:document.getElementById('audio').currentTime = 10;">Jump to 10 secs "...be with us in, er, 1 minute... ok" </button>
Try it here: http://jsfiddle.net/cpickard/29Gt3/
EDIT: Tried with Firefox Nightly, no improvement. I have reported it as bug 994561 in bugzilla. Still looking for a workaround for now.
The problem lies in the VBR encoding of the mp3.
Download that mp3 to disk and convert it to fixed bit rate, say with Audacity.
Run the example from disk:
<audio autoplay id="audio" src="./converted.mp3" controls preload></audio>
<button onclick="javascript:document.getElementById('audio').currentTime = 10;">
Jump to 10 secs "...be with us in, er, 1 minute... ok" </button>
and it works fine for me.
So my suggestion for workaround is is to upload an alternative fixed-bit mp3 file in place of the one you are using. Then it should work in the current FFx.
I work on SoundJS and while implementing audio sprites recently ran into similar issues. According to the spec, setting the position of html audio playhead can be inaccurate by up to 300ms. So that could explain some of the issues you are seeing.
Interestingly, your fiddle plays correctly for me in FF 28 on win 8.1 if I just let it play through from the start.
There are also some known issues with audio length accuracy that may also have an effect, which you can read about here.
If you want precision, I would definitely recommend using Web Audio where possible or a library like SoundJS.
Hope that helps.
I met the same issue, and I solved it by converting my MP3 file to the CBR(Constant Bit Rate) format. Then, it can solve the inconsistent issue between the currentTime and the real sound.
Choose the CBR format
Steps:
Download and install "Audacity" (it's a free for any platform)
Open your MP3 file
Click [File] -> [Export] -> [Options] -> [Constant] (See: Converting MP3 to Constant Bit Rate)
Audacity will ask you to provide the LAME MP3 encoder
(See: [download and install the LAME MP3 encoder])
There will be no inconsistent/asynchronous issue.
Also see:
HTML5 audio starts from the wrong position in Firefox
Inconsistent seeking in HTML5 Audio player
tsungjung411#gmail.com
I just tried your code with another audio url here, it seemed to work and i did not experience a delay of any sort in Firefox( v29) which i did previously.
<audio autoplay id="audio" src="http://mediaelementjs.com/media/AirReview-Landmarks-02-ChasingCorporate.mp3" controls preload></audio>
I guess to jump around an audio file, your server must be configured properly.
The client sends byte range requests to seek and play certain regions of a file, so the server must response adequately:
In order to support seeking and playing back regions of the media that
aren't yet downloaded, Gecko uses HTTP 1.1 byte-range requests to
retrieve the media from the seek target position. In addition, if you
don't serve X-Content-Duration headers, Gecko uses byte-range requests
to seek to the end of the media (assuming you serve the Content-Length
header) in order to determine the duration of the media.
Hope this helps..
You could also try looking into Web Audio API for sound-effect-like playback which gives you some guarantees about the playback delays.
After testing the fiddle it is noticable that there is some issue with FF , anywho , after searching sometime , the issue is due to "Performance lag" , but the good news is that someone has found a solution to that issue , you may want to read this :
http://lowlag.alienbill.com/
a single script will solve it all.
I have two pages, A and B. The flow is as follows:
Go to A
javascript Ajaxes a bunch of content to add to A, forming A'
go to B
pressing [Back] goes back to A, not A', without all the Ajaxed content
Has anyone else noticed this, and if so, how do you fix it?
If Chrome was caching the A' state just before going to B, and reproduces A' upon back, that would be acceptable. If Chrome simply re-loaded the entirety of A (including the Ajax requests that transformed it into A') that would work too. The current behaviour, which is loading an old, incomplete version of A, is not what I want.
EDIT: I know it's loading a cached version because the server isn't receiving any new requests when i hit [Back].
This topic is old but thought I would share my solution. To get Firefox, Chrome and Safari to behave consistently, you have to set an unload handler on the page that needs to be reloaded when going back, and also use cache busting headers.
Example
In HTTP Headers
Cache-Control: must-revalidate, no-store, no-cache, private
And in the javascript for the page
$(window).unload(function(){}); // Does nothing but break the bfcache
Read here for more info: http://madhatted.com/2013/6/16/you-do-not-understand-browser-history
I know that topic is old but solution to this problem is not so easy to find I've just wasted few hours to solve it. These two lines solved the Chrome problem for me:
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.SetNoStore();
Well, if you are using xhr request and not hidden frames the back and forward buttons do not tie in to xhr request
I have a dashboard web-app that I want to play an alert sound if its having problems connecting. The site's ajax code will poll for data and throttle down its refresh rate if it can't connect. Once the server comes back up, the site will continue working.
In the mean time I would like a sound to play each time it can't connect (so I know to check the server). Here is that code. This code works.
var error_audio = new Audio("audio/"+settings.refresh.error_audio);
error_audio.load();
//this gets called when there is a connection error.
function onConnectionError() {
error_audio.play();
}
However the 2nd time through the function the audio doesn't play. Digging around in Chrome's debugger the 'played' attribute in the audio element gets set to true. Setting it to false has no results. Any ideas?
I encountered this just today, after more searching I found that you must set the source property on the audio element again to get it to restart. Don't worry, no network activity occurs, and the operation is heavily optimized.
var error_audio = new Audio("audio/"+settings.refresh.error_audio);
error_audio.load();
//this gets called when there is a connection error.
function onConnectionError() {
error_audio.src = "audio/"+settings.refresh.error_audio;
error_audio.play();
}
This behavior is expressed in chrome 21. FF doesn't seem to mind setting the src twice either!
Try setting error_audio.currentTime to 0 before playing it. Maybe it doesn't automatically go back to the beginning
You need to implement the Content-Range response headers, since Chrome requests the file in multiple parts via the Range HTTP header.
See here: HTML5 <audio> Safari live broadcast vs not
Once that has been implemented, both the play() function and setting the currentTime property should work.
Q: I’VE GOT AN AUDIOBUFFERSOURCENODE, THAT I JUST PLAYED BACK WITH NOTEON(), AND I WANT TO PLAY IT AGAIN, BUT NOTEON() DOESN’T DO ANYTHING! HELP!
A: Once a source node has finished playing back, it can’t play back more. To play back the underlying buffer again, you should create a new AudioBufferSourceNode and call noteOn().
Though re-creating the source node may feel inefficient, source nodes are heavily optimized for this pattern. Plus, if you keep a handle to the AudioBuffer, you don't need to make another request to the asset to play the same sound again. If you find yourself needing to repeat this pattern, encapsulate playback with a simple helper function like playSound(buffer).
Q: WHEN PLAYING BACK A SOUND, WHY DO YOU NEED TO MAKE A NEW SOURCE NODE EVERY TIME?
A: The idea of this architecture is to decouple audio asset from playback state. Taking a record player analogy, buffers are analogous to records and sources to play-heads. Because many applications involve multiple versions of the same buffer playing simultaneously, this pattern is essential.
source:
http://updates.html5rocks.com/2012/01/Web-Audio-FAQ
You need to pause the audio just before its end and change the current playing time to zero, then play it.
Javascript/Jquery to control HTML5 audio elements - check this link - explains How to handle/control the HTML5 audio elements?. It may help you!
Chrome/Safari have fixed this issue in newer versions of the browser and the above code now works as expected. I am not sure the precise version it was fixed in.
I have a page that includes a dynamic js-script depending on the page I'm visiting. However, I'm getting errors in my log from some IE8-visitors, where it seems like the actual request-url is completely mangled for the mentioned script.
This is what it should fetch:
<script type="text/javascript" src="?partial=filterjs&json=true&viewall"></script>
which translates to /sv/5/outlet?partial=filterjs&json=true&viewall
However, looking in my logs, I see stuff like:
/sv/5/outlet?partial=filterjs&json=truepor</a></li></ul></h2></li><li%20class=
/sv/7/jackor?partial=filteent/view/teams
It seems to truncate the url, and append random stuff from the actual markup that comes later on (way later on, in fact, although approx at the same offset)
I first thought it had something to do with the new XSS-filter that IE8 implemented, but tried disabling it using the HTTP-header
X-XSS-Protection: 0
Without success.
I cannot reproduce this error on my own machine either, however this happens several times a day (on a site with approx 3000 visits per day). This is happening on both XP, Vista and Win7 according to the user-agent (NT 5.1, 6.0 and 6.1).
Anyone recognize this behaviour?
Yes, this is a known bug in the lookahead downloader in Internet Explorer, where it drops a 4k part of the page when doing lookahead downloads.
This sometimes means that an URL for a resource in the page is cut and combined with some other text later in the page, resulting in a bad URL being requested.
The lookahead downloader is only used to try to fill the cache beforehand, when the resource is actually needed in the page it will be requested with the correct URL, so the user doesn't experience any errors in the page because of this.