opengl

在线教育不同于线下教育， 内容需要经过电子白板展现给用户，如何做出优秀的在线教育白板成为研究的重点。本文来自学而思网校客户端架构负责人赵文杰在LiveVideoStackCon 2018大会上的分享，并由LiveVideoStack整理而成。 文 / 赵文杰 整理 / LiveVideoStack 大家好，我是来自学而思的赵文杰，现就职于学而思网校并担任架构师的工作，接下来我将为大家分享互动白板在在线教育上的应用。 今天的话题主要围绕在线教育，也就是如何借助技术的力量将知识更生动地传递给学生，其中一种方式是电子白板。可以说电子白板在在线教育领域起着举足轻重的作用，学而思网校今年的学员数量已达到百万级别，在电子白板相关领域积累了一定的实践经验。 本次我将围绕相关实践经验和以下几个方面进行分享。 1、在线教育的形式 在线教育主要分为大班课与小班课两种形式，大班课的核心成员由一位主讲老师与若干位辅导老师组成。“线上主讲+线下辅导”也是近两年在线教育较为成功的模式之一，甚至在一些方面超越了公办教学的传统课堂模式。我们可以把一堂大课分为多个小班并为其各配一位辅导老师而共用一位主讲老师，包括学而思、腾讯课堂、学霸君在内的诸多在线教育平台主流采用此种模式，也验证了其盈利模式的可行性；小班课是指一位老师给一位或几位学生辅导学习，有的一个老师对六个学生就已经很多了。对家长而言

更新 之前在知乎上发了一个 帖子 来询问，有个答主金条回答了而且还带了参考文档，原来在 specification 中有说明（好吧，看见那个一坨我就没有去翻了，后面有问题还是得去这里看看，说不定可以找到答案）。 概要 之前调试一个 opengl 小程序时，我写的临时代码无论如何都绘制不出形状来，检查了顶点数据 N 遍后确认顶点数据无误，于是我把注意点转向了 api 的调用，发现无法绘制出来形状和 opengl 版本是有些关系的。于是想写一篇 blog 整理一下。 opengl 历史就不说了，下面的测试代码用两种方式绘制三角形，一种是 opengl 现代模式绘制，另一种是兼容模式绘制。现代模式就是指定了 opengl 最低版本是 3.3 。 问题与结论 我遇见的问题如下。 为什么我没有创建 vao 就绘制不出三角形？而在 opengles 中确可以。 当我使用 vao 时，我可以不用 bo 来缓存顶点属性数据吗？ 如果我想在 opengl 中直接调用 glVertexAttribPointer 设置属性后调用 draw 函数绘制（调试时，总是想少写些代码），应该在什么环境下？ 写代码测试后结论如下。 指定 opengl 最低版本号为 3.3 时，这时绘制要创建一个 vertex array object （vao），否则无法绘制出形状。 使用 vao 时，此时要使用 buffer

MNN是一个轻量级的深度神经网络推理引擎，在端侧加载深度神经网络模型进行推理预测。目前，MNN已经在阿里巴巴的手机淘宝、手机天猫、优酷等20多个App中使用，覆盖直播、短视频、搜索推荐、商品图像搜索、互动营销、权益发放、安全风控等场景。此外，IoT等场景下也有若干应用。 整体特点 轻量性 • 针对端侧设备特点深度定制和裁剪，无任何依赖，可以方便地部署到移动设备和各种嵌入式设备中。 • iOS平台：armv7+arm64静态库大小5MB左右，链接生成可执行文件增加大小620KB左右，metallib文件600KB左右。 • Android平台：so大小500KB左右，OpenCL库300KB左右，Vulkan库300KB左右。 通用性 • 支持Tensorflow、Caffe、ONNX等主流模型文件格式，支持CNN、RNN、GAN等常用网络。 • 支持 149 个TensorflowOp、47 个CaffeOp、74 个 ONNX Op；各计算设备支持的MNN Op数：CPU 110个，Metal 55个，OpenCL 29个，Vulkan 31个。 • 支持iOS 8.0+、Android 4.3+和具有POSIX接口的嵌入式设备。 • 支持异构设备混合计算，目前支持CPU和GPU，可以动态导入GPU Op插件，替代CPU Op的实现。 高性能 • 不依赖任何第三方计算库

一、前言 做视频监控系统，绕不过onvif这玩意，这玩意主要就是为了统一一个大概的标准，能够对各个厂家的监控设备进行常用的一些操作，比如搜索、获取信息、云台控制、事件订阅、抓拍图片等，如果没有这个规范，那么各个厂家都各自为政，需要用私有的sdk去处理，这样就很麻烦很惨了，几十个厂家就需要几十个sdk，对于程序员来说简直是灾难，想想就很恐怖的事情，哪个程序员不想多活几年！ onvif设备搜索是最基本的功能，想要对设备进行进一步的处理，必须先搜索到设备，默认onvif搜索只能搜索到同一个网段的设备，要跨网段的话，需要手动指定设备的IP地址或者onvif地址进行搜索，这两者在封装的onvif类中都考虑到了，经历过各种复杂的现场情况的考验，也可以算是本系统的一个小特色吧。 onvif主要的功能 搜索设备，获取设备的信息比如厂家、型号等。 获取设备的多个配置文件信息profile。 获取对应配置文件的视频流地址rtsp，以及分辨率等参数。 云台控制，上下左右移动，焦距放大缩小，相对和绝对移动。 获取预置位信息，触发预置位。 订阅事件，接收设备的各种消息尤其是报警事件比如IO口的报警。 抓图，获取设备当前的图片。 获取、创建、删除用户信息。 获取和设备网络配置信息比如IP地址等。 获取和设置NTP时间同步。 获取和设置设备时间。 重启设备。 onvif的处理流程 绑定组播IP（239.255

一、前言 用ffmpeg来做音视频同步，个人认为这个是ffmpeg基础处理中最难的一个，无数人就卡在这里，怎么也不准，本人也是尝试过网上各种demo，基本上都是渣渣，要么仅仅支持极其少量的视频文件比如收到的数据包是一帧视频一帧音频的，要么根本没法同步歪七八糟的，要么进度跳过去直接蹦蹦蹦崩溃的，其实最完美的音视频同步处理demo就是ffplay，我亲测过几十种各种各样的音视频本地文件，数十种视频流文件，都是非常完美，当然啦这是亲生的啦，不完美还玩个屁。 如果仅仅是播放视频流（不带音频流），可能不需要音视频同步，所以最开始只做rtsp视频流播放的时候根本没有考虑同步的问题，因为没遇到也不需要，等到后期发现各种rtmp、http、m3u8这种视频流的时候，问题大了去了，他是hls格式的视频流文件一次性过来的，一个个小视频文件过来的，如果没有同步的话，意味着突然之间刷刷刷的图片过去很多，下一次来的又是刷刷的，这就需要自己计算同步了，上次接收到的数据包放入队列，到了需要显示的时候就显示。 常用的音视频同步方法： 通过fps来控制，fps表示一秒钟播放多少帧，比如25帧，可以自行计算一帧解码用掉的时间，一帧占用（1000/25=40毫秒），通过延时来处理，这其实是最渣渣的办法。 记住开始解码的时间startTime，通过av_rescale_q计算pts时间，两者的差值就是需要延时的时间

同步发布在Cocos论坛 Cocos Creator 3D初体验 官方文档 https://docs.cocos.com/creator3d/manual/zh/ 下载 https://www.cocos.com/creator3d 目前个人使用的版本是v1.1.1，官方已发布v1.2版本 整体的使用感受 UI界面的制作一如既往的便捷高效 对Cocos Creator 2D上手很友好 有自己的3D编辑器 材质系统非常的灵活 当前版本对2D游戏的支持不够完善 目前不太完善的地方 2D方面 不支持LabelAtlas，可以使用bmfont间接来实现 mask不支持图片作为模板 场景资源的自动释放不可用,可以通过一些特殊手段来释放内存 暂不支持动态合图 暂不支持spine、龙骨 3D方面 不支持动画分层，也就是不支持角色上下半身播放不同的动作。 v1.1.1阴影只支持平面阴影，也就是说阴影只能投到地上但无法投射到模型身上。v1.2阴影支持shadowMap但不是很完善。 v1.1.1不支持雾效，v1.2已支持。 暂不支持后处理(HDR、景深、泛光) 其他 暂不支持通过npm的方式引入代码库 帮助美术同学上手新引擎的相关文档 材质系统 https://docs.cocos.com/creator3d/manual/zh/material-system/overview.html