HTML5 has an onboard volume detection.
<video controls width="320" height="176" onvolumechange="alert('The volume has been changed')">
This is for the player only.
Is it possible to detect volume from the system? Say a phone. Can I get volume readings of my phone from the mobile browser?
Or can I use JS to detect if the audio jack is plugged in?
Can Volume level be detected for audio out using GetUserMedia?
Short answer for this is no!
This is how web-browsers have been made for a very long time now, and Microsoft/Google/Apple/Mozilla/Opera have done this to avoid exploits through File.IO and such. Actually, we should be thankful for this - as it isolates you computer (with all your personal stuff) from the web-application (which might be hosted on a server with hostile intentions).
Actually, there is one way you could do this, but it would only work for IE users - and the answer is activeX plugins. Now, you could make your javascript create such a plugin and communicate with it - but who knows if activeX will be supported by IE in the future.
So per se, there is no way this is achievable with HTML5/Javascript alone - just think of the browser as the OS on which your web-app is running. So Google, Microsoft etc + the rest of the people who decides the HTML5 standards are the ones who decides how much access the developer gets. Camera hardware, GPS hardware etc. we do get to access, but we are not allowed to do whatever we want with that hardware - its not always the developers choice.
Related
I tried to take a screenshot of a movie on the Disney+ web app when I realised that the video turns black as soon as I try to take a new screenshot with Snipping Tool. When I tried to do the same thing with OBS and Discord streams, I saw the same effect.
Interestingly, this only works for Chrome on my machine (I also tried Firefox and Edge and they just let me record my screen).
When I saw this, I became really curious on how they achieved this.
Does anyone have any idea how I can recreate this for my own web projects?
I became really curious on how they achieved this.
They use Widevine.
Widevine homepage.
https://ottverse.com/widevine-drm-how-does-it-work/
https://en.wikipedia.org/wiki/Widevine
News reports:
https://www.cordcuttersnews.com/sadly-disney-wont-work-on-chromebooks-linux-some-android-devices-because-of-drm/
https://www.tomsguide.com/news/disney-plus-will-work-on-chromebooks
https://www.androidpolice.com/2019/10/22/disney-will-only-work-on-devices-that-support-the-strictest-widevine-l3-drm/
It's also used by Netflix, Hulu and others.
Widevine is Google's DRM system that's baked-in to Chrome.
All other major browsers have adopted it as well, because no-one will use a browser that can't access Netflix.
Mozilla's and Microsoft's support is less user-hostile and as you noticed.
It's just a standard HTML5 <video> element - when the browser downloads the video stream it will see that it's encrypted with Widevine and that engages the Widevine client-side code which does all the DRM biz.
Though there are HTML and DOM features that facilitate DRM, I'm unsure of the extent that any JavaScript is required to use it - as theoretically everything the browser needs to know to load the DRM system should be embedded in the raw media stream.
On Windows, I understand (though unconfirmed) that Widevine makes use of SetWindowDisplayAffinity to block screenshots.
Nothing stops you from doing this in your own native code (e.g. if you had an Electron fork), but please don't because it's a real dick-move to your users, in addition to not working at all if the user has the DWM disabled (e.g. they're running Windows 7 with Aero disabled).
Has anyone any idea how I can recreate this for my own web projects?
You'll need to license Widevine yourself. This is a complicated process intended only for large media production companies and content rightsholders, not individuals or small businesses.
Anyway, even if you could, please don't. Why would you want to make to harder for users to share and appreciate your media? Just stick it up on YouTube instead.
This question is mainly geared towards audio engineers.
I was looking at a few videos here and here concerning the Web Audio API in javascript and how people are using it to make music. I was wondering can this API be used to create sound quality on the level of existing Digital Audio Workstations (DAWs) like Ableton, FL Studio, Reason, Logic, etc.
Or is there some kind of inherent limitation to the browser? I think VSTs cannot be used by Web Audio API, but regardless of VSTs is there something that an audio engine used by DAWs can do that Web Audio cannot do in terms of quality? Or can the sound be just as good. I believe that samples can be played just as effectively (?), but maybe the synthesis would be limited?
Can HTML5 Web Audio be as high quality as a DAW?
Yes! Browsers use a high quality audio engine, with floating point samples all the way through.
Additionally, the API itself is one of the most straightforward to use and is quite extensible. It also supports very specific timing of control.
I think VSTs cannot be used by Web Audio API
That is correct.
but maybe the synthesis would be limited?
There are no real fundamental limitations. If you can code it, you can do it.
Now, there are a couple things you didn't ask about but still should know about. The first is an issue of latency. Browsers don't use ASIO or anything like that, so if you're using the Web Audio API to process and return low latency audio, you're going to have a bad time. In Chrome, you can improve this by letting Chrome open the audio device in exclusive mode.
Another issue is input/output channel count. This typically maxes out at 8 channels. Internally though, you can do pretty much whatever you want. The limitation is from the browser, not the Web Audio API itself.
There are some high quality audio applications that could run in the browser, but you can only do realtime audio in Chromium-based browsers, and you can't get realtime input even then.
Only Chromium supports high-priority audio threads in Audio Worklets, which you need for stable, realtime audio.
The WebMIDI API only runs on the main thread, which makes it useless for realtime input.
The WebUSB API is threadable, but does not permit communication with audio-class devices (which includes MIDI controllers (and soundcards)).
Keyboard, touch and mouse events must (currently) be handled by the main thread.
So, in short, you have no (practical) way to control realtime audio in Chromium, and cannot even do realtime audio (reliably) on any other platform.
Note: Adding support for WebMIDI workers was requested nine years ago, and the issue is still open (just for adding it to the spec).
Note: Electron will allow you to access protected USB device classes (Audio/MIDI), but Electron WebUSB support is still in progress. NWJS has WebUSB support, but no way to access protected device classes (though I opened an issue recently). WebUSB will work on these platforms eventually, but you would still need to implement web drivers for your controllers (even class-compliant ones), so this will not be an ideal solution, even once it it works.
Taking a photo from the browser on an Android or iOS device isn't hard, as we all know. Just use a file input field and add a parameter called capture. However, as far as I know, not a single browser for Windows 10 does support that tag.
The requirement is to take high-res photos on a Surface Pro tablet and annotate them immediately from within a website. Right now, I'm using getVideoTracks as a halfhearted fallback for Windows devices. This, though, has some serious drawbacks, namely a significantly reduced image resolution (only 2 MP) and a great loss in color depth and control over the camera, just to name two of them. Switching between the native camera app and the website and uploading the pictures through a regular file input is also not an option in our productive environment.
Is there any way to trigger the native camera app on a Surface Pro from JavaScript and use the captured photos immediately? Or a browser which already supports the ImageCapture API? Chrome crashes with the error message "DOMException: setOptions failed", even when running the official samples, which seems to be a known bug for ages. Or is there a Windows browser which supports the capture attribute on input fields?
Thank you in advance for your help!
To preface this, all of my experience has been with developing Ruby on Rails web apps serving, essentially, text data - I don't have any experience yet with rich media.
I'm looking into developing a music notation app (for practice and because I'm dissatisfied with many of the current options), and am trying to determine whether or not to build a native app or a web app. Since all of my programming experience lies in web development, I would prefer to make this a web app if I can, because if I chose to go native I would need to find a decent cross-platform solution in addition to the usual pitfalls of developing natively.
I suspect that even with HTML5 I wouldn't have access to enough processing power to make a browser-based audio engine feasible. It would need to have the ability to play and sequence not a single large .wav file of a song, but many short .wav files concurrently and in sequence. There would be no need for recording - only playback.
But since I've never done this before I really don't know if this is possible. So, I wanted to pose this to more experienced HTML5 media developers:
For modern browsers (I'm not too concerned with support for older browsers), would such an audio engine be feasible? (As in, is the current landscape of JS libraries and the HTML5 audio API sufficient for building something like this?) Or would something like this be far too CPU / memory hungry in a browser?
Thanks!
In my experience Chrome and Firefox for desktop both work great with multiple, sequenced, .wav files embedded in audio tags. You can trigger them with JavaScript and it all seems to work great.
Unfortunately, Mobile Safari seemed to be unhappy with more than one audio tag playing at once, and Chrome for Android had similar limitations. This was a year ago, so things might be different now.
Since we were targeting iPads, we wound up using Phonegap to mix in some native sound libraries into our HTML & JavaScript app. One gotcha that tripped us up: if you want looping audio samples, stick to .wav files; .mp3 files have some silence at the start and end that's really tricky to get rid of.
I've been investigating Web Audio Api to build synths, and it's still very primitive and difficult to use. The infrastructure seems to have had a boost when Web Audio was introduced, but not much development since. Mobile audio on the web is rarely mentioned, too clunky, or unsupported.
At the same time, JS has become significantly faster with the V8 engine, JS loading can happen as needed, asynchronously, and non-blocking, which may solve many of the CPU/memory concerns you have. Look into NodeJS and various module loaders such as webpack, ES6, for more info.
I think there will be attention to web-based music apps because the web can support multiple users. That could be a good reason to keep pushing through these murky waters.. especially if you're talking concurrent connections.
See Molgav tracker. It works on desktop and mobile, it uses hundred of sampled instruments, it has UI adapted for small mobile touchscreens. See how examples sounds.
Whether is it possible to get default media player using Javascript, customize play controls and control play functions (Play, Stop, Seek, Pause..etc)
Thanks in advance,
Sri
No. The operating system's idea of a default media player (if it even has such a concept) is not accessible to the web browser, and most media players can't be controlled from a web page's JavaScript code anyway.
(With good reason: exposing a highly complex program like a media player to the Internet is a dangerous proposition. If just one bit of code in the handling of any format the player can read has an exploitable bug, then now every web page you visit could embed a media player and use the security hole to take over your machine. Indeed, this has happened many times in the past with Windows Media Player, QuickTime and RealPlayer, even though they were designed to be Internet-facing.)
You can embed a particular media player that was designed for it, and fall back to another media player if not available. So you could try to embed WMP, then fall back to QT if that failed, and fall back to Real if that failed.
But really, the days when it made any sense to do this are long gone. Today's it's all about the HTML5 and Flash video. The embedding of media players is dead, and good riddance to it.
I'm not sure what you mean but if you're talking about Windows Media player specifically I'm sure their embed version will have some skin Params, etc., you can play with.
Although I would advise you to take a look at HTML5 Media Player (http://html5demos.com/video) which is customizable and controllable via JavaScript
Here's a certified library that would be helpful in pushing html5 to the limit when it comes to video embedding: http://www.kaltura.org/project/