This video spreading across Discord is very intriguing...
The same webm file behaves as follows in the following browsers:
Browser / Player
Message
Chrome
"Discord detected on Chromium/Electron"
Firefox
"Discord detected on Gecko (Firefox)"
VLC
"Discord detected on Gecko (Firefox)"
Media Player Classic
"Discord detected on Chromium/Electron"
Edge
"Discord detected on Chromium/Electron"
Safari
Play bar loads but only plays first frame of video.
Epiphany
Play bar loads but won't play at all.
Edge (Legacy)
Won't load/play
IE11
Won't load/play
Windows 10 Movies and TV
Won't load/play
I'm well aware that the "Discord" part of the message baked-in to the video, but what about the rest?
I had originally suspected that the .webm file was somehow switching to a streaming method and using server-side headers to influence the video content, but I tried in a VM in airplane mode and it still worked.
My second thought is that since .webm-capable browsers can be split up into two groups: Chromium-based and Gecko-based, that this video has multiple video sources embedded and is taking advantage of a very specific browser incompatibility, like a magic trick that forces you to select a card.
Related
I am trying to use mediaRecorder API and make it run on maximum of browsers
video/webm;codecs=vp8,opus : that works fine on chrome and Firefox.. but not on Safari
video/mp4;codecs:h264 : works on Safari and Chrome.. but not on Firefox
It looks like Safari is now able to play webm.
What would be the mime type to use to make it run on both 3 browsers ?
I've been attempting the same thing and it is painful to say the least.
I'm able to use MediaRecorder to record video across Chrome, Firefox, Edge, and Safari. BUT the resulting videos do not playback on all browsers.
Safari - records in mp4 and mp4 will playback on all browsers
Chrome & Edge - I'm recording with mimeType: "video/webm;codecs=vp9", which will playback on Chrome, Firefox, and Edge, but not Safari.
Firefox - I'm using the default. It will playback on Chrome, Firefox, and Edge, but not Safari.
Supposedly Safari will playback webm with macOS Big Sur 11.3. I need to upgrade to test this.
Unfortunately webm is still not supported by iOS, so I'm looking into the Cloudconvert API to convert webm videos to mp4 before storing in S3.
Other suggestions welcome.
You'll need to use the MediaRecorder.isMediaTypeSupported API to find out what the browser you are using supports. See this open PR for details.
That does not help with playback however.
You've stumbled into an electropolitical food fight.
Sad to say, there's no commonality of codecs between browsers. You won't be able to find a common codec. Apple (Safari) is firmly in the H.264 / AAC world, the world of MP4.
Chrome, but not open-source Chromium, supports H.264 (which carries a patent burden). The fully open source Chromium browser does not. Firefox, via an automatically installed plugin from OpenH264.org, does, but it only supports H.264's constrained baseline version, not the fancier versions. Use MIME type video/webm; codecs="avc1.42E01F" and you'll be fine in Firefox and Chrome.
Microsoft new Edge supports the same stuff as Chrome.
WebRTC is rigged to allow endpoints to negotiate codecs with each other. In my opinion this is a kludgey way to patch this electropolitical squabble.
This is not a good situation. But it's Q1CY2021 reality.
as a simple answer that I found since it's not simply out there. Use a library like below to record in mp3. It's not supported by browser MediaRecorder natively, but libraries make it easy to encode to mp3
and then you have a blob or file that can be played in any browser and even mobile devices like ios
https://github.com/closeio/mic-recorder-to-mp3
I've tried a bunch of things to no avail. Setting the src of an audio element to the following base64 webm dataurl snippet and playing it works in most browsers, but is failing in Safari. Pasting the snippet in the location bar even works in Chrome.
https://gist.github.com/mayorbyrne/99e47f58eefcfe72e84e3e320d136c2c#file-gistfile1-txt
I am able to play a base64 encoded mp3 dataurl, as the following fiddle I found in another response works: https://www.jsfiddle.net/apo299od -- In addition, I've tried replacing the beginning of the snippet data:audio/webm with data:audio/mp3 (works in Chrome, etc), and that moves me further along, but the audio doesn't actually play, it just flashes the audio symbol in the browser for a quick second.
Just wondering if I am spinning my wheels here, or if there is a way to get this snippet playing in an audio element on Safari.
Safari on iOS doesn't support the Vorbis / Opus audio codecs in WebM and on desktop only via third-party extensions like the VLC Web Browser plugin. Safari on iOS 11+ / macOS High Sierra+ can play Opus only if it's in a CAF container.
Note: Safari on iOS supports low-complexity AAC audio, MP3 audio, AIF audio, WAVE audio, and baseline profile MPEG-4 video. Safari on the desktop (Mac OS X and Windows) supports all media supported by the installed version of QuickTime, including any installed third-party codecs
source: https://developer.apple.com/library/archive/documentation/AudioVideo/Conceptual/Using_HTML5_Audio_Video/AudioandVideoTagBasics/AudioandVideoTagBasics.html
Safari can support Ogg Opus files with WebAssembly decoding. You can see the demo and code below. Not as simple as using an <audio> element, but you will get faster, low-latency playback using the Web Audio API:
https://github.com/AnthumChris/fetch-stream-audio
I'm trying to serve some video content from a webserver, with the intention of supporting a reasonably wide set of browsers.
For iOS, as far as I can tell the way to go is to use HLS (HTTP Live Streaming) whereas on the desktop (and I guess Android?) MPEG-DASH is the state of the art. As a fallback I can provide a few static videos.
I've got this working on iOS with HLS and Chrome, Firefox, Opera, and Edge on desktop, but Safari on Mac just shows an activity spinner when I press play. As far as I can tell, this is because Safari tries and fails to use DASH as the playback method despite lack of Webm support and HLS being listed first.
For MPEG-DASH I have used Webm with VP9 and Opus, and my <video> tag looks something like this:
<video controls style="display:inline-block;max-width:174.22vh;max-height:98vh;width:98vw;height:55.125vw;background-color:#ccc;" preload="auto" poster="my-preview-image.jpg" data-dashjs-player>
<source src="myvideo/hls/playlist.m3u8" type="application/x-mpegURL">
<source src="myvideo/dash/manifest.mpd" type="application/dash+xml">
<source src="myvideo/myvideo-vp9.webm" type="video/webm; codecs=vp9,opus">
<source src="myvideo/myvideo-vp8.webm" type="video/webm; codecs=vp8,vorbis">
<source src="myvideo/myvideo-h264.m4v" type="video/mp4; codecs=h264,aac">
</video>
And I'm just importing the reference DASH implementation using
<script src="dash.all.min.js"></script>
I'm generating the HLS and DASH streams using ffmpeg from a high-quality master video exported from Final Cut Pro. The static Webm fallback files are also generated using ffmpeg while the H264 static fallback file is a lower-bitrate export from Final Cut Pro.
Is there a way I can either:
Tell DASH to respect the order of the sources and not jump ahead of the HLS stream
Or, not kick in if video/webm; codecs=vp9,opus is not supported by the browser.
Finally, if neither of those are possible, can I support multiple different codecs simultaneously with DASH? i.e. can I provide both VP9 and H264 DASH streams and have it pick VP9 over H264 where supported and otherwise fall back to H264 (higher bitrate or lower quality)? How would I go about producing that stream data?
From what you have shared, your browser will use the dashjs player when it encounters the video tag with the 'data-dashjs-player' attribute and the DASH player will focus on the formats it supports which do not include HLS.
As a crude solution you could check whether the browser can play HLS and use the native video tag if it can and your DASH player if it does not. Checking for HLS playback is a little undefined but the below approach appears to work at this time:
document.createElement('video').canPlayType('application/vnd.apple.mpegURL')
This should return 'maybe' on a browser which can play HLS (only Safari at this time AFAIK) and nothing if it can't - I just tested it on Safari and Chrome and it seems to behave like this.
Its worth noting that dash.js should be able to play MPEG DASH files on safari so it may be worth looking into the console or logs to try to find why it will not play your DASH video.
The title pretty say it all, a fully fonctional video.js player broke on safari for mac after moving the video on a distant media server. It works on chrome, firefox and IEs.
my first guess is a cross server issue, but it shoudln't work on others browsers if it was the case.
Using mediaelement.js with great success except for Firefox on Mac OS X where the video seems to load fine and display the correct duration and the play head scrubs - the only problem is that the video is blank unlike in Firefox on Windows and all other browsers.
We are using the single h.264 option.
Sporadically we also see this error in Firefox on OS X randomly on page load - Error: this.pluginAPI.playMedia is not a function
Anybody have any ideas?