This content has been marked as final. Show 7 replies
I see in comments on http://javafx-jira.kenai.com/browse/RT-3458 "Camera and Microphone" that Randahl advised you that he is able to use Java Sound to access a microphone (which he does successfully for a stand-alone app).
If it works for stand-alone app it will work for a browser embedded app.
As Randahl points out in the comments on that jira issue:
Of course, when running in a web page, there may be certain privileges that your app needs to have. You might want to look up Java Webstart and security privileges.Signing with a self-signed certificate is straight-forward.
Signing with a certificate signed by a certificate authority, is a bit more complicated and expensive, but perhaps worthwhile depending on your application.
For info on signing see the JavaFX deployment documentation:
http://docs.oracle.com/javafx/2/deployment/packaging.htm#BABJGFBH "Sign the JAR Files"
Further links to related info and threads are referenced from:
Signing a JavaFX application "Signing a JavaFX application"
Try your app out first without signing it first - if there are no security exceptions, then signing is not required - if there are security exceptions (i.e. stuff doesn't work in browser embedded mode but does as a stand-alone app), then you will need to sign your app.
There are many pitfalls of deploying in browser embedded mode, be careful that you understand what it means for you and your users if you choose this deployment mode.
By the way on a related topic:
I am not sure, if it is possible to stream audio with the JavaFX MediaPlayer!?
I've looked into the Media class and it seems, it only supports a String as source (file, or http), but no InputStream.
Depending on your requirements, this could be important as well.
Does anybody know, if I am correct, or if Streaming (audio and video) is planned for JavaFX 8.0?
Hello and thanks for your answer
Please, what are those "many pitfalls of deploying in browser embedded mode"?
The deployment Kit does not work well?
Maybe he refers to all the Java Critical Patch Updates which were released during the past weeks!?
I mean, e.g Firefox disabled the Java plugin because of security issues.
Or he refers to all the trouble you will get into, when you try to sign your jars and generate a JNLP file.
I tried it myself, only with self signing and stumbled over these bugs:
By the way on a related topic: I am not sure, if it is possible to stream audio with the JavaFX MediaPlayer!?Note that this question and answer is only tangentally related to the original question of sound from microphone and entirely unrelated to the original poster's intention of using javax.sound classes to capture microphone input within an applet.
It is possible to stream audio with the JavaFX MediaPlayer.
JavaFX supports http live streaming (which includes the ability to use an audio only stream).
See the JavaFX media documentation:
HTTP Live Streaming (HLS)For further info, see the HTTP Live Streaming Specification:
HLS playback handles sources with these characteristics:
- On-demand and live playlists.
- Elementary MP3 audio streams (audio/mpegurl) and multiplexed MP2T streams (application/vnd.apple.mpegurl) with one AAC audio and one H.264/AVC video track.
- Playlists with integer or float duration
Sources which do not conform to this basic profile are not guaranteed to be handled. The playlist contains information about the streams comprising the source and is downloaded at the start of playback. Switching between alternate streams, bit rates, and video resolutions is handled automatically as a function of network conditions.
And an HTTP Live Streaming faq:
JavaFX MediaPlayer currently doesn't support some other streaming media protocols (and generally related formats) such as:
- rtsp (real time streaming protocol) - the original realnetworks realplayer protocol.
- mms (microsoft media server protocol) - a protocol for streaming windows media .wmv/.wma files.
- rtmp (real time messaging protocol) - the original flash streaming protocol.
- ogg (vorbis/theora bitstreams) - open container format for multimedia.
I don't believe support for those additional protocols or related formats is planned for JavaFX 8.
There is a feature request to support aac/aac+ radio streaming (e.g. shoutcast/icecast) - the feature is currently targeted at Lombard (JavaFX 8):
http://javafx-jira.kenai.com/browse/RT-19582 "aac/aac+ radio streaming"
http://javafx-jira.kenai.com/browse/RT-17556 "Support for shoutcast/icecast streaming (mp3/aac(+))"
One of the jira issues mentions that there is a separate feature request on file for streaming from a Java InputStream, but I don't know what the link to that is, nor when that is scheduled.
Finally, there is this issue currently scheduled for implementation in Lombard (JavaFX 8):
http://javafx-jira.kenai.com/browse/RT-2684 "Media playback needs to be extensible. User defined codecs or media sources should be supported."
Once that is implemented, it should be able to develop 3rd party add in plugins to allow the JavaFX media player to playback other media codecs (e.g. the opus codec) and utilize different streaming protocols (such as the ones that are currently not supported today).
I do have an open question on whether it is possible to "Use http live streaming to stream data from a Webcam"
Using http live streaming to stream data from a Webcam
In case somebody knows the answer to that.
what are those "many pitfalls of deploying in browser embedded mode"?Ah, I was hoping you wouldn't ask and just do some independent research into this, but I guess I may as well answer.
Don't take this post as a negative comment on Java of JavaFX, it's really just specific to the deployment in a browser scenario.
The main issue is that embedded Java applications won't work immediately in many user's browsers.
Many security experts advise (and numerous tech writers) advise that user's remove or disable Java and many browser vendors have taken this to heart, making it more intrusive to the user to run Java in a browser (and sometimes stopping Java from working in a browser at all). A google search by clicking the link provides more information:
Basically the reason for the advice to disable Java in a browser is that many zero-day vulnerabilities have been found in the Java client runtime and these have been exploited numerous times by drive by download malware attacks. In such an attack, a user just visits a url in a browser and their computer becomes seriously infected with malware.
In recent Java updates, Oracle have upped the default security profile settings for Java in applets so that every applet (even unsigned ones) will show a security warning before running - perhaps this will reduce calls to disable java in browsers as well as browser vendors aggressively disabling it (but that remains to be seen).
There are other issues besides (these are off the top of my head, so some my be slightly inaccurate or outdated):
- the Java runtime on Windows installs the ASK toolbar by default on every update
- there is currently (as of JavaFX 2.2) no plugin for JavaFX in a browser on Linux.
- troubleshooting issues when installations go wrong is difficult.
- internet explorer 10 doesn't allow the JavaFX browser plugin to run.
- only a subset of browsers are supported (for example JavaFX 2.2 apps don't run in Chrome on OS X).
- android, iOS and Windows RT systems are highly unlikely to let the JavaFX browser plugin run (ever).
- every java applet from an untrusted publisher will display at least one security warning message (and all publishers are untrusted by default).
- security dialogs of signed apps request all permissions from the system (even though the app may only require a few high level permissions).
- signing apps with a code signing certificate from a trusted CA is expensive and time consuming for a single developer and requires regular renewal and ongoing expense.
- when a java applet fails, often the user will be presented with a pretty uninformative error message.
- each browser vendor seems to have implemented their own method of disabling untrustworthy plugins and most of them seem to treat the java plugin and runtime as untrusted unless you are running the very latest version of the plugin and even then they can block the plugin and can make it hard to re-enable for users.
- care must be taken that the user installs the correct architecture version of the java runtime to match their browser (e.g. 32bit runtime for 32 bit browser).
- the java runtime is auto-updated and may be updated to a version which has compatibility issues with your app, causing your app to spontaneously stop working on some user systems.
- some jnlp features did not work for JavaFX 2.0 (e.g. webstart related ones such as desktop icons and custom splash screens).
- jnlp has a jar and network caching feature which seems more trouble than it is worth as you might not want the user running a cached archive.
- jnlp based updates of apps can be as slow as installing the original software.
- there are not that many applets in widespread usage, so many users don't have experience with them.
- numerous users who have used applets in the past, may be wary of the technology due to poor user experiences that had in the past with applets in general.
- a large part of your deployment is out of your control:
* how the Java runtime gets installed and the associated branding and advertising screens which come with it.
* the deployment toolkit scripts and runtime should be obtained from Oracle to function correctly with the latest Java plugin (and Oracle can drop them or stop supporting them like they did JavaFX 1.x scripts - though this is unlikely to occur for the JavaFX 2 deployment scripts during the next ten years).
* I believe the user needs admin privileges to install the Oracle Java runtime distributable.
Some other classic issues such as slow start up time, grey patches appearing while the applet is loading, etc. have been rectified by improvements in the underlying platform, deployment toolkit and plugin technology.
Some more background information on the technology is available here:
All of that doesn't mean that you shouldn't deploy a browser embedded JavaFX app, just that it's a good idea to understand what you are doing before you start doing it so that you can set your expectations and your user's expectations appropriately.
Alternative deployment technologies to consider are standalone jars, webstart apps and self-contained (native) apps. These other deployment technologies bring some advantages, but also some disadvantages as well. Such options are not mutually exclusive with browser embedded apps. For instance, you could a offer browser embedded version of your app, and also a self-contained version for those who prefer to install your software like a "normal" app. A self-contained app would be useful if you intend to target deployment to an app store or something like a yum based rpm distribution network:
One thing you might want to try is a hallway usability test of your chosen deployment technology - pick five or six people at random and ask them to open the ensemble app on various computers and browsers and observe them and get their comments on the usability of it.
Thanks a lot for your answers, they are very very interesting and i will read all that work.
My initial post is beaucoup my client:
- needs to records voice from microphone in wav format for scientific traitments in the server (specialist in phonetic). No streaming at all
- needs Web and standalone versions (or only web at least)
that's why i thought that JavaFx was a good solution but i think that it is a risc for me
I know very very very well Flex/AIR/Flash/as3 and you can do all of that staff work without problems at all. Server could be PHP or Java.
But i needed to know if others solutions would do the job as well.
If my client decide to do only web version i think that a good solution could be HTML5/web sound API (only Chrome and Mozilla)/Ajax.
I don't like (as many people) the Applets!
Flash Player does not give me feal of a risc so flex/AIR could be also a good solution for web/standalone job
Thanks thanks a lot beacause you helped me a lot in my choice.
Java and the web is not (yet) a good solution.
Nora (from Paris, with a very bad english...)