openmax用法

已于 2023-04-05 14:29:31 修改
阅读量2.8k 收藏 20
点赞数 6
分类专栏： 音视频 文章标签： openmax
于 2022-05-17 22:29:27 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wangbuji/article/details/124830923
版权

     

一  omx概述

 OpenMax是一个多媒体应用程序的框架标准。它自上而下分为三层，Application Layer, Integration Layer和Development Layer。应用层规定了应用程序和多媒体中间层的标准接口，使应用程序的移植性更好。集成层定义了多媒体组件的接口，使得多媒体框架能以一种统一的方式访问多媒体Codec和组件，以便在嵌入式流媒体框架中快速集成加速编解码器。开发层为Codec厂商和硬件厂商提供了一套API，使开发更加便捷。

                                                          图 OpenMax的分层结构

omx由组件构成：

1. 组件是独立的一个处理模块，可以有内部独立的线程（但并不一定）处理数据。 通常组件类型有：splitter组件、hot组件、sink组件、clock组件等。

2. 组件之间通过端口进行数据通信，每个组件至少要有一个端口，根据数据方向区分：有输入端口 和 输出端口 两种方向。任意一个端口只能是其中一种方向。

     OMXMaster 负责OMX中编解码器插件管理，软件解码和硬件解码都使用OMX标准，挂载plugins的方式来进行管理。

     软解通过 addPlugin(new SoftOMXPlugin)把这些编解码器的名字都放在PluginByComponentName。

     硬件编解码是通过 addVendorPlugin(); 加载 libstagefrighthw.so.各个芯片平台可以遵循openmax 标准,生成libstagefrighthw.so的库来提供android应用。

android定义软编解码    /frameworks/av/media/libstagefright/omx/OMXMaster.cpp

  1. kComponents[] = {  
  2.     { "OMX.google.aac.decoder", "aacdec", "audio_decoder.aac" },  
  3.     { "OMX.google.aac.encoder", "aacenc", "audio_encoder.aac" },  
  4.     { "OMX.google.amrnb.decoder", "amrdec", "audio_decoder.amrnb" },  
  5.     { "OMX.google.amrnb.encoder", "amrnbenc", "audio_encoder.amrnb" },  
  6.     { "OMX.google.amrwb.decoder", "amrdec", "audio_decoder.amrwb" },  
  7.     { "OMX.google.amrwb.encoder", "amrwbenc", "audio_encoder.amrwb" },  
  8.     { "OMX.google.h264.decoder", "h264dec", "video_decoder.avc" },  
  9.     { "OMX.google.h264.encoder", "h264enc", "video_encoder.avc" },  
  10.     { "OMX.google.g711.alaw.decoder", "g711dec", "audio_decoder.g711alaw" },  
  11.     { "OMX.google.g711.mlaw.decoder", "g711dec", "audio_decoder.g711mlaw" },  
  12.     { "OMX.google.h263.decoder", "mpeg4dec", "video_decoder.h263" },  
  13.     { "OMX.google.h263.encoder", "mpeg4enc", "video_encoder.h263" },  
  14.     { "OMX.google.mpeg4.decoder", "mpeg4dec", "video_decoder.mpeg4" },  
  15.     { "OMX.google.mpeg4.encoder", "mpeg4enc", "video_encoder.mpeg4" },  
  16.     { "OMX.google.mp3.decoder", "mp3dec", "audio_decoder.mp3" },  
  17.     { "OMX.google.vorbis.decoder", "vorbisdec", "audio_decoder.vorbis" },  
  18.     { "OMX.google.vpx.decoder", "vpxdec", "video_decoder.vpx" },  
  19.     { "OMX.google.raw.decoder", "rawdec", "audio_decoder.raw" },  
  20.     { "OMX.google.flac.encoder", "flacenc", "audio_encoder.flac" },  
  21. };  

高通定义         /QNX/qnx_ap/AMSS/multimedia/video/source/common/applications/qplayer/inc/OmxPlayer.h

// OMX component name

#define QCOM_DEMUXER_COMPONENT_NAME              "OMX.qcom.file.demuxer"

#define QCOM_IVRENDERER_COMPONENT_NAME           "OMX.qcom.video.mmirenderer"

#define QCOM_CLOCK_COMPONENT_NAME                "OMX.qcom.mmiclock"

#define QCOM_VIDEODECODER_COMPONENT_NAME         "OMX.qcom.video.decoder"

#define QCOM_VIDEODECODER_COMPONENT_NAME_AVC     "OMX.qcom.video.decoder.avc"

#define QCOM_VIDEODECODER_COMPONENT_NAME_MPEG4   "OMX.qcom.video.decoder.mpeg4"

#define QCOM_VIDEODECODER_COMPONENT_NAME_H263    "OMX.qcom.video.decoder.h263"

#define QCOM_VIDEODECODER_COMPONENT_NAME_WMV     "OMX.qcom.video.decoder.wmv"

#define QCOM_VIDEODECODER_COMPONENT_NAME_MPEG2   "OMX.qcom.video.decoder.mpeg2"

#define QCOM_VIDEODECODER_COMPONENT_NAME_DIVX    "OMX.qcom.video.decoder.divx"

#define QCOM_VIDEODECODER_COMPONENT_NAME_DIVX311 "OMX.qcom.video.decoder.divx311"

#define QCOM_VIDEODECODER_COMPONENT_NAME_VP8     "OMX.qcom.video.decoder.vp8"

#define QCOM_VIDEODECODER_COMPONENT_NAME_SPARK   "OMX.qcom.video.decoder.spark"

#define QCOM_VIDEODECODER_COMPONENT_NAME_VC1     "OMX.qcom.video.decoder.vc1"

#define QCOM_VIDEODECODER_COMPONENT_NAME_HEVC    "OMX.qcom.video.decoder.hevc"

#define QCOM_VIDEODECODER_COMPONENT_NAME_VP9     "OMX.qcom.video.decoder.vp9"

#define QCOM_AUDIODECODER_COMPONENT_NAME         "OMX.qcom.audiodecoder"

#define QCOM_AUDIORENDERER_COMPONENT_NAME        "OMX.qcom.audiorenderer"

#define QCOM_RTPSOURCE_COMPONENT_NAME            "OMX.qcom.rtpSource"

#define QCOM_MPEG2TSDEMUXER_COMPONENT_NAME       "OMX.qcom.demuxer.mpeg2ts"

#define QCOM_VPP_COMPONENT_NAME                  "OMX.qcom.vpp"

3. 端口根据通信的数据类型可以分为四种：Video_Port; Audio_Port; Image_Port; Other_Port; 其中除了音视频和图像数据，其他数据都是通过Other_Port来传递，比较典型的就是Clock全局时钟。

4. 每个组件都有自己独立的运行状态机，总共有6个状态。

   OMX_StateInvalid : 组件运行中产生无法恢复的错误，不能再继续进行了，只能卸载组件

   OMX_StateLoaded : 组件已经加载到系统中，但是还没有进行初始化

   OMX_StateWaitForResources：组件正在等待资源，当资源到位后会切换成Idle状态

   OMX_StateIdle：组件初始化完成，一切准备就绪

   OMX_StateExecuting：组件正常运行，进行相关数据处理

   OMX_StatePause：组件暂停运行

5. 组件支持两种不同的Profile:

1）Base Profile: 仅支持 non-tunnel方式的数据通信，也可能支持Proprietary模式

2）Interop Profile: 必须支持tunnel 和 non-tunnel两种数据通信方式，也可能支持Proprietary模式

       OMX集成层由Client、Core、Component和Port组成，Client通过Core得到对应Component的Handle，而后通过命令直接和Component进行交互。每个Component至少有一个Port进行数据交互，如Decoder有一个输入Port接收码流，一个输出Port输出YUV序列。Component内部可能通过消息处理机制完成Client要求的任务。

                                              图 StageFright的OMX结构

调用过程

二  omx用法

文件描述
OMX_Types.h数据类型，里面定义了组件类型、输入输出等
OMX_Core.hIL层的核心API，有命令枚举、状态枚举、组件注册/初始化等等
OMX_Component.h组件相关的API，有端口类型与定义、组件回调函数成员定义等
OMX_Audio.h与音频相关的常量和结构体定义
OMX_IVCommon.h图像与视频通用的一些常量和结构体定义
OMX_Video.h视频相关的常量和结构体定义
OMX_VideoExt.h视频相关的常量和数据结构，是对OMX_Video.h的补充扩展
OMX_Image.h图像相关的常量和结构体定义
OMX_Other.h其它部分的结构体定义 (包含A/V同步)
OMX_Index.hOpenMAX定义的数据结构索引
OMX_IndexExt.hOpenMax 定义的数据结构扩展索引
OMX_ContentPipe.h内容的管道定义

  • OMX_BUFFERSUPPLIERTYPE：用于组件内部端口数据流标识。

  • OMX_COMMANDTYPE：命令相关的枚举，用于Client对组件的命令控制。

  • OMX_STATETYPE：组件状态相关的枚举，用于组件状态标识。

  • OMX_ERRORTYPE：错误相关的枚举，类似于C库的错误状态集，用于标识组件内部或者Client的出错状态。

  • OMX_EVENTTYPE：事件相关的枚举，用于组件内部向Client发送事件通知。

1组件库函数：

       

  1. IL层支持的库函数主要有两组：一组是针对所有组件库的Core函数； 另外一组是针对单个组件的函数。
  2. 大部分的函数操作都是同步调用，并且严格限制函数的执行时间（例如：OMX_SetConfig 限制在5ms内；OMX_UseBuffer 限制在20ms内）。
  3. OMX_FillThisBuffer() 和 OMX_EmptyThisBuffer()是异步调用，组件在实际执行完成后通过 EmptyBufferDone() 和 FillBufferDone() 两个回调通知执行完成。
  4. OMX_SendCommand() 函数也是异步调用，支持5种命令调用

        1）OMX_CommandStateSet： 切换状态机

        2）OMX_CommandFlush： 刷新缓冲区

        3）OMX_CommandPortDisable：禁用某个端口

        4）OMX_CommandPortEnable 启用某个端口

        5）OMX_CommandMarkBuffer：标记缓冲区对象（如：仅解码）

        这些命令执行完成后通过 EventHandler() 回调来通知完成

通过EmptyThisBuffer传递未解码的buffer给component，component收到该命令后会去读取input port buffer中的数据，将其组装为帧之后进行解码，buffer处理完成后会通过EmptyBufferDone通知上层输入使用完成，上层收到命令可以继续送输入帧流程。输出buffer方面，通过FillThisBuffer传递填充输出的空buffer给component，component在解码之后通过FillBufferDone通知上层输出填写完成，上层可以继续送待填充的输出帧流程。
 

 

  2缓冲区对象

 3组件通信方式

tunnel模式

  1. IL Client通过OMX_AllocateBuffer() 在组件A的输出端口上创建缓冲区对象，这个缓冲区对象直接返回给 IL Client。
  2. IL Client再将这个缓冲区对象，通过 OMX_UseBuffer()指定给组件B的输入端口使用这个缓冲区对象。
  3. IL Client调用 OMX Core的 OMX_SetupTunnel(hCompA, nOutPortIdx, hCompB, nInPortIdx) 函数来将两个组件的输入输出端口建立隧道通信方式。注：这个函数内部实现会调用两个组件的内部函数ComponentTunnelRequest()来传递组件本身的信息。
  4. Push数据方式：组件A数据准备完毕后，直接调用组件B上的 OMX_EmptyThisBuffer()方法让组件B取数据，组件B获取完数据后，将OMX_EmptyBufferDone()通知直接回调给组件A，通知组件A这个缓冲区已经清空，可以继续使用了。
  5. Pull数据方式：组件B需要数据的时候，直接调用组件A上的 OMX_FillThisBuffer()方法让组件A填充数据，组件A填充完成后，将OMX_FillBufferDone()通知直接回调给组件B，通知组件B这个缓冲区上数据可以使用了。

与 Non-tunnel方式主要的差异就是：建立隧道后，组件之间的数据通信不需要IL Client参与了，两个组件内部直接进行。 通常支持Tunnel通信方式的组件都有内部线程，方便数据同步处理

non-tunnel模式

  1. IL Client通过OMX_AllocateBuffer() 在组件A的输出端口上创建缓冲区对象，这个缓冲区对象直接返回给 IL Client。
  2. IL Client再将这个缓冲区对象，通过 OMX_UseBuffer()指定给组件B的输入端口使用这个缓冲区对象。
  3. 在循环的数据处理过程中，IL Client调用OMX_FillThisBuffer() 命令组件A将处理好要输出的数据填入这个缓冲区中，注意：这个调用是异步的，这个调用返回后，缓冲区数据可能还没有填充好。
  4. 组件A内部先进行数据处理，处理完成后将输出数据填入缓冲区，然后通过 OMX_FillBufferDone()回调函数通知IL Client数据已经准备好。
  5. IL Client接收到回调后，调用OMX_EmptyThisBuffer()命令组件B来取缓冲区中的数据，注意：这个调用也是异步的，这个调用返回后，缓冲区数据可能还没有取走。
  6. 组件B内部根据优先处理顺序，将缓冲区中的数据全部取走后，然后通过OMX_EmptyBufferDone()回调函数通知IL Client缓冲区已经清空，可以继续使用。 如此反复来传递缓冲区对象，使得两个组件通过一个缓冲区来进行通信。
  7. 最后在组件A上释放这个缓冲区对象

proprietary模式

  1. 组件之间有类似DMA之类的直接通信机制，不需要外部提供缓冲区和控制缓冲区对象传递。
  2. IL Client 只需要调用 OMX Core的 OMX_SetupTunnel(hCompA, nOutPortIdx, hCompB, nInPortIdx) 函数来将两个组件的输入输出端口建立关联即可。
  3. 通常这种情况下的组件都是由硬件来实现，直接通过硬件或者系统内部的共享缓冲区来访问数据
  4. 通信时也不再有 OMX_FillBufferDone() 和 OMX_EmptyBufferDone() 的回调

步基
关注
  • 6
    点赞
  • 踩
  • 20
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
node-raspberrypi:Raspberry Pi的各种NodeJS绑定
05-10
节点树莓派 RaspberryPi的各种NodeJS绑定 正在安装 该项目已发布在！ 这仅适用于RaspberryPi并安装了VideoCore固件！ npm install raspberrypi 当前绑定 OpenMAX的 播放h264视频 显示JPEG图像 原料药 图片 displayImage（fileName，displayDuration） 在屏幕上同步显示图像。 仅支持非渐进式jpeg！ 用法示例： var returncode = raspberrypi . displayImage ( __dirname + "/data/raspberry.jpg" , 10 ) ; console . log ( "Done displaying image! Return Code: " + returncode ) ; displayImage（fileName，displ
OpenMax概述及与Gstreamer的对接
最新发布
David的博客
03-13 933
openmax概述，对接gstreamer
ofxOMXPlayer:用于Raspberry Pi 0-3上的openFrameworks的OpenMax加速视频播放器。 不适用于RPI4
04-30
要求： GPU分割设置为128（对于较大的视频，可能需要更高的分辨率） openFrameworks 10，Raspberry Pi 0-3 运行install_depends.sh以获取必要的libav依赖项 当前已知的主要问题： 具有音频和音轨（甚至无声）的视频效果最好，并允许更准确的循环/帧跟踪 描述： 这是Raspberry Pi的openFrameworks视频播放器插件。 视频播放器是硬件加速的，可以为openFrameworks提供纹理以用于着色器等。 用法： 除非您正在做出贡献或正在寻找前沿，否则请使用“ 。 版本包含经过测试的版本，适用于特定版本的openFrameworks。 克隆到openFrameworks /插件 有2种播放模式：直接播放（又名非纹理播放）或纹理播放。 直接的： 直接渲染到屏幕，无纹理访问或像素。 这与您在omxplayer中看到的
Android底层开发技术实战详解--内核、移植和驱动.(电子工业.王振丽).part2
06-01
书名：《Android底层开发技术实战详解——内核、移植和驱动》(电子工业出版社.王振丽)。本书从底层原理开始讲起，结合真实的案例向读者详细介绍了android内核、移植和驱动开发的整个流程。全书分为19章，依次讲解驱动移植的必要性，何为hal层深入分析，goldfish、msm、map内核和驱动解析，显示系统、输入系统、振动器系统、音频系统、视频输出系统的驱动，openmax多媒体、多媒体插件框架，传感器、照相机、wi-fi、蓝牙、gps和电话系统等。在每一章中，重点介绍了与Android驱动开发相关的底层知识，并对Android源码进行了剖析。 本书适合Android研发人员及Android爱好者学习，也可以作为相关培训学校和大专院校相关专业的教学用书。 全书压缩打包成3部分，这是第2部分。 目录： 第1章　Android底层开发基础 1 1.1 什么是驱动 1 1.1.1 驱动程序的魅力 1 1.1.2 电脑中的驱动 2 1.1.3 手机中的驱动程序 2 1.2 开源还是不开源的问题 3 1.2.1 雾里看花的开源 3 1.2.2 从为什么选择java谈为什么不开源驱动程序 3 1.2.3 对驱动开发者来说是一把双刃剑 4 1.3 Android和Linux 4 1.3.1 Linux简介 5 1.3.2 Android和Linux的关系 5 1.4 简析Linux内核 8 1.4.1 内核的体系结构 8 1.4.2 和Android密切相关的Linux内核知识 10 1.5 分析Linux内核源代码很有必要 14 1.5.1 源代码目录结构 14 1.5.2 浏览源代码的工具 16 1.5.3 为什么用汇编语言编写内核代码 17 1.5.4 Linux内核的显著特性 18 1.5.5 学习Linux内核的方法 26 第2章　分析Android源代码 31 2.1 搭建Linux开发环境和工具 31 2.1.1 搭建Linux开发环境 31 2.1.2 设置环境变量 32 2.1.3 安装编译工具 32 2.2 获取Android源代码 33 2.3 分析并编译Android源代码 35 2.3.1 Android源代码的结构 35 2.3.2 编译Android源代码 40 2.3.3 运行Android源代码 42 2.3.4 实践演练——演示编译Android程序的两种方法 43 2.4 编译Android kernel 47 2.4.1 获取goldfish内核代码 47 2.4.2 获取msm内核代码 50 2.4.3 获取omap内核代码 50 2.4.4 编译Android的Linux内核 50 2.5 运行模拟器 52 2.5.1 Linux环境下运行模拟器的方法 53 2.5.2 模拟器辅助工具——adb 54 第3章　驱动需要移植 57 3.1 驱动开发需要做的工作 57 3.2 Android移植 59 3.2.1 移植的任务 60 3.2.2 移植的内容 60 3.2.3 驱动开发的任务 61 3.3 Android对Linux的改造 61 3.3.1 Android对Linux内核文件的改动 62 3.3.2 为Android构建 Linux的操作系统 63 3.4 内核空间和用户空间接口是一个媒介 64 3.4.1 内核空间和用户空间的相互作用 64 3.4.2 系统和硬件之间的交互 64 3.4.3 使用relay实现内核到用户空间的数据传输 66 3.5 三类驱动程序 70 3.5.1 字符设备驱动程序 70 3.5.2 块设备驱动程序 79 3.5.3 网络设备驱动程序 82 第4章　hal层深入分析 84 4.1 认识hal层 84 4.1.1 hal层的发展 84 4.1.2 过去和现在的区别 86 4.2 分析hal层源代码 86 4.2.1 分析hal moudle 86 4.2.2 分析mokoid工程 89 4.3 总结hal层的使用方法 98 4.4 传感器在hal层的表现 101 4.4.1 hal层的sensor代码 102 4.4.2 总结sensor编程的流程 104 4.4.3 分析sensor源代码看Android api 与硬件平台的衔接 104 4.5 移植总结 116 4.5.1 移植各个Android部件的方式 116 4.5.2 移植技巧之一——不得不说的辅助工作 117 第5章　goldfish下的驱动解析 125 5.1 staging驱动 125 5.1.1 staging驱动概述 125 5.1.2 binder驱动程序 126 5.1.3 logger驱动程序 135 5.1.4 lowmemorykiller组件 136 5.1.5 timed output驱动程序 137 5.1.6 timed gpio驱动程序 139 5.1.7 ram console驱动程序 139 5.2 wakelock和early_suspend 140 5.2.1 wakelock和early_suspend的原理 140 5.2.2 Android休眠 141 5.2.3 Android唤醒 144 5.3 ashmem驱动程序 145 5.4 pmem驱动程序 148 5.5 alarm驱动程序 149 5.5.1 alarm简析 149 5.5.2 alarm驱动程序的实现 150 5.6 usb gadget驱动程序151 5.7 Android paranoid驱动程序153 5.8 goldfish设备驱动154 5.8.1 framebuffer驱动155 5.8.2 键盘驱动159 5.8.3 实时时钟驱动程序160 5.8.4 tty终端驱动程序161 5.8.5 nandflash驱动程序162 5.8.6 mmc驱动程序162 5.8.7 电池驱动程序162 第6章　msm内核和驱动解析164 6.1 msm基础164 6.1.1 常见msm处理器产品164 6.1.2 snapdragon内核介绍165 6.2 移植msm内核简介166 6.3 移植msm168 6.3.1 makefile文件168 6.3.2 驱动和组件170 6.3.3 设备驱动172 6.3.4 高通特有的组件174 第7章　omap内核和驱动解析177 7.1 omap基础177 7.1.1 omap简析177 7.1.2 常见omap处理器产品177 7.1.3 开发平台178 7.2 omap内核178 7.3 移植omap体系结构180 7.3.1 移植omap平台180 7.3.2 移植omap处理器183 7.4 移植Android专用驱动和组件188 7.5 omap的设备驱动190 第8章　显示系统驱动应用195 8.1 显示系统介绍195 8.1.1 Android的版本195 8.1.2 不同版本的显示系统195 8.2 移植和调试前的准备196 8.2.1 framebuffer驱动程序196 8.2.2 硬件抽象层198 8.3 实现显示系统的驱动程序210 8.3.1 goldfish中的framebuffer驱动程序210 8.3.2 使用gralloc模块的驱动程序214 8.4 msm高通处理器中的显示驱动实现224 8.4.1 msm中的framebuffer驱动程序225 8.4.2 msm中的gralloc驱动程序227 8.5 omap处理器中的显示驱动实现235 第9章　输入系统驱动应用239 9.1 输入系统介绍239 9.1.1 Android输入系统结构元素介绍239 9.1.2 移植Android输入系统时的工作240 9.2 input（输入）驱动241 9.3 模拟器的输入驱动256 9.4 msm高通处理器中的输入驱动实现257 9.4.1 触摸屏驱动257 9.4.2 按键和轨迹球驱动264 9.5 omap处理器平台中的输入驱动实现266 9.5.1 触摸屏驱动267 9.5.2 键盘驱动267 第10章　振动器系统驱动269 10.1 振动器系统结构269 10.1.1 硬件抽象层271 10.1.2 jni框架部分272 10.2 开始移植273 10.2.1 移植振动器驱动程序273 10.2.2 实现硬件抽象层274 10.3 在msm平台实现振动器驱动275 第11章　音频系统驱动279 11.1 音频系统结构279 11.2 分析音频系统的层次280 11.2.1 层次说明280 11.2.2 media库中的audio框架281 11.2.3 本地代码284 11.2.4 jni代码288 11.2.5 java代码289 11.3 移植audio系统的必备技术289 11.3.1 移植audio系统所要做的工作289 11.3.2 分析硬件抽象层290 11.3.3 分析audioflinger中的audio硬件抽象层的实现291 11.4 真正实现audio硬件抽象层298 11.5 msm平台实现audio驱动系统298 11.5.1 实现audio驱动程序298 11.5.2 实现硬件抽象层299 11.6 oss平台实现audio驱动系统304 11.6.1 oss驱动程序介绍304 11.6.2 mixer305 11.7 alsa平台实现audio系统312 11.7.1 注册音频设备和音频驱动312 11.7.2 在Android中使用alsa声卡313 11.7.3 在omap平台移植Android的alsa声卡驱动322 第12章　视频输出系统驱动326 12.1 视频输出系统结构326 12.2 需要移植的部分328 12.3 分析硬件抽象层328 12.3.1 overlay系统硬件抽象层的接口328 12.3.2 实现overlay系统的硬件抽象层331 12.3.3 实现接口332 12.4 实现overlay硬件抽象层333 12.5 在omap平台实现overlay系统335 12.5.1 实现输出视频驱动程序335 12.5.2 实现overlay硬件抽象层337 12.6 系统层调用overlay hal的架构342 12.6.1 调用overlay hal的架构的流程342 12.6.2 s3c6410 Android overlay的测试代码346 第13章　openmax多媒体框架349 13.1 openmax基本层次结构349 13.2 分析openmax框架构成350 13.2.1 openmax总体层次结构350 13.2.2 openmax il层的结构351 13.2.3 Android中的openmax354 13.3 实现openmax il层接口354 13.3.1 openmax il层的接口354 13.3.2 在openmax il层中需要做什么361 13.3.3 研究Android中的openmax适配层361 13.4 在omap平台实现openmax il363 13.4.1 实现文件364 13.4.2 分析ti openmax il的核心365 13.4.3 实现ti openmax il组件实例368 第14章　多媒体插件框架373 14.1 Android多媒体插件373 14.2 需要移植的内容374 14.3 opencore引擎375 14.3.1 opencore层次结构375 14.3.2 opencore代码结构376 14.3.3 opencore编译结构377 14.3.4 opencore oscl381 14.3.5 实现opencore中的openmax部分383 14.3.6 opencore的扩展398 14.4 stagefright引擎404 14.4.1 stagefright代码结构404 14.4.2 stagefright实现openmax接口405 14.4.3 video buffer传输流程409 第15章　传感器系统415 15.1 传感器系统的结构415 15.2 需要移植的内容417 15.2.1 移植驱动程序417 15.2.2 移植硬件抽象层418 15.2.3 实现上层部分419 15.3 在模拟器中实现传感器424 第16章　照相机系统430 16.1 camera系统的结构430 16.2 需要移植的内容433 16.3 移植和调试433 16.3.1 v4l2驱动程序433 16.3.2 硬件抽象层441 16.4 实现camera系统的硬件抽象层446 16.4.1 java程序部分446 16.4.2 camera的java本地调用部分447 16.4.3 camera的本地库libui.so448 16.4.4 camera服务libcameraservice.so449 16.5 msm平台实现camera系统454 16.6 omap平台实现camera系统457 第17章　wi-fi系统、蓝牙系统和gps系统459 17.1 wi-fi系统459 17.1.1 wi-fi系统的结构459 17.1.2 需要移植的内容461 17.1.3 移植和调试461 17.1.4 omap平台实现wi-fi469 17.1.5 配置wi-fi的流程471 17.1.6 具体演练——在Android下实现ethernet473 17.2 蓝牙系统475 17.2.1 蓝牙系统的结构475 17.2.2 需要移植的内容477 17.2.3 具体移植478 17.2.4 msm平台的蓝牙驱动480 17.3 定位系统482 17.3.1 定位系统的结构483 17.3.2 需要移植的内容484 17.3.3 移植和调试484 第18章　电话系统498 18.1 电话系统基础498 18.1.1 电话系统简介498 18.1.2 电话系统结构500 18.2 需要移植的内容501 18.3 移植和调试502 18.3.1 驱动程序502 18.3.2 ril接口504 18.4 电话系统实现流程分析507 18.4.1 初始启动流程507 18.4.2 request流程509 18.4.3 response流程512 第19章　其他系统514 19.1 alarm警报器系统514 19.1.1 alarm系统的结构514 19.1.2 需要移植的内容515 19.1.3 移植和调试516 19.1.4 模拟器环境的具体实现518 19.1.5 msm平台实现alarm518 19.2 lights光系统519 19.2.1 lights光系统的结构520 19.2.2 需要移植的内容521 19.2.3 移植和调试521 19.2.4 msm平台实现光系统523 19.3 battery电池系统524 19.3.1 battery系统的结构524 19.3.2 需要移植的内容526 19.3.3 移植和调试526 19.3.4 在模拟器中实现电池系统529
Open-Set-Recognition:开放集识别
03-18
公开集识别项目 使用PyTorch进行的开放集识别项目。 如有任何问题，请发送电子邮件 注意：由于我的实验性实现（特别是我的方法），需要重新构造。 要求 对于不同的算法和不同的数据集，要求会有所不同。通常，基本和必不可少的要求是： # pytorch 1.4+, torchvision 0.7.0 + pip3 install torch torchvision # sklearn pip3 install -U scikit-learn # numpy pip3 install numpy # scikit-learn-0.23.2 pip3 install -U sklearn 对于OpenMax： pip3 install libmr 对于绘制MNIST： pip3 install imageio pip3 install tqdm 配套 数据集 CIFAR-100（完成）
openmax实现
09-11
openmax实现 包装了，ffmpeg，libogg,libmad,写了读取，解复用，解码，slink等组件。
《Towards Open Set Deep Networks》：一文搞懂开集识别算法 OpenMax：
weixin_54353432的博客
05-05 3796
《Towards Open Set Deep Networks》：一文搞懂开集识别算法 OpenMax
编解码抽象层OpenMax简介
runafterhit的博客
09-05 3343
一、OpenMax相关概念 OpenMax存在背景—为多媒体硬解方案提供标准提升移植效率 随着消费者对视频、音频、语音和 3D 等应用程序在智能手机、音频和视频媒体播放器和游戏机等各种平台上的改进功能的需求不断增长，多媒体硬件平台出现了各种解决方案加速多媒体应用程序。（如具：有特定多媒体扩展功能的通用处理器、低级硬件加速器，包括 DSP 在内的多处理器架构、专用硬件视频解码器） 所有这些架构变体的主要挑战之一是开发高效的代码。尽管通常会提供编译器，但很少能从高级编程语言中挖掘整个架构的全部潜力。结果是应用程
OpenMax标准介绍以及应用
tugouxp的专栏
04-11 1344
OpenMAX™是一个免版税的跨平台API标准，通过支持跨多个操作系统和芯片平台开发、集成和编程加速多媒体组件，提供了全面的流媒体编解码器和应用程序可移植性。OpenMAX API将与处理器一起发布，使库和编解码器的用户能够快速有效地充分利用新处理器的加速潜力——而不管底层硬件架构如何。 OpenMAX DL(开发层)api包含一组全面的音频、视频和图像功能，可以在新的cpu、硬件引擎和dsp上实现和优化，然后用于广泛的加速编解码器功能，如MPEG-4、H.264、MP3、AAC和JPEG。OpenMAX
OpenMax概述
eydwyz的专栏
08-27 3704
一、OpenMax简介 OpenMAX是一个多媒体应用程序的标准。由NVIDIA公司和Khronos™在2006年推出。 它是无授权费的、跨平台的C语言程序接口序列，这些接口对音频、视频、静态图片的常用操作进行封装。 它包括三层，分别是应用层（AI）、集成层（IL）和开发层（DL）。其中IL层已经成为了事实上的多媒体框架标准。嵌入式处理器或者多媒体编解码模块的硬件生产者，通常提供标准的OpenMax IL层的软件接口，这样软件的开发者就可以基于这个层次的标准化接口进行多媒体程序...
适用于 Windows PC 的 硬件加速树莓派客户端_C语言_代码_下载
07-04
适用于 Windows PC 的硬件加速树莓派客户端。这更像是一个概念验证，表明 OpenMAX 可以用作 RDP 查看器而不是成品。没有身份验证，使用风险自负。 它使用 NVIDIA 显卡对 H.264 视频进行编码，并使用 OpenMAX 来显示视频。它可以在 RPI 上实现 1080P 60FPS RDP，而在两台显示器上的延迟相对较低，约为 200 毫秒。当服务器上无法访问 GPU 时，它会以较低的 FPS 回退到 CPU 编码，大约 10FPS，具体取决于 CPU。它使用 DXGI 在 Windows 8 中加速桌面捕获它可以在虚拟机中工作，以便成为真正的瘦客户端。 更多详情、使用方法，请下载后阅读README.md文件
Android底层开发技术实战详解--内核、移植和驱动.(电子工业.王振丽).part3
06-01
书名：《Android底层开发技术实战详解——内核、移植和驱动》(电子工业出版社.王振丽)。本书从底层原理开始讲起，结合真实的案例向读者详细介绍了android内核、移植和驱动开发的整个流程。全书分为19章，依次讲解驱动移植的必要性，何为hal层深入分析，goldfish、msm、map内核和驱动解析，显示系统、输入系统、振动器系统、音频系统、视频输出系统的驱动，openmax多媒体、多媒体插件框架，传感器、照相机、wi-fi、蓝牙、gps和电话系统等。在每一章中，重点介绍了与Android驱动开发相关的底层知识，并对Android源码进行了剖析。 本书适合Android研发人员及Android爱好者学习，也可以作为相关培训学校和大专院校相关专业的教学用书。 全书压缩打包成3部分，这是第3部分。 目录： 第1章　Android底层开发基础 1 1.1 什么是驱动 1 1.1.1 驱动程序的魅力 1 1.1.2 电脑中的驱动 2 1.1.3 手机中的驱动程序 2 1.2 开源还是不开源的问题 3 1.2.1 雾里看花的开源 3 1.2.2 从为什么选择java谈为什么不开源驱动程序 3 1.2.3 对驱动开发者来说是一把双刃剑 4 1.3 Android和Linux 4 1.3.1 Linux简介 5 1.3.2 Android和Linux的关系 5 1.4 简析Linux内核 8 1.4.1 内核的体系结构 8 1.4.2 和Android密切相关的Linux内核知识 10 1.5 分析Linux内核源代码很有必要 14 1.5.1 源代码目录结构 14 1.5.2 浏览源代码的工具 16 1.5.3 为什么用汇编语言编写内核代码 17 1.5.4 Linux内核的显著特性 18 1.5.5 学习Linux内核的方法 26 第2章　分析Android源代码 31 2.1 搭建Linux开发环境和工具 31 2.1.1 搭建Linux开发环境 31 2.1.2 设置环境变量 32 2.1.3 安装编译工具 32 2.2 获取Android源代码 33 2.3 分析并编译Android源代码 35 2.3.1 Android源代码的结构 35 2.3.2 编译Android源代码 40 2.3.3 运行Android源代码 42 2.3.4 实践演练——演示编译Android程序的两种方法 43 2.4 编译Android kernel 47 2.4.1 获取goldfish内核代码 47 2.4.2 获取msm内核代码 50 2.4.3 获取omap内核代码 50 2.4.4 编译Android的Linux内核 50 2.5 运行模拟器 52 2.5.1 Linux环境下运行模拟器的方法 53 2.5.2 模拟器辅助工具——adb 54 第3章　驱动需要移植 57 3.1 驱动开发需要做的工作 57 3.2 Android移植 59 3.2.1 移植的任务 60 3.2.2 移植的内容 60 3.2.3 驱动开发的任务 61 3.3 Android对Linux的改造 61 3.3.1 Android对Linux内核文件的改动 62 3.3.2 为Android构建 Linux的操作系统 63 3.4 内核空间和用户空间接口是一个媒介 64 3.4.1 内核空间和用户空间的相互作用 64 3.4.2 系统和硬件之间的交互 64 3.4.3 使用relay实现内核到用户空间的数据传输 66 3.5 三类驱动程序 70 3.5.1 字符设备驱动程序 70 3.5.2 块设备驱动程序 79 3.5.3 网络设备驱动程序 82 第4章　hal层深入分析 84 4.1 认识hal层 84 4.1.1 hal层的发展 84 4.1.2 过去和现在的区别 86 4.2 分析hal层源代码 86 4.2.1 分析hal moudle 86 4.2.2 分析mokoid工程 89 4.3 总结hal层的使用方法 98 4.4 传感器在hal层的表现 101 4.4.1 hal层的sensor代码 102 4.4.2 总结sensor编程的流程 104 4.4.3 分析sensor源代码看Android api 与硬件平台的衔接 104 4.5 移植总结 116 4.5.1 移植各个Android部件的方式 116 4.5.2 移植技巧之一——不得不说的辅助工作 117 第5章　goldfish下的驱动解析 125 5.1 staging驱动 125 5.1.1 staging驱动概述 125 5.1.2 binder驱动程序 126 5.1.3 logger驱动程序 135 5.1.4 lowmemorykiller组件 136 5.1.5 timed output驱动程序 137 5.1.6 timed gpio驱动程序 139 5.1.7 ram console驱动程序 139 5.2 wakelock和early_suspend 140 5.2.1 wakelock和early_suspend的原理 140 5.2.2 Android休眠 141 5.2.3 Android唤醒 144 5.3 ashmem驱动程序 145 5.4 pmem驱动程序 148 5.5 alarm驱动程序 149 5.5.1 alarm简析 149 5.5.2 alarm驱动程序的实现 150 5.6 usb gadget驱动程序151 5.7 Android paranoid驱动程序153 5.8 goldfish设备驱动154 5.8.1 framebuffer驱动155 5.8.2 键盘驱动159 5.8.3 实时时钟驱动程序160 5.8.4 tty终端驱动程序161 5.8.5 nandflash驱动程序162 5.8.6 mmc驱动程序162 5.8.7 电池驱动程序162 第6章　msm内核和驱动解析164 6.1 msm基础164 6.1.1 常见msm处理器产品164 6.1.2 snapdragon内核介绍165 6.2 移植msm内核简介166 6.3 移植msm168 6.3.1 makefile文件168 6.3.2 驱动和组件170 6.3.3 设备驱动172 6.3.4 高通特有的组件174 第7章　omap内核和驱动解析177 7.1 omap基础177 7.1.1 omap简析177 7.1.2 常见omap处理器产品177 7.1.3 开发平台178 7.2 omap内核178 7.3 移植omap体系结构180 7.3.1 移植omap平台180 7.3.2 移植omap处理器183 7.4 移植Android专用驱动和组件188 7.5 omap的设备驱动190 第8章　显示系统驱动应用195 8.1 显示系统介绍195 8.1.1 Android的版本195 8.1.2 不同版本的显示系统195 8.2 移植和调试前的准备196 8.2.1 framebuffer驱动程序196 8.2.2 硬件抽象层198 8.3 实现显示系统的驱动程序210 8.3.1 goldfish中的framebuffer驱动程序210 8.3.2 使用gralloc模块的驱动程序214 8.4 msm高通处理器中的显示驱动实现224 8.4.1 msm中的framebuffer驱动程序225 8.4.2 msm中的gralloc驱动程序227 8.5 omap处理器中的显示驱动实现235 第9章　输入系统驱动应用239 9.1 输入系统介绍239 9.1.1 Android输入系统结构元素介绍239 9.1.2 移植Android输入系统时的工作240 9.2 input（输入）驱动241 9.3 模拟器的输入驱动256 9.4 msm高通处理器中的输入驱动实现257 9.4.1 触摸屏驱动257 9.4.2 按键和轨迹球驱动264 9.5 omap处理器平台中的输入驱动实现266 9.5.1 触摸屏驱动267 9.5.2 键盘驱动267 第10章　振动器系统驱动269 10.1 振动器系统结构269 10.1.1 硬件抽象层271 10.1.2 jni框架部分272 10.2 开始移植273 10.2.1 移植振动器驱动程序273 10.2.2 实现硬件抽象层274 10.3 在msm平台实现振动器驱动275 第11章　音频系统驱动279 11.1 音频系统结构279 11.2 分析音频系统的层次280 11.2.1 层次说明280 11.2.2 media库中的audio框架281 11.2.3 本地代码284 11.2.4 jni代码288 11.2.5 java代码289 11.3 移植audio系统的必备技术289 11.3.1 移植audio系统所要做的工作289 11.3.2 分析硬件抽象层290 11.3.3 分析audioflinger中的audio硬件抽象层的实现291 11.4 真正实现audio硬件抽象层298 11.5 msm平台实现audio驱动系统298 11.5.1 实现audio驱动程序298 11.5.2 实现硬件抽象层299 11.6 oss平台实现audio驱动系统304 11.6.1 oss驱动程序介绍304 11.6.2 mixer305 11.7 alsa平台实现audio系统312 11.7.1 注册音频设备和音频驱动312 11.7.2 在Android中使用alsa声卡313 11.7.3 在omap平台移植Android的alsa声卡驱动322 第12章　视频输出系统驱动326 12.1 视频输出系统结构326 12.2 需要移植的部分328 12.3 分析硬件抽象层328 12.3.1 overlay系统硬件抽象层的接口328 12.3.2 实现overlay系统的硬件抽象层331 12.3.3 实现接口332 12.4 实现overlay硬件抽象层333 12.5 在omap平台实现overlay系统335 12.5.1 实现输出视频驱动程序335 12.5.2 实现overlay硬件抽象层337 12.6 系统层调用overlay hal的架构342 12.6.1 调用overlay hal的架构的流程342 12.6.2 s3c6410 Android overlay的测试代码346 第13章　openmax多媒体框架349 13.1 openmax基本层次结构349 13.2 分析openmax框架构成350 13.2.1 openmax总体层次结构350 13.2.2 openmax il层的结构351 13.2.3 Android中的openmax354 13.3 实现openmax il层接口354 13.3.1 openmax il层的接口354 13.3.2 在openmax il层中需要做什么361 13.3.3 研究Android中的openmax适配层361 13.4 在omap平台实现openmax il363 13.4.1 实现文件364 13.4.2 分析ti openmax il的核心365 13.4.3 实现ti openmax il组件实例368 第14章　多媒体插件框架373 14.1 Android多媒体插件373 14.2 需要移植的内容374 14.3 opencore引擎375 14.3.1 opencore层次结构375 14.3.2 opencore代码结构376 14.3.3 opencore编译结构377 14.3.4 opencore oscl381 14.3.5 实现opencore中的openmax部分383 14.3.6 opencore的扩展398 14.4 stagefright引擎404 14.4.1 stagefright代码结构404 14.4.2 stagefright实现openmax接口405 14.4.3 video buffer传输流程409 第15章　传感器系统415 15.1 传感器系统的结构415 15.2 需要移植的内容417 15.2.1 移植驱动程序417 15.2.2 移植硬件抽象层418 15.2.3 实现上层部分419 15.3 在模拟器中实现传感器424 第16章　照相机系统430 16.1 camera系统的结构430 16.2 需要移植的内容433 16.3 移植和调试433 16.3.1 v4l2驱动程序433 16.3.2 硬件抽象层441 16.4 实现camera系统的硬件抽象层446 16.4.1 java程序部分446 16.4.2 camera的java本地调用部分447 16.4.3 camera的本地库libui.so448 16.4.4 camera服务libcameraservice.so449 16.5 msm平台实现camera系统454 16.6 omap平台实现camera系统457 第17章　wi-fi系统、蓝牙系统和gps系统459 17.1 wi-fi系统459 17.1.1 wi-fi系统的结构459 17.1.2 需要移植的内容461 17.1.3 移植和调试461 17.1.4 omap平台实现wi-fi469 17.1.5 配置wi-fi的流程471 17.1.6 具体演练——在Android下实现ethernet473 17.2 蓝牙系统475 17.2.1 蓝牙系统的结构475 17.2.2 需要移植的内容477 17.2.3 具体移植478 17.2.4 msm平台的蓝牙驱动480 17.3 定位系统482 17.3.1 定位系统的结构483 17.3.2 需要移植的内容484 17.3.3 移植和调试484 第18章　电话系统498 18.1 电话系统基础498 18.1.1 电话系统简介498 18.1.2 电话系统结构500 18.2 需要移植的内容501 18.3 移植和调试502 18.3.1 驱动程序502 18.3.2 ril接口504 18.4 电话系统实现流程分析507 18.4.1 初始启动流程507 18.4.2 request流程509 18.4.3 response流程512 第19章　其他系统514 19.1 alarm警报器系统514 19.1.1 alarm系统的结构514 19.1.2 需要移植的内容515 19.1.3 移植和调试516 19.1.4 模拟器环境的具体实现518 19.1.5 msm平台实现alarm518 19.2 lights光系统519 19.2.1 lights光系统的结构520 19.2.2 需要移植的内容521 19.2.3 移植和调试521 19.2.4 msm平台实现光系统523 19.3 battery电池系统524 19.3.1 battery系统的结构524 19.3.2 需要移植的内容526 19.3.3 移植和调试526 19.3.4 在模拟器中实现电池系统529
android-framework-hal
01-09
7 Android的Audio系统 7.1 Audio系统的综述 Audio系统架构和代码路径 7.2 meida库中Audio相关接口 Audio系统的本地核心接口，类的层次结构 7.3 Audio系统和上层接口 Audio系统的JAVA层次的接口 7.4 Audio硬件抽象层 Audio系统的移植，Audio硬件抽象层的实现方法 ALSA Audio HAL实现 8 Android的Video 输入输出系统 8.1 Video输入输出系统的综述 视频输入输出系统架构和代码路径 8.2 Overlay系统 视频输出系统的结构 8.3 Overlay的硬件抽象层 视频输出系统的移植，抽象层实现 8.4 Camera系统与上层接口 Camera系统的层次结构 8.5 Camera的硬件抽象层 Camera系统的移植 Camera和Overlay的结合与数据传送 9 Android的多媒体系统 9.1 多媒体系统的结构 应用到底层的层次结构 9.2 media核心库的结构 多媒体本地代码的结构 9.3 多媒体部分的上层代码 照相机，媒体播放，媒体录制的框架结构 9.4 PackageVideo的架构 OpenMAX编译码插件的集成 9.5 stagefright的架构与实现（Éclair新增） 10 Android的电话系统 10.1 电话系统结构 Android电话系统的层次结构 10.2 电话系统组成部分 Android电话系统的本地和JAVA程序运行流程 10.3 电话系统移植层 为特定Modem移植的方法 11 Android的连接部分 11.1 WIFI无线局域网的部分 11.2 蓝牙部分 11.3 GPS部分 12 Android的传感器系统 12.1 Android传感器系统概述 12.2 Android传感器系统的层次结构 12.3 Android传感器系统的硬件抽象层和移植 重力加速度等传感器的移植 12.4 Android传感器系统的使用 1.HAL 技术详解 1.1 HAL 架構解析 1.2 Service与Manager的意义与用途 1.3 libhardware 与 HAL API 1.4 Stub & Module 的观念 1.5 专题讨论：定义并撰写第一个HAL Stub 2.HAL Development 2.1 HAL Stub Analysis and Design (OOAD) 2.2 HAL Stub Class 2.3 HAL Stub Interface 2.4 专题讨论：开发 LED 的 HAL 模组 3.Android API Design 3.1 Abstract Class and Interface in Android 3.2 The Reuse of Framework Design 3.3 OOAD of new APIs 3.4 Implementaion of new APIs 3.5 Singleton Pattern to Android APIs 3.6 Factory Method Pattern to Android APIs 4.Extend Android API 4.1 如何加入 API 至 Android Framework 4.2 如何编译并制作独立 JAR 档 4.3 上机实验：开发LedService API 与制作mokoid.jar 程式库 5.JNI & Runtime Library 5.1 什么是 JNI 5.2 如何撰写 JNI & Native Method 5.3 如何制作 Android Runtime Library 5.4 专题讨论：如何开发与制作Runtime Library 6.5 专题讨论：SensorManager与SensorService实例 7.SystemService 与 HAL 整合7.1 IPC、 Remote method call与Binder观念说明 7.2 AIDL 介绍与IInterface设计观念解析 7.3 Activity & ApplicationContext 7.4 ServiceManager 7.5 专题讨论：LedService设计与ILedService探讨 8.Manager API (Refinement-架构优化) 8.1 SensorManager与 SensorService实例探讨 8.2 Remote Object观念与IBinder介绍 8.3 如何以Proxy Object整合Android Service 8.4 Long operations 的解析与实作细节 8.5 RemoteException 的解析与实作细节 8.6 Handler 与 Message 的解析与实作细节 8.7 Error Handling 9.专题探讨 9.1 整合驱动程式至Android 框架 9.2 撰写Anroid应用程式以控制LED 9.3 标准的Android HAL 架构 9.4 HAL Stub OOAD & Implementation
gcm-cf：[CVPR 2021]已发布反事实零镜头和开放式视觉识别代码
03-03
50的OSR代码OSR：Softmax，OpenMax，CGDL的强基准（F1分数） OSR：实施我们的GCM-CF 有关技术细节，请参阅： 反事实零射击和开放式视觉识别 ， ，，，*平等贡献IEEE 2021年计算机视觉和模式识别会议（CVPR）用法请...
Android底层开发技术实战详解--内核、移植和驱动.(电子工业.王振丽).part1
06-01
4.3 总结hal层的使用方法 98 4.4 传感器在hal层的表现 101 4.4.1 hal层的sensor代码 102 4.4.2 总结sensor编程的流程 104 4.4.3 分析sensor源代码看Android api 与硬件平台的衔接 104 4.5 ...
rtp协议详解
热门推荐
wangbuji的博客
01-12 1万+
RTP的头部格式 版本号（V）：2比特，用来标志使用的RTP版本。 填充位（P）：1比特，如果该位置位，则该RTP包的尾部就包含附加的填充字节。 扩展位（X）：1比特，如果该位置位的话，RTP固定头部后面就跟有一个扩展头部。 CSRC计数器（CC）：4比特，含有固定头部后面跟着的CSRC的数目。 标记位（M）：1比特,该位的解释由配置文档（Profile）来承担....
x264详解
wangbuji的博客
12-11 9609
x264默认是基于帧的线程，比基于切片的吞吐量更好 帧线程添加帧等待时间是需要不同的帧上工作 x264最大线程数128，一般控制16个线程以内。 在基于片段线程的情况下，所有线程都在同一帧上工作。每个帧都被分割成片，每个片在一个核上编码，然后结果一起做出最终帧。 一 码率控制 X264提供三种码率控制的方式：bitrate, qp, crf。这三种方式是互斥的，使用时设置其中之一即可。 （1）bitrate x264会尝试把给定的位元率作为整体平均值来编码。这意味着最终编码...
直播常见问题原因汇总
wangbuji的博客
12-02 7800
目录 一 播放卡顿 二 首开慢 三 延时高 四 音画不同步 五 黑屏、花屏、闪屏 六 播放闪屏 七 播放杂音、噪音、回声 八 拖动不准 一 播放卡顿 卡顿的本质就是播放器渲染的帧率太低，每秒显示不足25帧（人眼视觉特性经验值），可能的原因如下： 1视频流显示时间戳PTS问题 播放器一般是严格根据码流中的音视频PTS来做音画同步的，如果码流中的PTS出现错误，肯定会影响播放画面的渲染时机。例如 pts 1 50 ...
tensorflow openmax
01-09
TensorFlow OpenMax是一个用于图像分类任务的开源工具，可以用于处理和分析深度学习模型的输出概率分布。 OpenMax是一种开源的概率校准框架，旨在提高深度学习模型的不确定性估计。概率校准是指通过调整分类器的概率输出，使其更符合实际概率分布。传统的深度学习模型往往对于属于不同类别的样本，输出的概率很接近1或者0，忽略了模型的不确定性。而OpenMax通过引入Open Set Recognition的概念，对未知样本进行特殊处理，提供更加准确的概率估计。 TensorFlow OpenMax基于TensorFlow框架，提供了一套接口和工具，可以方便地集成到现有的深度学习模型中。通过调用OpenMax接口，可以获取深度学习模型的概率输出，然后使用OpenMax工具对这些概率进行校准。校准的过程包括计算置信度分布和外部期望分布，并进一步计算OpenMax概率。 使用TensorFlow OpenMax可以提高深度学习模型在图像分类任务中的表现。通过校准概率输出，可以更准确地估计模型的不确定性，并能够对未知样本进行更好的处理。这对于一些对模型的鲁棒性要求较高的应用场景非常有用。 总而言之，TensorFlow OpenMax是一个用于图像分类任务的开源工具，可以用于处理和校准深度学习模型的概率输出。它能够提高模型的不确定性估计，并能够对未知样本进行更好的处理，提高模型的鲁棒性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

步基

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值