2018年4月30日星期一

每日文章精选 2018 04 30


发帖者 时间： 没有评论:
标签：

假装很忙的三个命令行工具


Linuxeden 开源社区 --

有时候你很忙。而有时候你只是需要看起来很忙，就像电影中的黑客一样。有一些开源工具就是干这个的。

如果在你在消磨时光时看过谍战片、动作片或犯罪片，那么你就会清晰地在脑海中勾勒出黑客的电脑屏幕的样子。就像是在《黑客帝国》电影中， 代码雨 一样的十六进制数字流，又或是一排排快速移动的代码。

也许电影中出现一幅世界地图，其中布满了闪烁的光点和一些快速更新的图表。不可或缺的，也可能有 3D 旋转的几何形状。甚至，这一切都会显示在一些完全不符合人类习惯的数量荒谬的显示屏上。 在《剑鱼行动》电影中黑客就使用了七个显示屏。

当然，我们这些从事计算机行业的人一下子就明白这完全是胡说八道。虽然在我们中，许多人都有双显示器（或更多），但一个闪烁的数据仪表盘、刷新的数据通常和专注工作是相互矛盾的。编写代码、项目管理和系统管理与日常工作不同。我们遇到的大多数情况，为了解决问题，都需要大量的思考，与客户沟通所得到一些研究和组织的资料，然后才是少许的 敲代码 。

然而，这与我们想追求电影中的效果并不矛盾，也许，我们只是想要看起来“忙于工作”而已。

注：当然，我仅仅是在此胡诌。 如果您公司实际上是根据您繁忙程度来评估您的工作时，无论您是蓝领还是白领，都需要亟待解决这样的工作文化。假装工作很忙是一种有毒的文化，对公司和员工都有害无益。

这就是说，让我们找些乐子，用一些老式的、毫无意义的数据和代码片段填充我们的屏幕。（当然，数据或许有意义，但不是在这种没有上下文的环境中。）当然有一些用于此用途的有趣的图形界面程序，如 hackertyper.net 或是 GEEKtyper.com 网站（LCTT 译注：是在线假装黑客操作的网站），为什么不使用标准的 Linux 终端程序呢？对于更老派的外观，可以考虑使用 酷炫复古终端 ，这听起来确实如此：一个酷炫的复古终端程序。我将在下面的屏幕截图中使用酷炫复古终端，因为它看起来的确很酷。

Genact

我们来看下第一个工具——Genact。Genact 的原理很简单，就是慢慢地无尽循环播放您选择的一个序列，让您的代码在您外出休息时“编译”。由您来决定播放顺序，但是其中默认包含数字货币挖矿模拟器、Composer PHP 依赖关系管理工具、内核编译器、下载器、内存转储等工具。其中我最喜欢的是其中类似《模拟城市》加载显示。所以只要没有人仔细检查，你可以花一整个下午等待您的电脑完成进度条。

Genact 发布了 支持 Linux、OS X 和 Windows 的版本。并且其 Rust 源代码 在 GitHub 上开源（遵循 MIT 许可证）。

Hollywood

Hollywood 采取更直接的方法。它本质上是在终端中创建一个随机的数量和配置的分屏，并启动那些看起来很繁忙的应用程序，如 htop、目录树、源代码文件等，并每隔几秒将其切换。它被组织成一个 shell 脚本，所以可以非常容易地根据需求进行修改。

Hollywood 的 源代码 在 GitHub 上开源（遵循 Apache 2.0 许可证）。

Blessed-contrib

Blessed-contrib 是我个人最喜欢的应用，实际上并不是为了这种表演而专门设计的应用。相反地，它是一个基于 Node.js 的终端仪表盘的构建库的演示文件。与其他两个不同，实际上我已经在工作中使用 Blessed-contrib 的库，而不是用于假装忙于工作。因为它是一个相当有用的库，并且可以使用一组在命令行显示信息的小部件。与此同时填充虚拟数据也很容易，所以可以很容易实现你在计算机上模拟《战争游戏》的想法。

Blessed-contrib 的 源代码 在 GitHub 上（遵循 MIT 许可证）。

当然，尽管这些工具很容易使用，但也有很多其他的方式使你的屏幕丰富。在你看到电影中最常用的工具之一就是 Nmap，这是一个开源的网络安全扫描工具。实际上，它被广泛用作展示好莱坞电影中，黑客电脑屏幕上的工具。因此 Nmap 的开发者创建了一个 页面 ，列出了它出现在其中的一些电影，从《黑客帝国 2：重装上阵》到《谍影重重 3》、《龙纹身的女孩》，甚至《虎胆龙威 4》。

当然，您可以创建自己的组合，使用终端多路复用器（如 screen 或 tmux）启动您希望使用的任何数据切分程序。

那么，您是如何使用您的屏幕的呢？

via: https://opensource.com/article/18/2/command-line-tools-productivity

作者：Jason Baker 译者：wyxplus 校对：wxy

本文由 LCTT 原创编译，Linux 中国 荣誉推出

转自 https://ift.tt/2I28zIE

The post 假装很忙的三个命令行工具 appeared first on Linuxeden开源社区.

https://ift.tt/2HGWWUb
发帖者 时间： 没有评论:
标签：

Cassandra 3.11.2 发布，分布式 K/V 存储系统


Linuxeden 开源社区 --Cassandra
Cassandra

Cassandra 3.11.2 发布了，Apache Cassandra 是一套开源分布式 Key-Value 存储系统。它最初由 Facebook 开发，用于储存特别大的数据。Facebook 目前在使用此系统。

该版本改进内容包括：

 * Fix ReadCommandTest (CASSANDRA-14234)
 * Remove trailing period from latency reports at keyspace level (CASSANDRA-14233)
 * Backport CASSANDRA-13080: Use new token allocation for non bootstrap case as well (CASSANDRA-14212)
 * Remove dependencies on JVM internal classes from JMXServerUtils (CASSANDRA-14173) 
 * Add DEFAULT, UNSET, MBEAN and MBEANS to `ReservedKeywords` (CASSANDRA-14205)
 * Add Unittest for schema migration fix (CASSANDRA-14140)
 * Print correct snitch info from nodetool describecluster (CASSANDRA-13528)
 * Close socket on error during connect on OutboundTcpConnection (CASSANDRA-9630)
 * Enable CDC unittest (CASSANDRA-14141)
 * Acquire read lock before accessing CompactionStrategyManager fields (CASSANDRA-14139)
 * Split CommitLogStressTest to avoid timeout (CASSANDRA-14143)
 * Avoid invalidating disk boundaries unnecessarily (CASSANDRA-14083)
 * Avoid exposing compaction strategy index externally (CASSANDRA-14082)
 * Prevent continuous schema exchange between 3.0 and 3.11 nodes (CASSANDRA-14109)
 * Fix imbalanced disks when replacing node with same address with JBOD (CASSANDRA-14084)
 * Reload compaction strategies when disk boundaries are invalidated (CASSANDRA-13948)
 * Remove OpenJDK log warning (CASSANDRA-13916)
 * Prevent compaction strategies from looping indefinitely (CASSANDRA-14079)
 * Cache disk boundaries (CASSANDRA-13215)
 * Add asm jar to build.xml for maven builds (CASSANDRA-11193)
 * Round buffer size to powers of 2 for the chunk cache (CASSANDRA-13897)
 * Update jackson JSON jars (CASSANDRA-13949)
 * Avoid locks when checking LCS fanout and if we should defrag (CASSANDRA-13930)
 * Correctly count range tombstones in traces and tombstone thresholds (CASSANDRA-8527)

下载地址：http://cassandra.apache.org/download/

转自 https://ift.tt/2JAmX80

The post Cassandra 3.11.2 发布，分布式 K/V 存储系统 appeared first on Linuxeden开源社区.

https://ift.tt/2rbHs3k
发帖者 时间： 没有评论:
标签：

VNote 1.15，更好的图表，更好的预览


Linuxeden 开源社区 --
VNote

VNote 1.15 发布啦！作为一个更懂程序员的 Markdown 笔记，这次 VNote 终于支持 PlantUML 和 Graphviz 了。

  • 支持 PlantUML, Graphviz ；
  • 支持 PlantUML, Graphviz, MathJax 以及 Flowchart.js 的 原地预览 ，在编辑模式就能给您足够好的反馈和信息；
  • 支持 PlantUML, Graphviz, Flowchart.js 以及 Mermaid 图表的实时两边 实时预览 ，方便编辑大图表；

先来一张图来展示一下原地预览的效果：

vnote_inplace_preview.png

然后，VNote 也采用了两边预览的方式，不过 VNote 是利用这个来预览图表，方便在编辑比较大的图表的时候查看整个图表。

Selection_003.png

相信 Vim 和 PlantUML 的加持，应该也可以让 VNote 在一票 Markdown 编辑器和笔记软件中有一点点自己的色彩了！

每个人心目中都有自己的标准和喜好。记得之前写了一篇 VNote 和 Markdown 的一些心得体会（个人感觉真的是很深度），发表到少数派上，结果反响还没有那种说一下基本 Markdown 语法或者列几个 Markdown 编辑器的文章好。深深体会到了“萝卜青菜，各有所爱”。希望 VNote 会是作为程序员的您的菜！

谢谢！

转自 https://ift.tt/2HAYjI5

The post VNote 1.15，更好的图表，更好的预览 appeared first on Linuxeden开源社区.

https://ift.tt/2vYPDpt
发帖者 时间： 没有评论:
标签：

开源美图 2018 04 30


Linuxeden 开源社区 --

Sea Bridge & City View High Definition Wallpapers for 2012 Year

The post 开源美图 2018 04 30 appeared first on Linuxeden开源社区.

https://ift.tt/2r9wL1Z
发帖者 时间： 没有评论:
标签：

2018年4月29日星期日

Redis Desktop Manager 0.9.3 发布，Redis 桌面管理工具


Linuxeden 开源社区 --Redis Desktop Manager
Redis Desktop Manager

Redis Desktop Manager 0.9.3 发布，此次更新内容如下：

新特性：

  • 支持 ReJSON 模块。

bug 修复：

  • Fix #4095: Fedora 27 – QQmlApplicationEngine 加载组件失败。

同时，由于目前中国镜像的流量很高，因此仅适用于订阅用户。

详情见 发布公告 。

Redis Desktop Manager（RDM）是一个快速、简单且支持跨平台的 Redis 桌面管理工具，基于 Qt 5 开发，支持通过 SSH Tunnel 连接。

下载地址：

转自 https://ift.tt/2vWaUQG

The post Redis Desktop Manager 0.9.3 发布，Redis 桌面管理工具 appeared first on Linuxeden开源社区.

https://ift.tt/2Ft4J5V
发帖者 时间： 没有评论:
标签：

每日文章精选 2018 04 29


发帖者 时间： 没有评论:
标签：

微信工程师业余做了条围棋“狗” 竟然夺冠了


Linuxeden 开源社区 --

据腾讯科技报道，“贝瑞基因杯”2018 世界人工智能围棋大赛在本月底福州举办，经过两日鏖战，来自腾讯微信团队的人工智能围棋程序 PhoenixGo（凤凰围棋）成功夺冠。

微信工程师业余做了条围棋“狗” 竟然夺冠了

据悉，PhoenixGo 是一款由腾讯微信翻译团队开发的人工智能围棋程序，基于 AlphaGo Zero 论文实现，同时做了若干提高训练效率的创新，利用微信服务器的闲时计算资源进行自我对弈，缓解了 Zero 版本对海量资源的苛刻需求。

并且该项目并非官方正式立项项目，只是由几名工程师在开发机器翻译引擎之余的闲暇之作，微信团队技术之强令人艳羡。

“贝瑞基因杯”2018 世界人工智能围棋大赛参赛选手众多，绝艺，PhoenixGo、LeelaZero、TSGo、石子旋风、Golois，HEROZ Kishi、Baduki 等诸多知名人工智能围棋高手都参加比赛，没想到竟然让不懂围棋的微信翻译团队拿了冠军。

微信工程师业余做了条围棋“狗” 竟然夺冠了

转自 https://ift.tt/2HGjows

The post 微信工程师业余做了条围棋“狗” 竟然夺冠了 appeared first on Linuxeden开源社区.

https://ift.tt/2vTBcmB
发帖者 时间： 没有评论:
标签：

实时音视频的架构设计


Linuxeden 开源社区 --

从直播在线上抓娃娃，不断变化的是玩法的创新，始终不变的是对超低延迟的苛求。实时架构是超低延迟的基石，如何在信源编码、信道编码和实时传输整个链条来构建实时架构？在实时架构的基础之上，如果通过优化采集、编码、传输、解码和渲染中的关键环节来降低延迟？本文将会介绍即构在这方面的思考与实践。

从直播到线上抓娃娃

图 1

图 1 展示了实时音视频两种不同的应用场景——连麦互动直播和线上娃娃机。虽然这两种都是互动，但是对于实时音视频的要求却不同。第一个实时连麦是语音视频流的互动，例如其中一个说了一句话，另外一个人听到了，再回复一句话，这个实时性只是对语音视频流的实时性要求很高。而第二种线上抓娃娃则对信令的延迟提出了更高的要求，操纵者无需说话，看到的是娃娃机传回来的视频流结果。

如果考量互动直播是用实时音视频的延迟，那么线上抓娃娃则是用信令和视频流的延时。随着时代的发展，我们对实时语音视频的定义会慢慢有一些不同，将来可能还有更多的因素需要考虑。

图 2

图 2 是即构互动直播的实时架构图，我们把互动直播分为两部分，一个是主播侧，需要更低的延迟，另一侧是普通观众，对延时不太敏感，但对流畅性敏感，中间通过一些旁路的服务把这两个集群（一个集群叫超低延迟集群，另外一个集群叫围观集群）连接起来。

在超低延时部分，我们提供的服务包括流状态更新、房间管理等，以及一些流媒体服务，主要起到分发的作用。我们通过超低延迟服务器集群（和观众侧不太一样），提供实时分发的功能。

此外还提供了动态调度的服务，帮助我们在现有的资源网络上找到更好的链路。后面的观众集群是另外一个集群，把它们分开是出于一些业务方和我们自己成本上的考虑，另外会提供存储、PCB 加速、分发的功能。

中间的旁路服务包括混流、转格式（主要是转码）、转协议等。为什么要混流？举一个比较简单的例子。当主播一侧有 9 个人连麦，如果没有混流服务，观众端就会同时拉 9 路音视频，这样对带宽压力很大。

普通观众是通过围观服务器集群（延迟相对大的集群）去拉这些流的，这个集群的延迟可控性相对比较弱，有可能会出现这 9 路画面之间的不同步现象，通过混流服务，观众拉的都是合成好的音视频流，就不会出现各路流之间的不同步问题。

还有转格式转码的服务，前面集群提供的是很低延迟的服务，里面一些，比如说编码码流，不能够在传统的 CDN 网络分发，如果想在传统的 CDN 网络上分发，就要服务端的转码。还有就是转协议，因为前面提供一个更低延时的服务，后面要在 CDN 网络上分发，所以协议也需要转。

图 3

图 3 是线上娃娃机的 APP 版本的架构图，这里的是特色是线上娃娃机可以实时推两路视频流，上机玩家可以随时任意去切其中一路画面去看。这两路视频流首先通过我们超低延时服务器集群，同时上机玩家也可以推一路流上去，可以给围观观众方看到这个人在抓娃娃时候的一些表情、反应、语言，增加一种互动性。此外，玩家需要通过手机远程操控娃娃机，因此还需要实时信令的分发。

图 4

接下来是娃娃机的 H5 架构图。在推流方面和 APP 版本没有太大的区别，娃娃机一侧还是走的私有协议。不同的地方是因为私有协议没有办法直接让 H5 拉到流，所以中间会加入一个媒体网关，作用是把我们的私有协议翻译成 H5 可以识别的码流格式，然后 H5 端通过 websocket 方式把这路流拉下来，这里需要媒体网关做到超低延时的转换。

简单来看，这里的网关服务器只是做了一个分发服务，好像不会引入延时，实际上不然。

因为 websocket 拉的是 TCP 的流，但是我们推的是 UDP 的，当视频帧很大的时候，一个帧数据就要切割成很多 UDP 包上行，服务器需要将这些 UDP 包攒起来，凑成一个完整的帧后才下发给 H5，这样才能保证不花屏，才能跑得通，所以这个攒包组帧的过程是会有延迟的。信令部分和 APP 部分基本是相似的。

实时架构的若干点思考

刚才介绍了实时音视频的两种场景，下面提出一点思考： 实时音视频有什么样的特征？怎么样去架构一个实时音视频系统？

这是仁者见仁，智者见智的问题。你可以通过很多方式把这个系统架构起来，都会达到相对不错的效果。但是我认为，无论怎样，实时音视频都有绕不过如下几个点，只有把它们做好了，才能够在业界有更高的知名度、更好的技术储备。

第一是实时音视频是不能等的，因为等了就不是实时音视频了。 不能等，这里会引入一个矛盾。既然不能等，例如你把实时音视频也看作一个消费模型来看，那是提前生产还是按需生产？字面上理解很简单，肯定是按需生产，需要的时候才生产，如果提前生产就是延时了。但是并不是每一个点都做成按需生产是合理的。

举一个例子，比如你要去播放一段音频，最好的做法是系统或者驱动告诉你，它需要数据了，然后去解一帧塞给它，这就是按需生产。但是为什么还有提前生产一说呢？就是系统告诉你它要数据的时候，实际上它有一个对响应周期的要求。

你现去生产可能就要等去解完一帧，但是这个时候来得及吗？如果你只有一路下行，可能就来得及。但是现在要求很多路下行，在很短的时间周期内解很多帧，对硬件性能有很高的要求。通常来讲，并不可取。这只是实时音视频中一个简单的例子。 提前生产会引入延迟的，那么到底要提前多久生产，怎么样动态估计我们什么时候应该生产？这是一个开放性的问题，也是一个大家在设计系统时要重点考虑的。

第二是实时音视频不能久等。 实时音视频中有些等待是避免不了的，例如你要做音频编码，它本来一定要 20 毫秒一帧或者 40 毫秒一帧去做，给一个采样点点是编不了的。这里既然有些延迟和等待避免不了，我们当然希望系统处理的粒度越低越好，这样可能会带来更低的延时。但是处理的粒度越低，整个系统在频繁跑的时候，你可以认为它是一套循环，当循环的东西很少，这个循环就会跑很多次，对系统来说就是一个很大的开销和负担。

所以不能久等的时候，我们当然希望它处理粒度小。另外处理粒度小还有一个优势，在整个系统中并不能保证每一个环节的处理粒度是一致的。例如这个节点可能要求是 10 毫秒，下一个结点要求 15 毫秒，这是由于算法的限制，可能没有办法避免。如果在整个系统内选一个相对小的粒度，在粒度拼接的时候，例如 10-15 毫秒，要两个 10 毫秒才能够 15 毫秒，还剩下 5 毫秒，剩的就比较少。

如果粒度很粗，可能剩下的东西就很多。在粒度拼接的时候，这个剩余的量代表了整个链路中的延迟。所以我们希望处理粒度尽量小，但是又不能小到整个系统没有办法接受的粒度。

第三，实时音视频不能死等。 例如你需要接收一个网络包的时候，这个包迟迟不到，这个时候你不能完全不等，完全不等就会卡。但是在等的时候有一个超时的机制，例如这个音频包就是很久不到，就把它跳过去做一个纠帧补偿，当包最终还是到了的时候，我也只能把它扔掉，而不应该把它利用起来。

图 5

此外，实时音视频在服务器端还需要深入考虑这样几个问题：第一是负载均衡。第二是就近接入，第三是质量评估，第四是动态路由，第五是算法流控。

第一，负载均衡是说让整个服务器的每一个节点都承担相对均匀的服务，不至于使得某一个节点负载过高造成一些丢包，造成网络往返时的增大，这样对任何的网络损伤来讲，对实时音视频都会造成比较大的延迟增加。

第二是就近接入，这里的“近”并不是指地域上的近，而是“网络上的近”。很简单的例子，我们在深圳做推流，香港离得很近，可以推到香港的服务器，但实际上这毕竟是一个跨域的网络，有不稳定的因素在里面，所以我们宁愿推远一点。这个近指的应该是在网络质量评估意义上的近，例如网络往返时很小、往返时很平稳、分布在延迟比较大的时刻不会还具有很大的概率，丢包率很低等。

要做到就近接入，这个近要有一个很好的质量评估体系。质量评估方法有两种：

  1. 事后质量评估。在复盘的时候，例如这个网络平稳的运行了一个月，复盘看一下整个月中的质量怎么样，这样的质量评估可以认为是一个相对离线的评估，它能够给我们提供一个指标，最近一个月的网络和上个月相比是否有所改善。我们可以从中学习到一些经验，例如这个月和上个月的调度上有些策略上的不同。这是一个系统化的经验总结和优化的方法。
  2. 实时质量评估。更重要的应该是一个实时上的评估，例如我现在推流，能够实时监控到当前的质量是怎么样的，就可以做到实时动态路由。实时动态路由是说某个人推流从北京推到迪拜，有很多链路可以选，他可能根据之前的一些经验，假如他之前经验告诉你，直接推到迪拜，这个链路是很好的，但是毕竟有个例。有动态实时的质量评估，就知道这个时候推迪拜是否好，如果不好，可以在用户无感知的情况下更换，随时增减整个链路中一些路由的节点。这就是动态路由的思路。

实时动态路由是说某个人推流从北京推到迪拜，有很多链路可以选，他可能根据之前的一些经验，假如他之前经验告诉你，直接推到迪拜，这个链路是很好的，但是毕竟有个例。有动态实时的质量评估，就知道这个时候推迪拜是否好，如果不好，可以在用户无感知的情况下更换，随时增减整个链路中一些路由的节点。这就是动态路由的思路。

实际情况中是结合前面这 4 个点，在我们的网络和服务器资源集中，去选出质量最优或者近似最优的链路来保证实时音视频的服务的。但是资源集是有限的，没有人可以保证你的资源集中一定可以选出的这个最优具有很好的链路特征。保证不了就要考虑第五点，我即使选出了一个认为是整个资源集中最优的链路，但是它的质量还达不到很好的标准，就要通过一些算法才能弥补。这些算法包括在一个不可靠的网络中怎么样进行可靠的音视频传输的技术，这些技术在接下来我们会和大家稍微分享一下，也包括整个链路的一些拥塞控制。

关于信源编码的思考

图 6

信源编码是为了减少网络中的负担，把大量的数据压缩成比较小的网络数据，来减少网络负担的方式。压缩方式有很多种，我们先以音频来看，上面画了一些图（图 6），我们重点看 Opus 编码器，它有几种模式在里面，一种是线性预测模式，还有一种是混合模式，还有一种是频域编码模式。混合模式是把两种编码模式混合在一起，根据不同的情况进行选择。

图 6 是一个编码器，横轴是码率，纵轴是它的质量，中间是各种音频编解码器的表现。你会发现线性预测的方式能够在低码率上提供比较好的质量，但是在 20K 左右的时候就没有曲线了，因为它不支持那么高的码率。然后看 MDCT 编码，它可以在比较高的码率上达到近似透明的音质。音频编码器是有不同的编码原理在里面的，像这种 LP Mode 是模拟人的发声模型，既然有了数学建模，它的特征是能够在一个比较低的码率上提供一个比较可靠的质量。

但是它的特点是容易达到一种质量上的饱和，也就是说当你码率给它很高的时候，实际上它也就编的效果还是那样，因为它毕竟是一种参数化的编码。所以根据业务场景，当你需要一个很高的音质，又需要音乐场景的时候，选择它明显不合适。MDCT MODE 没有任何的模型在里面，实际上就是把信号转换成频域，直接去量化。既然没有模型化，它是比较消耗码率的，但是它可以在一个较高的码率上提供很好的质量，可是低码率的表现远远不如模型化的方法。

图 7

整体总结起来，音频包括语音和音乐两种，因此有适合语音的 codec 和适合音乐的 codec。第一种 codec 适合语音，语音可以模型化，适用于语音的 codec 能够在低码率上提供很好的质量，提供一个相对高的压缩比, 但是它容易达到饱和，不能够提供一个近似于透明的音质。另外一种 codec 的编码原理不一样，能够把音乐、语音都编得很好，但是特点是不能够提供太高的压缩比，指望它能够在低码率下提供很高的编码质量是做不到的。

图 8

关于视频编码，最简单的几个点有 I 帧、P 帧、B 帧。I 帧是自参考，P 帧是向前参考，它会参考历史帧的特性进行编码。B 帧是双向参考，它可以参考前面的帧，也可以参考后面的帧。B 帧可以带来更高的压缩比，提供更好的质量。但是因为它会参考将来的帧，所以会引入延迟，因此我们在实时音视频系统中是很少用到 B 帧的。

想要做好实时的音视频系统，流控是一定要做的，流控对视频的编解码有什么要求？至少有一点，编解码器的码控一定要很稳定。为什么？举例说，我现在有一个很好的拥塞控制策略，带宽估计做得很好，一点差错都没有，估计出某一个时刻可分配视频的带宽就是 500kbps，就可以让视频编码器设置成 500kbps。但是，如果码控不是很稳定，你设置 500kbps 的时候，视频编码器可能就跑到 600kbps 了，这样就会带来一些阻塞和延迟。因此，我们希望选择的 codec 具有很好的码控策略。

实际上一些开源代码都是有做码控的，但是直接拿来用并不是适合你的场景，因为这些开源代码做起来，可能或多或少的考虑其他的场景，并不只是实时音视频场景。比如说某个 codec 是用来是压片的，希望半个小时或者一个小时之内达到预定的码率就可以，不会管这一秒钟或者下一秒是什么样子的，但是实时音视频就是要求要把时间窗做得很小。

另外我们希望 codec 有分层编码的能力。什么是分层编码？为什么要有分层编码？分层编码也分两种，一种是时域上的分层，一种是空域上的分层。前者是编码的时候是当前帧不参考上一帧，而是有隔帧参考的策略；后者可以认为使用较低的码率先编码一个小的画面，然后使用剩余的码率编码增量的部分，得到更高分辨率的画面。

为什么要这样做？实时音视频中并不是很多场景都是一对一的，当不是一对一，要做流控的时候，不可能因为某一路观众的下行不好，就把主播上行推流的码率降下来，因为可能还有一千个观众的网络很好，这些网络好的观众也会因为个别观众网络不好，而只能看到不那么清晰的画面。所以要分层，可以在服务器端选择给用户到底下发哪一层的，因为有分层策略，如果这个人线路不好，只要选择其中一个比较小的层次发给他就可以了，例如核心层，这样可以紧紧利用核心层把整个视频还原，可能会损伤一些细节或者帧率偏低，但是至少整体可用。

最后，我想说一下，很多人认为，视频的数据量很大，视频的延时比音频应该更高才对，实际上不是。因为很多的延迟实际上是编解码自有的延迟，如果编解码中没有 B 帧的话，你可以理解为视频编码是没有任何延迟的。但是音频编码或多或少都会参考一些将来的数据，也就是说音频编码器的延时一定是存在的。因此，通常来讲，音频的延时比视频的延时更高才对。

关于信道编码技术的思考

图 9

信道编码分几个部分。一种是根据先验知识的网络冗余编码技术——前向纠错技术。以 RS（4，6）编码为例，我要发一个分组，这个分组有六个包，其中有四个包是实际媒体数据，有两个包是冗余包。那么在解码端收到六个包中任意的四个，就可以完全恢复所有携带媒体内容的包。

例如这里 2、3 都丢了，收到了 1、4、r1、r2，也能够完全恢复 2 和 3。这样看来很好，任意两个丢掉都可以完全恢复。但是这样的算法也有它的弱点，不太适合突发性的丢包。因为这个分组不宜太大，如果分组很大，分组就有很大的延时。分组如果很小，很可能整个分组都丢掉了。

实际上这种做法就没有任何意义。所以它不太适合突发性丢包，而且它毕竟是根据先验知识去做的一种冗余，也就是说它永远是根据上一时刻网络的状态作出的判断，下一时刻网络是什么样的，是预测的东西。网络是实时发生变化的，这种预测的东西并不完全可靠。

所以它恢复的效率在实际网络中相对比较低，而且这样的算法复杂度相对比较高。当然它也有优势，例如我们是提前算好的，一次性发过去，不需要等到你发现丢包时我再做怎样的冗余传输，所以不受网络往返的影响。而且这种分组可以任意、随机调整大小冗余度，比较适合均匀丢包的场景。

图 10

另外一项技术是丢包重传技术。相对来说，丢包重传相对 RS 来讲，更有针对性，所以恢复效率比较高。第一个 Go Back N 技术是类似于 TCP 的传输技术，发送端在不断的发包，接收端要负责告诉发送端我现在收到包的情况是怎么样，收到的连续的帧的是序列号什么样的。发送端发现发了 10 个帧，接收端只正确收到 8，不管 9 号包或者 10 号包是否收到，都会丢包重传。所以 Go Back N 技术有一定的目的性，维护的是丢包状态，它知道哪些包是没有收到的，但是并不精准。

接下来是自动选择重传技术（Selective ARQ）。选择性的重传，是在接收端发现了哪个包丢了，然后才会让发送端重新发送这个包。听起来是非常好的一个技术，效率很高，丢了哪个包就重传哪个包。但是它的弱点在于，你必须要假定这个包是频密的发送才可以。例如发送端发出 1、2、3、4 这样的包，但是一秒钟才发一个包，什么时候发现 2 丢了呢？收到 3 的时候。如果 2 作为最后一包，永远发现不了丢掉了。也就是如果发包不频密，至少需要 1 秒钟才发现它丢。这个时候再让它重传，就很晚了。

所以在一个真实的系统中，选择性重传是首选，因为音视频的大部分场景是频密的，但是可能也要结合一些 Go-Back -N 的做法。发一些确认机制，这样才能把重传做得更加完备。另外所有的重传都要至少等一个网络往还时，因为无论是确认丢包还是反馈收包情况，都需要一个网络往返时，所以它的弱点是，它受网络往返时影响比较大，如果控制不好，有可能造成重传风暴。优势是算法计算复杂比较低，且容易实现。另外，因为它有很大的针对性，无效的重传包会比较少，针对突发性的丢包会有比较好的效果。

刚才讲了针对不可靠网络的两种传输技术，前向纠错和丢包重传，它们都有各自的优点和缺点。实际上一个好的网络分发技术应该是将这两种结合在一起的，根据不同的信道情况把这两种技术结合在一起。

图 11

图 11 来自于网络，首先从左下角蓝色部分看起，当网络往返时很小，丢包率不高的时候就用重传。但是当网络 RTT 很高的时候，在这个图里面去看，就没有选用重传策略。从我个人的角度来看，我认为这并不是一个非常合理的做法。因为刚才提到了，FEC 是一个无目的性的、根据先验知识去做的一种冗余技术，虽然当 RTT 很高，重传很耗时，但如果没有重传，要加很多冗余包，才能把丢掉的包完全恢复，实际就会带来很大的资源浪费。而且当你丢包率很高的时候，可能还并不能够完全恢复所有包。视频只要丢帧就会很卡，视频丢包率应该控制在千分之几以下，才可以达到顺畅的可以观看的水平。

图 12

关于信道编码的思考。信道编码和网络吞吐呈反比关系。无论是重传性编码还是冗余性编码，都会占用带宽，从而减低实际媒体信息的吞吐量。现实的生活中，信道都有限制。当你传输的时候，就要根据信道的特征去做一些策略。信道如果有拥塞，我们就需要有一个拥塞控制的算法，去估计应该把整个信道怎么样做合理分配。

另外，在做一个系统的时候，想清楚如何去评价一个系统的效果是很重要的一个点。在信道编码的时候，一个很重要的指标是，信道编码的有效性是什么样子的。有效性分为两种，一种是重传或者冗余能否真的把丢掉的包补回来，这是一个有效性。即使这个包补回来了，但是如果经过一个信道编码策略之后，还有一些丢包。

例如原来的丢包是 20%，补回来变成 1%，那么这个重传在我们的评价当中实际上是没有效果的，因为 1% 的丢包对音频来讲是无所谓的，但是对视频来讲是很卡的。在这样的评价系统中，补回来还有 1% 的丢包，那么所有的编码都是没有太大意义的。举这个例子，如果在这时信道也发生拥塞，再进行这样的信道编码，就不会达到很好的效果。这个时候是否应该停止所有的信道编码呢？

还有信道编码有效性的判断，衡量它是否好，就是加了多少冗余，冗余中有多少没有被利用好，如果这些冗余像刚才那个例子那样，6 包带 2 包的冗余，刚好丢掉 2 包，整个包都恢复出来了都使用到了，那就是百分之百的冗余都有效。如果 4 包信息丢了 1 包，却带了 2 包荣誉，其中 1 包就没有效果。所以想要做一个好的系统，应该先想到如何评价这个系统的好坏。

引入延迟的环节和降低延迟的思路

延迟的引入主要分三部分，一个是采集 / 渲染。这好像是很简单一个部分，但是它引入延迟可能是最大的，可能是整个分发过程中最大的环节。

有很多人不是特别理解，但实际上在即构现有的网络结构中，网络往返时的延迟都控制在 50 毫秒以内，但是渲染和采集，尤其是渲染，几乎没有任何移动端系统可以保证它百分之百的 50 毫秒，这是一些硬件上的限制。如何去降低这些延迟？刚才我已经举了一个生产消费模型的思路，到底是按需生产还是提前生产，这些都是可以仔细去考虑的。

还有编解码会带来一些延迟，尤其是音频会带来一些延迟。这些延迟中有些是避免不了的，我们就要根据实际的使用场景去减少这些延迟，这些都是要在具体形态上做一些权衡的东西。还有处理粒度上的考虑，也会影响整个系统的延迟。

还有一个延迟，大家都能看到的，就是网络分发延迟。如何去减小？除了在资源集中找到一个最优子集之外，还有信道编码的东西，要做一个很好的信道编码系统，我们如何评价信道编码系统的好坏。有了这些思路之后，可以指导我们去做更好的下一步的开发工作。

作者介绍

关旭 ，即构科技音视频引擎核心专家，硕士毕业于南开大学数学系，先后就职于中兴通讯、腾讯等公司负责音视频相关的研发工作，在实时音视频技术上有多年积累，当前在即构科技主要负责音视频引擎核心开发。

转自 https://ift.tt/2Kg0MVU

The post 实时音视频的架构设计 appeared first on Linuxeden开源社区.

https://ift.tt/2vWAmpg
发帖者 时间： 没有评论:
标签：

bboss elasticsearch v5.0.6.2 发布


Linuxeden 开源社区 --

The best elasticsearch highlevel java rest api—–bboss

bboss elasticsearch v5.0.6.2 发布

v5.0.6.2 新增功能及改进：

1. 升级最新的 bboss 版本到 5.0.5.7

2. 新增 bboss es rest boot 模块，极简配置，接近零配置快速将 bboss es 集成到自己的项目中，比如：spring boot，bboss boot，其他 boot 应用、非 boot 应用等等。在项目中导入 bboss es：

maven

<dependency>
    <groupId>com.bbossgroups.plugins</groupId>
    <artifactId>bboss-elasticsearch-rest-booter</artifactId>
    <version>5.0.6.2</version>
</dependency>

gradle

compile "com.bbossgroups.plugins:bboss-elasticsearch-rest-booter:5.0.6.2"

如果 es 服务器就在本机，导入后 bboss 后，不需要做任何配置就可以正常使用 bboss es。

3.bboss es rest boot 支持多个集群 es 配置，参考文档：《Spring boot 集成 Elasticsearch Restful API 案例分享 》

bboss es boot 使用案例

https://gitee.com/bbossgroups/eshelloword-booter

参考文档

bboss es 源码地址

转自 https://ift.tt/2vQtDgm

The post bboss elasticsearch v5.0.6.2 发布 appeared first on Linuxeden开源社区.

https://ift.tt/2r6jUxI
发帖者 时间： 没有评论:
标签：

2018年4月28日星期六

PHP 开发框架 CakePHP 3.6.2 发布，bug 修复版本


Linuxeden 开源社区 --CakePHP
CakePHP

PHP 开发框架 CakePHP 3.6.2 发布，这是 3.6 版本分支的维护版本，修复了几个社区报告的问题。

Bug 修复：

  • 修复了 CSRF 令牌验证中潜在的侧通道时序问题。
  • request->here 改进了弃用警告。
  • 如果是由子类实现的 Cake \ Form \ Form :: validator（），现在只会发出弃用警告。
  • 当无法分析 XML 内容时改进错误报告。

详情见 发布公告 。

CakePHP 是一个运用了诸如 ActiveRecord、Association Data Mapping、Front Controller 和 MVC 等著名设计模式的快速开发框架。该项目主要目标是提供一个可以让各种层次的 PHP 开发人员快速地开发出健壮的 Web 应用，而 又不失灵活性。

下载地址：

转自 https://ift.tt/2HVyuSf

The post PHP 开发框架 CakePHP 3.6.2 发布，bug 修复版本 appeared first on Linuxeden开源社区.

https://ift.tt/2HBM3Hi
发帖者 时间： 没有评论:
标签：

Ant Design 3.4.4 发布，阿里企业级 UI 设计语言


Linuxeden 开源社区 --Ant Design
Ant Design

Ant Design 3.4.4 发布，此次更新内容如下：

  • 修复 3.4.2 中引入的 Upload 中 onChange 参数 { file } file 不是 File 实例的问题。#10293
  • 修复 webpack@4 下使用 Tree Shaking 样式丢失的问题。#10217 @whtsky

详情见 发布公告 。

Ant Design 是阿里开源的一套企业级的 UI 设计语言和 React 实现，特性如下：

  • 提炼自企业级中后台产品的交互语言和视觉风格。
  • 开箱即用的高质量 React 组件。
  • 使用 TypeScript 构建，提供完整的类型定义文件。
  • 全链路开发和设计工具体系。

下载地址：

转自 https://ift.tt/2HANvFO

The post Ant Design 3.4.4 发布，阿里企业级 UI 设计语言 appeared first on Linuxeden开源社区.

https://ift.tt/2rcAb3B
发帖者 时间： 没有评论:
标签：

OpenCV 3.4.1 发布，扩展深度神经网络模块


Linuxeden 开源社区 --OpenCV
OpenCV

OpenCV 3.4.1 发布，此次更新主要扩展了 DNN(Deep Neural Networks，深度神经网络) 模块，修复了多个 bug 以及做了一些功能改进。

更新内容包括：

  • 增加了对量化 TensorFlow 网络的支持。
  • OpenCV 现在可以使用 Intel DL 推理引擎作为 DNN 加速后端。
  • 向性能关键的内核（如卷积和完全连接层）添加了 AVX-512 加速功能。
  • 在 TensorFlow Object Detection API 中训练和再训练的基于 SSD 的模型可以通过单个调用 python 脚本来创建文本图形表示，从而更容易导入。
  • 支持 Android NDK16
  • C ++ 17：OpenCV 源码和测试符合 C ++ 17 标准
  • ……

详情见 更新日志 。

OpenCV 是 Intel 开源的计算机视觉库。它由一系列 C 函数和少量 C++ 类构成，实现了图像处理和计算机视觉方面的很多通用算法。OpenCV 拥有包括 300 多个 C 函数的跨平台的中、高层 API。

下载地址：

转自 https://ift.tt/2jepPMJ

The post OpenCV 3.4.1 发布，扩展深度神经网络模块 appeared first on Linuxeden开源社区.

https://ift.tt/2HyREhw
发帖者 时间： 没有评论:
标签：

每日文章精选 2018 04 28


发帖者 时间： 没有评论:
标签：

阿里妈妈自主研发新一代检索模型对外公布


Linuxeden 开源社区 --

4 月 25 日，阿里妈妈搜索直通车算法团队携最新论文亮相 WWW 2018（The International World Wide Web Conference）。今年的 WWW 大会在法国里昂召开，阿里妈妈高级算法工程师闫肃作为该论文第一作者在大会现场进行了口头报告。

阿里妈妈入选此次大会的论文名为《Beyond Keywords and Relevance： A Personalized Ad Retrieval Framework in E-Commerce Sponsored Search》，评委一致认为该方法是对传统搜索广告检索框架的重新定义，实际上，这也是搜索直通车首次公开其自研的新一代智能检索模型。

阿里搜索直通车广告业务有着巨大的体量和影响力，其技术工作有着非常高的挑战性。面对淘系搜索广告业务场景中真实存在的各种痛点和挑战，阿里技术一线的同学们不断地进行技术探索，通过一次次的技术突破和创新，解决了大量的业务难题。本次阿里妈妈在 WWW 2018 公开的新一代智能检索模型工作，就是搜索直通车算法团队的同学一次从实践出发，将技术创新和业务诉求相结合的范例。

图 1：“新一代”搜索广告智能检索框架

在论文中，阿里的技术同学突破了以“关键词”和“相关性”为核心的传统搜索广告检索框架，提出了新一代的搜索广告智能检索模型。新一代搜索广告智能检索模型引入用户行为异构图挖掘、机器学习等相关技术，通过模型学习的方式智能构建索引，解决了传统搜索广告检索系统不能解决的种种痛点，在搜索直通车业务线上取得了出色的效果，给广告商、用户和平台带来了三赢。

图 2：搜索广告系统由三方参与：广告商、用户和系统平台

在搜索广告系统中，每一次搜索广告的展示、点击和转化都需要三个参与方（广告商、用户和平台）的密切合作。平台是用户搜索请求和广告商投放的广告之间的桥梁，进行着流量匹配、广告展现等工作。其中，广告检索模块负责理解用户的搜索意图，快速准确地从海量广告中检索出一个小规模的高质量广告候选集。广告检索模块需要兼顾系统的效果与效率，因此在算法工作中存在着巨大的技术挑战。

在传统的搜索广告系统中，广告商必须为自己的广告选择竞价关键词。平台进行广告检索时会受到竞价关键词的约束。如果广告商没有事先为广告购买相应的关键词，那么即使用户搜索请求与广告紧密相关，平台也不会检索回这些广告。但是，受限于市场信息的缺失和投放管理的巨大成本，广告商有时并不能及时准确地为自己的广告选择出最合适的关键词。在这种情况下，广告检索算法不能实现最优的流量匹配，给广告商、用户和平台三方均带来了损失。

此外，传统的搜索广告检索模型只关注于搜索请求与广告之间的相关性；这往往和平台的目标（RPM、CTR、GMV 等）并不完全一致。如何在考虑相关性的同时，兼顾平台目标和用户体验，是广告检索模型需要解决的巨大难点。

近年来，越来越多的个性化信息被引入电商搜索广告系统，如用户在平台上的浏览、点击、交易等行为。一方面，这些个性化信息能够帮助广告检索模型更好地理解用户的搜索意图。但另一方面，个性化信息也给广告检索带了新的挑战：面对从各种复杂丰富的个性化信号通道检索回的广告，检索模型需要能够高效、准确地对其按照统一标准快速排序。这个问题，在目前已知的工作中，均没有得到有效地解决。

图 3：用户行为异构图图示例。图中包含了三种节点：用户搜索信号、广告检索键和广告。用户搜索信号和广告检索键之间的边表示改写，广告检索键和广告之间的边表示广告海选。

面对上述传统搜索广告检索系统中存在的各种难题和挑战，阿里妈妈搜索直通车算法团队的同学提出了一种创新的搜索广告智能检索系统。新的智能检索系统首先使用用户在平台上的历史行为构建出一张庞大复杂的用户行为异构图。异构图中节点分别表示“用户搜索信号”、“广告检索键”和“广告”，边分别表示“用户搜索意图信号改写”关系和“广告召回”关系。接着，检索系统面向平台 RPM、CTR 等指标，学习异构图中边的权重，挖掘出重要的改写关系和广告召回关系。

这样，通过对异构图的深入挖掘，检索系统同时进行了“用户搜索意图信号改写”和“广告召回”两个检索子任务的统一联合学习。最后，检索系统根据模型的边挖掘结果，自动构建相应的“改写索引”和“广告召回索引”。通过两个模型智能构建的索引，检索系统将用户行为异构图和模型挖掘结果存储下来，实现了对线上搜索请求的高效检索。由于新的智能检索模型不再强制要求广告商购买关键词，所以新的检索系统使用 OCPC 策略，在保证广告商 ROI 的基础上，决定广告的点击收费。

阿里妈妈搜索直通车业务有着巨大的体量和规模庞大的用户数据，因此新的智能广告检索模型在实际落地过程中，也面临着各种技术挑战。例如，在新的广告检索系统中，用户行为异构图庞大复杂，包含了上百亿的节点和上万亿的边，使得模型训练非常困难。为了兼顾检索系统的的效果和性能，阿里技术同学提出了多种异构图初始化方法，在尽量保留重要关系的前提下，实现了对异构图的剪枝，给模型的训练提供了良好的起点。

又例如，在搜索广告检索阶段，为了提高检索效率，模型无法获取足够多的信息或者使用过于复杂的特征。因此，在新的检索模型中，阿里技术同学有针对性地设计了两种“粒度”不同特征：稀疏特征和连续特征。前者是一种细粒度的特征，保证了模型效果；后者则是一种粗粒度特征，用于提高模型的覆盖能力和稳定性。

新的智能搜索广告检索模型，在搜索直通车平台上取得了出色的效果，给广告商、用户和平台带来了三赢：新的检索模型通过 OCPC 的方式自动为广告出价，在保证了广告商的 ROI 前提下，把广告商从繁重的买词任务中解放了出来；通过引入丰富的个性化信号，新的检索模型能够更好地理解用户的搜索意图，达成更准确的流量匹配，提升了用户体验；新的检索模型不再单纯以相关性为目标，而是综合考虑平台的目标和用户的体验，提升了平台收益，也维护了平台的生态环境。

阿里妈妈在 WWW 2018 论文中公布的新一代搜索广告智能检索模型，不仅仅是国际一流的学术成果，更是搜索直通车算法团队的一线技术同学，以技术为驱动，服务广大淘宝、天猫用户和卖家的真实实践。

值得一提的是，WWW 大会作为全球互联网探讨未来发展的首要国际学术会议，聚集来自国际著名大学、研究机构、跨国企业和国际标准化组织的一流学者和工业界精英，对论文的要求十分严苛，近几年的论文录取率约为 15%左右。

随着万维网的不断发展，WWW 大会从最开始的注重万维网的系统部署与架构分析，发展到关注超链接和多媒体，再到如今集中于人工智能、深度学习、安全与隐私保护、内容分析、推荐与挖掘等领域，越来越吸引阿里巴巴、谷歌、腾讯等互联网巨头的加入，推动理论前沿和工业场景应用的紧密结合，持续为各国信息化建设提供了重要的技术支持。

论文原文链接：https://arxiv.org/abs/1712.10110

转自 https://ift.tt/2jfeMDe

The post 阿里妈妈自主研发新一代检索模型对外公布 appeared first on Linuxeden开源社区.

https://ift.tt/2Jw7Jko
发帖者 时间： 没有评论:
标签：
订阅： 博文 (Atom)