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.
Related
I am currently working on a small project where I want to split an mp3 into frames, send them to a client (browser) through a websocket and then play them back using WebAudio (webkitAudioContext). My server is running nodejs and to transfer the data as binary, I use binaryJS. The browser I am testing with is Chrome 25.0.1354.0 dev, running on Ubuntu 12.04.
I have gotten as far as successfully splitting the mp3 into frames, or, at least, based on my tests, it seems to work. If I write the frames back into a file, mplayer has no problem playing back the file and also parses the header correctly. Each frame is stored in a nodejs Buffer of the correct size and the last byte of the buffer is always the first byte before the next sync word.
As an initial test, I am only sending the first MP3 frame. The client receives the frame successfully (stored in an ArrayBuffer), and the buffer contains the correct data. However, when I call decode, I get the following message:
Uncaught Error: SyntaxError: DOM Exception 12
My function, where I call decodeAudio, looks like this:
streamDone = ->
bArray = new Uint8Array(arr[0].byteLength)
console.log "Stream is done, bytes", bArray.length
context.decodeAudioData bArray, playAudio, err
The initial frame that I am trying to deocde, can be found here.
I have been banging my head in the wall for a couple of days now trying to solve this. Has anyone managed to solve this and sucessfully decoded mp3 frames, and see what I do wrong? I have found two related question on StackOverflow, but the answers did not help me solve my problem. However, according to the accepted answer here, my frame should qualify as a valid mp3 chunk and, thus, be decoded.
Thanks in advance for any help!
Turns out that a break and some fresh eyes can work wonders, a general code cleanup solved the issue. If anyone is interested in the code, I published it here.
I have a buffering issue.
On my page (which I access remotely), I have a video that I position using the currentTime attribute.
However, it seems like, despite the fact that I do not autobuffer, the video is still buffered until this position.
Is that correct?
Is there a way I can seek to this position without reading the video until this point in time?
Assuming you are referencing the video asset by http, you probably need to enable pseudo-streaming on your webserver, otherwise the entire video will be transferred even though the browsers might be sending the &start= parameters on the request.
Take a look here: http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v4/12207/video-delivery-http-pseudo-streaming
and another comment here: http://www.longtailvideo.com/support/blog/11887/html5-video-not-quite-there-yet
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.
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.