你这种是硬件间数据流转通信的一种应用吧。
本质是 数据传输-数据接收-数据处理-数据反馈 这样一个流程。
具体如何实现这样的数据流转，需要看双方提供的条件、通信链路等等。
你所谓的压缩接口应该就是一种 数据通道 和 使用的接口（经过软件封装的，比如表现为一种驱动程序提供的接口之类）
我想这就是你所想要的东西，它不一定是库，这要从不同的应用或者硬件角度去看（从ARM方面看就是对DSP驱动的相应接口，从DSP看就是简单的通信协议实现），因为你提供的信息不足，只能讨论到这里。
可以参考下资料【双核处理器ARM+DSP如何实现协同工作 】以及【ARM+DSP双核处理器应用程序攻略】。
DSP＋ARM的工作方式，有两种方案可以选择。DSP和ARM是两颗独立的芯片；一颗芯片包含了DSP+ARM两个核，TI的Davinci和OMAP平台就是这种架构。1.如果是两个单独的芯片，DSP端算法直接做成lib库，在编译的时候链接上就行。如果是一个芯片包括两个核，TI有一套自己的算法封装模式，按照其Codec Engine要求，可以封装自己的算法2.CCS下的程序既可以在ARM上跑，也可以在DSP上跑的，看你的GEL文件引导的是ARM还是DSP。将图片放在一个目录上，CCS下程序就可以file open操作了，和你用CCS烧写程序是一样的ARM和DSP的通信，如果是两个单独的芯片，通信时可以参考HPI 通信接口。如果是应用TI Davinci或OMAP平台，会使用到DSPlink，即DSP/BIOSTM link，是基于DaVinci架构处理器的ARM与DSP端进行通信，DSPlink提供了一套通用的API，从应用层抽象出ARM与DSP的物理连接特性，从而降低用户开发程序的复杂度。Davinci或OMAP平台就如你所说的ARM下打开图片，传给DSP。总之ARM负责控制和调试，DSP负责算法。对应ARM和DSP分别是不同的指令集和编译器，可以把SOC的芯片看成是两个单芯片的合成，需要两套不同的开发工具。对于芯片的外设接口，ARM核和DSP核都可以访问，典型的情况是ARM控制所有的外设，通过OS上的驱动去控制和管理，这部分和传统的ARM芯片类似；DSP主要是进行算法加速，只是和memory打交道，为了保持芯片的资源管理的一致性，尽量避免由DSP去访问外设。当然，根据具体的应用需求，DSP也是可以控制外设接口进行数据的收发，这时，需要做好系统的管理，避免双核操作的冲突。
DSP和ARM是两颗独立的芯片；一颗芯片包含了DSP+ARM两个核，TI的Davinci和OMAP平台就是这种架构。
具体可以参考资料【双核处理器ARM+DSP如何实现协同工作】和【ARM+DSP双核处理器应用程序攻略】
