It seems on the iPad (iOS v. 5.1.1), Safari does not keep a video element's readyState value according to specification. Even while loading from the video source readyState equals zero.
I've made a demonstration jsfiddle which continuously checks the video's readyState. A funny observation: the readyState changes only after clicking the play button.
Actually, I've expected the readyState to switch to a higher number during loading (as it is the case with all browsers on the desktop I've tested--including Safari.) Is there a workaround? Am I getting something wrong here?
From the Apple developer documentation:
Note: The preload attribute is supported in Safari 5.0 and later. Safari on iOS never preloads.
According to Apple the desired behavior on a mobile device is that loading only starts after you actively request the resource so as to not waste bandwidth or battery.
Regarding your question this means that Apple is adhering to the spec. Since no preload occurs and loading only starts after you click the play button the readyState is zero before that point in time.
However, the video tag has special events which are supposed to give more information than readyState.
onCanplay
onCanplaythrough
onProgress
Again, quoting the Apple developer library (Using DOM Events to monitor load progress)
Note: On the iPad, Safari does not begin downloading until the user clicks the poster or placeholder. Currently, downloads begun in this manner do not emit progress events.
Related
I'm using the RTCMulticonnection library for a webrtc video streaming platform. It functions pretty much like this: There's a list of users, each with a profile page that has a chat button. Upon clicking this chat button, the caller is taken into a chat room page (a new browser tab) where he issues a connection.open() to create the room.
Afterwards a chat request is send through the node server to the callee, which gets a confirmation popup. If he accepts he is taken in the chat room page (a new tab) where a connection.join(roomId) is called.
My problem is that on ipad/iphone both the audio AND video stream are added only on the first call, either if you are a caller or a callee. If you afterwards want to call someone else on the ipad only the audio stream is added to the chat view, but from the remote side you get the video stream just fine.
Is there a flag that gets set up somewhere, somehow that I'm missing?
Also there's some cases that causes iOS devices to freeze up pretty bad so that they need a hard reboot, but I haven't pinned down the culprit.
On desktops and android devices the flow seems to work fine... so far.
This is a bug in WebKit:
Safari on iOS11 Freezes when viewing a cropped remote video
Frequent situations where iOS device locks up, requiring a hard reboot when consuming webrtc streams on IOS
It's solved since iOS 11.2.
I'm developing a site for a client and am stuck at this point, as both of us have been able to recreate this issue in Chrome on Android.
For whatever reason, when we load this page on Android in Chrome:
http://miso.gostppro.com
The video loader just keeps spinning and spinning and the video never plays.
And tapping it on it doesn't do anything either (doesn't start the play, doesn't open it in YouTube app, nothing).
It works just fine in other browsers (Firefox for Android loads it and plays it just fine), so I'm confused as to why this is happening.
What am I missing?
Is it some call in the API or something?
I'm lost.
In short, it won't work. Quoting the documentation:
The HTML5 element, in certain mobile browsers (such as Chrome
and Safari), only allows playback to take place if it's initiated by a
user interaction (such as tapping on the player). (...) Due to this
restriction, functions and parameters such as autoplay,
playVideo(), loadVideoById() won't work in all mobile environments.
You're calling event.target.playVideo(); in your onPlayerReady handler, which is not allowed in mobile environments and throws a warning in console (for future reference - I highly recommend using Remote Debugging in Chrome).
So, back to your problem - I'd just get rid of the onPlayerReady handler and use autoplay player variable instead. It should work on desktops and not break the player on mobile either.
I tested your webpage on my Nexus 5 running Android 5.1.1 and found a few issues:
First I was getting this error:
Failed to execute 'postMessage' on 'DOMWindow': https://www.youtube.com !== http://miso.gostppro.com
Which I thought was an http vs https error, but after I refreshed the page with error went away and I saw a new warning:
Failed to execute 'play' on 'HTMLMediaElement': API can only be initiated by a user gesture.
As pointed out in jkondratowicz's answer, this is a byproduct of mobile browsers disallowing autoplay on HTML5 videos. The only think I can think of is remove any JavaScript related to the player and the autoplay parameter and allow the user to manually start video playback when they're ready.
I was also getting mixed results results with adding an listener to the page load event which calls play() on the iframe:
function callback () {
document.querySelector('ytplayer').play();
}
window.addEventListener("load", callback, false);
So with iOS 8, we can now record the screen of iOS devices. I've searched extensively and cannot find a way to detect, let alone prevent, this recording. The app I'm working on deals with some potentially sensitive information and images and would like to prevent this if at all possible.
Thank you in advance for your responses and insights!
Anthony
Apparently, there is some way to detect whether a display or QuickTime streaming is connected, because the Netflix app will show an error when that is the case (which also means you can't just use an iOS device and stream to your computer to watch it in big). The app works perfectly if QuickTime streaming is off with the cable is plugged in.
Maybe it just detects whether an external display is connected, and screen recording behaves like that, so basically you might have some success with these APIs and notifications.
Also, you could use an encrypted HTTP Live Stream according to Apple which would be blacked out in the stream / the recording.
Has anyone else noticed that Safari (and even Chrome) for iOS attempt to preload all audio tags even if you use the preload="none":
<audio src="test.mp3" preload="none"></audio>
Desktop browsers appear to work correctly, but as soon as I load the page from the iPhone the Apache server registers a request for the file.
According to Apple Docs, Mobile Safari never loads music file or metadata until user touch is detected. This is to make sure a webpage doesn't request a lot of music or data to be downloaded on mobile devices which might take up a lot of mobile data. So preload tag is essentially always set to "none" in mobile Safari regardless of what your code has. Here's the link to the docs where they explain everything.
Quote straight from the docs "Note: The preload attribute is supported in Safari 5.0 and later. Safari on iOS never preloads."
I have built an app, designed to play each sound as the first one is finished by using 'ended' event.
In my initial version, each sound has its own audio element, resulting in something like:
function play_next_audio(){
speaker = $('audio#' + sounds[i++]).get(0);
speaker.addEventListener('ended',play_next_audio);
speaker.play();
}
This works great on all desktop browsers, including Safari, but does not go beyond the very first letter on iOS.
I have also tried a different approach - a single audio element that loads each sound in turn. There I experimented with binding the 'ended' event as well as loading first and binding 'canplaythrough' event instead. In both cases, it fails to work even on the desktop Safari - this time successfully playing the first two letters.
Here is the isolated test:
http://dev.connectfu.com:42001/app/test-sounds.html
Note that audio.load() is commented out several places - having it in or out seems to make no difference.
What am I doing wrong? How can I play series of sounds on iOS? Thank you so much for the help!
update As of 2017, the ended event doesn't fire on Safari (or Chrome) on iOS under several conditions. More information can be found here: It's almost 2017, and HTML5 audio is still broken on iOS.
I've built an HTML5 audio player (Chavah Messianic Radio) that "works" on Safari on iOS.
By "works", I mean, it plays the best it can on Apple's crippled iOS <audio> implementation. At the time of this writing, this includes iOS 5. I've tested this on iPhone 3 and up, and iPad original, iPad 2, and iPad 3.
Here are my findings:
Apple does not allow you to call .play on any audio until user interaction. For me, this means detecting iOS, then showing the music as paused until the user clicks play. Their reasoning is that this will consume data and battery; in practice, though, it just cripples web apps and stifles the evolution of the web.
If you want to play successive sounds (one after another), use a single element. When it's time to play the next sound, set existingAudio.src, then call existingAudio.load(), then call existingAudio.play(). This will allow you to play successive sounds.
Audio events don't fire if Safari is in the background.. While audio will continue playing if the user switches to a different app, the .ended event won't fire. This means it's practically impossible to build a music player app.
Hope this helps.
<rant>
In the meantime: Apple, please, please, please give us better support for HTML5 in iOS Safari. Here are your action items, Apple:
Let HTML5 audio work in the background.
Support OGG.
Support pre-loading audio.
Support concurrent audio.
Let us play audio without user interaction.
Do those things, Apple, you'll be the industry leader in mobile HTML5 audio, everyone will emulate you, you'll once again be leading the way, and web apps will work perfectly on your platforms, while being crippled on other mobile platforms. Yes, these features will use data and the battery, but native apps already do this. Stop crippling web apps and be the leader. Make HTML5 <audio> a first-class citizen on iOS.
</rant>
I don't believe the .play() method is supported for audio or video in iOS. Apple does not like the idea of videos or audio automatically playing upon visiting a page.
Here is a helpful reading about the state of HTML5 audio support across platforms: http://www.phoboslab.org/log/2011/03/the-state-of-html5-audio