图片库插件

图片库插件使用户能够共享库中的图片. 可以将集成自定义职位画廊, 控制访问, 从特定源导入.

下载图片库插件 | WordPress 图片库

这是一个插件开发的 VideoWhisper.com 主要是为了整合中像这样的解决方案的前端图片库管理功能 付费视频聊天, 视频共享 VOD, 视频直播 在哪里住点播内容提供商还想要包括静态图片, 观众为他们的快照.

关键功能

  • 将图片职位类型添加到 WordPress 站点与画廊分类
  • 允许上传和导入的图片从前端和后端
  • 生成缩略图, 生成特征图像
  • AJAX 显示和更新的图片列表
  • 简码上市图片, 上传表单, 导入窗体
  • 大规模的图片上传
  • 大规模的图片导入 (从服务器)
  • 可以共享图片的设置用户类型
  • 挂起的图片 / 批准用户类型,可以 ’ t 直接发布

会员

  • 定义全球图片访问列表 (角色, 用户的电子邮件 & id)
  • 角色画廊: 通过某些角色分配作为访问图片
  • 异常画廊: 免费, 注册, 未出版
  • 显示预览和自定义消息时无法访问

HTML5 的图片上传

  • 拖动 & 下降
  • AJAX (没有提交, 页面加载需要上传更多图片)
  • 多图片支持
  • 状态 / 每次上载的进度栏
  • 不可预知的安全上载文件名称
  • 回退到旧版浏览器的标准上传
  • 移动照相机上传 (iOS6 +, 安卓 3+)
  • 后端多上传菜单

实现WebRTC视频聊天和会议支持

WebRTC 是一种新型的实时视频通信技术. 支持在所有浏览器和设备上都不可用, 但正在增加. 目前的真正问题是可伸缩性.

可 伸缩 性

因为 WebRTC 利用对等网络, 还必须有一个附近的节点, 以帮助分发流到其他本地主机. 在全球网络上进行窥视可能会非常困难.

传统的 WebRTC 解决方案要求每个客户端在复杂网络中建立和维护与每个其他参与者的单独连接, 在这种情况下, 随着每个附加参与者的增加, 带宽负载会成倍增加。.

广播公司需要服务器级的连接到多个用户的实时流, 并使用常规的家庭 ADSL 连接 (有更高的下载和更大的上传) 导致实际问题.

测试时使用 2 或者很少有用户在演示和小负载测试中工作正常, WebRTC 限制经常显示在生产模式下: 当许多用户观看相同的 HD 流和广播连接是定期的, 变得不可用.

所有初创企业都希望他们的流式应用程序将成为一个巨大的成功, 成千上万的观众观看. 一个执行者流了一个 全高清视频 at 8 Mbps的 直接到 100 世界各地的观众需要多达800Mbps 的上传连接.
大多数 ADSL 连接有下100Mbps 上传允许流这样的视频, 以最大的 12 用户.

解决方案是使用中继服务器进行流式可靠的 WebRTC, 并将客户端与 BroadcastLiveVideo 解决方案.

常规浏览器支持和实现的可靠性

旧系统的默认 PC 浏览器当前不支持 WebRTC (用于旧 Mac OS 的 Windows 和 Safari 的 Internet 浏览器) 或通常由许多用户使用的旧版本.
这将创建一个现实的问题,组织网络与标准软件分发, 较旧的 OS 设置, 工作室和互联网 caffes 与限制性管理软件或平原新手用户使用他们的计算机的默认设置.
实现WebRTC是不是目前默认移动浏览器既支持, 除外最新的Andr​​oid.
虽然实现WebRTC是普遍的技术爱好者和发烧友, 很多普通用户将不能访问此类的实现,或者可以使用只有有限的功能.

WebRTC 标准早在批准的过程中. 支持 WebRTC 的浏览器不完全透明, 更新可能会导致执行 WebRTC 的问题。.

欲了解更多详情,请参阅这些参考点:

[表]

PC浏览器;共享;实现WebRTC;RTMP

互联网浏览器 + 边缘 (Windows默认);9%;蕙;是的

Safari浏览器 (默认的MacOS);13%; 没有; 是的

铬;57%;是的;是的

火狐; 9%;是 *;是的

歌剧;5%;是的;是的

[/表]

*Mozilla 报告 导航器 getUserMedia 已否决MediaDevices.getUserMedia 作为实验 .
*IE 不支持 WebRTC 在所有但有计划引入一些支持 边缘 浏览器 .

PC 浏览器市场份额显示 WebRTC 安装程序将不能用于很多 PC 用户由于浏览器支持. 许多这些用户的默认浏览器是初学者还是从使用不同的浏览器限制工作场所的政策,不太可能改变他们的浏览器.
在手机上实现WebRTC支持甚至更低,而RTMP都支持Android和iOS上与 应用程序.
RTMP流可以发布到iOS和Android浏览器为 HLS.

实现WebRTC VS RTMP

目前, 实现WebRTC仍处于发展的讨论其完整实现,而RTMP已经可用于任何实时通信项目的部署.

实现WebRTC可能是为未来的溶液和RTMP是用于本一个解决方案,可以要求一会.

实现WebRTC能松当前战斗的标准化和互操作性, 有洁癖的Web浏览器或谷歌从一个不同的市场方法很多具体的实施方案, 微软, 苹果.

RTMP 是可靠的实现在所有的 PC 浏览器与 Flash 插件和独立的应用程序的移动和桌面操作系统.

中继 (RTMP服务器) VS P2P (实现WebRTC或Flash RTMFP)

根据 ISP 和网络设置用户重要份额不能连接,并在所有流直接向对方. 一些经历巨大的潜伏期 (几秒钟) 和过大规模的P2P帧丢失.

测试与这是你的P2P网络功能 RTMFP连接检查 .

使用中继服务器是视频通信最可靠的解决方案.

一些供应商只能说 8% 他们的用户需要RTMP但可能有偏见考虑到他们强调实现WebRTC / 不需要流媒体服务器成本的 RTMFP 会话.
通常大多数家庭互联网连接不搭配 P2P 除非用户处于相同或非常接近网络. 服务器级连接通常需要对此技术进行可靠的 P2P.

安全问题与使用的浏览器,支持实现WebRTC

一月 2015, TorrentFreak的报道,浏览器支持实现WebRTC从一个严重的安全缺陷,危及VPN-隧道的安全遭受, 通过允许用户的真实IP地址被读. IP地址读取请求是不是在浏览器中显影剂控制台可见, 并且它们不会被普通广告拦截/隐私的插件 (可实现在线跟踪​​广告商和其他实体,尽管预防措施).

如果您的浏览器是实现WebRTC标准测试此 IP检测工具.

闪光灯的结尾

flash 计划在十年前停止使用, 但替代方案需要很长时间, 浏览器继续支持, 因为这是提供广播网络摄像头等某些功能的唯一可靠方法.

目前, 浏览器和开发人员计划 结束时对 flash 的最终支持。 2020.

当其他技术可用且仅由 flash 提供的功能可靠时, 浏览器将停止闪存支持 (从网络摄像头流式直播视频).