How does chrome know which tabs are playing some sound? Alternatively, how does chrome know which tabs to put the speaker sign on?
This article may be useful:
From ghacks.net:
"Google Chrome uses an internal version of Adobe Flash which Google can use to determine when Flash is being used for audio playback.
Mozilla does not have that luxury. While it is working on a patch to display indicators when HTML5 is being used for audio playback, it cannot do anything about plug-in contents on its own."
Assuming that's correct, then from there it's not hard to imagine that if they know of every single instance of flash being used for audio playback, that they probably have an associated property indicating which tab it is on.
Related
Is there any way to take the system's sound as an input for the Web Audio API?
For example take a user's spotify music that is playing as an input and analyze it to do stuff with it?
There is a specification which almost does what you want. It's the counterpart of the Media Capture and Streams spec (aka getUserMedia()).
navigator.mediaDevices.getDisplayMedia();
The spec is called Screen Capture and as the name implies it is meant for capturing video and not audio. Capturing audio is optional and not yet supported by any browser if I recall correctly.
There is currently an open issue discussing audio-only support. Maybe it's a good idea to share your use case there.
https://developers.google.com/web/updates/2017/09/autoplay-policy-changes
A while back, Chrome changed their autoplay policy so that you can't autoplay a video unless it is muted, or the user has interacted with the web page.
I use HTML5 video as part of a digital signage application, but it's common that the page is never clicked - for example when launched automatically in Kiosk mode.
If I mute the video it can autoplay, then if I bind to the play event and try and unmute it causes the video to stop playing (I guess they thought of that). I've had no other luck with similar trickery.
I understand the reasoning behind this behavior and on a website it makes sense - but mine is not a website, it's an application.
Is there a way around this? For example, if I moved to being a Chrome Application/Extension would the policy no longer be enforced? I'm somewhat stumped and would appreciate any insight.
(Asking people to go to chrome://flags/#autoplay-policy is not really an option)
If you are able to control the launch of Chrome, then you should be able to launch chrome from the command line, or via a script, with a flag to ask it to ignore the requirement for a gesture - e.g.:
$ chrome --autoplay-policy=no-user-gesture-required
This flag changed recently which may cause some confusion or be relevant if using older versions - see this discussion for some background: https://groups.google.com/a/chromium.org/forum/#!topic/headless-dev/zxPyN5f8MAQ
According to Google, as of Chrome 55, Flash is disabled for sites unless they "only support flash." But, I don't see any explanation of what that means exactly.
We have a lot of legacy flash content. And, for the most part, we can host that content in a pretty thin wrapper. But, the DOM clearly doesn't consist only of an embed or object tag. It has a title, a div container for positioning, perhaps some analytics, etc..
At what point, from a technical perspective, does it transition from/to being "only" flash with respect to Chrome 55 and 56+?
Our current situation is that our new, thin wrapper "works for me." But, "works for me" is not an acceptable response to customer complaints. Until our very lengthy flash conversion project is done (1 to 2 years from now), we need to know where the technical line in the sand is.
If there's something official from Google or line in the Chromium source that makes it clear, that would be ideal.
after chrome version 55+, chrome prefer html5 over flash by default.
Before 55 version, client easily deactive/ active flash plugin by chrome://plugins. Unfortunately this removed. Also chrome changes the plugin list api. Before 55 version, we can check flash is in plugin list or not , now we can not check the plugin exist . About one year, chrome keeps supporting flash, but it will perefer html5 if your player support html5 too ( ie : rtmp for flash, hls or mpegdash for html5 )
chrome://flags/#prefer-html-over-flash
here it shows that html over flash is default ( default is active ).
Also chrome generate a module that
chrome://site-engagement/
Here is a rank about website, you can update the value, if 100% , flash automatically chosen. Otherwise flash is blocked.
For more details
read this presentation.
https://docs.google.com/presentation/d/106_KLNJfwb9L-1hVVa4i29aw1YXUy9qFX-Ye4kvJj-4/edit#slide=id.p
I can't watch Periscope without flash:
Since Periscope is pretty new and hype I find it a pity flash is required. My best guess then is that they simply can't.
But what is the technical restriction if one?
I can't say for sure about their own technical restrictions but they are serving the video in chunks of .ts files. It is not impossible for HTML5-based player to handle MPEG-TS streams so I can only assume this is a temporary solution.
Example of an HTML5 player handling .ts format is THEOPlayer. Also DailyMotion released an open-source JavaScript HLS streaming client. If others can already do it now, Twitter will do it soon.
Why Flash? :
It's an easy solution that works same on all browsers that it's installed onto so Edge, Chrome, Safari & Firefox etc so it will each give a consistent result to their user base without specific browser limitations (since it's a plugin).
Why assume temporary? :
First of all as you said it's still new (growing/developing). They have a few job openings for video programmers. This particular job opening requires "Ability to create an interface in HTML, CSS and JavaScript". They are currently using a Flash-based JW Player instead of a custom-made Twitter player. That will change in time.
I'm trying to build a html5 app, part of it requires the recording of audios whose length should be up to a minute and then encode it into 64 based, so I did quite a bit searching and didn't find a good answer.
Are there any ways to record an audio with Html5, Javascript or maybe local APIs on a html5 app, especially on an IOS device?
Html5 doesn't yet have a widely accepted method of recording audio. If you are targeting non-iOS, you can use flash, or any number of javascript wrappers that call out to flash( eg. http://www.sajithmr.me/jrecorder-jquery I think soundmanager2 will also work, but I'm not sure). For iOS, you still need to write an app. :(
Short answer is no for now. Because audio not yet implemented to HTML5 browsers yet.
Method is working but you can't capture any audio.
Well here is a detailed answer for you: Recording html5 audio
This may be too late for a response, but having said that, both Chrome and Firefox now fully support getUserMedia and you can use it along with the AudioContext interface if needed, to capture audio directly from the browser.
The following gitHub project records audio and saves it in MP3 format directly in the browser using just HTML5 and JS.
The audio recording is saved in base64 and can also be directly listened to from the browser after the recording is made.
The project can be found here:
https://github.com/nusofthq/Recordmp3js
and is an extension of RecorderJS that also uses libmp3lame.js.
If you wish you can read more details about the actual implementation:
http://nusofthq.com/blog/recording-mp3-using-only-html5-and-javascript-recordmp3-js/