简体   繁体   English

通过Java Applet进行屏幕共享

[英]Screensharing via Java Applet

I am looking for an addition for our "livestream and podcast" solution, which uses a camera to film speeches in our house. 我正在为我们的“直播和播客”解决方案寻找一个补充,它使用相机拍摄我们家的演讲。

It has been requested to view the slides of our speakers directly as a image in the webbrowser instead of the video stream. 已要求我们将扬声器的幻灯片直接作为webbrowser中的图像而不是视频流进行查看。 We don't want/can not install software on the speakers laptop, so I thought about a Java applet, which the speaker can just run via a webbrowser. 我们不希望/不能在扬声器笔记本电脑上安装软件,所以我想到了一个Java小程序,扬声器可以通过webbrowser运行。

So what I need is technically this: 所以我需要的是技术上的:

[speakers laptop] -> [Screencapture every N seconds via applet on a webpage] -> [Displaying the screen of the speaker on a different webpage for the external viewers] [扬声器笔记本电脑] - > [通过网页上的小程序每N秒进行一次屏幕截图] - > [在外部观众的不同网页上显示扬声器的屏幕]

I know there are Java applications which do record the screen, but save the file output locally. 我知道有些Java应用程序会记录屏幕,但会在本地保存文件输出。 I need something that does the same, but sends the image to the server. 我需要做同样的事情,但是将图像发送到服务器。 On the server side I thought about a websocket.js accepting and displaying the image (other suggestions are welcome). 在服务器端,我想到了websocket.js接受并显示图像(欢迎其他建议)。

It would be great if somebody could help me out here. 如果有人可以帮助我,这将是很好的。 Btw, I never programmed in Java, so telling me which frameworks I need won't really help me. 顺便说一句,我从来没有用Java编程,所以告诉我哪些框架我不需要真正帮助我。

Thanks!! 谢谢!!

I was recently asked to evaluate possibilities for live screen-cast via applet. 我最近被要求评估通过applet进行实时屏幕投射的可能性。 Most video APIs do not support codecs that have high enough compression (eg JMF). 大多数视频API不支持具有足够高压缩的编解码器(例如JMF)。 Some APIs can do advanced formats (JFFMPEG, Xuggle) but also use natives. 有些API可以使用高级格式(JFFMPEG,Xuggle),但也可以使用本机格式。 While natives are normally no problem for an app. 虽然本机通常对应用程序没有问题。 launched (free floating) using Java Web Start or a Plug-In 2 applet, the makers of Xuggle identify 'the order of loading natives' as a problem (eg won't work) for both JWS and applets. 使用Java Web Start或Plug-In 2 applet启动(自由浮动),Xuggle的制造商将“加载本机”的顺序识别为JWS和applet的问题(例如,不起作用)。

It is a pity that more than a decade into its development, Java has no reasonable API for video capture/processing that can be deployed for a wide use (applet/JWS based - for the 'general public') GUI. 令人遗憾的是,在开发十多年之后,Java没有合理的视频捕获/处理API,可以广泛使用(基于applet / JWS - 用于'普通大众')GUI。

Perhaps you can find a solution using Flash. 也许您可以使用Flash找到解决方案。

Update 1 更新1

In fact, I do not need the screen to be recorded as a video. 实际上,我不需要将屏幕录制为视频。

In fact, you mentioned much of that in your initial question, but I focused on just a few keywords before drafting a reply. 事实上,你在最初的问题中提到了很多,但在起草回复之前我只关注了几个关键词。 My bad. 我的错。 :P :P

OK. 好。

  • Getting an image is relatively easy. 获取图像相对容易。 An applet would need to be trusted in order to get a screenshot, but once trusted, it is just a few lines of code to get the image. 需要信任小程序以获取屏幕截图,但一旦信任,只需几行代码即可获取图像。
  • Encoding the image to JPEG of particular quality/compression setting (in memory) is also doable. 将图像编码为特定质量/压缩设置(在存储器中)的JPEG也是可行的。
  • Sending the image to the server would depend on the size in bytes and connection speed, but one image with a high compression, every 10 seconds, should be doable. 将图像发送到服务器将取决于字节大小和连接速度,但是每10秒具有高压缩的一个图像应该是可行的。 The server would need to implement functionality to accept the image. 服务器需要实现接受图像的功能。

As far as displaying the image on the client, it seems you already have some ideas based around JS. 至于在客户端上显示图像,似乎你已经有了一些基于JS的想法。 If you can make that work that would be optimal, since it can then be viewed in browsers with no Java. 如果你可以做到最佳的工作,那么它可以在没有Java的浏览器中查看。

I would still recommend you deploy the app. 仍然建议你部署应用程序。 to the 'speaker' using Java Web Start , rather than embed an applet. 使用Java Web Start到'发言者',而不是嵌入applet。 A JWS app. 一个JWS应用程序。 will give you less deployment & maintenance troubles, and the JWS launch is ..nicer. 将为您提供更少的部署和维护麻烦,并且JWS的推出是..nicer。 Further, a free floating frame launched using JWS can minimize itself (or in later JREs, become transparent), during the action of taking a screen image - thereby capturing everything on the screen except itself. 此外,在拍摄屏幕图像的过程中,使用JWS启动的自由浮动框架可以最小化自身(或在后面的JRE中变得透明),从而捕获屏幕上除了自身之外的所有内容。

Update 2 更新2

I actually found this code here. 我实际上在这里找到了这个代码

That is ..horrible. 那太可怕了。 Not the code, the site. 不是代码,网站。 When I visited it I got a message saying a pop-up had been suppressed (fair enough). 当我访问它时,我收到一条消息,说弹出窗口被压制(足够公平)。 Then there was the irritating 'vibrating dialog' hovering in the middle of the page (and following the scroll). 然后,在页面中间盘旋(并在滚动之后)有一个刺激性的“振动对话”。 You click the little x to see - another tab opened with yet another floating dialog, saying some other rubbish about how "You've won.." - with sound loud enough to drown out my high volume trance/dance playlist. 你点击小x来看 - 另一个用另一个浮动对话框打开的标签,说一些关于“你赢了......”的其他垃圾 - 声音响亮,足以淹没我的高容量恍惚/舞蹈播放列表。

Then after closing that the hell out of my FF, I go back to the original page, close the damn 'dialog', scroll down & see.. a red background to the code (shudder). 然后关闭了我的FF之后,我回到原始页面,关闭该死的'对话',向下滚动并看到..代码的红色背景(颤抖)。 That is as far as I could manage. 就我所能管理而言。 I closed the page with the code. 我用代码关闭了页面。

Try this code instead, for a single screen-shot. 对于单个屏幕截图,请尝试使用此代码

Would it be possible to use this on the client side.. 是否有可能在客户端使用它..

Yes. 是。

.. and receive it with javascript on the server side? ..并在服务器端用javascript接收它?

Not really. 并不是的。 Unless you mean an IIS based server running Microsoft's JScript. 除非您指的是运行Microsoft JScript的基于IIS的服务器。 JavaScript is a client side technology. JavaScript是一种客户端技术。

For security reasons, servers need to protect themselves. 出于安全原因,服务器需要保护自己。 EG From: EG来自:

  • Someone creating a slavebot that uploads all the 1000s of docs on the slave machine's to the site - to make it crash. 有人创建了一个slavebot,它将从机上的所有1000个文档上传到站点 - 以使其崩溃。
  • People high-jacking your server for storing and serving bestiality porn (or worse). 人们高举你的服务器存储和服务兽性色情(或更糟)。

Because of things like that (bad people have lots of imagination), while servers can easily accept uploads, they are generally not configured by default to allow them. 由于这样的事情(坏人有很多想象力),虽然服务器可以轻松接受上传,但默认情况下它们通常不会配置允许上传。

.. (I don't want Java on my server ;-) ..(我不想在我的服务器上使用Java ;-)

It can be done using PHP, ASP, CGI etc. It does not need Java specifically, but it does need some active involvement from the server, if only to check the size of what is being uploaded and abort if it gets too large! 它可以使用PHP,ASP,CGI等完成。它不需要特定的Java,但它确实需要服务器的一些主动参与,如果只检查正在上传的内容的大小,如果它变得太大就中止!

..Will take a look at the link you posted, but as I said, I can't program in Java, though I can understand some of it. ..请看看你发布的链接,但正如我所说,我不能用Java编程,虽然我可以理解其中的一些。 Thanks! 谢谢!

It sounds like you'll need some help getting the server-side of it ready, as well. 听起来你需要一些帮助才能让服务器端做好准备。 It is trivial for someone that knows how (not me), but a potential security nightmare for the inexperienced. 对于那些知道如何(不是我),但对于缺乏经验的潜在安全噩梦的人来说,这是微不足道的。

Update 3 更新3

where do I add the function to send the picture? 我在哪里添加发送图片的功能?

Sorry. 抱歉。 I've not tried to implement that - you'd want to want to encode it to JPEG before sending, to reduce the size. 我没有试图实现这一点 - 你希望在发送之前将其编码为JPEG,以减小尺寸。 See this code for how to provide an adjustable compression/quality where the user can see the effect. 请参阅此代码 ,了解如何在用户可以看到效果的情况下提供可调压缩/质量。

There are various ways to get an image to a server. 有多种方法可以将图像提供给服务器。 EG sockets, HTTP, FTP.. AFAIU it would depend on how the server is accepting it. EG套接字,HTTP,FTP .. AFAIU它取决于服务器如何接受它。 I am unfamiliar with the specific term 'websocket' or the node.js script. 我不熟悉特定术语'websocket'或node.js脚本。 Can you link to what you mean? 你能链接到你的意思吗?

..the old code added to pastebin, so it's readable ..旧代码添加到pastebin,所以它是可读的

Smart thinking. 聪明的思考。 I notice it uses sockets, it was in the back of my mind that sockets would be best for this, since they have low overhead and short wait times. 我注意到它使用了套接字,我认为套接字最适合这个,因为它们的开销很低,等待时间很短。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM