WTH, just share it.
原文来自:http://www.mbaonline.com/android/


Using haarcascade_frontalface_alt to implement “passenger flow statistics”. The detail flow chart of the major implementation Sample test program:https://oddmeta.net/p/easyiv/passenger_flow_statistics.7z Sample video: https://oddmeta.net/p/easyiv/passenger_flow_statistics.avi BTW: […]
年关临近,又得开始准备年终总结了,我先简单罗列一下,以便写总结的时候有个参考(仅限于产品部分)。 元旦之后一个多星期又开始搞Hermes相关的一些功能,但是说实在的,我对此真的不太积极,而这主要的原因是在于,我认为(一直认为)这并不是“走在一条正确的道路上”,而且,I don’t in charge of this product。 众所周知,STUNT相对于STUN及成功率是相当的低,而且相对来说,中间流程控制起来会更加的麻烦。但是事实上,虽然我在项目周会或者其他多种场合说 明和强调,Hermes却一直在沿着这条我“个人”认为不正确的道路上走下去,而且越走越远,甚至开始衍生出其他许多这样那样的“花头”来,如: 1. 为节省打洞,把原来两开的两种socket(一种用于信令及控制,一种用于视频的传输)进行合并,以复用socket。 2. Tunnel 这如果是在其他“环境”下,可能直接就被枪毙了,可是,我们已经花了很多人力来朝着这个方向来做基于这么一个思想的东西。不对,不是一个,而是很多个衍生 产品。当然,需要去做这些衍生产品,以及这么急着在这个不确定的、甚至明知很滥的也不可能规模化的基础上去做的原因很大一部分是在于市场的需要,或者说是 那些Board members的要求。 可这实在是让人受不了了,再加一句我“个人”的见解,这些东西即使做出来到头来很多做法也都最终会被推翻掉的,再过阵子,大家回头来看这堆东西,说不定就会称之为“垃圾”,在一个宝贵的时间里做出来的“宝贵”的垃圾。可是,你又能怎么办呢? 我先来数一数这N宗罪(不仅限于Hermes,所以题目也要改一下)。虽然在各种场合,我已经说了太多遍了,但也许我也还是得再说。 第一宗罪:似乎天下只有TCP,没有UDP。 从绑定单一的8000端口,到程序的实现,无一不是朝这个方向去做。 […]
An issue of call establishment delay when conferencing with Polycom MCU RMX2000 The situation was 1. Meeting entities 1). Polycom MCU: Polycom […]
Issue: #ping xxxx connect: No buffer space available #dmesg Neighbour table overflow messages.