So, I remember working on a project last year and running into this same issue - not being able to autoplay a video on an ipad since Apple is concerned with data usage charges. As silly as this problem seems, it keeps popping up again and again and has caused a major stoppage in the current project I'm working on (it seems to always come down to hacking away to make things work on the ipad now).
Anyway, the current issue is with Audio tags. I've built an HTML5/JS game engine and all works beautifully across all browsers, phones and tablets, but I'm dynamically creating audio elements for sound effects and scenery music.
Last I understood, the workaround was to have a single element that the user plays once, then you can dynamically change the src to be whatever you like - this obviously won't work in my case since a user can generate hundreds of different sound effects under different conditions. I've even seen some horrible "silent noise" hacks to work around this issue...
Not sure if anyone is going to request seeing code... but I'm just appending an audio tag with autoplay and a src. Works great everywhere, hoping that someone has a simple workaround (or perhaps Apple was smart enough to include a setting in the OS to allow for autoplaying?)
Thanks!
Related
Basically the title, whenever i play the video on firefox or chrome everything works fine. But on microsoft edge i get the following error:
Independent composition is disabled for video rendering. This can negatively impact performance.
Edge will play the first second of the video and then display "video couldnt be rendered". I can barely find anything about this error and have no idea how to go about fixing this or if this is just a bug on microsoft edge. On this website i saw something about disabling css on the video tag which i tried and still no luck.
I find one article and one thread for this error.
In MSDN issues page it was marked as fixed. So if you are using any older version then try to upgrade to latest version may solve your issue.
Independent composition is disabled for video rendering
In other SO thread, the solution for this issue was mentioned that,
The way to fix it is to look for CSS animations/transforms on the element. These are usually suspect of a element being kicked out of independent rendering.
HTML5 video turns black in IE and Edge
So you can try these two suggestions may help you to solve your issue.
Two and a half years ago Adobe announced that FlashPlayer 10 would support color correction. Admittedly the implementation was really basic because it would always assume all content to be sRGB encoded and would convert that content to the current display profile in use on the system. This was the introduction blog post by John Nack.
All AS3 needed to activate this feature is:
stage.colorCorrection = ColorCorrection.ON;
...and yes you do need stage access for this to work and no that is not the problem.
So back when it was new I wrote a little wrapper to display images in Internet Explorer and Chrome so that they would render correctly for folks with extended gamut displays and also used this in a flash based video player with the same purpose.
Revisiting either today I find that what I know to have worked no longer does. What changed in the meantime is FlashPlayer's version and most likely the browser versions, too. I tried OS X, Win 7, Win XP, icc v2 and icc v4 display profiles on all of these, different browser versions, flash player versions to no avail.
You'll say that I must have done something wrong but the example page Adobe published a while later and which I lknow to have worked for sure also fails nowadays. If you look at the Flash applet you'll find it saying:
stage.colorCorrectionSupport: unsupported
If it sais supported for your system please comment the OS, browser and version and FlashPlayer version. Otherwise I'm looking for any clues to what happened to this feature.
At least the Adobe staff participating on their boards seems to be clueless. Quote: Because this feature seems to be disabled by default in most major browsers, I'm thinking that it was an experimental web standard proposal that died or something. We're not doing a whole lot here, it's mostly dependent on the browsers passing us the right data and doing the right color conversion math. We're pretty far down the chain of events.
I know for a fact that this worked at some point of FlashPlayer's evolution. So the following might help in solving what's going on:
does the Adobe example still work for anyone caring to look?
if this were about a deprecated browser feature why doesn't it work on old browsers anymore?
did it stop working on any particular FlashPlayer? (I tried several but could no longer make it work)
Notes:
color correction did not work with wmode transparent for some reason (but opaque was fine)
color correction originally also sometimes failed when using alpha bleding transitions
UPDATE: The feature still seems to work when wmode is set to "window". Of course that is very limiting. If you have a lightbox etc. on a page the Flash content will always stay on top of it etc. - so that's bad.
With wmode="window" the example also worked for me on OSX 10.6 (only version I tested thus far) and Win XP 32 bit. It still failed with all win 64 bit versions I tried but those systems have multiple screens so maybe I'll have to retry with a single screen since the first comment below suggests it worked on Win 7 64.
On the systems this worked I tried Firefox, Safari, Internet Explorer and Chrome. All worked the same except that when using Chrome the built-in Flash player always gives stage.colorCorrectionSupport: unsupported while disabeling the built-in FP and using the system's Flash player works as in the other browsers.
So the questions above can be narrowed to why does this no longer work for any other wmode especially "opaque" - which did work before and which is what Adobe uses in their on-line version of the sample file...
UPDATE 2: Flash Player's newer wmodes "gpu" and "direct" make the feature fail on the systems / browsers named above where wmode "window" worked out.
UPDATE 3: After finding the wmode = "window" angle I decided to post a follow-up on the Adobe forum I quoted from initially. That lead to this whole issue being acknowledged as a bug in Flash player at: https://bugbase.adobe.com/index.cfm?event=bug&id=3596843 So I guess there won't be an answer to the question of what happened to stage.colorCorrection but hopefully it will sort itself out.
UPDATE 4: O.k. here is the mandatory bit of stupidity... When I said that I remembered wmode "opaque" to have worked before I errored. Upon reviewing this further I found that a long time ago I had put wmode="normal" in one of my JS files and since normal does not exist older versions of Flash Player used the standard wmode window so that was why it worked back then. More modern Flash Players have other defaults e.g. direct where color management fails and so it failed for me. So I think this never worked with any wmode other than "window" but I'm curious what the future might bring for this...
(yeah this is an old question, but I was product manager for Flash Player 10, so I thought I'd answer)
It works with window mode because Flash Player gets the rectangle in the browser and gets pretty much full control of the rendering stack and doesn't have to deal with compositing with items it doesn't know the color status of.
When you switch to something like wmode transparent, you go into a pretty crazy back and forth process compositing with the rendered elements above and below it. When you go into wmode GPU, the rendering stack is largely handed over to the GPU (not surprisingly). In both cases, Flash Player loses some control of the rendering stack and at that point things like color correction aren't possible.
The primary reason for this feature in Flash Player 10 was to enable interactive e-publishing in Flash Player (like inDesign SWF export) as well as support for applications that could help in a print-oriented tool chain.
I'm a little confused by this one. A similar question was posted here:
How to deal with poor HTML5 video performance in Chrome?
but no satisfactory resolution seems to have come of it.
The long and short of it is that the HTML5 video element has a very poor performance in Chrome. Every other browser I've tried (IE9/10, Opera, Firefox, Safari, Safari iOS) runs absolutely fine but Chrome (for Windows) buffers very slowly and occasionally stops buffering altogether. It seems to ignore the preload attribute, although according to this article:
http://oddlystudios.com/blog/html5-video-problems-in-chrome/
it DOES preload, just limits itself at a couple of MB. This is definitely a recent thing, probably only affecting recent versions (I'm on 26.0.1410.64 m) and it's not only affecting my projects but also other sites including YouTube. It seems to be irrespective of file format, and only seems to affect longer videos (those of 5 minutes and above).
I guess my question is, has anybody else come across this phenomenon? If so, how do you combat it? In the other thread disabling the hardware acceleration for H.264 was suggested, but not only does this not work for me, but it's impractical from a development standpoint.
Yes Chrome itself preload just few of MB's among its entire video. The only approach taken by me was, to show loading progress bar while we load the entire video at background. once fully loaded the video, remove the loading layer and show the video to play ahead.
I've been using flash video for embedded videos on my site. My old 2.2.x android plays them fine but I'm noticing a lot of new android devices as well as apple devices will not play my videos because flashplayer is fading, so I'm investigating the solution - and HTML5 video seems to be the new thing.
I've just spent 2 hours searching google and read a lot of stuff but most of it is from 1, 2, or 3 years ago -- and judging from what I've read it looks like using the html5 video tag still requires each video to be converted to multiple formats, and full screen is some sort of vendor specific extension -- different on each browser which happens to support it.
So my question is whether HTML5 video tag is a full replacement for the flash player now, or is it still a kludgiferous scheme requiring browser specific hacks for half a dozen most popular browsers -- in 2013?
Does it work on PC's, Macs, Androids, and iPhones?
caniuse.com is a great resource for pretty good data to answer this question.
As of now...
~92% of web users' browsers support the HTML video tag. The main one that doesn't is Opera Mini (about 4.5%). For those users, you can use a Flash fallback, which is actually not too much work. There are a handful of very simple solutions that will handle this for you, like videoJS, jPlayer and JWPlayer.
For now, you do need to encode in two, possibly three formats. About 92% of users support MPEG-4/h.264. Opera Mini and IE8 do not support it.
Only about 71% of users can support full-screen HTML video, so for Android and iOS (mainly), all versions, the best you can do is set the video to fill 100% of the browser window. If full-screen is that important, then you'll want to use Flash.
So, in short, yes, HTML5 video does require a little extra work, but at this point, it's not that hard to get right, and it's a standard that's moving in the direction of better stability and uniformity. YouTube, for example, uses it (with fallbacks), if that's any indication that it's ready for prime time.
I am in the process of updating my business website and I've decided to use HTML5/CSS3 (with some PHP) for the whole thing and it works fantastic in every new browser (IE9, FF6, O11, S5, C13) with or without JS.
Now I am not sure what I should do about every other browser version. I imagine I have a small amount of leeway with most of the browsers (atleast the previous version) except IE8 (I have the IE shiv, but it doesn't cover non-js browsers.). Most of the features degrade nicely, but there will always be issues with older browsers.
I know nonJS browsers are probably a minority, but it would be nice
to cover them as well
This list is ordered in the order of current preference to cover the
largest number of browsers(nonJS/JS) but time to implement hasn't been
considered.
Only considering web-browsers, plan is for a mobile site for mobile browsers
Here is the list:
Build a really dodge version of the site using tables^, etc. and redirect the users there if they have an old version of the browser (server-side) and have a warning on there about upgrading.
Use Javascript to fix up the bits they don't work (like the shiv). This doesn't really cover the nonJS browsers which as stated are probably a minority.
Build a static old browser page to redirect the old browser users to a page with links to upgrade download links. This is a real copout solutions, but is quick to implement
Assume the only users that have old browsers are IE users, and use conditional comments to implement one of the previous options. Assumptions are always bad
Pretend users have the most upto date browsers and make no attempt to fix the site at all. Not really a practical option
Rebuild the website for HTML4 and use it accross the site. Bit of a waste of current work. As well as it looks a bit dissappointing if a webdeveloper has a site using old technologies, which was the driving force for the upgrade
What are your thoughts/solutions to the HTML4/5 limbo? Is there anything you've done in current projects to combat this?
Cheers,
Steve.
P.S. Being a member of the 'I hate IE6 and don't care for it's existance' club, I'm pretending that IE6 (or less) never existed.
Update (to clarify)
^ - by tables, I mean are really slapped together version of the current website, using either a table/non-table based layout. But something that may not look pretty when the source is viewed, it's really just there to fill the compatibility void.
It's perfectly acceptable to have features in some browsers and no features for an older browser. See Here.
However, it should be noted that whenever a fix is doable, you should have it. Unless a website is a JavaScript based app, it should be working without JavaScript, note that working != working perfectly.
if you have a hover state with a cool transition, which Chrome 23423 will support, but IE7 won't, then you can either emulate it using Modernizr and jQuery, or leave it as is, and IE7 won't enjoy the goodness. BooHoo.
You must however, give older browser users a message to encourage them to upgrade to a better ones, especially talking about IE<=7.
You built the website in the wrong direction.
If you want to support older versions, instead of building a cutting edge website and then trying to get it to work in older browsers, you need to build a basic site that works everywhere, then use advanced CSS and Javascript feature detection to add features for the newest browsers.