I am building an HTML5 web game, a spin on the classic asteroids game to be precise. The problem I'm running into is that Safari, unlike Chrome or Firefox, will NOT automatically cache and use .wav sound files. This is causing substantial lag if there are an abundance of sounds occurring. On each instance of needing a "shooting" sound, the browser will perform a new GET request to obtain the audio file, as seen below:
you will see that the 151013__bubaproducer__laser-classic-shot-2.wav is the shooting sound that is being requested through the network over and over again and is not being cached. In an attempt to force Safari to cache this file, I've created an Asteroids.manifest file for the appcache to utilize:
Yes, that is the correct directory location relative to both the index.html as well as the Asteroids.manifest. And the manifest file does appear to be consumed, as it is visible in Safari's debugger storage:
Please let me know if you have any suggestions, as I've tried a variety of different setups of the .manifest file, including naming it .appcache, ensuring that it is served up with a MIME type of text/cache-manifest, and removing the NETWORK/CACHE/FALLBACK fields
Edit note: the window.applicationCache.status() is 1 (Idle)
I think that Safari doesn't cache audio files even if listed in the manifest file. Have you tried encoding the audio as BASE64 string and decode/convert back to audio at startup? Have a look at the WepApi, it can probably help you with that process.
If you mean mobile, then there are some posts here: HTML5 offline video caching in mobile safari
In summary, there is an ~5mb limit for the cache in mobile Safari. There may be something similar on the desktop. Another poster said that audio & video are not cached by the iPhone since they are played by external applications. It seems the only workaround is to store them as base64 in the local database (or local storage perhaps also? - Just keep in mind that "in private" browsing disables it).
If not, perhaps something to consider if you do plan to target the mobile version.
Related
I’m currently working on a web application whose main purpose is streaming/timeshifting TV channels. Application is written in Javascript React framework and for web player we are using CookPete ReactPlayer with integrated hls.js. We have managed to successfully play live TV channels but unfortunately, we are experiencing some issues with timeshifting channels
Live streams are distributed over XtreamUI server as a m3u8 lists, and have this kind of format
example.org/live/username/password/channel_1.m3u8
So when a user is watching Live TV this kind of URL goes to the player source and CookPete player + hls.js are doing their magic with parsing/processing m3u8 list which results in playing video flawlessly.
Here comes the problem, for timeshift XtreamUI are using this kind of URL example.org/streaming/timeshift.php?username=XXX&password=XXX&stream=2&start=2020-04-26:19-23&duration=7
As you can see its PHP script which STREAMS raw bytes into the player. Here are response headers from /streaming/timeshift.php
As you can notice, the Content-type is video/mp2t which for some reason cannot be played in the browser environment.( Google Chrome, Mozilla Firefox, IE 11). This warning pops up.
On the other hand, Safari browser on Mac video is playing completely normal, but the request from Safari is a little bit different. This is a screenshot from Safari's console network tab. As you can see there are several requests with different byte-ranges.
We are seeking a solution which will provide playing timeshift video (video/mp2t content) in Google Chrome, Mozilla Firefox and IE 11. All suggestions/advices are welcome.
the Content-type is video/mp2t which for some reason cannot be played in the browser environment
This is because chrome and Firefox do not support mpeg transport streams, and safari does. hls.js works because it knows how to read a binary ts file, and rewrite it as mp4 fragment before sending to the the media source extensions buffer. You will need to do the same. Take a look at mux.js.
In Firefox install a codec by running this command.
sudo apt-get install libavcodec58
Install a similar codec in chrome too. It should fix the problem.
My application receives a RTP Stream (H264 or VP8), put it into Fragmented MP4 or WebM and send it over Websocket to my Javascript App where I display video using Media Source Extension.
Chrome works ok with both Codecs but Firefox shows a huge CPU usage, 50%-60%.
Chrome only 6%.
Javascript calls mediaSource.updateBuffer, wait for updateend and then call again mediaSource.updateBuffer. Nothing different as any example out there.
Anyone having also this problem with Firefox?
Without a lot more specific information (profiling your code, checking your browser flags and capabilities) it isn't possible to definitively say what the issue is.
I suspect that in Chrome, your codecs are hardware accelerated, and in Firefox they are not.
The problem is intermittent, but video.js is failing to load and play mp4's that have been cached in Chrome for OS X. Here's what I know so far:
Disable cache (while DevTools is open) allows the video to play 100% of the time on reload
If caching is not disabled, and cache is manually cleared the problem still happens
Closing and restarting Chrome will resolve the problem until the next page refresh
Appending a ?nocache=20131028-084318 to the source url does not resolve the problem.
Watching HTTP request using Charles Proxy, I see that on successful runs an HTTP request goes out to Brightcove (my video host). On failed refreshes, the request never happens.
On successful runs the sequence of VideoJS events:
loadstart
durationchange
loadedmetadata
loadeddata
On fails:
loadstart
I've tried a variety of ways of setting up the video element, including one noted here, Video.js Stalling during file load on iOS
and even the most basic setup noted here, https://github.com/videojs/video.js/blob/master/docs/setup.md The latter seems to work better; however, once the browser gets into a bad state clearing the cache and restarting the browser is required.
I'm having the same issue but in Chrome for Windows. I first noticed that it would only load when dev tools is open then I saw your question and realized the dev tools was bypassing caching.
If a user visits the page (on some browsers ie: Safari 6.1, etc...) the video will play the first time. If the user reloads the page by clicking in the address bar and hitting the 'ENTER' key, the video will not fire off it's LOADED/READY (or any other) events on the page 'reload'. This behavior does not happen if the user refreshes the page with the REFRESH button or REFRESH key combo (generally).
I bypassed my Brightcove player issues by dynamically loading the player on the page so it CANNOT be cached.
I also cache busted the Brightcove JS file for good measure.
Load player dynamically with this code:
http://support.brightcove.com/en/video-cloud/docs/dynamically-loading-player-using-javascript
Just some opinionated advice. Stay away form Brightcove whenever possible. My peers and I run into LOTS of bugs in their player as well as radically poor documentation.
I am not sure if this is specific to video.js. I am able to reproduce this problem by setting up a vanilla html5 video tag. It definitely looks to be related to some caching issue.
Currently, I am able to circumvent the problem by attaching a guid as a query parameter to the video url to ensure Chrome thinks this is a new video request. I do think there is a Chrome bug out there that needs to be addressed.
I Just found a ticket that matches what I can reproduce:
https://code.google.com/p/chromium/issues/detail?id=234779
I faced this problem and I solved it by disabling the cache to the javaScript file that contains the videojs instance options.
Add this line to your main page at the head
<script>document.write('<script src="vid.js?dev=' + Math.floor(Math.random() * 100) + '"\><\/script>');</script>
Note: vid.js is the file that I put the settings in..
Another solution that I didn't try, but I think it might work, is by adding the JavaScript of the settings in jQuery (ready function).
I'm trying to implement audio recording in a website. Basically the user should be able to press a button and speak something into the microphone. The recorded audio should then be sent to the server for further processing. I realise that you can do this with Flash, but for now I'm trying to avoid that.
I found several resources on the internet about it (i.e. link) but as it seems, this functionality is not widly supported yet. I experienced differences betweet the used browser and between the used operating system. For instance, the Chrome Browser doesn't seem to access any microphone on Linux correctly. So i was wondering if anyone knows a good resource to dive into this. Or maybe someone tried to set up something like this himself, and can help with some suggestions about where the limitations of HTML5 and the JavaScript Web Audio API are right now.
Thanks!
As of Chrome Version 27.0.1453.56 beta Mac, audio recording works with this demo application https://github.com/mattdiamond/Recorderjs
This app returns back a WAV file for the user which can be uploaded to the server.
If you want a truly robust solution that works on most desktop web browsers, you may need to resort to Flash.
This article covers up pretty well the current state of audio video capture possibilites using HTML5:
http://hdfvr.com/html5-video-recording
Also for just audio capture, here's a gitHub project that records audio to mp3 directly from the browser:
https://github.com/nusofthq/Recordmp3js
I'm working on a project using the HTML5 application cache to support an offline version of my application. When the user visits the application the first time, the browser automatically downloads all the files in the cache manifest file and saves them in the cache for offline use.
In Chrome, when the user navigates to a different URL (still within my application, which also references the cache manifest file), it will continue to download the files into the cache.
However, on iOS (I've tried iPhone, iPad, and iPod touch), if you navigate during the downloading progress, it seems to halt the process and subsequent pages do not download any files at all. In fact, the only way I can get it to restart the process of downloading files into the cache, I have to go into the Mobile Safari settings and clear the cache.
Am I doing something wrong? Or does the user actually have to wait on the same page until all the resources are cached (otherwise the cache is broken). It seems like there is maybe a bug in the implementation, but maybe someone has some experience with this problem?
Any chance you can post the content of your cache manifest? The first things I'd check are that (a) the relevant pages are listed in there, (b) the pages you navigate to have manifest attributes pointing to the cache file and (c) that you have an HTML5 doctype for each page.
You could try forcing a cache update programmatically too:
Safari Client-Side Storage and Offline Applications Programming Guide: Updating the Cache