I have two questions. If you can, please answer...
Could you show an example, where used plugin by object element in HTML?
Previously we could add video for flash player by using object, but now that doesn't used. Can you show an example, where used any resource for any plugin?
The simple answer is that browser plugins are a dead technology.
The term generally refers to applications implementing NPAPI (the "Netscape Plugin Application Programming Interface"), originally implemented by the Netscape browser (predecessor of today's Firefox) and then copied by other browsers. It essentially gives complete control over part of the web page to an external program, which makes it very flexible, but very hard to make secure and stable.
In 2015, Google Chrome removed support for NPAPI, using a new API to support Adobe Flash; Firefox blocked any plugin other than Flash in 2017. In 2021, Adobe ended support for Flash, and pushed out an update automatically uninstalling it from user's computers, so these exceptions are no longer needed.
Related
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 have an app that functions perfectly outside of Tide. The app uses Flowplayer to load and play a video using HTML5. It appears that when Flowplayer insert the video tag and sets the src attributes, the path is prefaced by the namespace (application id) used in my app configuration. Is there a way to disable this?
Everything in my app is inside the resources folder so there is no need to include the application name in the path.
Thanks,
H
#Ward Where we left TideSDK, unfortunately it did not have support for audio/video tags in HTML5. The HTML parser within the webkit in that code does not handle this properly. We decided more than a year ago to put our energy into a broader effort for mobile, web, and desktop called TideKit that is due to be released shortly. http://youtu.be/aE7gN-d0GhU
HTML5 support is state-of-the-art including audio/video so embedding is just as easy as using the tags. Working with anything HTML5 or creating apps with native capabilities and UI will be easier and better than ever. TideKit will launch with a CLI and an app to connect with our build service to optimize build's based for your app's requirements (and where you want it to go). Any code you have in TideSDK can be migrated easily.
My team is writing an HTML5 app that uses the appcache and localstorage heavily. Our target platform is ipad and android tablets (and design time we work extensively in desktop browsers, though that's not necessarily a must-have).
Now we want to add some offline-available features that will be beyond what the browser-based storage can support-- namely a library of video & binary content that will be bigger than the appcache can handle.
Without the major mobile browsers implementing the html5 filesystem api, it seems very much like some kind of native app approach will be required (PLEASE correct me if I'm wrong here... I'd love to be wrong on this!). So, I'd love to hear opinions/experiences folks have had. We're noodling around with a few different ideas involving one or more of the following:
Compiling in phonegap + using their file apis
Using the Dropbox sdk (which would also require some kind of native support, not sure if phonegap would work)
writing per-platform custom native apps that host webkit controls, then providing the majority of functionality with our existing, cross-platform html5 app (basically we'd be writing a per-platform custom browser using the standard webkit controls).
Note that I'm a fan of #3 because I feel like we could release a relatively stable shell but then preserve the html5 cross-platform goodness & ease of distribution of our app. However, I don't know if this approach works (and/or if Apple frowns upon this type of approach-- seems like a bit of an App Store loophole).
Very interested to hear what you've tried and/or heard about.
This might be a completely stupid idea but, if you're looking for a cheap way to get extra storage, why not just use an html or js file to contain the data? You could even, for whatever reason, store it as a 64-bit data uri and run the media natively. I think you could even save data to it by just manipulating the manifest to be reflective. It'd take a bit of tom foolery, but it should work.
If you use approach 1 you will be well positioned to move to a web app once the major browsers support the File API. You see the File API in PhoneGap is based on the W3C spec that the browsers will implement.
2, I started working on a Dropbox plugin for PhoneGap Android but I need some "spare time" to finish it.
3, Apple will probably reject your app if it is just a wrapper around your web site. They've done that in the past.
Simon
I want to make a single web application avoiding any flash code. This application must contain videoconference, and I want to implement it in pure HTML5. It is possible? I know about websockets, but don't know really if videoconference can be implemented through them with a relative performance (at least, 24fps + sound at a right resolution, minimum 640x480), and both endpoints being web apps (both endpoints should use browser).
Thanks in advance
Anyone following up this question - on Feb 4th, 2013 they produced the solution with WEBRTC in Chrome and Firefox. For examples see https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-calling/ or http://www.html5rocks.com/en/tutorials/webrtc/basics/ or https://code.google.com/p/sipservlets/wiki/HTML5WebRTCVideoApplication
You can't really use HTML5 video for live streaming at the moment, and it doesn't have support for web cams yet.
Ericsson has modyfied a WebKit browser and is showing how this can be done with hopfully upcoming HTML5 Stream API. See Beyond HTML5 - Implementing and stream management in WebKit
It is impossible to capture web-cam images/microphone feed just through JavaScript (although there are plug-ins which let you handle output through flash), so it would be necessary for you to have some kind of application/plug-in installed.
The speed part is just for the client to worry. I mean, web sockets will be as fast as the connection permits.
You should do some research about web workers, since they would be very useful for speeding up your application (you could have microphone interface, web-cam interface and UI all with their particular worker, thus never blocking the application or rendering it unresponsive).
EDIT: the aforementioned jQuery plug-in works through the use of <canvas>.
As Jonas said, according to the situations now, we can't build video conference with HTML5. There are many limitations with browsers also. As there is no common video codec supported by all browsers. And live-streaming is also properly supported by safari only(using HTML5 video tag). As per my experience we can't build live-streaming on windows with any browser properly.
But if you wanna get some information about live streaming see https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html
you can use this source to test your live-streaming examples
"http://xfunoonx.api.channel.livestream.com/3.0/playlist.m3u8"
This content will work only with safari on Mac.