每次看一会视频 ，就直接崩掉

【功能模块】视频调阅【操作步骤&问题现象】1、在获取到经纬度、高度后，开发同事从测试环境打包，在线上环境上传包。（获取经纬度、高度求助帖子地址：https://bbs.huaweicloud.com/forum/thread-193792-1-1.html）2、打开视频调阅界面为空任何东西或页面获取摄像机列表页面一直为loading状态，然后浏览器无响应【截图信息】【日志信息】（可选，上传日志内容或者附件）

ModelArts有支持支持视频流分析的功能吗? 即拉流进行视频分析?

【功能模块】综合安防-视频调阅【操作步骤&问题现象】1、调用视频调阅内接口返回摄像头点位数据时，经度、维度、高度，三个数据相同，返回结果都为维度。2、【截图信息】接口地址：'/SmartCampus__SecurityManagement/1.0.0/getEquipmentWithTypeList'返回数据截图如下：【日志信息】（可选，上传日志内容或者附件）

              干货！！！CANN 环境搭建快人一步，全流程演示视频看这里→                                              进入昇腾社区立即体验CANN，欢迎大家留言分享~延伸阅读  工具安装：【离线部署工具ascend-deployer】

一.存储容器化存储作为基础组件，直接和本地盘打交道，所以我们一个要解决的事情就是如果Kubernetes 管理本地盘。kubernetes管理本地盘通过官方提供的local-static-provisioner自动生成LocalPersistentVolume管理磁盘。LocalPersistentVolume是Kubernetes提供的一种管理本地盘的资源。5.1 使用Statefulset管理存储容器通过statefulset 管理有状态的存储服务， 为每个pod分配一个单独的磁盘可以使用volumeClaimTemplates给每个pod生成唯一的pvc，具体规则{podName}，事先准备好PVC 和 PV，通过Statefulset 我们就可以把我们的存储托管到云上了。另外借助daemonset，可以把我们gateway模块部署到每一个node上面。处理云存储的请求。5.2 存储容器化的收益1）降低运维成本基于Kubernetes和statfulset获得了滚动更新，灰度更新，健康检查，快速扩容等功能，只需要一组yaml文件就可以快速搭建一个集群，相比于传统写ansible脚本部署的方式复杂度大大降低。2）降低开发运维成本由于Kubernetes把存储抽象成StorageClass PersistentVolume PersistentVolumeClaim。我们可以通过他们管理我们的存储资源，基于Kubernetes lable的过滤功能，可以实现简单的关系查询，通过PVC与PV管理存储资源，减少管理端的开发。定位问题也能通过POD信息快速定位到问题机器和问题云盘。而且接入Kubernetes生态上的prometheus后，监控告警也能快速开发。3）隔离性增强docker限制cpu memory使用，减少进程之间资源互相干扰，进一步提升资源利用率。 在做流媒体容器化过程中，各个系统 Portal 平台、中间件、ops 基础设施、监控等都做了相应的适配改造，改造后的架构矩阵如下图所示。Portal：流媒体 的 PaaS 平台入口，提供 CI/CD 能力、资源管理、自助运维、应用画像、应用授权(db 授权、支付授权、应用间授权)等功能。2.运维工具：提供应用的可观测性工具, 包括 watcher（监控和报警）、bistoury （Java 应用在线 Debug）、qtrace（tracing 系统）、loki/elk（提供实时日志/离线日志查看）。中间件：应用用到的所有中间件，mq、配置中心、分布式调度系统 qschedule、dubbo 、mysql sdk 等。3.虚拟化集群：底层的 K8s 和 OpenStack 集群。4.Noah：测试环境管理平台，支持应用 KVM/容器混合部署。一．CI/CD 流程改造 主要改造点:应用画像: 把应用相关的运行时配置、白名单配置、发布参数等收敛到一起，为容器发布提供统一的声明式配置。授权系统: 应用所有的授权操作都通过一个入口进行，并实现自动化的授权。K8s 多集群方案: 通过调研对比，KubeSphere 对运维优化、压测评估后也满足我们对性能的要求，最终我们选取了 KubeSphere 作为多集群方案。二.中间件适配改造改造关注点：由于容器化后，IP 经常变化是常态，所以各个公共组件和中间件要适配和接受这种变化。Qmq组件改造点：Broker端加快过期数据的处理速度。原因:由于IP变化频繁，对于一个主题有几百个甚至上千个的IP订阅，会产生很多文件Qconfig/Qschedule组件改造点：按实例级别的推送、任务执行在容器场景下不建议使用 。原因:因为IP经常变化，在容器化场景下发布、pod驱逐等都会导致IP变化，按实例维度推送没有意义Dubbo组件改造点：更改上线下线逻辑，下线记录由永久节点改为临时节点。 原因:上下线机制加上频繁的IP变更会导致zookeeper上产生大量的过期数据Openresty改造点：监听多K8s集群的endpoint变更，并更新到upstream; KVM、容器server地址共存，支持KVM和容器混合部署;三应用平滑迁移方案设计为了帮助业务快速平滑地迁移到容器，制定了一些规范和自动化测试验证等操作来实现这个目标。1.容器化的前置条件: 应用无状态、不存在 post_offline hook（服务下线后执行的脚本）、check_url 中不存在预热操作。2.测试环境验证: 自动升级 SDK、自动迁移。我们会在编译阶段帮助业务自动升级和更改 pom 文件来完成 SDK 的升级，并在测试环境部署和验证，如果升级失败会通知用户并提示。3.线上验证: 第一步线上发布，但不接线上流量，然后通过自动化测试验证，验证通过后接入线上流量。4.线上 KVM 与容器混部署：保险起见，线上的容器和 KVM 会同时在线一段时间，等验证期过后再逐步下线 KVM。5.线上全量发布: 确认服务没问题后，下线 KVM。6.观察: 观察一段时间，如果没有问题则回收 KVM。

一.存储容器化存储作为基础组件，直接和本地盘打交道，所以我们一个要解决的事情就是如果Kubernetes 管理本地盘。kubernetes管理本地盘通过官方提供的local-static-provisioner自动生成LocalPersistentVolume管理磁盘。LocalPersistentVolume是Kubernetes提供的一种管理本地盘的资源。5.1 使用Statefulset管理存储容器通过statefulset 管理有状态的存储服务， 为每个pod分配一个单独的磁盘可以使用volumeClaimTemplates给每个pod生成唯一的pvc，具体规则{podName}，事先准备好PVC 和 PV，通过Statefulset 我们就可以把我们的存储托管到云上了。另外借助daemonset，可以把我们gateway模块部署到每一个node上面。处理云存储的请求。5.2 存储容器化的收益1）降低运维成本基于Kubernetes和statfulset获得了滚动更新，灰度更新，健康检查，快速扩容等功能，只需要一组yaml文件就可以快速搭建一个集群，相比于传统写ansible脚本部署的方式复杂度大大降低。2）降低开发运维成本由于Kubernetes把存储抽象成StorageClass PersistentVolume PersistentVolumeClaim。我们可以通过他们管理我们的存储资源，基于Kubernetes lable的过滤功能，可以实现简单的关系查询，通过PVC与PV管理存储资源，减少管理端的开发。定位问题也能通过POD信息快速定位到问题机器和问题云盘。而且接入Kubernetes生态上的prometheus后，监控告警也能快速开发。3）隔离性增强docker限制cpu memory使用，减少进程之间资源互相干扰，进一步提升资源利用率。在做流媒体容器化过程中，各个系统 Portal 平台、中间件、ops 基础设施、监控等都做了相应的适配改造，改造后的架构矩阵如下图所示。1. Portal：流媒体 的 PaaS 平台入口，提供 CI/CD 能力、资源管理、自助运维、应用画像、应用授权(db 授权、支付授权、应用间授权)等功能。2.运维工具：提供应用的可观测性工具, 包括 watcher（监控和报警）、bistoury （Java 应用在线 Debug）、qtrace（tracing 系统）、loki/elk（提供实时日志/离线日志查看）。中间件：应用用到的所有中间件，mq、配置中心、分布式调度系统 qschedule、dubbo 、mysql sdk 等。3.虚拟化集群：底层的 K8s 和 OpenStack 集群。4.Noah：测试环境管理平台，支持应用 KVM/容器混合部署。一．CI/CD 流程改造主要改造点:应用画像: 把应用相关的运行时配置、白名单配置、发布参数等收敛到一起，为容器发布提供统一的声明式配置。授权系统: 应用所有的授权操作都通过一个入口进行，并实现自动化的授权。K8s 多集群方案: 通过调研对比，KubeSphere 对运维优化、压测评估后也满足我们对性能的要求，最终我们选取了 KubeSphere 作为多集群方案。二.中间件适配改造改造关注点：由于容器化后，IP 经常变化是常态，所以各个公共组件和中间件要适配和接受这种变化。Qmq组件改造点：Broker端加快过期数据的处理速度。原因:由于IP变化频繁，对于一个主题有几百个甚至上千个的IP订阅，会产生很多文件Qconfig/Qschedule组件改造点：按实例级别的推送、任务执行在容器场景下不建议使用 。原因:因为IP经常变化，在容器化场景下发布、pod驱逐等都会导致IP变化，按实例维度推送没有意义Dubbo组件改造点：更改上线下线逻辑，下线记录由永久节点改为临时节点。 原因:上下线机制加上频繁的IP变更会导致zookeeper上产生大量的过期数据Openresty改造点：监听多K8s集群的endpoint变更，并更新到upstream; KVM、容器server地址共存，支持KVM和容器混合部署;三应用平滑迁移方案设计为了帮助业务快速平滑地迁移到容器，制定了一些规范和自动化测试验证等操作来实现这个目标。1.容器化的前置条件: 应用无状态、不存在 post_offline hook（服务下线后执行的脚本）、check_url 中不存在预热操作。2.测试环境验证: 自动升级 SDK、自动迁移。我们会在编译阶段帮助业务自动升级和更改 pom 文件来完成 SDK 的升级，并在测试环境部署和验证，如果升级失败会通知用户并提示。3.线上验证: 第一步线上发布，但不接线上流量，然后通过自动化测试验证，验证通过后接入线上流量。4.线上 KVM 与容器混部署：保险起见，线上的容器和 KVM 会同时在线一段时间，等验证期过后再逐步下线 KVM。5.线上全量发布: 确认服务没问题后，下线 KVM。6.观察: 观察一段时间，如果没有问题则回收 KVM。

行业痛点由于视频监控能最大的记录和还原当被监控的场景，近年来，视频监控逐步从专业领域的应用普及到了各个民用、家用领域，各个摄像相机厂家也纷纷推出各种型号的摄像机和解决方案。由于视频监控数据量大，也会遇到各种问题：存储资源消耗大且增长迅速。视频监控业务极度消耗存储资源，一个成规模的互联网视频监控服务往往需要PB级甚至更多存储资源，普通IDC或小云服务提供商有限的基础设施很容易成为云视频监控业务爆发增长的瓶颈，一旦出现存储瓶颈，扩容难度大，迁移成本高。对数据可靠性要求高。监控视频数据是安防监控业务的核心价值数据，必须不能丢失。尤其是在互联网业务模式下，如果能做到视频数据不丢失，安防监控服务提供商就能向其终端用户提供可靠的视频存储服务。带宽资源消耗巨大，且上行、下行流量不对称。7*24小时写入视频流的视频监控业务是重资产的业务，数万级别摄像头、数GB级别并发上传流量带来了巨大的带宽成本。并且，视频监控业务有明显的上行流量远大于下行流量的特点，而在互联网类的业务模式下，下行流量才是行业的有效业务流量。在传统IDC架构中，流量不对称的特点直接导致无效成本的增加。用户观看体验在海量并发业务下难以保障。流畅是视频监控最重要的用户体验，数万路视频并发写入、观看需要优质的基础设施、强大的产品性能，来保障视频体验质量。视频流一般为分片存储，任意分片写入失败，就会直接导致播放时卡顿。阿里云针对安防监控服务在传统IT架构下面临的上述问题，基于阿里云存储服务，提供视频监控解决方案。从2015年推出视频监控存储与播放解决方案以来，帮助大量的视频监控企业解决了上云的过程中遇到的问题，针对不同的视频监控厂商，也推出了不同的解决方案：方案一、针对传统视频监控平台解决方案：参考架构：方案解读：视频流由摄像头推送到流媒体服务器（需要用户自己用ECS搭建）。流媒体服务器对视频流进行TS切片（需要用户自己用ECS搭建） 并转存到OSS。视频直播业务可由OSS直接实现，或者由流媒体服务器 进行转发。视频录像回看业务可以直接从OSS中拉去，或者由流媒体服务器从OSS中拉取后转发给用户端解决方案特点和优势：弹性计算，使得单摄像头综合成本下降30%，整体计算成本下降50%。通过采用低成本低配置云服务器来保证业务持续性，搭配使用弹性伸缩服务在业务高峰期自动增加云服务器数量来保证业务的正常运转。同时，这种弹性伸缩能力，能够提高资源利用率。而且，上行带宽零收费又进一步降低监控视频上传成本，使得整体成本结构更加合理。更加流畅的视频观看体验。阿里云优质的BGP带宽带来更低的播放延迟；阿里云对象存储具有极低的写入失败率，能够有效避免因视频文件切片写入失败导致视频观看出现卡顿等不流畅现象。海量视频文件存储能力。阿里云的对象存储（OSS）能够提供海量的文件存储，同时具有10个9的数据可靠性，并提供同城热备和异地灾备方案，使海量监控视频永久存储，随时可得。可扩展性更好。解决方案中存储、计算和分发在都轻松扩展。方案二、针对摄像机解决方案参考架构：方案解读：视频源（摄像机或者是流媒体服务器）登录获取到访问OSS的权限（阿里云提供访问OSS的鉴权服务）后，直接将视频流推送到阿里云对象存储OSS；用户采用阿里云独有的追加式写入功能，将视频码流为保存到OSS；若用户视频保存为HLS（TS+M3U8）格式（该格式为互联网最常见的视频文件格式之一），则无需通过其他服务，可以方便的通过手机、电脑等终端实时观看视频流和录像回放。完美实现云视频实时观看和录像云端回放。方案优势：充裕的接入带宽，即使有大量突发访问，也能保证整体业务平稳顺畅。2.更加流畅的视频观看体验。阿里云优质的BGP带宽带来更低的播放延迟；阿里云对象存储具有极低的写入失败率，能够有效避免因视频文件切片写入失败导致视频观看出现卡顿等不流畅现象。3.海量视频文件存储能力。阿里云的对象存储（OSS）能够提供海量的文件存储，同时具有10个9的数据可靠性，并提供同城热备和异地灾备方案，使海量监控视频永久存储，随时可得。可扩展性更好。解决方案中存储、计算和分发在都可轻松扩展。文件生命周期管理。针对视频监需要大量定期删除过期文件的场景，阿里云OSS存储服务支持到期文件自动删除，免除您删除过期文件的后顾之忧。灾备能力。阿里云OSS提供多节点数据复制功能，轻松实现数据的异地灾备。行业技术能力。世界各地的视频监控摄像机头都有用到阿里云的服务，在视频监控领域阿里云积累了大量的行业和技术经验，可以保证用户的业务平稳运行。方案三、针对支持RTMP推流协议的摄像机：参考架构：方案解读：通过OSS实现直接接收RTMP流然后转换成HLS存储到OSS，通过OSS的下行流量实现点播和直播。2.用户需要在OSS申请bucket，开通直播服务。3.直播数据转换为HLS（TS+M3U8）格式后保存为OSS文件，可选是否保留文件进行点播。视频直播、点播都是HLS（TS+M3U8）格式。客户获取M3U8地址后直接播放。方案优势：除集合了方案一和方案二的优势外。还有有以下特点：极简的系统架构，只需摄像机支持RTMP协议，无需对摄像机软硬件做改造，即可实现云存储；支持HLS直播与点播功能，轻松实现互联网应用；总之，针对视频监控数据的高可用需求，对比传统的存储方案阿里云视频监控解决方案解决了以下难题：1. 对写入成功率要求高由于视频数据写入存储失败会导致观看卡顿甚至无法播放，而阿里云存储专门针对视频监控行业海量文件写入场景进行优化，提供业内顶尖的写入成功率，遥遥领先于同行，且经过大量客户海量数据检验。2. 数据可靠性要求高云存自动实现三分数据备份，提供11个9的数据高可靠性，保障视频录像文件安全可靠、可信。支持百万级视频设备接入，架构灵活可靠、弹性扩展，可根据不同业务需求弹性开通、释放资源。举一个极端的例子，哪怕有人冲到机房里面拿走了阿里云的一些服务器，也不必担心其中的数据会泄密或者丢失，因为里面的数据被储存为加密文件碎片，看不到任何一个完整的文件，而三份备份则摄像机所拍摄内容可以在云端被安全找回，秒级恢复。真正做到了数据看不见、摸不着、拿不走。挖掘云上监控数据的行业价值一、实时视频分析----摄像机遇上云智能视频分析，从看得清到看得懂视频上传到云端后，通过消息服务通知阿里云AI服务，获取视频后进行指定的视频分析，并把视频分析结果实时通知用户。全智能的云视频分析系统，可以有效的避免信息遗漏、使各种高危风险在发生的之初就立即通知处理人员从而避免事件的发生。大大提高整个视频监控系统的效果和质量，减少工作人员的强度。场景举例：• 人脸识别： 家庭人脸智能时光相册、幼儿园宝宝智能分类录像、智能门铃 ..• 人数统计： 商超人流统计、热点区域分析、收银排队分析…• 特定行为分析： 家庭老人跌倒识别、手势识别、宝宝哭闹识别、入侵检测 …• 智能交通：车牌识别、拥堵检测、交通违章识别• 公共防护：区域保护、入侵检测…• 公安侦查：嫌疑犯识别、群体事件• 幼儿园：宝宝异常行为识别、哭闹坚持、跌倒检测…二、离线视频分析----智能挖掘存量视频金矿，让数据发挥无限价值当视频文件上传到云端后，大量的视频文件占了大量的存储空间，由于成本和其他因素的考虑，一般视频数据存储一定期限后就定期删除。所以这海量的数据没有产生任何的价值，给人造成的影响是存储只会花钱不会赚钱。实际上呢？这是一座视频数据金矿！通过阿里云或自研的视频分析算法，不仅可以挖掘存量视频价值，甚至还可以跨界拓展各类业务• 视频浓缩去重：去除重复背景，将视频中有意义的场景自动永久保存• 视频结构化标签：将非结构化视频内容理解成结构化数据• 智能交通：离线违章检测，对海量的治安、卡口等非交通类摄像机数据进行二次数据挖掘，对违章车辆进行处罚• 公安刑侦：海量视频搜索、案件线索关联…

一、背景全民直播时代，人们每天刷着五花八门的短视频，每分每秒都有无数的视频文件被生成、播放。但你可曾想过这些电视剧、电影、视频广告、短视频等影音是以怎样的数据形式在我们的显示设备中播放出来的？本文将基于 OpenHarmony 3.2 Beta1 版本的媒体能力，为你详细解读一个视频文件（本文以 MP4 封装格式、H264 压缩格式的视频文件为例）是怎么在基于 OpenHarmony 标准系统的设备上播放出来的。同时也带你一窥“播放一个视频文件”这件对 OpenHarmony 3.2 Beta1 版本系统能力很轻松的事，是由多少服务层、功能接口、工具、插件、命令行及代码等共同协作完成的。 二、OpenHarmony 3.2媒体能力全景OpenHarmony 技术架构如下图所示，完成视频文件播放功能的是多媒体子系统。下图所示为多媒体子系统框架图如图所示，OpenHarmony 多媒体子系统拉起了一个叫 mediaserver 的服务来处理媒体事务，并且封装了接口层包括JS接口、native 接口提供给 APP 调用，mediaserver 的核心则是引入了 gstreamer（以下简称 gst）框架来完成媒体功能（注：gstreamer 是一套功能强大、兼容性好、结构清晰的开源媒体框架，这里不做赘述，后面有专文解析）。OpenHarmony 也在 gst 的基础上开发了 player engine 来实现播放，同时也利用 gst 丰富的插件资源实现几乎所有的媒体功能。截至目前，已移植进来的开源插件包括 file source、demuxer、video decoder、libav 插件等，当然也包括 OpenHarmony 自研的 video sink、memsink、codec hdi 插件等。三、把大象装冰箱（H264视频播放）总共分几步？视频播放流程图如下：如图所示，播放一个视频大致分为 4 步：解协议->解封装->解压缩->送显播放pipeline根据视频播放的步骤，我们在 OpenHarmony 上每一个环节都能找到对应的插件来完成，同时参考 media_standard 代码仓的代码目录，相关的代码都可以找到对应的实现逻辑。1、对于一个本地视频文件（比如/data/h264-640x480.mp4），对应的 filesrc 插件来完成文件的解析，拿到MP4文件流；OpenHarmony 处理本地视频文件 URI 的 SetSource 逻辑代码如下：int32_t PlayerEngineGstImpl::SetSource(const std::string &url) { std::unique_lock<std::mutex> lock(mutex_); CHECK_AND_RETURN_RET_LOG(!url.empty(), MSERR_INVALID_VAL, "input url is empty!"); CHECK_AND_RETURN_RET_LOG(url.length() <= MAX_URI_SIZE, MSERR_INVALID_VAL, "input url length is invalid!"); std::string realUriPath; int32_t ret = MSERR_OK; if (IsFileUrl(url)) { ret = GetRealPath(url, realUriPath); if (ret != MSERR_OK) { return ret; } url_ = "file://" + realUriPath; } else { url_ = url; } MEDIA_LOGD("set player source: %{public}s", url_.c_str()); return ret; }这样就会得到一个 URI：file:///data/h264-640x480.mp4，gst 正是通过 URI 前缀来判断是否是本地视频文件，然后获取文件内容。2、拿到 MP4 文件流后，对应的 qtdemux 插件来解封装，完成音视频分流，输出 H264 裸码流和音频流；3、拿到 H264 码流后，h264parse 插件开始切片，输出 H264 帧数据；4、处理 H264 帧数据，就由 avdec_h264 插件来完成，一般情况会输出 NV12 的像素数据，当然这个解码器是基于 ffmpeg 的软解插件，相信不久各个芯片厂商的硬件加速解码器都会加进来；可以使用 gst-inspect 工具查看 avdec_h264 解码插件，使用 ffmpeg 的解码能力，支持的格式非常丰富。5、至此解码的工作已经完成，后面就要根据显示的像素格式、size 来对解码输出数据进行后处理（转换、缩放、裁剪等），会由 Converter、Scaler、Clip 插件来完成；6、满足显示要求后就会使用 surfacesink 插件完成合成送显。送显需要先申请显示 surface buffer，申请逻辑代码如下：GstSurfaceMemory *gst_surface_allocator_alloc(GstSurfaceAllocator *allocator, GstSurfaceAllocParam param) { g_return_val_if_fail(allocator != nullptr && allocator->surface != nullptr, nullptr); static constexpr int32_t stride_alignment = 8; int32_t wait_time = param.dont_wait ? 0 : INT_MAX; // wait forever or no wait. OHOS::BufferRequestConfig request_config = { param.width, param.height, stride_alignment, param.format, static_cast<uint32_t>(param.usage) | HBM_USE_CPU_READ | HBM_USE_CPU_WRITE | HBM_USE_MEM_DMA, wait_time }; int32_t release_fence = -1; OHOS::sptr<OHOS::SurfaceBuffer> surface_buffer = nullptr; OHOS::SurfaceError ret = allocator->surface->RequestBuffer(surface_buffer, release_fence, request_config); if (ret == OHOS::SurfaceError::SURFACE_ERROR_NO_BUFFER) { GST_INFO("there is no more buffers"); } if (ret != OHOS::SurfaceError::SURFACE_ERROR_OK || surface_buffer == nullptr) { return nullptr; } ret = surface_buffer->Map(); if (ret != OHOS::SurfaceError::SURFACE_ERROR_OK) { GST_ERROR("surface_buffer Map failed"); return nullptr; } OHOS::sptr<OHOS::SyncFence> autoFence = new(std::nothrow) OHOS::SyncFence(release_fence); if (autoFence != nullptr) { autoFence->Wait(100); // 100ms } GstSurfaceMemory *memory = reinterpret_cast<GstSurfaceMemory *>(g_slice_alloc0(sizeof(GstSurfaceMemory))); if (memory == nullptr) { GST_ERROR("alloc GstSurfaceMemory slice failed"); allocator->surface->CancelBuffer(surface_buffer); return nullptr; } gst_memory_init(GST_MEMORY_CAST(memory), (GstMemoryFlags)0, GST_ALLOCATOR_CAST(allocator), nullptr, surface_buffer->GetSize(), 0, 0, surface_buffer->GetSize()); memory->buf = surface_buffer; memory->fence = -1; memory->need_render = FALSE; GST_DEBUG("alloc surface buffer for width: %d, height: %d, format: %d, size: %u", param.width, param.height, param.format, surface_buffer->GetSize()); return memory; }申请好的 buffer 会放入 buffer pool，形成一个 buffer 队列。解码器解完一帧会将数据放入 buffer pool，sink 插件会从 buffer pool 中拿到数据送显，代码逻辑如下：static GstFlowReturn gst_surface_mem_sink_do_app_render(GstMemSink *memsink, GstBuffer *buffer, bool is_preroll) { g_return_val_if_fail(memsink != nullptr && buffer != nullptr, GST_FLOW_ERROR); GstSurfaceMemSink *surface_sink = GST_SURFACE_MEM_SINK_CAST(memsink); g_return_val_if_fail(surface_sink != nullptr, GST_FLOW_ERROR); GstSurfaceMemSinkPrivate *priv = surface_sink->priv; GST_OBJECT_LOCK(surface_sink); if (gst_surface_mem_sink_drop_frame_check(surface_sink) == FALSE) { GST_OBJECT_UNLOCK(surface_sink); GST_DEBUG_OBJECT(surface_sink, "user set rate, drop same frame"); return GST_FLOW_OK; } if (surface_sink->firstRenderFrame) { GST_WARNING_OBJECT(surface_sink, "KPI-TRACE: first render frame"); surface_sink->firstRenderFrame = FALSE; } for (guint i = 0; i < gst_buffer_n_memory(buffer); i++) { GstMemory *memory = gst_buffer_peek_memory(buffer, i); if (!gst_is_surface_memory(memory)) { GST_WARNING_OBJECT(surface_sink, "not surface buffer !, 0x%06" PRIXPTR, FAKE_POINTER(memory)); continue; } GstSurfaceMemory *surface_mem = reinterpret_cast<GstSurfaceMemory *>(memory); surface_mem->need_render = TRUE; gboolean needFlush = TRUE; if (is_preroll) { surface_sink->prerollBuffer = buffer; } else { if (surface_sink->prerollBuffer == buffer) { // if it's paused, then play, this buffer is render by preroll surface_sink->prerollBuffer = nullptr; needFlush = FALSE; } } if (needFlush) { OHOS::BufferFlushConfig flushConfig = { { 0, 0, surface_mem->buf->GetWidth(), surface_mem->buf->GetHeight() }, }; gst_surface_mem_sink_dump_buffer(surface_sink, buffer); OHOS::SurfaceError ret = priv->surface->FlushBuffer(surface_mem->buf, surface_mem->fence, flushConfig); if (ret != OHOS::SurfaceError::SURFACE_ERROR_OK) { surface_mem->need_render = FALSE; GST_ERROR_OBJECT(surface_sink, "flush buffer to surface failed, %d", ret); } } } GST_OBJECT_UNLOCK(surface_sink); GST_DEBUG_OBJECT(surface_sink, "End gst_surface_mem_sink_do_app_render"); return GST_FLOW_OK; }再加上 audio 的插件解码出音频数据，OpenHarmony 的 player 会完成音视频同步，至此一个视频文件就会播放显示在屏幕上。OpenHarmony 为了实现更好的用户体验，同时也引入了一些解决性能问题的插件，比如 multiqueue 插件来实现 buffer 队列，也使用 decodebin 高级插件来完成解码 element 的选择。通过梳理，我们最终可以得到一条播放的 pipeline：而通过播放 OpenHarmony 自带的图库播放本地 H264 视频，抓取 log，搜索 OnElementSetupCb 关键字也可以得到播放的 pipeline，这也进一步验证了本文的分析。另外，我们也可以使用 gst-launch 手动创建 pipeline 来验证：gst-launch --gst-plugin-path=/system/lib/media/plugins filesrc location=/data/media/h264.mp4 ! qtdemux ! h264parse ! avdec_h264 ! videoconvert ! videoscale ! video/x-raw,width=640,height=480 ! surfacememsink附录：OpenHarmony标准系统media组件介绍https://gitee.com/openharmony/multimedia_media_standardhttps://gitee.com/openharmony/multimedia_media_standardMP4封装格式介绍https://wenku.baidu.com/view/b4f52a376ddb6f1aff00bed5b9f3f90f76c64dbd.htmlhttps://wenku.baidu.com/view/b4f52a376ddb6f1aff00bed5b9f3f90f76c64dbd.htmlgst介绍https://gstreamer.freedesktop.org/documentation/tutorials/index.html?gi-language=chttps://gstreamer.freedesktop.org/documentation/tutorials/index.html?gi-language=chttps://blog.csdn.net/qq_45662588/article/details/120763198https://blog.csdn.net/qq_45662588/article/details/120763198OpenHarmony 3.2 Beta1 版本路书https://gitee.com/openharmony/docs/blob/master/zh-cn/release-notes/OpenHarmony-v3.2-beta1.mdOpenHarmony媒体子系统框架介绍https://gitee.com/openharmony/docs/blob/master/zh-cn/readme/%E5%AA%92%E4%BD%93%E5%AD%90%E7%B3%BB%E7%BB%9F.mdhttps://gitee.com/openharmony/docs/blob/master/zh-cn/readme/%E5%AA%92%E4%BD%93%E5%AD%90%E7%B3%BB%E7%BB%9F.mdOpenHarmony视频播放应用开发指导https://gitee.com/openharmony/docs/blob/master/zh-cn/application-dev/media/video-playback.md转载于 OpenAtom OpenHarmony 微信公众号

随着新一代折叠屏手机HUAWEI Mate Xs 2发布，HarmonyOS折叠屏设计规范（后文简称：设计规范）也马不停蹄地更新啦！这次更新的设计规范不仅新增了更多应用场景案例，帮助大家高效设计不同类型的业务应用，还通过清晰直观的案例对比图，帮助大家有效避坑。HarmonyOS折叠屏设计规范：https://developer.harmonyos.com/cn/docs/design/des-guides/basic-requirements-0000001193421226一、基础要求我们发现部分应用在手机上显示效果很好，但是到折叠屏上，图片、字体、卡片等元素过大，导致一屏看不了多少信息，完全没有利用到大屏幕的优势，反而比在普通手机上浏览效率更低。因此，本次设计规范就在“基础要求”章节针对内容、图片、字体、弹出框、屏幕旋转等提供了适配设计指南。下面将挑选三个比较典型的案例对比图为大家介绍。 1. 信息展示完整图1是信息展示案例对比图，设计规范建议展开态不应出现页面内的内容元素数量减少，或图形化元素模糊、分辨率下降或视觉体量减小等损失，应确保展开态的内容元素不少于折叠态内容元素信息量的3/4。图1 信息展示 2. 字体/图标适配图2是字体适配案例对比图，设计规范建议展开态图标和字体大小不应发生明显变化，在保证可读性的基础上，建议保持跟折叠态一样的大小。若一定要发生大小变化，则最大不要超过1.2倍。为确保有较好的可读性，展开态单屏每行文本长度不超过40字，推荐36字左右。图2 字体/图标适配 3. 弹出框适配图3和图4是弹出框适配案例对比图，设计规范建议展开态和折叠态弹出框保持相同的大小，或大小变化不超过1.2倍。图3 弹出框适配 图4 弹出框不适配了解完折叠屏设计的基础要求，各位开发者、设计师或者产品经理也许想说，上面这些都是小case啦，有没有不同场景的应用案例供我们参考呀？没问题，这就安排！二、典型应用案例你们期待已久的不同场景的应用案例来啦！本次设计规范在“典型应用案例”章节提供了影音娱乐、新闻资讯、生活服务、社交通讯、H5、金融和游戏类等7大场景的应用案例，大家可以参考这些案例，并结合自己应用的业务类型及业务场景，进行折叠屏上的最佳界面适配和创新设计。 由于篇幅有限，此处不再针对上述各个场景展开介绍，下面我们以较为普遍的影音娱乐为例为大家介绍在界面设计时，需要注意些什么。 1. 首页广告在视频应用中，首页顶部往往会有广告。图5和图6是首页广告案例对比图，设计规范建议从折叠态到展开态应用在广告图/视频的左右增加上一张、下一张。不建议从折叠态到展开态直接等比放大广告内容，导致一屏幕显示信息太少，降低浏览效率。图5 首页广告推荐形式 图6 首页广告不推荐形式 2. 视频列表视频类内容往往有不同的长宽比例，因此视频列表常采用宫格结构或瀑布流布局。设计规范建议在展开态增加显示列数为原来的两倍。例如图7是视频应用的视频列表，在折叠态双列显示，展开态扩展为四列。图7 竖向视频列表 图8和图9是带横向视频的应用案例对比图，在折叠态单列显示，推荐展开态扩展为双列。不推荐展开态直接放大显示原来的视频列表，导致单张图片/视频高度超过1/2屏幕高度。 图8 横向视频列表推荐形式 图9 横向视频列表不推荐形式 特殊情况如展开态显示三列（图10所示），则单个图片/视频高度不超过1/2屏幕高度。 图10 三列视频列表如果说典型应用案例可以帮助大家找到正确的努力方向，那么设计自检表则可以帮助大家提高审核通过率~三、设计自检表为了让大家的应用在折叠屏上有更好的使用体验，以及帮助大家能够顺利通过审核，我们提供了设计自检表供大家对照执行。本次更新的自检表对图片&视频、字体、弹出框等提供了量化的自检条目，便于大家用于应用的快速对比验证。最后，除了以上内容，设计规范还在原有章节内容中新增了更多案例对比图，欢迎大家点击“阅读原文”，了解更多HarmonyOS折叠屏设计规范的详细内容。 转载于HarmonyOS开发者微信公众号

之前介绍过《强大的视频抠图(RVM)在AI Gallery的Notebook案例使用》，使用是可以使用，但是还是有点瑕疵，有点障碍的。主要可能存在的障碍就是 torch.hub.load 的使用，需要联网使用github上的资源，这样就存在一点点不确定性，有时候就是连不上对吧。 本篇就是去掉这个不确定行，保证无障碍可用，并且有些新东西哦 首先和原来的notebook一样，仍然是下载，因为这里有模型，用的到 import os !wget https://obs-aigallery-zc.obs.cn-north-4.myhuaweicloud.com/clf/code/RVM/RVM.zip os.system('unzip RVM.zip') !ls RVM asianboss2.mp4 com.mp4 fgr.mp4 pha.mp4 rvm_mobilenetv3.pth 可以看到包里有4个mp4文件，这个是推理用的输入和输出的视频，这里不用。有用的是模型文件 `rvm_mobilenetv3.pth` 原来的加载模型是这样的，这就是可能造成阻碍的地方 #原来的 ***不执行*** import torch from IPython.display import HTML from base64 import b64decode, b64encode model = torch.hub.load("PeterL1n/RobustVideoMatting", "mobilenetv3",pretrained=False).cuda() # or "resnet50" model.load_state_dict(torch.load('rvm_mobilenetv3.pth')) convert_video = torch.hub.load("PeterL1n/RobustVideoMatting", "converter") 需要换一种方式来加载模型，这样先要有加载使用的代码，gitee上有从github同步过来的项目代码，先下载下来并解压： !wget https://gitee.com/harrygt/RobustVideoMatting/repository/archive/v1.0.0.zip import os os.system('unzip -q v1.0.0.zip') #解开后的目录：RobustVideoMatting-v1.0.0 现在该下载的东西都有了，下面要切换到GPU环境，按照顺序，要开始安装torch包和跑代码了。安装torch包使用requirements里指定的版本。如果安装默认最新的包，和下面的推理代码会有不匹配。 但是呢，经过多次尝试，发现在PyTorch-1.8环境里，代码可以直接跑（项目requirement文件里给的是torch1.9.0版本） 既然能跑，我们就不再折腾卸载和按照torch包了。 直接安装其他的包，如果输入输出是视频的话，主要是ffmpeg的python封装包av 另外最新的pillow好像和项目代码有点冲突，我们指定低一点的版本pillow==8.3.2 !pip install --quiet av==8.0.3 pims==0.5 pillow==8.3.2 #这里报错有不兼容什么的，不管了，没关系 #先切换目录， model 模块在下载解开后的这个代码目录 RobustVideoMatting-v1.0.0 中 import os os.chdir('RobustVideoMatting-v1.0.0') import torch import torchvision from model import MattingNetwork model = MattingNetwork('mobilenetv3').eval().cuda() # or "resnet50" model.load_state_dict(torch.load('../RVM/rvm_mobilenetv3.pth')) 加载模型后，调用转换API。这里我们不转换视频，来转换图片序列试试。图片序列用最简单的就一张图片的。 input_source: 填入输入图片的目录，放一张图片到 inpic 目录 output_type: png_sequence 不再是video output_composition: 填入输出图片的目录 outpic output_video_mbps：这个参数是视频才用的，所以注释一下 然后新建好 inpic, outpic 这2个目录，然后找一张图片放进去 os.system('mkdir inpic outpic') from inference import convert_video convert_video( model, # The model, can be on any device (cpu or cuda). input_source='inpic', # A video file or an image sequence directory. output_type='png_sequence', # Choose "video" or "png_sequence" output_composition='outpic', # File path if video; directory path if png sequence. # output_video_mbps=4, # Output video mbps. Not needed for png sequence. downsample_ratio=None, # A hyperparameter to adjust or use None for auto. seq_chunk=12, # Process n frames at once for better parallelism. ) 好了，分别来看一下效果， 实际上我们这里是将RVM当做图片抠图工具来用了，这个实在是杀鸡用牛刀，大材小用了 因为RVM主要是对于视频也就是图片时间序列的实时抠图处理，这方面能力很强。 而对于单张图片，抠图的细致性，比起专做图像抠图的应用来说，通过对比发现，还是粗糙一点。 比如如果是证件照抠图和remove.bg比较起来，差了那么一点点 但是这张图片，好像RVM更强~ from PIL import Image %matplotlib inline img = Image.open('inpic/img_hb_01.jpg', "r") display(img)  img = Image.open('outpic/0000.png', "r") display(img)  而remove.bg的效果是这样的，就衣服来说，还是RVM强点  最后放一个[在ai-gallery上的链接](https://developer.huaweicloud.com/develop/aigallery/notebook/detail?id=a369b6d8-6aa0-4035-a3f1-a208391b78d2)

用户就是三四个人去看视频，走流量感觉一个1080P 的视频3G左右 好烧钱，另一种峰值计费方式没用过求大佬们指点一下。

　　随着5G、数字化技术的应用发展，万物互联的智能物联网(IoT)时代正款款走来。传统的音视频模式已不能适应现代用户的需求，推出先进的数字化和模块化的音视频技术及系统成为行业趋势，各行业领域的技术和产品服务商也开始抢滩布局这个蓝海市场。　　6月28日，《中国经营报》记者从声网方面获悉，其正式推出“灵隼物联网云平台”。据悉，该产品平台专注于智能音视频设备的低代码、端到端开发平台，提供完整的IoT场景化解决方案。　　“音视频物联网的演进，从视听上云、即时连接到目前阶段需要随时随地的实时互动，发展过程中，实时音视频技术在其中的应用占据越来越重要的位置。”声网IoT行业产品负责人侯云忆对记者表示。　　门槛高、体验差是行业通病　　2020年，全球IoT设备连接数量首次超过非IoT设备。其中，在消费产品设备端，随着网络带宽的提升、硬件性能的提升，超高清和沉浸式的新型多媒体终端设备快速增长，常见的有智能机器人、智能车载、智能手表、智能门铃、智能门锁等，而这些设备场景的互动都需要实时音视频技术的支持，音视频物联网正迎来快速增长期，设备的“眼睛”和“耳朵”将无处不在。　　虽然市场在高速增长，但音视频物联网的开发门槛依然很高。首先，对物联网的从业者来说，音视频智能设备面世前，需要面临从芯片、模组到软件方案选型时的平台兼容难题；其次嵌入式、客户端、管理后台等一整套业务逻辑的开发周期也较长；同时音视频体验、网络环境等性能问题成为难以逾越的大山。从用户的角度，则是希望在可以快速连接设备的同时拥有流畅清晰的视频和语音互动体验。　　以智能门铃为例，想要完成该产品的开发，厂商常规的解决方案有两种：一是自研物联网平台，需要面临开发成本高、硬件方案选型难、开发周期长、产品上线慢的困难；二是选择经典的IoT平台，这种窄带数据平台，音视频通常为附加的增值功能，又会面临音视频体验差、平台缺乏开放性、功能同质化严重等问题。　　总结来说，目前物联网市场上，很难有一个“体验好用、开发易用”的音视频物联网平台。基于以上物联网平台开发门槛高、音视频体验差等难点，声网推出了灵隼物联网云平台产品，有Turnkey、自定义两种低代码开发模式，为开发者提供一个端到端、低代码开发平台。据介绍，基于该平台，开发者能在一小时内构建音视频智能硬件的示例场景。　　聚焦在物联网视频硬件研发生产的爱培科产品经理郭力为对记者表示，以前开发搭载适配硬件的IoT平台，需要集成各个组件、移植SDK、优化CPU内存等。移植这种端对端一站式方案，确实能更快完成产品应用的开发和落地，降低研发成本和缩减上线周期。　　智慧物联的下一站　　不过，物联网业务依然存在诸多痛点难点，实时音视频使用对产品的价值到底在哪？未来智慧物联又将如何发展？　　谈及物联网业务当下存在的痛点，博流智能科技产品市场开发总监杜瑞彬告诉记者，“当下物联网行业存在三大痛点，一是产品链路太长，需要经历硬件方案的导入到对接云平台再到落地工厂进行产出；二是不同的硬件产品通过品牌商背后的平台实现互联互通做的还不够；三是智能硬件还需要进一步深入用户场景。”　　方块连连总经理黄友谊则认为，以智能门锁行业为例，该行业产品同质化严重，因此行业都在拓展实时音视频通话作为附加功能，但通话的体验又很难保障。基于RTC技术，方块连连可实现优质的远程通话能力，小程序即可接入的方式也为用户提供了便利。　　而在元宇宙火热的当下及未来，智慧物联的下一站在哪？对此，侯云忆表示，物联网将是元宇宙最重要的感知基础设施，如果世界是元宇宙，实时音视频就是其中的神经网络，最终推动物联网走向人机协同，人机共融。　　亚马逊云科技物联网生态负责人田龙强则向记者强调说，实时音视频本身能支撑更广泛连接传感器，能够接入到各个产品中，不管是VR，还是未来的相关硬件产品，将会给用户带来体验上的大幅提升。谈及万物互联时，他指出伴随万物互联的发展，用户和企业对于隐私也越发重视，私域物联网是行业目前重要的关注方向。

前言无论是拍人拍景或是其他，“天空”都可以说是摄像中的关键元素。比如，一张平平无奇的景色图加上落日余晖的天空色调，是不是有内味了？（随手就可以变换出各种天空效果：晴天、彩虹、晚霞、暮光、夕阳等等）。当然，自然的天空还不是最酷炫的，今天给大家介绍一款基于原生视频的AI处理方法，不仅可以一键切置换天空背景，还可以打造任意“天空之城”。比如，《星际迷航》等科幻电影中经常出现的浩瀚星空、宇宙飞船，也可以利用这项技术融入随手拍的视频中，路人拍摄的公路片也能秒变科幻片，画面毫无违和感。好像只要脑洞够大，利用这项AI技术，可以创作无限种玩法，下面就简单介绍一下华为云的ModelArts 平台，本次ai换天是基于它来实现。ModelArts 是面向开发者的一站式 AI 开发平台，为机器学习与深度学习提供海量数据预处理及交互式智能标注、大规模分布式训练、自动化模型生成，及端-边-云模型按需部署能力，帮助用户快速创建和部署模型，管理全周期 AI 工作流。基础环境准备在使用 ModelArts 进行 AI 开发前，需先完成以下基础操作哦（如有已完成部分，请忽略），主要分为4步（注册–>实名认证–>服务授权–>领代金券）：使用手机号注册华为云账号：点击注册点此去完成实名认证，账号类型选"个人"，个人认证类型推荐使用"扫码认证"。 点此进入 ModelArts 控制台数据管理页面，上方会提示访问授权，点击【服务授权】按钮，按下图顺序操作： 进入 ModelArts 控制台首页，如下图，点击页面上的"彩蛋"，领取新手福利代金券！后续步骤可能会产生资源消耗费用，请务必领取。 以上操作，也提供了详细的视频教程，点此查看：ModelArts环境配置算法流程大致可以分为三个步骤：（1） 天空抠图这一步主要是通过对蒙版数据集进行训练，将图片中的天空和其它物体进行像素级的划分，将天空部分从图片中分离。（2） 运动估计对图片中物体的位移情况进行分析，预估相机的移动方向，使替换后的天空和之前的天空位移一致。（3） 图像混合将去掉天空的原视频和要替换后的天空视频进行融合，同时对非天空的部分采用色彩叠加，是天空和其它物体的视觉效果相近，是视频效果更加逼真。最后，算法使用数据增强的方法模拟出同一张图片在不同光照和天气的情况下的图片，使算法具有更强的适应性。基于ModelArts实现"魔法换天"视频操作具体步骤1.点击进入 【AI魔法换天】的案例页面，并完成基础配置。本次实践使用的是AI框架：PyTorch-1.4，在CPU和GPU下面均可运行，CPU环境运行预计花费9分钟,GPU环境运行预计花费2分钟；点击 Run in ModelArts，进入 JupyterLab 页面：稍等30s左右，等待项目初始化完毕......由于在GPU下运行的更快一些，所以我们需要进行规格切换，并选择 [限时免费]GPU: 1*V100|CPU: 8核 64GB ，点击切换规格。稍等一会就切换完成，如下所示：切换AI框架：PyTorch-1.42.安装和导入依赖包3.设定算法参数SkyAR算法提供了以下五个参数来调整换天的效果：skybox_center_crop: 天空体中心偏移auto_light_matching: 是否自动亮度匹配relighting_factor: 补光recoloring_factor: 重新着色halo_effect: 是否开启光环效应且提供了 datadir 和 skybox 两个参数来指定待处理的原视频和要替换的天空图片，通过路径进行指定即可，如下所示：4.预览一下原视频5.预览一下要替换的天空图片6.定义SkyFilter类类中实现模型结构定义、模型加载、处理视频等函数7.开始处理视频替换后输出的视频为out.avi，前后对比的视频为compare.avi8.对比原视频和处理后的视频9.生成你自己的换天视频三个步骤实现自定义视频的换天效果：（1）在自己本地电脑上准备好一个待处理的mp4视频文件和一张天空图片；（2）参考此文档，将视频文件和图片文件分别上传到ModelArts JupyterLab的SkyAR/test_videos目录和SkyAR/skybox目录下；（3）修改步骤3 “设定算法参数” 中datadir 和 skybox 两个参数的路径为你刚上传的视频和图片路径；（4）重新运行步骤3~8。最后效果是这样也可以是这样：超级大月亮很有感觉有木有总结通过本次实践，我基本了解了解图像分割的基本应用；了解运动估计的基本应用；了解图像混合的基本应用。同样感受到了AI的有趣，后面会体验更多的ai案例。