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

  2缓冲区对象

 3组件通信方式

tunnel模式

IL Client通过OMX_AllocateBuffer() 在组件A的输出端口上创建缓冲区对象，这个缓冲区对象直接返回给 IL Client。
IL Client再将这个缓冲区对象，通过 OMX_UseBuffer()指定给组件B的输入端口使用这个缓冲区对象。
IL Client调用 OMX Core的 OMX_SetupTunnel(hCompA, nOutPortIdx, hCompB, nInPortIdx) 函数来将两个组件的输入输出端口建立隧道通信方式。注：这个函数内部实现会调用两个组件的内部函数ComponentTunnelRequest()来传递组件本身的信息。
Push数据方式：组件A数据准备完毕后，直接调用组件B上的 OMX_EmptyThisBuffer()方法让组件B取数据，组件B获取完数据后，将OMX_EmptyBufferDone()通知直接回调给组件A，通知组件A这个缓冲区已经清空，可以继续使用了。
Pull数据方式：组件B需要数据的时候，直接调用组件A上的 OMX_FillThisBuffer()方法让组件A填充数据，组件A填充完成后，将OMX_FillBufferDone()通知直接回调给组件B，通知组件B这个缓冲区上数据可以使用了。
与 Non-tunnel方式主要的差异就是：建立隧道后，组件之间的数据通信不需要IL Client参与了，两个组件内部直接进行。 通常支持Tunnel通信方式的组件都有内部线程，方便数据同步处理

non-tunnel模式

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

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

ref：

openmax用法-CSDN博客

il手册官网：https://www.khronos.org/files/openmax_il_spec_1_0.pdf

中文翻译：GitHub - xfdingustc/OpenMAX: 本文对OpenMAX IL协议的1.0版本进行的中文的翻译，同时也有英文版的对照